通过后面实践的学习, 置信对 git 的模型曾经有了一个比拟深刻的意识, 在解说罕用开发命令之前, 先看下 git 整体操作流程
咱们依照一个失常的开发流程来学习, 咱们当初要开始开发了, 首先咱们须要把近程仓库同步到本地
git clone https://github.com/generalthink/git_learn.git运行完下面的命令, 在咱们的当前工作目录就会有一个 git_learn 的文件夹, 其中存在.git 目录 (git 保护仓库的根本) 以及和近程仓库一样的文件, 当初咱们的代码环境就和近程仓库统一了, 咱们就能够开始咱们的开发流程了。
开发流程
一般来说，无论是开发新性能 (feature) 还是批改 bug(issue)咱们都不会间接在骨干上进行开发，而是会在分支上进行开发，而后验证无误之后在同步到 master。
当初忽然有了一个 bug 咱们要新开一个分支来解决这个 bug, 那么咱们应该怎么做呢?
首先，新建一个 bugFix 分支, 并切换到这个分支
git branch bugFix
git checkout bugFix
或者
git checkout -b bugFix
新建一个分支, 只是多了一个指针指向以后最新的提交而已, 前面所有的提交都基于以后的分支, 星号代表以后分支。
而后，找到 bug 的起因，批改对应的文件，当初咱们批改了几个文件, 须要提交将它退出到咱们本地仓库, 同步到近程仓库会在前面的文章解说。
- 退出批改的文件到暂存区
git add *.java下面的操作实际上是使文件工作目录和暂存区的版本统一, 然而当初和仓库的版本还不统一. 想要查看具体存在哪些文件须要提交能够应用 git status 查看。
- 提交文件到本地仓库
git commit -m "fix bug"commit命令实际上是让 index 中文件在暂存区和仓库的版本保持一致, 通过这个步骤, 工作目录, 暂存区以及仓库的版本都是统一了，上面的图是提交前后 commit objects(能够查看数据模型那篇文章)的变动。
你在批改 bug 的同时, 其他人曾经往骨干分支上提交了其余性能的代码或者你本地原本就存在两个不同的分支, 所以修复了这个 bug 之后, 咱们的仓库看上去是这样的
合并分支
这个 bug 修复后, 被测试验证通过了, 而后接下来想要把这个分支的代码合并到骨干分支(或者合并两个不同的分支), 罕用的合并形式有 2 种
git merge
将 bugFix 合并到 master 分支上
// 切换到 master 分支
git checkout master
git merge bugFix
看到了没有,master 指向了一个领有两个父节点的提交记录, 如果从 master 开始沿着箭头向上看, 在达到终点的路上会通过所有的提交记录, 这意味着 master 蕴含了对代码库的所有批改。
这个时候如果你还想把 master 分支合并到 bugFix 分支也是能够的
git checkout bugFix
git merge master
因为 master 继承自 bugFix，Git 什么都不必做，只是简略地把 bugFix 挪动到 master 所指向的那个提交记录。
当初所有提交记录的色彩都一样了，这表明每一个分支都蕴含了代码库的所有批改！
git rebase
第二种合并分支的办法是 git rebase。Rebase 实际上就是取出一系列的提交记录，“复制”它们，而后在另外一个中央一一的放下去。
Rebase 的劣势就是能够发明更线性的提交历史.
git rebase master
当初 bugFix 分支上的工作在 master 的最顶端，同时咱们也失去了一个更线性的提交序列。
留神，提交记录 C3 仍然存在（树上那个虚线节点），而 C3′ 是咱们 Rebase 到 master 分支上的 C3 的正本。
当初惟一的问题就是 master 还没有更新，上面咱们就来更新它吧
git checkout master
git rebase bugFix
因为 bugFix 继承自 master，所以 Git 只是简略的把 master 分支的援用向前挪动了一下而已。