前言
天下可能有一种后悔药(版本控制)。
多人开发必定少不了开分支,分支工作一般也采用某些策略:
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