版本管理(Revision control)是一种软件工程方法，在开发的过程中，确保由不同开发人员编辑的同一档案都得到更新。代码版本管理其实就是我们在日常的开发过程中，将每天、每个阶段、每个功能等要求完成之后，将我们的代码再提供给他人的一种行为。
这个行为的目的就是，让每一个人的开发过程都有据可查，最后实现多人合作开发的目的。
目前市面上比较流行的是通过 Git 进行代码版本管理，因为它易于学习，占用内存小，具有闪电般快速的性能，
规范且流程化的版本管理，不仅能有效的提升代码质量，而且还能帮助项目团队有序协同，轻松提升研发效能，那么Git 代码版本管理的规范化流程有哪些呢？
基于 Git 的代码版本管理主要包括：代码库的分布、人员角色的划分、代码提交合并流程、代码冲突处理、分支管理。
代码库分类
根据代码库分布的位置及作用，分为以下几类：
主仓库：位于服务端，所有开发的代码最终都要合到主仓库。
个人代码库(服务端)：从主仓库 fork 出来，位于服务端。每个人自已开发的代码，由本地的 Git 库 push 到每个人自己的个人代码库(服务端)，再由个人代码库(服务端)合入主仓库。
个人工作库：位于每个开发人员的开发机器，从个人代码库(服务端)clone 到本地。每个开发人员开发的代码，先 commit 到个人工作库，再由个人工作库 push 到个人代码库(服务端)。
人员角色分类
这里说的角色，都是人员在主仓库上的角色。基于简化的原则，人员分为三类：
Owner：拥有主仓库的所有权限。
Committer：具有将开发人员的合并需求(PR)合入主仓库的权限。基于安全考虑，我们设置为只能通过 PR 的方式将代码合入主仓库，而不能直接 push 到主仓库。
Developer：只能从自己的个人代码库(服务端)提交合并代码的请求(PR)，是否能够合入，由 Committer 进行审核。
以 Gitee 企业版为例，Developer 进行 PR 后有权限的 Committer 需要对代码进行审查，审查通过后方可进行合并。
基本流程
在主仓库已经存在的情况下，日常操作流程如下：
开发人员从主仓库 fork 出自己的个人代码库。
开发人员将自己的个人代码库 clone 到本地，即个人工作库。
开发人员在开发了新代码后(包括新增和修改)，先将代码 commit 到自己的个人工作库，再由个人工作库 push 到个人代码库。
开发人员提交从个人工作库到主仓库的 PR，Committer 审核后，决定是否将 PR 合入主仓库。
每个开发人员从主仓库 pull 最新代码到个人工作库。
分支管理
主仓库缺省的 master 分支，是用来向生产环境发布的，所有合入的代码，原则上都必须是稳定的。
主仓库除了 master 分支外，至少还要有一个活动分支，命名建议为：br_工程名_active，平时日常的开发都基于活动分支开发。即从个人工作库提交 PR 到主仓库时，指向的是主仓库的活动分支。活动分支测试稳定后，将主仓库的活动分支通过 PR 的形式，合并到主仓库的 master 分支，同时打上 tag。
如果软件运行过程中发现必须立即修改的 Bug，则从主仓库的 master 分支中，拉出一个 bugfix 分支。为修复这个 Bug 的所有开发，都基于 bugfix 分支。待 bugfix 分支开发完成，并测试稳定后，将 bugfix 分支以 PR 的方合入主仓库的 master 分支。然后删除 bugfix 分支，视情况决定是否打 tag。
在生产开发协作的实际过程中，出于内部控制的考量，往往需要自定义拥有某些关键分支推送(push)和合并(merge)权限的人群。
以 Gitee企业版为例，可以采用「分支状态」中的「保护分支」功能。被设为保护分支之后，该分支只允许对应的「保护分支规则」内选中的仓库成员对此分支进行合并/推送操作。
常见问题
此部分内容会根据情况进行相应的增加。
活动分支合入主分支时发生冲突
产生原因
平时基于活动分支开发，如果这个过程中为了修复 Bug 而拉了一个 bugfix 分支，当 bugfix 分支开发完成并合入 master 分支后，如果 bugfix 分支和活动分支修改了相同的文件，则在活动分支合入 master 分支时就会产生冲突。
解决方法
从个人代码库(服务端)clone 一个库到本地，即专门用于合并的个人工作库。(也可以用之前的个人工作库，但初学都容易混淆，建议单独 clone 一个。)
从主仓库的活动分支上 pull 最新的代码到本地。
从主仓库的 master 分支上 pull 最新的代码到本地。
此时会产生冲突，手工修复冲突，然后先 commit 到本地的个人工作库，再 push 到个人代码库(服务端)。
提交从个人工作库(服务端)到主仓库的 PR(此时不会再有冲突)，然后由 Committer 审核后将PR合入主仓库。
不单是在研发团队的工作中，在开源项目中也同样需要规范的版本管理。而对初学者而言，我们建议在开始进行实践小项目的阶段即进行规范的版本管理，因为在以后的工作中代码版本管理将会是一项非常重要的技能。

                                                    

                                                        
2019独角兽企业重金招聘Python工程师标准>>>   
                                        
                                                
svn代码版本管理

