- 楔子
- 项目背景
- 正常的代码提交流程
- 分支管理
- 拉取代码
- 变基 vs 合并
- git stash/git stash apply stash@{index}
- git cherry-pick
- git pull —rebase/git rebase —continue
- git rebase -i/git rebase —continue
楔子
本文的有些git命令是基于我本地的git alias，如下做下解释：
[alias]
co = checkout
st = status
ci = commit
br = branch
项目背景
开发项目特别是团队协作的项目，每个项目组的人都会在本地建自己的项目分支，同时远端会有自己的repository，功能需求代码完成后会先把代码push到远端自己的相应的分支下，然后手动提交PR合到项目主线上来。
正常的代码提交流程
1. 基于zaihui/dev在本地新建一个branch，假如分支名叫做my_branch：
git fetch zaihui git co -b my_branch zaihui/dev
2. 本地分支my_branch开发，开发完成后提交代码：
git st git diff git add . git ci -m
3. 手动提交PR，将origin/my_branch合进zaihui/dev
其中，git add .和git ci -m 可以合并成git ci -am
分支管理
git br git br -v git br —merged git br -d/D
拉取代码
尽量用git fetch + git merge 少用git pull ——— 相当于先fetch再merge
变基 vs 合并
git rebase git merge
变基使得提交历史更加整洁。 你在查看一个经过变基的分支的历史记录时会发现，尽管实际的开发工作是并行的，但它们看上去就像是串行的一样，提交历史是一条直线没有分叉。
无论是通过变基，还是通过三方合并，整合的最终结果所指向的快照始终是一样的，只不过提交历史不同罢了。 变基是将一系列提交按照原有次序依次应用到另一分支上，而合并是把最终结果合在一起。
总的原则是，只对尚未推送或分享给别人的本地修改执行变基操作清理历史，从不对已推送至别处的提交执行变基操作
git stash/git stash apply stash@{index}
git stash / git stash apply stash@{index}这组命令可以使我们暂时保存当前的修改，并在之后的某个时间将代码恢复。它的用途非常广泛，而且对于提高我们的工作效率非常有帮助。它常常用于这样一种场景，当我们在一个分支上工作时修改了很多代码，但是任务还没完成，还没有到能够提交代码的程度，这时测试人员发现了一个非常严重的bug，需要我们紧急修复，这时我们怎么做呢？首先要做的就是先运行git stash命令将这些修改暂存，然后我们切换到master命令上去创建一个新的针对这个bug修复的分支，并在这个新的分支上工作。当我们完成修复工作后，我们切换回到之前的分支上，通过命令git stash stash@{index}将之前暂存的改动提取出来，继续我们的工作。
git cherry-pick
git cherry-pick
git pull —rebase/git rebase —continue
这组命令主要用于从远程代码库拉取代码到本地，主要针对在一个相同分支上的代码操作（比如master分支）。试想一下，当我们有多个人都在同一个分区上面进行代码操作时，这时候我们拉取代码时会有多少冲突，场面会有多么混乱。如果我们使用git pull或者git fetch从远程拉取代码，那么我们在提交自己新的代码时就会使得整个工作树变得非常凌乱。git pull –rebase / git rebase –continue可以很好的解决这些问题。首先我们将我们改动的代码提交到本地仓库，然后利用git pull –rebase命令将远程仓库的代码拉取到本地，它将其获取的所有的commit放在我们新提交的commit的底部，这步完成后可能会有冲突，等我们将冲突解决完成后，再利用git rebase –continue命令将解决冲突后的代码提交到之前提交的代码中去。通过这两步之后，我们整个的工作树始终会保持在一条直线上，而不会出现代码的merge分支的情况。
git rebase -i/git rebase —continue
与多人同时工作在一个相同的分支上相比，我们一般真对每个task都会新建一个对应的branch，每个人仅仅工作在自己的分支上，没有人会工作在master上，当工作完成后才会将代码提交到master上去。这样做的好处显而易见，它使得我们无须同时操作相同的分支，尤其是master的分支，从而保证了master分支的整洁与安全。那么这样做的一个关键在于我们在自己的分支上如何与master分支保持一致性。实践中，我们不应在工作切底完成之后，再与master分支同步代码，实践证明，这样会导致大量的冲突，我们应该做的是工作的每天都应该与master同步一次代码，这里仅仅是从master同步新的代码，而不应将自己的代码提交到master分支。git rebase -i master这条命令就是我们最好的工具。它不仅可以让我们当前的分支从master同步最新的代码，而且还可以将我们分支上的多个commit合并成为一个，可以让branch更简洁，毕竟branch上的代码都是为了实现一个功能。如果同步时有冲突，我们解决完冲突后，使用git rebase –continue将代码提交到先前的commit中去。有了这两条命令，我们在不同分支上的工作就会变得简单轻松。