工作也蛮长时间了，接触的我的项目也在减少，目前咱们组应用的是公司搭建的gitlab进行合作开发，这篇文章总结一下我集体在工作中最罕用的git操作流程，感觉还不错。
这里首先得先明确一些概念，仓库分为近程主体仓库、集体近程仓库和本地仓库。由我的项目负责人保护近程主体仓库，每个研发在本地仓库开发代码，同步到集体近程仓库，在进行代码合并申请，我的项目负责人在审核代码之后进行代码合并。
初始化仓库
首先，先fork我的项目到集体名下，git clone + URL 将我的项目复制到本地。
vs code关上我的项目，在新建终端中，git remote -v 查看仓库源
这里的origin是集体近程仓库，示意该我的项目曾经和集体近程仓库进行关联了。那还须要关联近程主体仓库，保障代码的更新。
git remote add + 名称 + 地址 我这里喜爱将近程主体仓库命名为main，地址就是近程主体仓库的URL。
当初两个仓库源都有了，然而并没有分支，还须要获取近程主仓库的分支，再依据须要新建本地分支和主仓库分支进行关联。
git fetch main 拉取近程主仓库的所有分支。vs code中能够显著看出执行前后区别。
vs code中这个GitLens 能够十分不便查看你操作的git相干信息，最下面的dev示意你以后处于的dev分支，并且是间接关联的origin/dev。Branches里是本地所有的分支。Contributors是合作者。Remote代表仓库源，也就是仓库初始化时进行的操作后果在这里很清晰的看到。
代码提交
已批改保留的文件会显示在源代码治理界面。
点击上图的加号，相当于在终端执行了git add
点击确定，相当于执行了 git commit -m “test”
更新到近程仓库
记住执行逻辑：本地提交的批改代码至暂存区，也就是下面那步骤；①拉取主体近程仓库最新代码到本地，合并本地代码；②提交到集体近程仓库；在gitlab平台上发动代码合并到主仓库的申请。
①
git fetch main devgit rebase main/dev②
git push origin d我这里举例的指令都是依照dev分支来执行的，①中也能够执行git push main dev，但这样会导致git提交记录中多出一条无用的合并记录。
同步主仓库分支
因为当初经手的我的项目也比拟多，主仓库上会开设多个分支来保护不同的我的项目。一个新的我的项目开发，就须要同步主仓库的分支到本地、到集体近程仓库，这种状况也算是常常遇到了。
就像上面这种状况，主仓库中有test分支，但我本地和集体近程仓库是没有的。
操作流程如下（一波图表白的明明拜拜）：