1.0开发，做dev1.0的branch
此时的目录结构
svn://proj/
             +trunk/ (不负担开发任务)
             +branches/
                           +dev_1.0 (copy from trunk)
             +tags/ 
1.0开发完成，merge dev1.0到trunk
此时的目录结构
svn://proj/
             +trunk/ (merge from branch dev_1.0) ===>测试，打tag或者修改合并后的bug，担负bug代码修改
             +branches/
                           +dev_1.0 (开发任务结束，freeze)
             +tags/ 
1) 合并后，测试如果有bug，可以直接在trunk上修改bug，直到修正后打tag进行发布
2）合并后，测试无问题直接打tag发布
发布后发现存在bug：需要修改，基于1.0的tag做branch_buffix_1.0
此时的目录结构
svn://proj/
             +trunk/ 
             +branches/
                           +dev_1.0 (开发任务结束，freeze)
                           +dev_2.0 （进行2.0开发）
               +branch_buffix_1.0
             +tags/
                     +tag_release_1.0 (copy from trunk) 
    1）如果2.0开发开始，但并没合并入主干：branch_buffix_1.0中修正bug后合并到主干，通过主干打tag发布
    2）如果2.0开发结束，而且合并入主干：branch_buffix_1.0中修正bug后依然合并到主干，但通过分支branch_buffix_1.0打tag发布
依次类推！！

总结：
1）tag上不做任务代码修改
2）新需求开发，从主干（最新稳定的）做分支在分支上开发
3）新需求分支开发完成或者分支bug修正后，都必须合并到主干
4）主干可在合并后发现问题（并没打tag）做部分修改

这是方法之一，比较适用于那些经常改动，bug较多的网站开发。

以下是收集出来的各方法说明：

SVN中Branch和tag建立的方法比较简单，totoiseSVN中的操作是:
1.选择Branch和tag..
2.在出来的界面中的ToURL中填上URL，一般是svn://IP/Project/branches/branch-1,这样就建立了一个 branch-1的branch.建立tag是一样的操作，只不过URL一般是svn://IP/Project/tags/tag-1
3.后面的Createcopyfrom是用于选择从你当前的workingbase中的哪个版本中建立Branch和tag，可以根据自己的选择来订 制，一般选择HeadRevision

建分支
svn copy svn://server/trunk svn://server/branches/ep -m "init ep"

>svn trunk，branch，tag
1. branch和tag，对于svn都是使用copy实现的，所以他们在默认的权限上和一般的目录没有区别
3. 介绍一下
trunk：表示开发时版本存放的目录，即在开发阶段的代码都提交到该目录上。
branches：表示发布的版本存放的目录，即项目上线时发布的稳定版本存放在该目录中。
tags：表示标签存放的目录。
3.一般情况下，
tag，是用来做一个milestone的，不管是不是release，都是一个可用的版本。这里，应该是只读的。更多的是一个显示用的，给人一个可读（readable）的标记。
branch，是用来做并行开发的，这里的并行是指和trunk进行比较。 
比如，3.0开发完成，这个时候要做一个tag，tag_release_3_0，然后基于这个tag做release，比如安装程序等。trunk进入 3.1的开发，但是3.0发现了bug，那么就需要基于tag_release_3_0做一个branch，branch_bugfix_3_0，基于这个branch进行bugfix，等到bugfix结束，做一个tag，tag_release_3_0_1，然后，根据需要决定 branch_bugfix_3_0是否并入trunk。 

trunk ：表示开发时版本存放的目录，即在开发阶段的代码都提交到该目录上。

