Git学习笔记 (3)

切换到master分支

$ git switch master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.
(use "git push" to publish your local commits)

Git还会自动提示我们当前master分支比远程的master分支要超前1个提交。

在master分支上把branch文件的最后一行改为：you can get them together later

然后提交：

$ git add readme.txt
$ git commit -m "later"
[master 5dc6824] later
1 file changed, 1 insertion(+), 1 deletion(-)

现在，master分支和feature1分支各自都分别有新的提交，变成了这样：

这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：

$ git merge featurel
Auto-merging branch
CONFLICT (content): Merge conflict in branch
Automatic merge failed; fix conflicts and then commit the result.

提示需要手动修改冲突

$ vim branch

修改内容为一致再提交：

$ git add branch
​
$ git commit -m "conflict fixed"
[master 161fdd0] conflict fixed

现在，master分支和featurel分支变成了下图所示：

用带参数的git log也可以看到分支的合并情况：

$ git log --graph --pretty=oneline --abbrev-commit
​
*   161fdd0 (HEAD -> master) conflict fixed
  |\
  | * 2dcde4f (featurel) another sentence
*   | ff2f5be later
  |/
*   33ed516 branch test
*   41f741d (origin/master) first commit
*   b358c1a try
*   9752f6c try

最后删除featurel分支

分支管理策略

通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。

如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

下面我们实战一下--no-ff方式的git merge：

首先，仍然创建并切换dev分支：

$ git switch -c dev
Switched to a new branch 'dev'

修改文件，并提交一个新的commit，然后使用：

$ git log --graph --pretty=oneline --abbrev-commit
​
*   ba04267 (HEAD -> master) merge with no-ff
  |\
  | * 4d7fe06 (dev) add merge
  |/
*   161fdd0 conflict fixed
  |\
  | * 2dcde4f another sentence
*   | ff2f5be later
  |/
*   33ed516 branch test
*   41f741d (origin/master) first commit
*   b358c1a try
*   9752f6c try

可以看到，不使用Fast forward模式，merge后就像这样：

在实际开发中，我们应该按照几个基本原则进行分支管理：

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；