git 关键词 常用命令

2.2

git log --pretty=oneline
git log --pretty=format:"%h - %an, %ar : %s"
git log --pretty=format:"%h %s" --graph
 git log --pretty="%h - %s" --author=gitster --since="2008-10-01"  --before="2008-11-01" --no-merges -- t/

2.3

初始化新仓库 git init

从现有仓库克隆  git clone git://github.com/schacon/grit.git
检查当前文件状态 git status
跟踪新文件git add README
忽略某些文件
cat .gitignore
# 此为注释 – 将被 Git 忽略
*.a       # 忽略所有 .a 结尾的文件
!lib.a    # 但 lib.a 除外
/TODO     # 仅仅忽略项目根目录下的 TODO 文件，不包括 subdir/TODO
build/    # 忽略 build/ 目录下的所有文件
doc/*.txt # 会忽略 doc/notes.txt 但不包括 doc/server/arch.txt


2.4  撤消操作
修改最后一次提交  git commit --amend  重新提交：
取消已经暂存的文件git reset HEAD benchmarks.rb 

取消对文件的修改git checkout -- benchmarks.rb

2.5  远程仓库的使用
添加远程仓库 从远程仓库抓取数据 推送数据到远程仓库 
git remote add pb git://github.com/paulboone/ticgit.git
git fetch pb
git push [remote-name] [branch-name]
查看远程仓库信息
它告诉我们，运行 git push 时缺省推送的分支是什么（译注：最后两行）。它还显示了有哪些远端分支还没有同步到本地（译注：第六行的caching 分支），哪些已同步到本地的远端分支在远端服务器上已被删除（译注：Stale tracking branches 下面的两个分支），以及运行git pull 时将自动合并哪些分支（译注：前四行中列出的 issues 和 master 分支）。
 git remote show origin
* remote origin
  URL: git@github.com:defunkt/github.git
  Remote branch merged with 'git pull' while on branch issues
    issues
  Remote branch merged with 'git pull' while on branch master
    master
  New remote branches (next fetch will store in remotes/origin)
    caching
  Stale tracking branches (use 'git remote prune')
    libwalker
    walker2
  Tracked remote branches
    acl
    apiv2
    dashboard2
    issues
    master
    postgres
  Local branch pushed with 'git push'
    master:master


远程仓库的删除和重命名
修改某个远程仓库在本地的简短名称  git remote rename pb paul
注意，对远程仓库的重命名，也会使对应的分支名称发生变化，原来的 pb/master 分支现在成了 paul/master。
碰到远端仓库服务器迁移，或者原来的克隆镜像不再使用，又或者某个参与者不再贡献代码，那么需要移除对应的远端仓库，可以运行 git remote rm 命令：
git remote rm paul




2.6  打标签
列显已有的标签 git tag
新建标签  git tag -a v1.4 -m 'my version 1.4'  -m 选项则指定了对应的标签说明 用 -a  指定标签名字
查看相应标签的版本信息 git show v1.4


签署标签 git tag -s v1.5 -m 'my signed 1.5 tag' 现在再运行git show v1.5会看到对应的 GPG 签名也附在其内：
验证签署标签  git tag -v [tag-name]  需要有签署者的公钥，存放在 keyring 中，才能验证
后期加注标签  git log --pretty=oneline   git tag -a v1.2 9fceb02
分享标签 git push origin [tagname]  或者 git push origin --tags


3.2  分支的新建与合并
分支的新建与切换git branch iss53 ;git checkout iss53或者git checkout -b iss53  
删除分支git branch -d iss53
分支的合并 git merge iss53
遇到冲突时的分支合并 
如果在不同的分支中都修改了同一个文件的同一部分,Git 作了合并，但没有提交，它会停下来等你解决冲突
确认所有冲突都已解决，也就是进入了暂存区，就可以用 git commit 来完成这次合并提交
图形界面的工具来解决这些问题，不妨运行git mergetool


3.3  分支的管理
git branch --merge 查看哪些分支已被并入当前分支
 git branch --no-merged 查看尚未合并的工作：


3.5  远程分支


推送本地分支 git push origin serverfix
本地分支推送到某个命名不同的远程分支：若想把远程分支叫作awesomebranch，可以用 git push origin serverfix:awesomebranch 当你的协作者再次从服务器上获取数据时，他们将得到一个新的远程分支 origin/serverfix


值得注意的是，在 fetch 操作下载好新的远程分支之后，你仍然无法在本地编辑该远程仓库中的分支。换句话说，在本例中，你不会有一个新的serverfix 分支，有的只是一个你无法移动的 origin/serverfix 指针,如果要把该内容合并到当前分支，可以运行 git merge origin/serverfix。如果想要一份自己的 serverfix 来开发，可以在远程分支的基础上分化出一个新的分支来：git checkout -b serverfix origin/serverfix


跟踪远程分支
从远程分支 checkout 出来的本地分支，称为_跟踪分支(tracking branch)_
跟踪分支是一种和远程分支有直接联系的本地分支。在跟踪分支里输入git push，Git 会自行推断应该向哪个服务器的哪个分支推送数据。反过来，在这些分支里运行 git pull 会获取所有远程索引，并把它们的数据都合并到本地分支中来


在克隆仓库时，Git 通常会自动创建一个名为 master 的分支来跟踪 origin/master。这正是git push 和 git pull 一开始就能正常工作的原因。当然，你可以随心所欲地设定为其它跟踪分支，比如origin 上除了 master 之外的其它分支。刚才我们已经看到了这样的一个例子：git checkout -b [分支名] [远程名]/[分支名]。还可以用--track 选项简化：git checkout --track origin/serverfix 
要为本地分支设定不同于远程分支的名字，只需在前个版本的命令里换个名字：git checkout -b sf origin/serverfix


删除远程分支
如果想在服务器上删除serverfix 分支，运行下面的命令： git push origin :serverfix


3.6  分支的衍合
相对于merge,它的原理是回到两个分支最近的共同祖先，根据当前分支（也就是要进行衍合的分支 experiment）后续的历次提交对象（这里只有一个 C3），生成一系列文件补丁，然后以基底分支（也就是主干分支master）最后一个提交对象（C4）为新的出发点，逐个应用之前准备好的补丁文件，最后会生成一个新的合并提交对象（C3’），从而改写 experiment 的提交历史，使它成为 master 分支的直接下游
git checkout experiment
git rebase master
git merge experiment


衍合的风险

一旦分支中的提交对象发布到公共仓库，就千万不要对该分支进行衍合操作。

3.7 Git reset 
库的逆转与恢复除了用来进行一些废弃的研发代码的重置外，还有一个重要的作用。比如我们从远程clone了一个代码库，在本地开发后，准备提交回远程。但是本地代码库在开发时，有功能性的commit，也有出于备份目的的commit等等。总之，commit的日志中有大量无用log，我们并不想把这些 log在提交回远程时也提交到库中。 因此，就要用到git reset。 
       git reset的概念比较复杂。它的命令形式：git reset [--mixed | --soft | --hard] [<commit-ish>] 
命令的选项： 
       --mixed 这个是默认的选项。如git reset [--mixed] dev^(dev^的定义可以参见2.6.5)。它的作用仅是重置分支状态到dev1^, 但是却不改变任何工作文件的内容。即，从dev1^到dev1的所有文件变化都保留了，但是dev1^到dev1之间的所有commit日志都被清除了， 而且，发生变化的文件内容也没有通过git add标识，如果您要重新commit，还需要对变化的文件做一次git add。 这样，commit后，就得到了一份非常干净的提交记录。 （回退了index和仓库中的内容） 
       --soft相当于做了git reset –mixed，后，又对变化的文件做了git add。如果用了该选项， 就可以直接commit了。（回退了仓库中的内容） 
       --hard这个命令就会导致所有信息的回退， 包括文件内容。 一般只有在重置废弃代码时，才用它。 执行后，文件内容也无法恢复回来了。（回退了工作目录、index和仓库中的内容） 
例如： 
切换到使用的分支上； 
       git reset HEAD^ 回退第一个记录 
       git reset HEAD~2 回退第二个记录 
如果想把工作目录下的文件也回退，则使用git reset - - hard HEAD^ 回退第一个记录 
       git reset - - hard HEAD~2 回退第二个记录 
还可以使用如下方法： 
将当前的工作目录完全回滚到指定的版本号，假设如下图，我们有A-G五次提交的版本，其中C的版本号是 bbaf6fb5060b4875b18ff9ff637ce118256d6f20，我们执行了'git reset bbaf6fb5060b4875b18ff9ff637ce118256d6f20'那么结果就只剩下了A-C三个提交的版本

3.8 Git revert 
还原某次对版本的修改，例如：git revert commit_id （其中commit_id为commit代码时生成的一个唯一表示的字符串）