branches ：表示发布的版本存放的目录，即项目上线时发布的稳定版本存放在该目录中。

tags ：表示标签存放的目录。 

转载  SVN的trunk branch tag 收藏

Subversion有一个很标准的目录结构，是这样的。
比如项目是proj，svn地址为svn://proj/，那么标准的svn布局是

svn://proj/|+-trunk+-branches+-tags
这是一个标准的布局，trunk为主开发目录，branches为分支开发目录，tags为tag存档目录（不允许修改）。但是具体这几个目录应该如何使用，svn并没有明确的规范，更多的还是用户自己的习惯。

对于这几个开发目录，一般的使用方法有两种。我更多的是从软件产品的角度出发（比如freebsd），因为互联网的开发模式是完全不一样的。
第一种方法，使用trunk作为主要的开发目录。
一般的，我们的所有的开发都是基于trunk进行开发，当一个版本/release开发告一段落（开发、测试、文档、制作安装程序、打包等）结束后，代码处于冻结状态（人为规定，可以通过hook来进行管理）。此时应该基于当前冻结的代码库，打tag。当下一个版本/阶段的开发任务开始，继续在trunk进行开发。
此时，如果发现了上一个已发行版本（Released Version）有一些bug，或者一些很急迫的功能要求，而正在开发的版本（Developing Version）无法满足时间要求，这时候就需要在上一个版本上进行修改了。应该基于发行版对应的tag，做相应的分支（branch）进行开发。
例如，刚刚发布1.0，正在开发2.0，此时要在1.0的基础上进行bug修正。
按照时间的顺序

1.0开发完毕，代码冻结 
基于已经冻结的trunk，为release1.0打tag
此时的目录结构为
svn://proj/
             +trunk/ (freeze)
             +branches/
             +tags/
                     +tag_release_1.0　(copy from trunk) 
2.0开始开发，trunk此时为2.0的开发版 
发现1.0有bug，需要修改，基于1.0的tag做branch
此时的目录结构为
svn://proj/
             +trunk/ ( dev 2.0 )
             +branches/
                           +dev_1.0_bugfix (copy from tag/release_1.0)
             +tags/
                     +release_1.0　(copy from trunk) 
在1.0 bugfix branch进行1.0 bugfix开发，在trunk进行2.0开发 
在1.0 bugfix 完成之后，基于dev_1.0_bugfix的branch做release等 
根据需要选择性的把dev_1.0_bugfix这个分支merge回trunk（什么时候进行这步操作，要根据具体情况） 
这是一种很标准的开发模式，很多的公司都是采用这种模式进行开发的。trunk永远是开发的主要目录。

第二种方法，在每一个release的branch中进行各自的开发，trunk只做发布使用。
这种开发模式当中，trunk是不承担具体开发任务的，一个版本/阶段的开发任务在开始的时候，根据已经release的版本做新的开发分支，并且基于这个分支进行开发。还是举上面的例子，这里面的时序关系是。

1.0开发，做dev1.0的branch
此时的目录结构
svn://proj/
             +trunk/ (不担负开发任务 )
             +branches/
                           +dev_1.0 (copy from trunk)
             +tags/ 
1.0开发完成，merge dev1.0到trunk
此时的目录结构
svn://proj/
             +trunk/ (merge from branch dev_1.0)
             +branches/
                           +dev_1.0 (开发任务结束，freeze)
             +tags/ 
根据trunk做1.0的tag
此时的目录结构
svn://proj/
             +trunk/ (merge from branch dev_1.0)
             +branches/
                           +dev_1.0 (开发任务结束，freeze)
             +tags/
                     +tag_release_1.0 (copy from trunk) 
1.0开发，做dev2.0分支
此时的目录结构
svn://proj/
             +trunk/ 
             +branches/
                           +dev_1.0 (开发任务结束，freeze)
                           +dev_2.0 （进行2.0开发）
             +tags/
                     +tag_release_1.0 (copy from trunk) 
1.0有bug，直接在dev1.0的分支上修复



详细说明我是如何应用SVN trunk(树干)、branches(分支)和tags(标记)。这种方法同样被称为“branch always”，两者非常接近。可能我所介绍的并不是最好的方法，但是它会给新手一些解释说明，告诉他们trunk、branches和tags是什么， 并且该如何去应用它们。

　　当然，如果本文有些要点需要澄清/确认，亦或者有一些错误的观点，还请你评论，自由发表自己的观点。

