git分支开发流程心得体会

最近项目中切换到git版本控制进行开发，开发工程中多有不顺，在此写篇心得体会，为什么说是心得体会，因为如何使用git的相关技术都会，或者在网上查查就行(好记性不如烂笔头)，但是使用经验这块确无法和技术进行对比，经验只有在实践中才能有所觉悟。

在上一家单位也使用过git，但是只是把git当成了svn进行，在此中有相关问题总结过：

问题1：

别人提交了代码，你先不跟新的前提下，你项目的的代码提交能否提交成功？

             不能提交成功，别人提交了代码，若你没有更新，直接提交你的代码是会提交不上的，得先pull后在进行commit。

问题2：

如何解决冲突?

              commit发现提交不上，pull时候会看到冲突文件，先手动解决冲突，提交时候:

              1.Add to Index

               2.commit 

-----------------------------------------------------------------------------------------------------------分割线-----------------------------------------------------------------------------------------------------------------------

在使用git分支中的使用又不太一样，使用流程如下：

1.创建分支

2.切换到该分支在该分支上进行开发

3.合并到主分支

补补分支，gitlab上面常用分支说明：

1. Master  

        顾名思义，既然名字叫Master，那么该分支就是主分支的意思。在git repo下主分支的职责主要就是负责记录stable版本的迭代，当在beta版本的项目或是开发版本的项目得到了充分的验证之后，我才能将分支并入master分支。master分支永远是production-ready的状态，即稳定可产品化发布的状态。

2. Develop

          这个分支就是我们平常开发的一个主要分支了，不管是要做新的feature还是需要做bug fix，都是从这个分支分出来做。在这个分支下主要负责记录开发状态下相对稳定的版本，即完成了某个feature或者修复了某个bug后的开发稳定版本。

3. Feature branches

       这是由许多分别负责不同feature开发的分支组成的一个分支系列。new feature主要就在这个分支系列下进行开发。当我在一个大的develop的迭代之下，往往我们会把每一个迭代分成很多个功能点，并将功能点分派给不同人的人员去开发。每一个人员开发的功能点就会形成一个feature分支，当功能点开发测试完毕之后，就会合并到develop分支去。

总的来说就是：

a.Master分支是受保护的分支，应该禁止开发人员像master往上面提交代码以及合并(marged)代码.

b.Develop分支也是受保护的分支，禁止开发人员像develop上面提交代码，但是可以让其他分支代码合并(marged)代码。

c.Feature branches分支是开发人员随意创建的分支，权限比较大，随意删除，marged到其他分支都没问题。

从上面这张流程图可以看出git的整个流程图(release brance和hotfixes分支除外)，从develop上面切换出去的分支在各自的上面进行开发，最后合并到develop上面去，master分支在从develop分支上面marger成一个release版本。