最常见的 Git 问题和操作清单汇总

5. 分支操纵

• 行使 Git 下载指定分支呼吁为：git clone -b 分支名客栈地点
• 拉取长途新分支 git checkout -b serverfix origin/serverfix
• 归并当地分支 git merge hotfix：(将 hotfix 分支归并到当前分支)
• 归并长途分支 git merge origin/serverfix
• 删除当地分支 git branch -d hotfix：(删除当地 hotfix 分支)
• 删除长途分支 git push origin --delete serverfix
• 上传新定名的当地分支：git push origin newName;
• 建设新分支：git branch branchName：(建设名为 branchName 的当地分支)
• 切换到新分支：git checkout branchName：(切换到 branchName 分支)
• 建设并切换分支：git checkout -b branchName：(相等于以上两条呼吁的归并)
• 查察当地分支：git branch
• 查察长途客栈全部分支：git branch -a
• 当地分支重定名： git branch -m oldName newName
• 重定名长途分支对应的当地分支：git branch -m oldName newName
• 把修改后的当地分支与长途分支关联：git branch --set-upstream-to origin/newName

五、优化操纵

1. 拉代替码 pull --rebase

在团队协作进程中，假设你和你的伙伴在当地中别离有各自的新提交，而你的伙伴先于你 push 了代码到长途分支上，以是你必需先执行 git pull 来获取伙伴的提交，然后才气push 本身的提交到长途分支。

而凭证 Git 的默认计策，假如长途分支和当地分支之间的提交线图有分叉的话(即不是 fast-forwarded)，Git 会执行一次 merge 操纵，因此发生一次没意义的提交记录，从而造成了像上图那样的紊乱。

着实在 pull 操纵的时辰，，行使 git pull --rebase选项即可很好地办理上述题目。 加上 --rebase 参数的浸染是，提交线图有分叉的话，Git 会 rebase 计策来取代默认的 merge 计策。

假设提交线图在执行 pull 前是这样的：

A---B---C  remotes/origin/master 
               / 
          D---E---F---G  master 

假如是执行 git pull 后，提交线图会酿成这样：

A---B---C remotes/origin/master 
               /          
          D---E---F---G---H master 

功效多出了 H 这个没须要的提交记录。假如是执行 git pull --rebase 的话，提交线图就会酿成这样：

remotes/origin/master 
                          | 
          D---E---A---B---C---F'---G'  master 

复制代码

F G 两个提交通过 rebase 方法从头拼接在 C 之后，多余的分叉去掉了，目标到达。

小结

大大都时辰，行使 git pull --rebase是为了使提交线图更悦目，从而利便 code review。

不外，假如你对行使 git 还不黑白常纯熟的话，我的提议是 git pull --rebase多操练屡次之后再行使，由于 rebase 在 git 中，算得上是『伤害举动』。

其它，还需留意的是，行使 git pull --rebase比直接 pull 轻易导致斗嘴的发生，假如预期斗嘴较量多的话，提议照旧直接 pull。

留意：

git pull = git fetch + git merge  
git pull --rebase = git fetch + git rebase 

2. 合代码 merge --no-ff

上述的 git pull --rebase 计策目标是修整提交线图，使其形成一条直线，而即将要用到的 git merge --no-ff 计策偏偏是反行其道，决心地弄出提交线图分叉出来。

假设你在当地筹备归并两个分支，而恰恰这两个分支是 fast-forwarded 的，那么直接归并后你获得一个直线的提交线图，虽然这样没什么弊端，但假如你想更清楚地汇报你伙伴：这一系列的提交都是为了实现统一个目标，那么你可以决心地将这次提交内容弄成一次提交线图分叉。

执行 git merge --no-ff 的功效或许会是这样的：

中间的分叉线路图很清楚的表现这些提交都是为了实现 complete adjusting user domains and tags

更进一步

每每我的风俗是，在归并分支之前(假设要在当地将 feature 分支归并到 dev 分支)，会先搜查 feature 分支是否『部门落伍』于长途 dev 分支：

git checkout dev 
git pull # 更新 dev 分支 
git log feature..dev 

假如没有输出任何提交信息的话，即暗示 feature 对付 dev 分支是 up-to-date 的。假若有输出的话而顿时执行了 git merge --no-ff 的话，提交线图会酿成这样：

以是这时在归并前，凡是我会先执行：

git checkout feature 
git rebase dev 

这样就可以将 feature 从头拼接到更新了的 dev 之后，然后就可以归并了，最终获得一个干净惬意的提交线图。

再次提示：像之条件到的，rebase 是『伤害举动』，提议你足够认识 git 时才这么做，不然的话是得不偿失啊。

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!