分支管理

Git管理分支是进行指针的切换，所以创建分支速度非常快

Git默认有一条主分支master，之前的每一次commit提交都在这个分支下进行的，一般项目中的第一个版本（核心）都是在master分支下进行提交的，当我们这个版本上线了，主分支的代码一般是我们需要以后部署在线上服务器中的，我们后续需要对其不断的进行优化或者修改bug，一般是从master分支分离出去，创建一个新的分支，在新的分支上进行需求的开发，当需求开发完后，我们需要进行合并分支（将master分支的指针往后移，移到新分支最新的提交后即可），将新开发的需求合并到主分支master中

---

工作流

除了主分支master（稳定分支），我们一般需要建立一个开发分支develop来完成日常的开发，这两个分支是并行的分支，最终将稳定的代码（即可以线上部署的）放到master分支里面，在开发分支develop中又可以根据功能需求点创建新的分支进行开发，master分支相对于实际开发是一个旧的版本，但是是一个相对稳定的版本

---

本地分支

在经过第一次commit提交之后，Git会自动的构建出主分支master

• 查看分支：git branch

  查看分支会列举出项目中的所有分支，*表示当前所在分支的指针（目前所处的分支，代码的提交都会在当前分支上进行）

• 创建分支：git branch 分支名

• 切换到指定分支，并更新工作区：git checkout 分支名，将指针指向到某个分支，在某个分支中会创建文件，编写代码都不会影响其他的分支，在其他分支中是看不到这些在当前分支中新建的文件

• 创建并切换分支：git checkout -b 分支名 创建分支和切换分支的组合形式

• 合并指定分支到当前分支：git merge 分支名

  一般是切换到主分支，将其他要合并的分支合并进来（将master主分支的指针进行位移），合并分支后，该分支的文件内容就合并到master主分支中

• 查看已经合并了的分支：git branch --merged

  • 刚创建的分支，没有进行任何的修改，与原分支是一样的，那这个新的分支等同于合并完了，也会在上述的指令中被查询到，如果对这个文件进行内容的修改并提交到版本库中，那么这个文件相对于原分支就不一样了，该分支就不会在上述指令的结果中出现，我们可以通过git branch --no-merged操作进行查找未合并的分支

  • 已经合并了的分支就没有用了，可以进行删除

• 删除合并后的分支：git branch -d 分支名

  • 对于合并完后的这个分支，就没有存在的必要的，我们需要对其进行删

• 删除未合并的分支：git branch -D 分支名

  如果有些分支在没有合并的时候进行删除（这个功能的需求点我们不想要了）Git终端会进行报错：error: The branch '分支名' is not fully merged.，我们可以通过上述方法进行删除未合并的分支

• 暂存文件：git stash

  当我们在一个分支中将一些文件放到缓存区后（没有在缓存区的文件是不能进行暂存操作的，只有跟版本库进行关联后的文件才能使用暂存操作），但是没有进行提交，在这个时候，我们又切换到了另一个分支，那么Git终端就会报错：error: Your local changes to the following files would be overwritten by checkout: 具体在暂存区中的文件 Plwase commit your changes or stash them before you switch branches.,在这个情况下，这个文件我们可能只是写了一半将其放到暂存区中，但是我们还不想进行commit提交到版本库中，我们可以通过上述命令将其文件进行暂存起来，这样我们就可以切换到其他的分支了

  • 我们可以通过git stash list进行查看暂存的文件（将文件放到了stash{0}暂存区中，我们可以创建很多个暂存区，0表示第一个暂存区），对不同的文件使用暂存操作git stash，会开辟不同的暂存区来进行文件的暂存
  • 等我们切换回这个分支，我们需要恢复放在暂存区中的文件：git stash apply（恢复不删除暂存区），恢复完后暂存区依然存在，我们可以通过git stash drop stash{0}操作进行删除
  • 恢复并删除暂存区：git stash pop

---

冲突

冲突的产生，是因为某一个文件被几个分支都占用修改了，在各自的分支中提交该文件到版本库中，是没有什么问题的，但是到合并分支时，首先合并到主分支的分支是没有什么问题的，但是后面其他分支合并进来就会产生冲突，就会出现合并失败：Automatic merge failed: fix conflicts and then commit the result.，提示你先修复这个冲突后再进行提交

处理冲突是不能系统进行自动处理的，只能进行人为的手动处理

我们可以查看这个冲突的文件，对存在冲突的部分进行人为的修改（接受还是删除），解决完冲突后，再对文件进行添加到缓冲区和提交到版本库

冲突的另一个实例：

我们在主分支master下创建一个新的分支，在该分支下我们创建了一个文件并将文件进行提交，之后我们又切换回到主分支下，在主分支中也创建了一个文件进行提交到版本库中，我们将新分支与主分支进行合并，会执行合并（如果产生冲突需要进行冲突的解决），但是不是之前分支直接并入（master主分支不加内容，在新分支中加内容并将分支合并进来）的快速合并（master主分支的指针往后进行移动），会产生一个新的合并消息，先将新分支的内容拿过来，和本地的代码进行合并操作，其合并操作是在master主分支下进行合并的，但是这样的情况是不好的，如果这个时候产生冲突，需要master主分支的开发者进行冲突的解决，这个逻辑显然是不正确的，我们应该让新分支的开发者来解决这个冲突，再直接合并给主分支即可，这时我们就需要在新分支下进行以下的操作：把新分支的提交记录先隐藏，再将新分支移到主分支最新的提交点，最后将新分支的动作再做一遍，这样就不会产生合并记录了，整个逻辑就是改变新分支的基础点

• 获得最新的主分支提交点：git rebase master
• 之后再切换到主分支中将新的分支进行合并进来
• 因此，我们在维护其他人的开源项目的时候，尽量使用一下rebase 操作

当然这种情况还存在于，我们拉出一个新分支进行开发，可能还有其他的开发者往这个项目中提交代码，这样在合并的时候可能就会出现冲突，我们也可通过rebase 操作来进行解决