GIT工作流程总结

单人开发

开发完之后，add自己修改的内容

add-commit-push

$ git add test.py	//添加
$ git add .        //命令中的点号 . 代表当前目录,将当前目录及其子目录中所有更改过的文件添加到暂存区
$ git commit -m "wrote a test file"	//提交
$ git push //提交到远程上游分支

这是最理想情况下的，适合于自己开发，但是当多人合作开发（企业开发环境）中时，就不能这样做了。

多人开发

当多人开发的时候，某个需求会被分配到你，这时(假设开发的分支是dev分支)，需要做的是，将自己本地的dev分支更新到最新，与远程的dev分支同步：

git pull

此时，你的本地dev分支就和远程的dev分支同步了，为了保持dev的正确性和整洁性，是不可以在本地dev分支上进行开发的，因为本地的dev需要拉取其他人的最新提交，让得dev上的内容都是正确且完整的。。这时，就需要为当前的开发需求单独创建一个分支（基于dev分支），假设这个开发需求叫做a ，那么我们就为这个需求单独创建一个分支，具体多大的需求才需要创建分支，完全看自己，要是小需求，直接在dev分支上修改也无妨

git branch dev_a

此时我们创建好了这个需求的分支，接下来需要进行的就是开发工作，当开发的工作完成时，进行add操作；这里推荐add具体的文件，而不是一股脑的将所有修改的文件都 add，因为这有可能导致后续提交代码的时候将测试代码提交，造成测试同学打包的时候无法正常使用

git add .     //添加所有修改过的文件到暂存区
git add <修改的文件>   //添加具体的某几个文件到暂存区，推荐

然后提交到本地的仓库中，提交的描述一般公司都有内部的规定

git commit -m"describe what you did"

此时dev_a分支上的开发工作就已经就绪了。但是有个问题，那就是，你在开发，其它的同事也在开发并且有可能已经开发完了并且提交了新的代码，所以，此时正确的做法是，先切换到dev分支，并拉一下最新的代码

git checkout dev
git pull

现在，dev分支新加了一些代码，但是我们的dev_a分支是基于没有新增代码的dev分支创建的，所以，要先将dev分支上新增的代码给到dev_a分支上——即rebase操作。这里有一个小问题需要解释：为什么不直接在dev分支上合并dev_a分支呢？答案是：你在开发，同事也在开发，如果你们修改的代码块有重合的部分，那么就会产生冲突，规范的做法是要将冲突解决在自己的分支上，让dev分支保持正确、干净（之前提过）；rebase操作就是再“基于”dev分支一次，将新的内容加到自己的分支上，有冲突就解决冲突，没有冲突就可以进行合并操作了。

git checkout dev_a    //切换回dev_a
git rebase dev

如果有冲突，解决冲突再继续rebase：

git rebase -continue  //解决后继续rebase

合并操作，如果是a和b要合并，a是标准分支，b是进行开发的分支，那么应该在a分支下，合并b

所以我们要在dev分支下，合并dev_a分支

git checkout dev
git merge dev_a    //由于已经rebase过了，所以不会出现冲突

此时dev分支就有我们的代码了，将dev分支进行提交即可，也标志着dev_a分支的使命完成了，删除即可，以保证本地仓库的整洁

git push            //提交代码到远程仓库
git branch -d dev_a    //不在dev_a分支下才能删除dev_a分支

工作目录切换tips

git stash

如果此时你在开发，在工作目录下，但是此时出现了一个紧急的bug需要你到其它分支进行排查，但是你还没开发完，没有办法进行add - commit的操作，但是如果直接git checkout 操作，会将当前工作目录下的内容带到其它分支的工作目录下，直接导致其他分支工作目录的混乱；那么此时怎么做呢——git stash：它的主要作用是临时保存（或“藏匿”）你当前工作目录中的未提交改动，使你可以切换分支或执行其他操作，而不必提交未完成的工作。

当你使用 git stash 时，Git 会将你的暂存区和工作目录中的修改（即那些已经用 git add 添加的和未添加的修改）保存起来，然后将它们从当前工作目录中移除，使你的工作目录看起来像是“干净”的，即与上次提交的状态一致。

git stash

当你处理完其它分支上的工作，回到这个分支想接着刚才的进度进行工作的时候，就可以使用 git stash pop 可以应用（并删除）存储列表中最近的更改。这会将之前存储的更改重新应用到当前工作目录。

git stash pop

那么问题来了，当反复出现这个情况的时候，可能需要多次git stash，最新存储的更改将有索引 stash@{0}，紧接着是 stash@{1}，依此类推。每次你创建一个新的 stash，它就会被放在列表的顶部，成为 stash@{0}，而之前的 stash 索引将依次增加。

可以使用 git stash list 查看当前存储的更改列表。

git stash list

如果你有多个存储的更改，可以使用 git stash apply stash@{n} 应用特定的更改，其中 n 是你想要应用的更改在 git stash list 中的索引，索引从0开始

git stash apply stash@{n}