持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第8天，点击查看活动详情

故事开始

在平时开发的仓库代码管理中，我们常用的命令好像也不多：pull拉取、commit提交、push推送、reset回退、revert还原、checkout切分支、git log查看日志等等，其实很简单，但如果涉及到多个仓库、多个分支，不仅是task_dev、develop和RC三大分支，线上还会出现按日期的迭代分支，且不止一个迭代分支，是不是会很绕。

拉取分支

切个新分支，很简单:

git checkout -b [new branch]
...
...

git checkout -b [new branch] origin/xxx 

两者有区别吗？有什么区别呢？ 是不是没深入思考过，所以你在猜，碰运气。

回退

回退到哪个提交版本，可能用的频率不及git pull、git checkout之类的，但合错代码了，就需要用到，我身边有工作五六年的同事不会回退，可能会出现一回退代码就再也合不进去了，为什么呢？有没有想过git的工作原理？

正常我们执行回退，大体执行这么几步：

// 第一步：查看最近的commit版本，找到你要回退到的那个commit，复制下来
git log
// 第二步：reset到目标commit
git reset --hard commitId

其实有很多工具提供的还原功能可能到此为止了，是不行的，还必须执行：

git push origin <branch-name> --force

覆盖远程仓库，使远程仓库也回退到相应版本。这样才算比较彻底的回退了。

不同仓库

这种情况可能更少见了，要看业务，可能工作多年也没执行过这种操作。先存在两个或多个仓库，如果需要在B仓库修改后，合并到A仓库，同时A仓库可能也有业务开发，那我们应该在A仓库操作合并B呢，还是在B仓库往A推送呢？个人认为应该是A仓库来执行合并B仓库操作，因为从这个逻辑本身来说就是A仓库相比于B仓库，代码更全，相当于主仓库。如何执行呢？

// 在A仓库目录下新建一个B仓库的源
git  remote add origin [new-origin] [B仓库地址]
// 指向新的源
git fetch [new-origin]
git checkout -b [new-branch] [new-origin]/[branch-xxx]

这样就在A仓库基于B的源仓库创建了个相当于中间分支，来与A仓库进行代码的合并，以后每次需要合并B仓库的代码，只需要在B仓库正常提交，然后在A仓库的中间分支拉取，然后再合并到A仓库即可。