实际开发场景下Git操作流程

1. 工作场景

  利用git对代码的版本管理是一个程序员基本技能之一。本文按照实际研发场景下的情形，描述一下具体每个步骤上相关的git 指令和注意事项。
  在这里假设一个场景，你是一名计算机视觉相关领域的算法工程师。在日常研发的过程中， 在阅读ATSS这篇论文的时候，你想对源码进行一定的研究。

2. 整个流程

  第一步：你按照论文中放出的github网址：https://github.com/sfzhang15/ATSS，找到该源码所在处，然后fork一份到自己的github账户下。图1是论文作者的源码页面， 图2是fork作者源码之后自己的github相关仓库的页面信息。此时你可以进行阅读源码、修改源码，甚至commit自己对源码的优化给论文作者等一系列操作。

图1

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

图3

  第三步，如图4所示，先通过指令，看一下当前本地的分支(branch)情况。可以看到本地分支只有一个名称为master的分支，称之为主线分支。但如果你在github的网页端看一看，就会发现其实github该仓库中已经有5个branches分支，如图5所示。也就是说此时我们并没有将远端（remote）所有的分支拉下来。

图4

图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, 那么本人就成为了官方代码的贡献者之一。

3. 番外篇

3.1 ahead xxx, behind yyy

  此时如果想舍弃掉本地的变动，可以执行

git reset --hard commit-id

3.2 删除中间commit节点

  例如，按照上文第六步所述，对d进行rebase，从而变成a—>b---->c---->d，但此时由于某种原因希望回退至a–>d的形式(也即删除中间的两个commit节点c和节点d)，可以执行

git rebase -i 节点a的commit id

然后在对应的条目下，选择drop模式即可。

3.3 一种优雅的方式将本地代码与远程仓库相关联

  公司服务器无法从github上clone代码仓库，但可以以代码包的方式download下来。通过将下载下来的代码包与公司的gitlab仓库关联，达到代码管理的目的。

git init
git add .
git commit -m "initial commit"
git remote add origin <remote_rep_url>
git push origin master