Git 分支工作策略

前言

天下可能有一种后悔药（版本控制）。

---

多人开发必定少不了开分支，分支工作一般也采用某些策略：

1. 切换到自己的工作分支进行开发

$ git checkout myDevelop

开发期

2. 开发完毕后提交自己的工作分支

$ git commit -a

3. 回到主分支

$ git checkout master

4. 将远程最新的版本拉取过来

$ git pull

5. 回到自己工作的分支

$ git checkout myDevelop

6. 用rebase合并主干的修改

$ git rebase master

7. 回到主分支

$ git checkout master

8. 合并自己工作分支的修改

$ git merge myDevelop

9. 提交到远程master

$ git push

这样一来远程主干上的历史永远是线性的。每个人在本地分支解决冲突，不会在主干上产生冲突。

 

关于rebase

官网上这么介绍

ok，已经讲得非常直白了，假设我们现在在topic分支上，现在的版本状态是这样

master有topic没有的内容，topic有master没有的内容

执行下方任意一条语句

就会变成这样：

相当于topic是最新的master的基础上新开的一条分支。

并且rebase还可以跳过上游分支修改过的提交：

A'和A是同样的变化。

 

** 在 rebase 的过程中，也许会出现冲突 conflict 。在这种情况， git 会停止 rebase 并会让你去解决冲突。在解决完冲突后，用 git add 命令去更新这些内容。

注意，无需执行 git-commit，只要执行 continue

git rebase --continue

这样 git 会继续应用余下的 patch 补丁文件。

 

** 在任何时候，我们都可以用 --abort 参数来终止 rebase 的行动，并且分支会回到 rebase 开始前的状态。

git rebase —abort

 

模式

git rebase 是采用Fast-forwarded也就是时间顺序的模式，总是保存最新的版本。

 

以上是对Git 分支工作的粗浅认识

转载请注明出处：https://blog.csdn.net/qq_36652619