0X00 怎样正确使用分支
通常情况下一个git仓库要保持三个及以上的分支，基本的分支明明如下：
| name |
function |
| master |
正常运行的稳定版本 |
| develop |
正常运行的开发版 |
| feature |
添加新功能的分支 |
| hotfix |
紧急修复bug的分支 |
如果你已经fork了一份代码到自己本地，当你想添加一个新功能比如「用户管理」的时候，就应该先换到develop分支，然后由这个分支创建一个新的名为feture_add_usermanager的分支。在新分支里编写代码后将代码提交一个PullRequest到自己的develop分支，合并起来后再提交一个PullRequest到团队的仓库中，等待团队其他成员review后就可以正式将代码合并到团队的develop中了。等下一次发布新版本的时候就可以将团队的develop分支合并到团队的master分支中了了。
如果中途项目出现了严重bug(不能登录)需要即使修改上线，那就从自己的master分支上新建一个名为hotfix_cantlogin的分支，修改完后直接提交PullRequest到团队的master分支，review且合并后就可以将该分支删除了。
0X01 合并多次commit
有的时候会出现这么一种情况：连续的n次commit解决的都是同一个问题，为了让最终的提交记录清晰明了，可以将这几次的commit合并为一次。看下面的实例：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
| commit bc83e15e3245ad4064fdd9fe2bf105252d0c51fc (HEAD -> develop)
Author: shawn <[email protected]>
Date: Mon Nov 6 00:52:43 2017 +0800
fix usermanager
commit affc0acb9a3de30288f144ae2d0b28a9fd60af4b
Author: shawn <[email protected]>
Date: Mon Nov 6 00:52:33 2017 +0800
fix usermanager
commit fcf13d712bd3dbd483442ffd316741e04acaaa3e
Author: shawn <[email protected]>
Date: Mon Nov 6 00:52:23 2017 +0800
fix usermanager
commit 2812e2928913e9b3a7650e389602b8bb10ca388b
Author: shawn <[email protected]>
Date: Mon Nov 6 00:52:08 2017 +0800
fix usermanager
commit f7f273d9c36d748183ac3e6a90f06ff14ed42f95
Author: shawn <[email protected]>
Date: Mon Nov 6 00:51:52 2017 +0800
add user_manager
|
最近的四次提交内容都是一样的，修改了四次bug最终才解决了问题，因为最近四次的commit是相同含义的修改，所以最好合并在一起，可以使用这个方法
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| # 最后接的id是你合并的这些commit之前的一个
git rebase -i f7f273d9c36d748183ac3e6a90f06ff14ed42f95
＃ 输入命令之后到vi环境的界面
pick 2812e29 fix usermanager
pick fcf13d7 fix usermanager
pick affc0ac fix usermanager
pick bc83e15 fix usermanager
# 我们将其修改为
pick 2812e29 fix usermanager
squash fcf13d7 fix usermanager
squash affc0ac fix usermanager
squash bc83e15 fix usermanager
# 保存退出，进入commit message修改的界面
这里会展示出合并的这几次commit的message，我们选择性的修改一下将这几次的commit message整合一下，继续保存。这次保存之后就相当把这几次的commit合并成一次了。
|
注意，如果你是从仓库中clone下来的项目，那么有可能在你合并完几个commit后再git push会提示错误。假设以前是有100次commit的，现在你合并了最后的三次，再push，就会和远端的仓库出现分歧。一般情况下都是在确认自己的代码没问题之后，使用git push -f的方式强行把代码推上去，这样就会覆盖掉最后的几次commit，以你新push的代码为基准了。
0X02 迁移一次commit
有的时候我们需要将某个分支中的某次提交复制到另一个分支，具体使用情景有很多。这里展示一个使用样例：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
| git log 查看master分支的commit，只有这一次
commit 2959f92753d84bff5b125b15cd9497c4d8dff637 (HEAD -> master)
Author: shawn <[email protected]>
Date: Sun Nov 12 16:09:07 2017 +0800
完成XXX功能
切换到dev分支查看commit，有四次
commit bba77c7faf7821802b108688a17d8e6655975b7e (HEAD -> dev)
Author: shawn <[email protected]>
Date: Sun Nov 12 16:11:47 2017 +0800
整理XXX
commit 9001f8250ce47a067c9af50bf62af025b872c3bc
Author: shawn <[email protected]>
Date: Sun Nov 12 16:11:37 2017 +0800
添加XXX
commit 6e4171ad632a7627be08ec7c9afaf64f55ccc98d
Author: shawn <[email protected]>
Date: Sun Nov 12 16:11:21 2017 +0800
修复XXX
commit 2959f92753d84bff5b125b15cd9497c4d8dff637 (master)
Author: shawn <[email protected]>
Date: Sun Nov 12 16:09:07 2017 +0800
完成XXX功能
如果此时我想将那个“添加XXX”的commit移到master分支，可以使用`git cherry-pick`
可以看到“添加XXX”的那次commit的ID为`6e4171ad632a7627be08ec7c9afaf64f55ccc98d`
我们复制这个ID，切到master分支，使用`git cherry-pick commit_id`
shawn in ~/test on master λ git cherry-pick 6e4171ad632a7627be08ec7c9afaf64f55ccc98d
[master f77b496] 修复XXX
Date: Sun Nov 12 16:11:21 2017 +0800
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 b
shawn in ~/test on master λ git log
commit f77b49677efb1ba967dbc323332e2f8495fdbca1 (HEAD -> master)
Author: shawn <[email protected]>
Date: Sun Nov 12 16:11:21 2017 +0800
修复XXX
commit 2959f92753d84bff5b125b15cd9497c4d8dff637
Author: shawn <[email protected]>
Date: Sun Nov 12 16:09:07 2017 +0800
完成XXX功能
这样一个commit就复制过来了。如果有冲突的话需要将冲突解决完才能合并。
|