——简单的对比

　　SVN的工作机制在某种程度上就像一颗正在生长的树：

    * 一颗有树干和许多分支的树
    * 分支从树干生长出来，并且细的分支从相对较粗的树干中长出
    * 一棵树可以只有树干没有分支（但是这种情况不会持续很久，随着树的成长，肯定会有分支啦，^^）
    * 一颗没有树干但是有很多分支的树看起来更像是地板上的一捆树枝
    * 如果树干患病了，最终分支也会受到影响，然后整棵树就会死亡
    * 如果分支患病了，你可以剪掉它，然后其他分支还会生长出来的哦！
    * 如果分支生长太快了，对于树干它可能会非常沉重，最后整棵树会垮塌掉
    * 当你感觉你的树、树干或者是分支看起来很漂亮的时候，你可以给它照张相，这样就就可以记得它在那时是多么的赞。

——Trunk

　　Trunk是放置稳定代码的主要环境，就好像一个汽车工厂，负责将成品的汽车零件组装在一起。

　　以下内容将告诉你如何使用SVN trunk：

    *
      除非你必须处理一些容易且能迅速解决的BUG，或者你必须添加一些无关逻辑的文件（比如媒体文件：图像，视频，CSS等等），否则永远 不要在trunk直接做开发
    *
      不要因为特殊的需求而去对先前的版本做太大的改变，如何相关的情况都意味着需要建立一个branch（如下所述）
    *
      不要提交一些可能破坏trunk的内容，例如从branch合并
    *
      如果你在某些时候偶然间破坏了trunk，bring some cake the next day (”with great responsibilities come… huge cakes”)

——Branches

　　一个branch就是从一个SVN仓库中的子树所作的一份普通拷贝。通常情况它的工作类似与UNIX系统上的符号链接，但是你一旦在一个SVN branch里修改了一些文件，并且这些被修改的文件从拷贝过来的源文件独立发展，就不能这么认为了。当一个branch完成了，并且认为它足够稳定的时 候，它必须合并回它原来的拷贝的地方，也就是说：如果原来是从trunk中拷贝的，就应该回到trunk去，或者合并回它原来拷贝的父级branch。

　　以下内容将告诉你如何使用SVN branches：

    *
      如果你需要修改你的应用程序，或者为它开发一个新的特性，请从trunk中创建一个新的branch，然后基于这个新的分支进行开发
    *
      除非是因为必须从一个branch中创建一个新的子branch，否则新的branch必须从trunk创建
    *
      当你创建了一个新branch，你应当立即切换过去。如果你没有这么做，那你为什么要在最初的地方创建这个分支呢？

——Tags

　　从表面上看，SVN branches和SVN tags没有什么差别，但是从概念上来说，它们有许多差别。其实一个SVN tags就是上文所述的“为这棵树照张相”：一个trunk或者一个branch修订版的命名快照。

　　以下内容将告诉你如何使用SVN tags：

    *
      作为一个开发者，永远不要切换至、取出，或者向一个SVN tag提交任何内容：一个tag好比某种“照片”，并不是实实在在的东西，tags只可读，不可写。
    *
      在特殊或者需要特别注意的环境中，如：生产环境（production）、？（staging）、测试环境（testing）等等，只 能从一个修复过的（fixed）tag中checkout和update，永远不要commit至一个tag。
    *
      对于上述提及到的环境，可以创建如下的tags：“production”，“staging”，“testing”等等。你也可以根 据软件版本、项目的成熟程度来命名tag：“1.0.3”，“stable”，“latest”等等。
    *
      当trunk已经稳定，并且可以对外发布，也要相应地重新创建tags，然后再更新相关的环境（production, staging, etc）

——工作流样例

　　假设你必须添加了一个特性至一个项目，且这个项目是受版本控制的，你差不多需要完成如下几个步骤：

   1.
      使用SVN checkout或者SVN switch从这个项目的trunk获得一个新的工作拷贝（branch）
   2.
      使用SVN切换至新的branch
   3.
      完成新特性的开发（当然，要做足够的测试，包括在开始编码前）
   4.
      一旦这个特性完成并且稳定（已提交），并经过你的同事们确认，切换至trunk
   5.
      合并你的分支至你的工作拷贝（trunk），并且解决一系列的冲突
   6.
      重新检查合并后的代码
   7.
      如果可能的话，麻烦你的同事对你所编写、更改的代码进行一次复查（review）
   8.
      提交合并后的工作拷贝至trunk
   9.
      如果某些部署需要特殊的环境（生成环境等等），请更新相关的tag至你刚刚提交到trunk的修订版本
  10.
      使用SVN update部署至相关环境
                                                    

                                                        





                                        
                                            
