1. 工作场景
利用git对代码的版本管理是一个程序员基本技能之一。本文按照实际研发场景下的情形,描述一下具体每个步骤上相关的git 指令和注意事项。
在这里假设一个场景,你是一名计算机视觉相关领域的算法工程师。在日常研发的过程中, 在阅读ATSS这篇论文的时候,你想对源码进行一定的研究。
2. 整个流程
第一步:你按照论文中放出的github网址:https://github.com/sfzhang15/ATSS,找到该源码所在处,然后fork一份到自己的github账户下。图1是论文作者的源码页面, 图2是fork作者源码之后自己的github相关仓库的页面信息。此时你可以进行阅读源码、修改源码,甚至commit自己对源码的优化给论文作者等一系列操作。
![在这里插入图片描述](https://i-blog.csdnimg.cn/blog_migrate/385a95d6e9fc6e00e282bd1d3e03cf57.png)
第二步,将远程仓库的源码clone到本地。下载到本地就可以使用我们熟悉的编辑器,例如vscode进行研发,以及在本地调试运行。
![在这里插入图片描述](https://i-blog.csdnimg.cn/blog_migrate/ac34d32f63923bbd4f540d0a51f6d2ae.png)
第三步,如图4所示,先通过指令,看一下当前本地的分支(branch)情况。可以看到本地分支只有一个名称为master的分支,称之为主线分支。但如果你在github的网页端看一看,就会发现其实github该仓库中已经有5个branches分支,如图5所示。也就是说此时我们并没有将远端(remote)所有的分支拉下来。
git fetch origin
现在想开发一个新的功能,或者修复一个bug。此时就出现了一个独立的开发任务。在master的基础上,新建一个分支出来,取名为putao。
第五步,提交代码。当自己独立单元的开发已经完成之后可以提交代码。
此时远程仓库的分支里面就会出现了一个新的分支:‘putao’
第6步:Merger.
在merger之前,我们首先要做git rebase master操作。
rebase称之为变基,这步的操作主要是因为在实际场景中,我们基于master分支拉一个putao分支在本地开发的期间,可能会有其他开发者向master分支merger了节点。从而使远程分支的状态变成了如图12所示。
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