git对于代码的版本管理确实是一个很好的工具，是一个程序员基本素养之一。上家公司一直用的是SVN。最近到了新公司用了git, 感觉像是发现了新大陆。
  首先按照实际研发场景下的情形，描述一下具体每个步骤上相关的git 指令和注意事项。
  在这里假设一个场景，你是一名计算机视觉相关领域的算法工程师。在日常研发的过程中， 在阅读ATSS这篇论文的时候，你想对源码进行一定的研究。
  第一步：你按照论文中放出的github网址：https://github.com/sfzhang15/ATSS，找到该源码所在处，然后fork一份到自己的github账户下。图1是论文作者的源码页面， 图2是fork作者源码之后自己的github相关仓库的页面信息。此时你就获取了一份源码， 可以展开自己读源码，改源码，甚至上传提交自己对源码的优化给论文作者等一系列操作了。

图1

图2
  第二步，将远程仓库的源码clone到本地。下载到本地就可以使用我们熟悉的编辑器例如vscode进行研发，以及在本地调试运行。

图3

  第三步，如图4所示，我们看一下当前我们本地的分支(branch)情况。

图4   可以看到我们本地分支只有一个master分支，我们就叫它主线分支吧。但如果你在github的网页端看一看，就会发现其实github该仓库中已经有5个branches分支，如图5所示。也就是说此时我们并没有将远端（remote）所有的分支拉下来。

图5   那么如果此时葡萄想将所有的分支都拉下来，它只需要 执行

git fetch origin

  现在葡萄想开发一个新的功能，或者修复一个bug。此时就出现了一个独立的开发任务。因此葡萄就在master的基础上，新建一个分支出来，取名为putao.

图6   再查看此时的本地分支，就会发现，‘putao’分支已经新建了出来，并在新建分支的同时，当前branch已经自动切换到新的分支。

图7   第四步，开发。这步骤就因人而异。但记住此时你都是在自己的私人分支：putao上进行研发，你完全不用担心污染主线分支。

  第五步，提交代码。当你认为自己的独立单元的开发已经完成之后可以提交代码

图8

图9

图10

此时远程仓库的分支里面就会出现了一个新的分支：‘putao’

图11

  第6步：Merger.
  在merger之前，我们首先要做git rebase master操作。
rebase称之为变基，这步的操作主要是因为在实际场景中，我们基于master分支拉一个putao分支在本地开发的期间，可能会有其他开发者向master分支merger了节点。从而使远程分支的状态变成了如图12所示。

图12   我们需要将我们当前的开发分支上的节点d的base进行更新，也就是rebase到master最新的head节点c.

git rebase master

  在此过程中如果有提示conflict，则手动解决冲突即可。当rebase之后，就可以在远端提交pull request操作了。
  第7步，提交pull requests。
  第8步，其他人进行代码的review之后，决定是否同意merger.如果同意则此次merger成功。
  其他：在开发一个独立的单元之后，就要提交merger。这是一个比较规范的节奏，要避免存在我将一个大的功能都开发完之后，再merger的想法，此时，上千行代码对于code review的人也不友好. 如果上述pr的操作，葡萄是在官方作者的github页面上操作的，并且官方作者同意了Pr, 那么葡萄就成为了官方代码的贡献者之一。