转载于:https://my.oschina.net/jiangchike/blog/365463

                                                    

基于git的简单实用的版本管理规范及流程，包括：代码库的分布、人员角色的划分、代码提交合并流程、代码冲突处理、分支管理。

代码库分类
根据代码库分布的位置及作用，分为以下几类：
主库：位于服务端，所有开发的代码最终都要合到主库。
个人代码库（服务端）：从主库fork出来，位于服务端。每个人自已开发的代码，由本地的git库push到每个人自己的个人代码库（服务端），再由个人代码库（服务端）合入主加。
个人工作库：位于每个开发人员的开发机器，从个人代码库（服务端）clone到本地。每个开发人员开发的代码，先commit到个人工作库，再由个人工作库push到个人代码库（服务端）。
人员角色分类
这里说的角色，都是人员在主库上的角色。基于简化的原则，人员分为三类：
Owner：拥有主库的所有权限。
Committer：具有将开发人员的合并需求（MR）合入主库的权限。基于安全考虑，我们设置为只能通过MR的方式将代码合入主库，而不能直接push到主库。
Developer：只能从自己的个人代码库（服务端）提交合并代码的请求（MR），是否能够合入，由Committer进行审核。
基本流程
在主库已经存在的情况下，日常操作流程如下：
开发人员从主库fork出自己的个人代码库。
开发人员将自己的个人代码库clone到本地，即个人工作库。
开发人员在开发了新代码后（包括新增和修改），先将代码commit到自己的个人工作库，再由个人工作库push到个人代码库。
开发人员提交从个人工作库到主库的MR，Committer审核后，决定是否将MR合入主库。
每个开发人员从主库pull最新代码到个人工作库。
分支管理
主库缺省的master分支，是用来向生产环境发布的，所有合入的代码，原则上都必须是稳定的。
主库除了master分支外，至少还要有一个活动分支，命名建议为：br_工程名_active，平时日常的开发都基于活动分支开发。即从个人工作库提交MR到主库时，指向的是主库的活动分支。活动分支测试稳定后，将主库的活动分支通过MR的形式，合并到主库的master分支，同时打上tag。
如果软件运行过程中发现必须立即修改的bug，则从主库的master分支中，拉出一个bugfix分支。为修复这个bug的所有开发，都基于bugfix分支。待bugfix分支开发完成，并测试稳定后，将bugfix分支以MR的方合入主库的master分支。然后删除bugfix分支，视情况决定是否打tag。
常见问题

此部分内容会根据情况进行相应的增加。

活动分支合入主分支时发生冲突
产生原因
平时基于活动分支开发，如果这个过程中为了修复bug而拉了一个bugfix分支，当bugfix分支开发完成并合入master分支后，如果bugfix分支和活动分支修改了相同的文件，则在活动分支合入master分支时就会产生冲突。
解决方法
从个人代码库（服务端）clone一个库到本地，即专门用于合并的个人工作库。（也可以用之前的个人工作库，但初学都容易混淆，建议单独clone一个。）
从主库的活动分支上pull最新的代码到本地。
从主库的master分支上pull最新的代码到本地。
此时会产生冲突，手工修复冲突，然后先commit到本地的个人工作库，再push到个人代码库（服务端）。
提交从个人工作库（服务端）到主库的MR（此时不会再有冲突），然后由Committer审核后将MR合入主库。

转载于:https://my.oschina.net/toothlou/blog/1585924

