最常见的 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。

（编辑：西安站长网）

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