当尚不清楚项目的某项修改对项目可能造成的影响的时候，git的分支管理指令可以让使用者同时进行主线任务的开发和分支任务的修改。但初次接触git的分支管理时，本小菜鸡还是碰到了许多令（十）人（分）疑（简）惑（单）的问题，记录下来希望能给初学git的小伙伴提供些帮助。
git branch：建立新的分支
git checkout：切换工作分支
git merge：合并两个分支
git branch [branch_name]用于创建新的本地分支，分支名为branch_name。需要注意的是，创建新的分支后不会自动切换到新的分支上，需要使用git checkout [branch_name]切换。
git branch -d [branch_name]用于删除本地名为[branch_name]分支，这个命令会检查该分支在上一次merge后是否进行了修改，存在没有合并的修改会导致删除失败。
git branch -D [branch_name]也是删除本地名为[branch_name]分支，不同的是该指令会直接删除，不会进行检查。
需要注意的是git branch -d与git branch -D都是删除本地分支的方法，不会影响远程仓库的分支结构。
不带参数的git branch显示当前的分支状态，前面带"*"的分支是当前正在使用的分支。
如果git branch返回为空，那多半是没有进行第一次commit，在第一次commit时会创建master分支，在此之前使用git branch [branch_name]创建新的分支也是不可以的，会出现如下提示：
-v：
git branch -v如下图所示，查看每个分支的最后一次commit记录。
git branch -r仅查看远程仓库的分支结构。
git branch -a可以查看所有分支结构，包括本地仓库和远程仓库，其中远程仓库的分支会用红色进行标识。
首先，不同分支的文件对应不同的文件快照，当进行分支切换时所有未合并的文件都会发生变化。
创建分支后新建的文件不共享！
新建的文件不共享！
新建的文件不共享！
实验4中由于最后两个分支不进行合并，创建分支后完善代码就变得比较繁琐，必须在两个分支下来回切换修改程序（当然也是因为创建分支前没有对公共部分进行足够的完善）。实际应用中由于分支大多用于部分功能的修改，最后会进行舍弃或与master分支合并，因而不会存在类似的问题。
git checkout [branch_name] 用于切换到一个名为[branch_name]的分支。
git checkout -b [branch_name] 用于创建一个新的分支并切换到该分支，分支名为[branch_name]。
git merge [branch_name(s)] 命令用于将（多个）待合并分支 [branch_name(s)] 与当前正在操作的分支进行合并。合并范围是从这些分支节点的最近公共祖先开始，合并到当前节点为止。
例如，合并前分支结构如图：
在master分支上使用git merge change合并后分支结构如图：
合并过程可能出现冲突！
合并过程可能出现冲突！
合并过程可能出现冲突！
删除将待合并分支上的所有commit(s)合并为一个未commit的节点。
例如，合并前分支结构如图：
在master分支上使用git merge --squash change后分支结构如图：
节点P包含了change分支相较于master分支的修改，且是未commit的状态。但不同于普通的merge操作的是，使用--squash参数合并的分支不会记录与change分支的继承关系，一个很明显的两个证明是：合并后使用git log显示commit记录不会包含change分支的信息；此时使用带检查的git branch -d change指令删除change分支会提示存在未合并内容。
在许多情况下使用--squash参数进行合并是更优的选择，因为大量的分支修改中的细节信息是不必要的，使用--squash参数可以保证master分支提交记录足够简洁。
git merge --abort用于恢复出现冲突的合并操作，但未commit的操作在某些情况下（如合并过程中发生了修改）可能无法恢复。因此，合并操作前及时commit是一个良好的编程习惯。
原文：https://www.cnblogs.com/hit1183710107/p/13264642.html