下面是小编帮大家整理的最简单的 Git 使用流程，本文共8篇，希望对大家带来帮助，欢迎大家分享。
篇1：最简单的 Git 使用流程
假设你的资料库默认分支为 master，当你有一个新的项目或者想法时，创建一个分支，然后在分支上开发，最后再合并到 master 上，
创建新分支并命名，此处我们创建名为 new_stuff 的分支
git branch new_stuff
移到新分支上
git checkout new_stuff
开始你的工作并保存结果
各种工具.....
添加所改动的文件以便提交
git add .
提交改动
git commit -m “made some changes”
回到 master 主分支
git checkout master
合并到主分支
git merge new_stuff
git branch 可显示所有的分支
删除分支
git branch -d new_stuff
结束！
篇2：ubuntu git 安装和使用
apt-get install git-core
2.那通过命令更新版本库
git clone git://git.kernel.org/pub/scm/git/git.git
3.创建一个新版本库
mkdir gittutorch
cd gitturtorch
git-init-db
这样，一个空的版本库就创建好了，并在当前目录中创建一个叫 .git 的子目录，你可以用 ls -a 查看一下，并请注意其中的三项内容：
一个叫 HEAD 的文件，我们现在来查看一下它的内容：
$ cat .git/HEAD
现在 HEAD 的内容应该是这样：
ref: refs/heads/master
我们可以看到，HEAD 文件中的内容其实只是包含了一个索引信息，并且，这个索引将总是指向你的项目中的当前开发分支。
一个叫 objects 的子目录，它包含了你的项目中的所有对象，我们不必直接地了解到这些对象内容，我们应该关心是存放在这些对象中的项目的数据。
一个叫 refs 的子目录，它用来保存指向对象的索引。
具体地说，子目录 refs 包含着两个子目录叫 heads 和 tags，就像他们的名字所表达的意味一样：他们存放了不同的开发分支的头的索引, 或者是你用来标定版本的标签的索引。
请注意：master 是默认的分支，这也是为什么 .git/HEAD 创建的时候就指向 master 的原因，尽管目前它其实并不存在。 git 将假设你会在 master 上开始并展开你以后的工作，除非你自己创建你自己的分支。
另外，这只是一个约定俗成的习惯而已，实际上你可以将你的工作分支叫任何名字，而不必在版本库中一定要有一个叫 master 的分支，尽管很多 git 工具都认为 master 分支是存在的。
现在已经创建好了一个 git 版本库，但是它是空的，还不能做任何事情，下一步就是怎么向版本库植入数据了。
第四步：植入内容跟踪信息：git-add：
为了简明起见，我们创建两个文件作为练习：
$ echo “Hello world” >hello
$ echo “Silly example” >example
我们再用 git-add 命令将这两个文件加入到版本库文件索引当中：
$ git-add hello example
git-add 实际上是个脚本命令，它是对 git 内核命令 git-update-index 的调用。因此上面的命令和下面的命令其实是等价的：
$ git-update-index --add hello example
如果你要将某个文件从 git 的目录跟踪系统中清除出去，同样可以用 git-update-index 命令。例如：
$ git-update-index --force-remove foo.c
git-add 可以将某个目录下的所有内容全都纳入内容跟踪之下，例如： git-add ./path/to/your/wanted 。但是在这样做之前，应该注意先将一些我们不希望跟踪的文件清理掉，例如，gcc 编译出来的 *.o 文件，vim 的交换文件 .*.swp 之类。
应该建立一个清晰的概念就是，git-add 和 git-update-index 只是刷新了 git 的跟踪信息，hello 和 example 这两个文件中的内容并没有提交到 git 的内容跟踪范畴之内。
第五步：提交内容到版本库：git-commit
既然我们刷新了 Git 的跟踪信息，现在我们看看版本库的状态：
$ git-status
我们能看到 git 的状态提示：
#
# Initial commit
#
#
# Updated but not checked in:
# (will commit)
#
# new file: example
# new file: hello
#
提示信息告诉我们版本库中加入了两个新的文件，并且 git 提示我们提交这些文件，我们可以通过 git-commit 命令来提交：
$ git-commit -m “Initial commit of gittutor reposistory”
第六步：查看当前的工作：git-diff
git-diff 命令将比较当前的工作目录和版本库数据库中的差异，
现在我们编辑一些文件来体验一下 git 的跟踪功能。
$ echo “It's a new day for git” >>hello
我们再来比较一下，当前的工作目录和版本库中的数据的差别。
$ git-diff
差异将以典型的 patch 方式表示出来：
diff --git a/hello b/hello
index 802992c..8fdaa4e 100644
--- a/hello
+++ b/hello
@@ -1 +1,2 @@
Hello world
+It's a new day for git
此时，我们可以再次使用组合命令 git-update-index 和 git-commit 将我们的工作提交到版本库中。
$ git-update-index hello
$ git-commit -m “new day for git”
实际上，如果要提交的文件都是已经纳入 git 版本库的文件，那么不必为这些文件都应用 git-update-index 命令之后再进行提交，下面的命令更简捷并且和上面的命令是等价的。
$ git-commit -a -m “new day for git”
一些命令：
初始化git数据库
$ git-init-db
添加文件
$ git-add hello.c
查看修改、提交记录
$ git-log
创建分支
$ git-branch roredu
查看分支
$ git-branch
* master
roredu
切换工作分支
$ git-checkout roredu
Switched to branch “roredu”
$ git-branch
master
* roredu
提交到当前工作分支并书写标记。
$ git-commit -a
创建xux分支对于master的补丁文件。
$ git-format-patch master roredu
配置开发者自己的签名和email。
$ git-config --global user.name “roredu”
$ git-config --global user.email “roredu@gmail.com”
修改文件名
$ git-mv roredu.c helight.c
删除文件
$ git-rm roredu.c
协同工作，下载项目：
git-clone ssh@wtb:192.168.0.21/home/wtb/NetBeansProjects/project1
这里wtb是用户名， 192.168.0.21是项目所在机器的IP 后面跟着的是项目目录和名称
篇3：使用git部署站点
我最开始的时候迁移站点都是傻乎乎的用FTP一个文件一个文件上传，一个wordpress需要半小时，而且容易中断，后来damao告诉我用wget这个神器，就发现其实可以通过SSH在服务器端直接做一些操作，速度非常快，
最近一段时间越来越喜欢用git来管理代码，而且代码变化越来越块越来越多，现在的工作流不再合适。因为版本管理和代码部署脱节了——使用git来管理版本，更新了代码之后，还需要其他工具来把代码同步到服务器，这就很冗余了，所以我尝试用git直接把代码push到服务器。
在服务器上的设置：
首先需要一个支持SSH的服务器，比如miao.in，在终端中输入命令：
cd /var/www/yoursite
git init .
git config receive.denyCurrentBranch ignore git
config --bool receive.denyNonFastForwards false
cd .git/hooks
wget utsl.gen.nz/git/post-update
chmod +x post-update
在本地git中配置：
[remote “prod”] url = your-ssh-username@your-host:/var/www/yoursite/.git
对应的git命令是：
$ git remote add prodyour-ssh-username@your-host:/var/www/yoursite/.git
这样就算配置完成了，如果要把本地git的代码推送到服务器，命令是：
$ git push prod master
master对应你自己的分支的名字就好，prod的意思是product，
FAQ
utsl.gen.nz/git/post-update是干嘛的？
在git的hooks文件夹可以配置一些钩子，这些钩子在git特定操作的时候被触发，post-update就是这样一种钩子，当push发生的时候，它会在远程代码仓库执行操作。所以我们用wget把这个post-update放到本地覆盖。
我不用git init，而用git clone可以吗？
没问题，但是还是要完成接下来的配置操作。
为啥push成功之后，代码没有生效？
远程的git已经拥有所有的版本信息，但对应的HEAD节点还没有跟当前文档对应，你可以用SSH登录远程服务器之后git checkout master（或者你的分支），之后就无需再次checkout了。
本地的配置文件跟服务器配置文件不一样，怎么办？
善用.gitignore。
还有问题？
多多使用以下命令来检查git状态：
git status
git log –pretty=oneline
git remote
git branch
还有问题请google、stackoverflow……
最后有问题，请留言。
篇4：理解Git的工作流程
如果你不理解 Git 的设计动机，那你就会处处碰壁，知道足够多的命令和参数后，你就会强行让 Git 按你想的来工作，而不是按 Git 自己的方式来。这就像把螺丝刀当锤子用；也能把活干完，但肯定干的差极了，花费很长时间，还会弄坏螺丝刀。
想想常见的 Git 工作流程是怎么失效的吧。
从 Master 创建一个分支，写代码，然后把这个分支合并回 Master。
多数时候这样做的效果会如你所愿，因为从你创建分支到合并回去之间，Master 一般都会有些变动。然后，有一天当你想把一个功能（feature）分支合并进 Master 的时候，而 Master 并没有像以往那样有变动，问题来了：这时 Git 不会进行合并 commit，而是将 Master 指向功能分支上的最新 commit。（看图）
不幸的是，你的功能分支有用来备份代码的 commit（作者称之为 checkpoint commit），这些经常进行的 commit 对应的代码可能处于不稳定状态！而这些 commit 现在没法和 Master 上那些稳定的 commit 区分开来了。当你想回滚的时候，很容易发生灾难性后果。
于是你就记住了：“当合并功能分支的时候，加上 -no-ff 选项强制进行一次全新的 commit。”嗯，这么做好像解决问题了，那么继续。
然后一天你在线上环境中发现了一个严重 bug，这时你需要追溯下这个 bug 是什么时候引入的。你运行了 bisect 命令，但却总是追溯到一些不稳定的 commit。因此你不得不放弃，改用人肉检查。
最后你将 bug 范围缩小到一个文件。你运行 blame 命令查看这个文件在过去 48 小时里的变动。然后 blame 告诉你这个文件已经好几周没有被修改过了――你知道根本不可能没有变动。哦，原来是因为 blame 计算变动是从第一次 commit 算起，而不是 merge 的时候。你在几周前的一次 commit 中改动了这个文件，但这个变动今天才被 merge 回来。
用 no-ff 来救急，bisect 又临时失效，blame 的运作机制又那么模糊，所有这些现象都说明一件事儿，那就是你正在把螺丝刀当锤子用。
反思版本控制
版本控制的存在是因为两个原因。
首先，版本控制是用来辅助写代码的。因为你要和同事同步代码，并经常备份自己的代码。当然了，把文件压缩后发邮件也行，不过工程大了大概就不好办了。
其次，就是辅助配置管理工作。其中就包括并行开发的管理，比如一边给线上版本修复 bug，一边开发下一个版本。配置管理也可以帮助弄清楚变动发生的具体时间，在追溯 bug 中是一个很好的工具。
一般说来，这两个原因是冲突的。
在开发一个功能的时候，你应该经常做备份性的 commit。然而，这些 commit 经常会让软件没法编译。
理想情况是，你的版本更新历史中的每一次变化都是明确且稳定的，不会有备份性 commit 带来的噪声，也不会有超过一万行代码变动的超大 commit。一个清晰的版本历史让回滚和选择性 merge 都变得相当容易，而且也方便以后的检查和分析。然而，要维护这样一个干净的历史版本库，也许意味着总是要等到代码完善之后才能提交变动。
那么，经常性的 commit 和干净的历史，你选择哪一个？
如果你是在刚起步的创业公司中，干净的历史没有太大帮助。你可以放心地把所有东西都往 Master 中提交，感觉不错的时候随时发布。
如果团队规模变大或是用户规模扩大了，你就需要些工具和技巧来做约束，包括自动化测试，代码检查，以及干净的版本历史。
功能分支貌似是一个不错的折中选择，能够基本的并行开发问题。当你写代码时候，可以不用怎么在意集成的问题，但它总有烦到你的时候。
当你的项目规模足够大的时候，简单的 branch/commit/merge 工作流程就出问题了。缝缝补补已经不行了。这时你需要一个干净的版本历史库。
Git 之所以是革命性的，就是因为它能同时给你这两方面的好处。你可以在原型开发过程中经常备份变动，而搞定后只需要交付一个干净的版本历史。
工作流程
考虑两种分支：公共的和私有的。
公共分支是项目的权威性历史库。在公共分支中，每一个 commit 都应该确保简洁、原子性，并且有完善的提交信息。此分支应该尽可能线性，且不能更改。公共分支包括 Master 和发行版的分支。
私有分支是供你自己使用的，就像解决问题时的草稿纸。
安全起见，把私有分支只保存在本地。如果你确实需要 push 到服务器的话（比如要同步你在家和办公室的电脑），最好告诉同事这是私有的，不要基于这个分支展开工作。
绝不要直接用 merge 命令把私有分支合并到公共分支中。要先用 reset、rebase、squash merges、commit amending 等工具把你的分支清理一下。
把你自己看做一个作者，每一次的 commit 视为书中的一章。作者不会出版最初的草稿，就像 Michael Crichton 说的，“伟大的书都不是写出来――而是改出来的”，
电脑资料
如果你没接触过 Git，那么修改历史对你来说好像是种禁忌。你习惯于认为提交过的所有东西都应该像刻在石头上一样不能抹去。但如果按这种逻辑，我们在文本处理软件器中也不应该使用“撤销”功能了。
实用主义者们直到变化变为噪音的时候才关注变化。对于配置管理来说，我们关注宏观的变化。日常 commit（checkpoint commits）只是备份于云端的用于“撤销”的缓冲。
如果你保持公共历史版本库的简洁，那么所谓的 fast-forward merge 就不仅安全而且可取了，它能保证版本变更历史的线性和易于追溯。
关于 -no-ff 仅剩的争论就只剩“文档证明”了。人们可能会先 merge 再 commit，以此代表最新的线上部署版本。不过，这是反模式的。用 tag 吧。
规则和例子
根据改变的多少、持续工作时间的长短，以及分支分叉了多远，我使用三种基本的方法。
1）短期工作
绝大多数时间，我做清理时只用 squash merge 命令。
假设我创建了一个功能分支，并且在接下来一个小时里进行了一系列的 checkpoint commit。
git checkout -b private_feature_branchtouch file1.txtgit add file1.txtgit commit -am“WIP”
完成开发后，我不是直接执行 git merge 命令，而是这样：
git checkout mastergit merge --squash private_feature_branchgit commit -v
然后我会花一分钟时间写个详细的 commit 日志。
2）较大的工作
有时候一个功能可以延续好几天，伴有大量的小的 commit。
我认为这些改变应该被分解为一些更小粒度的变更，所以 squash 作为工具来说就有点儿太糙了。（根据经验我一般会问，“这样能让阅读代码更容易吗？”）
如果我的 checkpoint commits 之后有合理的更新，我可以使用 rebase 的交互模式。
交互模式很强大。你可以用它来编辑、分解、重新排序、合并以前的 commit。
在我的功能分支上：
git rebase --interactive master
然后会打开一个编辑器，里边是 commit 列表。每一行上依次是，要执行的操作、commit 的 SHA1 值、当前 commit 的注释。并且提供了包含所有可用命令列表的图例。
默认情况下，每个 commit 的操作都是“pick”，即不会修改 commit。
pick ccd6e62 Work on back buttonpick 1c83feb Bug fixespick f9d0c33 Start work on toolbar
保存并退出，会弹出一个新的编辑器窗口，让我为本次合并 commit 做注释。就这样。
git checkout mastergit merge --squash private_feature_branchgit commit -v
舍弃分支
也许我的功能分支已经存在了很久很久，我不得不将好几个分支合并进这个功能分支中，以便当我写代码时这个分支是足够新的的。版本历史让人费解。最简单的办法是创建一个新的分支。
git checkout mastergit checkout -b cleaned_up_branchgit merge --squash private_feature_branchgit reset
现在，我就有了一个包含我所有修改且不含之前分支历史的工作目录。这样我就可以手动添加和 commit 我的变更了。
总结
如果你在与 Git 的默认设置背道而驰，先问问为什么。
将公共分支历史看做不可变的、原子性的、容易追溯的。将私有分支历史看做一次性的、可编辑的。
推荐的工作流程是：
基于公共分支创建一个私有分支。
经常向这个私有分支 commit 代码。
一旦你的代码完善了，就清理掉下私有分支的历史。
将干净的私有分支 merge 到公共分支中。
英文原文：Understanding the Git workflow 编译： 张重骐
来自: blog.jobbole.com
篇5：在VisualStudio中使用GIT
GIT作为源码管理的方式现在是越来越流行了，在VisualStudio 中，就通过插件的现实对GIT进行了官方支持，并且这个插件在VS中已经转正，本文在这里简单的介绍一下如何在Visual Studio中使用GIT进行源码管理。
PS: 由于篇幅所限，本文并没有对相关基础知识进行介绍，在读取本文前，假定你已经对GIT有一定的了解，并且对VisualStudio的团队管理器比较熟悉，后续有时间的话再进行相关知识的介绍。
将项目添加到GIT源码管理
将项目添加到GIT源码管理和通过TFS管理方式一样，直接在解决方案的右键菜单中点取即可。
和之前不同的是，此时会出现一个对话框会让你选择使用传统的TFS方式还是GIT方式来管理，这里选择Git。
选择完后，我们就可以在团队资源管理器中看到项目已经被托管起来，并且已经新建你一个master的分支。
安装第三方Git工具
从上面的截图我们也可以看到，团队管理器视图会提示你安装第三方Git工具。虽然不安装也可以使用，但是VisualStudio中集成的功能是比较少的（就目前来看，是不够用的），如果要使用其它的功能，则需要通过第三方Git工具来实现。
安 装方式比较简单，直接按照提示不停的下一步即可，这里就不多介绍了。系统自己带的是Git For Windows，带一个命令行和一个GUI程序，命令行可以在VS中直接启动，比较方便。你也可以自己安装其它的工具，第三方工具和系统自带的Git不冲 突，可以同时使用。
提交更改
从团队管理器中我们可以看到，对于Git的操作分包括更改、分支、提交三种。当我们把项目加入源码管理后，首先就是需要提交我们的修改，这里使用的是“更改”功能，而不是“提交”（“提交”页面是进行发布到Git服务器管理的）。进入提交页面后，操作界面如下：
首次使用时需要配置用户名和密码，这个是全局设置，
然后输入提交消息，点击提交按钮即可提交了。提交完成后，额可以到分支页面查看所有提交的历史记录。
创建分支
创建分支比较简单，直接点击新分支链接，选择源分支，输入名称即可：
切换分支
创建分支后，系统便自动切换到新分支上 ，此时我们的修改都是在新分支上进行。
如果要切换分支，直接在分支页面双击相应的分支即可，选中的分支高亮显示，同时代码也会自动切换到相应的分支，非常方便。
合并分支
分支修改完成后，往往会将其合并到主线上，点击合并链接，选择相应的分支，点击合并按钮即可。
发布到Git服务器
本地修改完成后，需要将其发布到Git服务器，以供备份和项目其它成员分享。发布的方法也比较简单：
进入“提交”页面
选择要发布的分支
输入Git仓库的URL
点击发布按钮
首次发布时会出现一个对话框提示输入Git仓库的身份认证信息。
和Git服务器同步修改
和Git服务器同步修改的常用命令后fetch、push、pull，在VisualStudio中也有对其进行支持，这里就不多介绍了。
如果你嫌麻烦的话，甚至可以直接点击同步按钮，一次性完成所有操作。
克隆Git仓库
对于非项目创建者的团队成员来说，首先的一步就是克隆Git仓库。操作方式如下：首先在团队管理器窗口中选择“连接到团队项目”，选择“ 克隆”链接，输入远程Git库的URL和本地路径，点击克隆按钮即可。
来自：www.cnblogs.com/TianFang/p/3345038.html
篇6：GoogleCode的git使用小记
早先就知道 GoogleCode 支持 git，不过一直没时间体验，近期实在受不了频繁的 svn commit 加上公司的联通网络访问 GoogleCode 实在是慢得让人无法忍受，于是咬咬牙想把 GoogleCode 中那陈年的代码迁移到 git 控制中。
总得来讲，设置 GoogleCode 项目中新的版本控制方案并不复杂，只需要在管理中点击需要的版本控制系统就行。不过令人失望的是 GoogleCode 并没有自动转换成你需要的版本控制系统 -- 可能这点要求有点高，或许可能是 GoogleCode 出于代码安全方面的考虑。
登录验证不同于 GitHub 等使用 ssh 密钥（又有点小失望），它使用 .netrc 规则（出于安全考虑，尽量将这个文件的属性设置为 600）。
PS，Windows 用户可以将同内容文件更名为 _netrc 然后放到 %HOME% 目录中。下面的命令可以让你得知你的 %HOME% 目录在哪：
echo %HOME%
设置验证完成后，就可以进行 git 的 clone 或者 push 等操作了，
这里还得提醒下的就是 wiki 和项目代码两个 clone 是分开的，虽然这并不是什么问题，但我更愿意是像 GitHub 一样是两条分支。
可能先前大家在 GoogleCode 上已经有 svn 控制的代码了，那么你一定想如何将 svn 控制的代码导入到 git 中，那么这篇文章可以帮助你。
值得注意的是，GoogleCode 上每个版本控制系统是独立的，这意味着即便你在后台选择了使用 git 作为版本控制系统，其实老的 svn 路径还是可以正常使用的。
总得来讲，相对 GoogleCode，我更喜欢 GitHub 多一点。甚至我还专门从 GoogleCode 中迁移了部分项目代码到 GitHub 上。不过相对 GitHub 而言，GoogleCode 的社会化属性相对少些，这或许对于开发者而言可以将更多的精力投入在开发中。
那么，到底爱 GoogleCode 还是 GitHub？既然用 git 了，这说明其实我只是不爱将鸡蛋放在一个篮子里而已 :^)
-- EOF --
篇7：《版本控制之道--使用Git》笔记
我认为每个学过Git的人都应该做过类似这种笔记，因为Git命令太多看着看着就把前边看过的忘了，之前我也看过Git，但是一直没用，现在一看几乎没有印象了，所以这次我要把我看到的命令记下来给我自己备忘，
Git已经是最流行的版本控制系统了，网上相关的免费学习资源很多，我见过的中文书籍就有：
Git Community Book 中文版
Pro Git 中文版
Git Magic 中文版
但我是买的一本纸质书叫做《版本控制之道—使用Git》，下边是我记录的几乎是整本书讲过的所有命令：
设置
git config —global user.name “Nshen” //必须
git config —global user.email “nshen121@gmail.com” //必须
git config —global color.ui “always” //或者“auto”, always不仅Base环境是彩色，Dos里也是彩色的。
git config —global core.editor notepad.exe //设为windows记事本
git config —global alias.ci “commit” //别名缩写
git config —global merge.tool //可以设置合并工具
git config —global —list //查看设置
其实最后这些设置都保存在C:\Documents and Settings\用户名\.gitconfig 文件下（windows）
查看帮助： git help command
初始化 :
git init
纳入版本控制:
git add *.txt //添加所有txt文件
git addREADME//添加单个文件
git add . //添加所有文件包括子目录，但不包括空目录
add命令是个多功能命令，根据目标文件的状态不同，此命令的效果也不同：可以用它开始跟踪新文件，或者把已跟踪的文件放到暂存区，还能用于合并时把有冲突的文件标记为已解决状态等）注意每次修改后都要重新add,不然就会提交之前add时的版本。
git add -i //进入交互式add
git add -p //直接进入补丁模式，可以暂存修改的一部分。
提交：
git commit -m “initial project version”
git commit -m “something” someFile //提交指定文件
git commit -CHEAD-a —amend //复用HEAD留言，增补提交（修改小错误，而不增加提交记录，掩盖自己的小马虎）
参数:
-m “提交的说明”
-a 动把所有已经跟踪过的文件暂存,并提交.(工作目录中修改过的文件都提交到版本库，不需一个一个手动add了)
—amend 增补提交
-C 复用指定提交的提交留言
-c 打开编辑器在已有的提交基础上编辑修改
e.g 修改最后一次提交:
git commit -m 'initial commit'git add forgotten_filegit commit --amend
如果没有修改就相当于更改提交说明,上边3个命令得到一个提交.
忽略提交的文件：
所有人都需要忽略的文件要写在.gitignore文件里，而只有自己的个人偏好需要忽略的文件要写在.git/info/exclude文件中
语法：
#此为注释 – 将被 Git 忽略*.a # 忽略所有 .a 结尾的文件!lib.a # 但 lib.a 除外*.[oa] #忽略以.o或.a结尾的文件*~#忽略以~结尾的文件/TODO # 仅仅忽略项目根目录下的 TODO 文件，不包括 subdir/TODObuild/ # 忽略 build/ 目录下的所有文件doc/*.txt # 会忽略 doc/notes.txt 但不包括 doc/server/arch.txt
查看文件改动：
git diff // 比较工作目录与缓存区的区别
git diff —cached 或者 git diff —staged //缓存区与版本库里的区别
git diffHEAD//三者的区别
请注意，单单 git diff 不过是显示还没有暂存起来的改动，而不是这次工作和上次提交之间的差异。所以有时候你一下子暂存了所有更新过的文件后，运行 git diff 后却什么也没有，就是这个原因。
git diff 18f822e //18f822e这个版本与当前目录的区别
git diff aaaaa..bbbbb //比较aaaaa与bbbbb之间差别
git diff —stat可以统计数据，比较特别的命令
重命名，移动，删除文件：
git mv file_from file_to //改名或移动
$git mv README.txt README$git status#On branch master#Your branch is ahead of'origin/master'by 1 commit.##Changes to be committed:#(use“git reset HEAD
其实，运行 git mv 就相当于运行了下面三条命令：
$ mvREADME.txtREADME
$ git rmREADME.txt
$ git addREADME
必须调用 git rm 文件名 //从暂存区移除,并且文件也被删除
如果只是手工删除了文件,运行git status时会出现
#Changed but not updated:#(use“git add/rm
此时必须再运行 git rm 文件名,才会在提交时候不再纳入版本管理.
如果删除之前修改过并且已经add到缓存区了的话,则必须强制删除 -f
另外一种情况是，我们想把文件从Git仓库中删除（亦即从暂存区域移除），但仍然希望保留在当前工作目录中。换句话说，仅是从跟踪清单中删除。比如一些大型日志文件或者一堆.a编译文件，不小心纳入仓库后，要移除跟踪但不删除文件，以便稍后在 .gitignore 文件中补上，用 —cached 选项即可：
查看状态：
查看当前状态:
git status
$git status#On branch master#Changes to be committed: //只要在这行后边的,说明放入暂存区了#(use“git reset HEAD
查看提交历史:
git log
这时“j”向下浏览，“k”向上浏览，“q”退出
git log —pretty=oneline //一行显示
—pretty=“%h %s” //以各种格式输出
git log –p -2 //-p显示每次提交的内容差异 -2表示最近2次更改
git log —since “5 hours”
—since “3 hours”
—since “1 minute”
—before =“-10.01”
git log 27j34j3j..03u43u23 //最老版本..最新版本（不包括起点只包括终点）
git log 34j4j4..HEAD
git log fhfs8fh.. //省略HEAD
git log “HEAD^^”..“HEAD^” //windows必须加引号表示回溯上一个提交
git log -1HEAD~1 //相当于git log -1HEAD^
问责：查明谁修改了代码
git blame hello.html //你也可以用“-L”参数在命令(blame)中指定开始和结束行:
git blame -L 12,+10 hello.html //12到22行
blame还可以跟踪内容复制，文件复制，略，见版本控制之道 79页
撤销：
撤销缓存区的修改（没有commit的）
git checkout head 文件名 //撤销暂存区的修改
git checkout head readme.txt todo.txt
git checkout head *.txt
git checkout head . //撤销所有
反转提交：
git revertHEAD//创建一个反向的新提交抵消原来的提交改动
如果需要反转多个，必须从最后的开始反转, 加 -n可以不马上提交，之后一起提交，
git revert -nHEAD
git revert -n 54efhds
git commit -m “revert head and 54efhds”
复位：还没有commit，让工作目录回到上次提交时的状态
git reset —hardHEAD//所有未提交的内容清空，这会让“git diff” 和“git diff —cached”命令的显示法都变为空
git reset —softHEAD//复位版本库，暂存差异，便于提交中发现错误需要更改时有用（例如私人密码放到里边了）
分支：
在当前分支末梢建立分支：
git branch RB_1.0（建立分支不会自动切换过去）
切换分支：
git checkout RB_1.0（切换到RB_1.0分支）
创建并切换分支：
git checkout -b RB_1.0（简化上边2步操作）
删除分支：
git branch -d RB_1.0
基于某次提交、分支或标签创建新分支:
git branch RB_1.0 master
git branch RB_1.0 6fe57de0
git branch Rb_1.01 1.0
查看分支：
git branch //列出本地分支iss53* master //*号表示当前所在分支testing
git branch -r //显示远程分支
git branch -a //列出所有分支
分支重命名：
git branch -m master mymaster
-M 大写M会覆盖同名的分支
合并分支：
直接合并：
git merge 想合并到当前分支的源分支名
git merge —no-commit 分支 //合并但不提交
压合合并：将分支压合成一条commit记录，并合并过来
git merge —squash 某bug分支
git commit -m “修复某bug”
拣选合并：只合并一个提交
git cherry-pick 321d76f
如果需要连续拣选，就需要加 -n参数
然后再git commit ，但不要加-m参数，编辑器就会使用刚拣选的提交留言作为现在的留言。
标签Tag:
查看标签:
git tag
创建标签：
git tag 1.0 //在当前分支最后一次提交创建标签
git tag 1.0 RB_1.0 //基于RB_1.0分支的最新踢脚创建标签
git tag 1.0 ae468d8kt //为某次提交创建标签
检出标签：
git checkout 1.0 //检出标签与检出分支一样操作，但检出标签后用git branch查看本地分支会发现你现在不再任何分支上
这时你不应该修改，而应该立即基于此标签创建一个分支
git checkout -b from-1.0
变基：
1）git rebase RB_1.01 //也许修改过一个bug，希望新版本变基到RB_1.01分支上
2）手动解决冲突 //如果解决不了直接git rebase-skip或-abort来跳过特定提交或完全放弃变基
3）git add xxx.html //冲突解决
4）git rebase —continue
git rebase --onto HEAD^^ HEAD^ HEAD
//—onto参数可以改写历史抹掉中间的参数，将倒数第一个参数变基到倒数第3个参数，为防止出错建议在试验性分支上先试验。
rebase -i 可以排序历史记录，多个提交合并为1个，一个提交分解成多个提交 ，
详见版本控制之道p86 ，需要编辑器支持，windows记事本不行
远程相关：
git clone git://github.com/schacon/grit.git //从现有仓库克隆
git clone git://github.com/schacon/grit.git mygrit //换名,唯一区别就是新建的目录成了mygrit,其他都一样
添加远程仓库:
git remote add pb git://github.com/paulboone/ticgit.git
clone会默认添加origin仓库，如果原本用git init创建的版本库，后来又想提交到远程版本库，就可以用下边的办法
git remote add origin git@example.com:/xxxxxx
查看远程分支：
git remote -v //查看远程仓库,默认clone后,应该有一个origin仓库,-v显示对应的clone地址
git remote show origin //查看远程仓库信息
远程仓库重命名和删除:
git remote rename pb paul
git remote rm paul
获取数据：
git fetch [remote-name] 拉取远程仓库到本地远程仓库,不自动合并 //$ git fetch origin$git fetch pbremote: Counting objects: 58, done.remote: Compressing objects: 100% (41/41), done.remote: Total 44 (delta 24), reused 1 (delta 0)Unpacking objects: 100% (44/44), done.From git://github.com/paulboone/ticgit* [new branch]master ->pb/master* [new branch]ticgit ->pb/ticgit
现在pb/master可以在本地访问了,你可以合并到自己的某个分支,或者切换到这个分支看看有什么有趣的更新
git pull 抓取数据合并到工作目录中当前分支
推送数据：
git push [remote-name] [branch-name] //默认为 git push origin master
git push origin serverfix //推送分支，其实是下边一句的简化,提取我的 serverfix 并更新到远程仓库的 serverfix
git push origin serverfix:serferfix
git push origin :serverfix //这个语法用于删除,只要把分号前留空
其他：
git gc //垃圾回收，每隔一段时间例如一个月运行一次可以减少磁盘占用空间。
git reflog //最后的保障,列出误删的东东
git bisect //二分查找，版本控制之道p124页，略
归档版本库，导出压缩包:
git archive —format=格式 —prefix=目录/ 版本>压缩包.zip
git archive —format=zip head>test.zip
git archive —format=tar —prefix=mysite-1.0/ 1.0 | gzip>mysite-1.0.tar.gz
git archive —format=zip —prefix=mysite-1.0/ 1.0 >mysie-1.0.zip
篇8：Ubuntu系统如何安装和配置Git使用Git
Git是免费的分布式版本控制系统，能够帮忙Linux内核开发，在Ubuntu系统中要如何安装和配置Git以及对Git的使用，下面为大家详细介绍下
一、Git安装：
1、二进制方式安装：
$ sudo apt-get install git-core
安装完成后，在终端中输入 git 就可以看到相关的命令了。如果只是需要使用git来管理本地的代码，那么现在 就 可 以使用了。如果需要和github上的项目结合，还需要做其他的一些操作。
2、github帐号的申请
如果只是需要将github上感兴趣的代码拷贝到本地，自己进行修改使用，而不打算共享发布的话，其实不申请 帐号也没有关系，只需要 git clone 代码到本地就可以了。 $ git clone git:// IP work（工作目录名）。
毕竟使用 github 就是为了开源的目的，首先去 github.com 上注册一个帐号。
3、在本地建立一个文件夹，然后做一些全局变量的初始化
$ git config --global user.name = “用户名或者用户ID”
$ git config --global user.email = 邮箱
这两个选项会在以后的使用过程中自动添加到代码中。
4、创建验证用的公钥
这个是比较复杂和困扰大多数人的地方，因为 git 是通过 ssh 的方式访问资源库的，所以需要在本地创建验证 用的文件，
使用命令：$ ssh-keygen -C ‘you email address@gmail.com’ -t rsa会在用户目录 ~/.ssh/ 下建立相应 的密钥文件。可以使用 $ ssh -v git@github.com 命令来测试链接是否畅通。
5、上传公钥
在 github.com 的界面中 选择右上角的 Account Settings，然后选择 SSH Public Keys ，选择新加。
Title 可以随便命名，Key 的内容拷贝自 ~/.ssh/id_rsa.pub 中的内容，完成后，可以再使用 ssh -v git@github.com 进行测试。看到下面的信息表示验证成功。
二、Git配置与使用
利用 github 来管理自己的项目，可以按照下面的步骤进行
1、建立仓库
在需要建立项目的文件夹中，使用 git init 进行仓库的建立。完成后，可以看到文件家中多了一个 .git 隐藏目 录。
2、添加文件
使用 git add 。 来进行初始文件的添加。这里 。 表示将文件夹下所有的文件都添加进去，我们也可以指定文件进 行添 加。
3、提交文件
使用 git commit -m ‘comment’ 提交，可以将编辑的内容进行提交。
4、删除或增加github远程来源
git remote add origin github.com/Git-Elite/CodeBase.git //蓝色部分为github托管的仓库地址
5、提交至github仓库
git push -u origin master
上面就是Ubuntu安装和配置Git的方法介绍了，在使用Git前，需要先建立一个github仓库，之后就能使用git管理Linux项目了。
文档为doc格式