版本管理(Revision control)是一种软件工程方法，在开发的过程中，确保由不同开发人员编辑的同一档案都得到更新。代码版本管理其实就是我们在日常的开发过程中，将每天、每个阶段、每个功能等要求完成之后，将我们的代码再提供给他人的一种行为。
这个行为的目的就是，让每一个人的开发过程都有据可查，最后实现多人合作开发的目的。
目前市面上比较流行的是通过 Git 进行代码版本管理，因为它易于学习，占用内存小，具有闪电般快速的性能，
规范且流程化的版本管理，不仅能有效的提升代码质量，而且还能帮助项目团队有序协同，轻松提升研发效能，那么Git 代码版本管理的规范化流程有哪些呢？
基于 Git 的代码版本管理主要包括：代码库的分布、人员角色的划分、代码提交合并流程、代码冲突处理、分支管理。
代码库分类
根据代码库分布的位置及作用，分为以下几类：
主仓库：位于服务端，所有开发的代码最终都要合到主仓库。
个人代码库(服务端)：从主仓库 fork 出来，位于服务端。每个人自已开发的代码，由本地的 Git 库 push 到每个人自己的个人代码库(服务端)，再由个人代码库(服务端)合入主仓库。
个人工作库：位于每个开发人员的开发机器，从个人代码库(服务端)clone 到本地。每个开发人员开发的代码，先 commit 到个人工作库，再由个人工作库 push 到个人代码库(服务端)。
人员角色分类
这里说的角色，都是人员在主仓库上的角色。基于简化的原则，人员分为三类：
Owner：拥有主仓库的所有权限。
Committer：具有将开发人员的合并需求(PR)合入主仓库的权限。基于安全考虑，我们设置为只能通过 PR 的方式将代码合入主仓库，而不能直接 push 到主仓库。
Developer：只能从自己的个人代码库(服务端)提交合并代码的请求(PR)，是否能够合入，由 Committer 进行审核。
以 Gitee 企业版为例，Developer 进行 PR 后有权限的 Committer 需要对代码进行审查，审查通过后方可进行合并。
基本流程
在主仓库已经存在的情况下，日常操作流程如下：
开发人员从主仓库 fork 出自己的个人代码库。
开发人员将自己的个人代码库 clone 到本地，即个人工作库。
开发人员在开发了新代码后(包括新增和修改)，先将代码 commit 到自己的个人工作库，再由个人工作库 push 到个人代码库。
开发人员提交从个人工作库到主仓库的 PR，Committer 审核后，决定是否将 PR 合入主仓库。
每个开发人员从主仓库 pull 最新代码到个人工作库。
分支管理
主仓库缺省的 master 分支，是用来向生产环境发布的，所有合入的代码，原则上都必须是稳定的。
主仓库除了 master 分支外，至少还要有一个活动分支，命名建议为：br_工程名_active，平时日常的开发都基于活动分支开发。即从个人工作库提交 PR 到主仓库时，指向的是主仓库的活动分支。活动分支测试稳定后，将主仓库的活动分支通过 PR 的形式，合并到主仓库的 master 分支，同时打上 tag。
如果软件运行过程中发现必须立即修改的 Bug，则从主仓库的 master 分支中，拉出一个 bugfix 分支。为修复这个 Bug 的所有开发，都基于 bugfix 分支。待 bugfix 分支开发完成，并测试稳定后，将 bugfix 分支以 PR 的方合入主仓库的 master 分支。然后删除 bugfix 分支，视情况决定是否打 tag。
在生产开发协作的实际过程中，出于内部控制的考量，往往需要自定义拥有某些关键分支推送(push)和合并(merge)权限的人群。
以 Gitee企业版为例，可以采用「分支状态」中的「保护分支」功能。被设为保护分支之后，该分支只允许对应的「保护分支规则」内选中的仓库成员对此分支进行合并/推送操作。
常见问题
此部分内容会根据情况进行相应的增加。
活动分支合入主分支时发生冲突
产生原因
平时基于活动分支开发，如果这个过程中为了修复 Bug 而拉了一个 bugfix 分支，当 bugfix 分支开发完成并合入 master 分支后，如果 bugfix 分支和活动分支修改了相同的文件，则在活动分支合入 master 分支时就会产生冲突。
解决方法
从个人代码库(服务端)clone 一个库到本地，即专门用于合并的个人工作库。(也可以用之前的个人工作库，但初学都容易混淆，建议单独 clone 一个。)
从主仓库的活动分支上 pull 最新的代码到本地。
从主仓库的 master 分支上 pull 最新的代码到本地。
此时会产生冲突，手工修复冲突，然后先 commit 到本地的个人工作库，再 push 到个人代码库(服务端)。
提交从个人工作库(服务端)到主仓库的 PR(此时不会再有冲突)，然后由 Committer 审核后将PR合入主仓库。
不单是在研发团队的工作中，在开源项目中也同样需要规范的版本管理。而对初学者而言，我们建议在开始进行实践小项目的阶段即进行规范的版本管理，因为在以后的工作中代码版本管理将会是一项非常重要的技能。