我认识的Git-Git工作流

WorkFlow 的字面意思，工作流，即工作流程。工作流不涉及任何命令，因为它就是一个规则，完全由开发者自定义，并且自遵守。

集中式工作流

集中式工作流以中央仓库作为项目所有修改的单点实体。相比svn缺省的开发分支trunk，git叫做master，所有修改提交到这个分支上。集中式工作流只用到master这个分支。

功能分支工作流

功能分支工作流背后的核心思路是所有的功能开发应该在一个专门的分支，而不是在master分支上。这个隔离可以方便多个开发者在各自的功能上开发而不会弄乱主干代码。另外，也保证了master分支的代码一定不会是有问题的，极大有利于集成环境。

功能开发隔离也让pull requests工作流成功可能，pull requests工作流能为每个分支发起一个讨论，在分支合入正式项目之前，给其它开发者有表示赞同的机会。另外，如果你在功能开发中有问题卡住了，可以开一个pull requests来向同学们征求建议。这些做法的重点就是，pull requests让团队成员之间互相评论工作变成非常方便！

Code Review是Pull Requests的一个重要的收益，但Pull Requests目的是讨论代码一个通用方式。你可以把Pull Requests作为专门给某个分支的讨论。这意味着可以在更早的开发过程中就可以进行Code Review。比如，一个开发者开发功能需要帮助时，要做的就是发起一个Pull Request，相关的人就会自动收到通知，在相关的提交旁边能看到需要帮助解决的问题。

Pull Request工作流

Pull Requests在【github.com】上方便开发者之间协作的功能。它提供了一个用户友好的Web界面，在集成提交的变更到正式项目前可以对变更进行讨论。

开发者向团队成员通知功能开发已经完成，Pull Requests是最简单的用法。开发者完成功能开发后，通过【github.com】账号发起一个Pull Request。这样让涉及这个功能的所有人知道，要去做Code Review和合并到master分支。

但是，Pull Request远不止一个简单的通知，而是为讨论提交的功能的一个专门论坛。如果变更有任何问题，团队成员反馈在Pull Request中，甚至push新的提交微调功能。所有的这些活动都直接跟踪在Pull Request中。

当要发起一个Pull Request，你所要做的就是请求（Request）另一个开发者（比如项目的维护者），来pull你仓库中一个分支到他的仓库中。这意味着你要提供4个信息（源仓库、源分支、目的仓库、目的分支），以发起Pull Request。

工作方式

Pull Request可以和功能分支工作流、Gitflow工作流或Forking工作流一起使用。但Pull Request要求要么分支不同，要么仓库不同，所以不能用于集中式工作流。在不同的工作流中使用Pull Request会有一些不同，但基本的过程是这样的：

• 开发者在本地仓库中新建一个专门的分支开发功能。
• 开发者push分支修改到公开的【github.com】仓库中。
• 开发者通过【github.com】发起一个Pull Request。
• 团队的其它成员review code，讨论并修改。
• 项目维护者合并功能到官方仓库中并关闭Pull Request。

Gitflow工作流

这节介绍的Gitflow工作流借鉴自在nvie的Vincent Driessen。

Git Flow 的分支结构很特别，按功能来说，可以分支为5种分支，从5 种分支的生命时间上，又可以分别归类为长期分支和暂时分支，或者更贴切描述为，主要分支和协助分支。

Gitflow工作流没有用超出功能分支工作流的概念和命令，而是为不同的分支分配一个很明确的角色，并定义分支之间如何和什么时候进行交互。除了使用功能分支，在做准备、维护和记录发布也使用各自的分支。当然你可以用上功能分支工作流所有的好处：Pull Requests、隔离实验性开发和更高效的协作。

GitLab 既支持 Git Flow 的分支策略，也有 GitHub Flow 的 Pull Request（ Merge Request ） 和 issue tracking。

工作方式

Gitflow工作流仍然用中央仓库作为所有开发者的交互中心。和其它的工作流一样，开发者在本地工作并push分支到要中央仓库中。

Git 在团队中的最佳实践--如何正确使用Git Flow

git flow精简模型

1，有特殊含义的分支只有三种：master、release、feature。master分支为主干，其含义是master分支代码就是线上跑的代码；release分支为发布分支，它会承载功能发布、QA回归等流程；feature分支为功能分支，它承载了具体的功能开发，所有的开发者都将基于feature分支签出自己的个人开发分支。

2，从master签出的分支只能是release和feature分支，master上的改动必然都是来自release分支。换句话说，除了release分支，其他的所有类型的分支都不允许直接合并到master分支。这一点是强硬要求，否则无法保证master分支的代码质量。言下之意，master上的代码都是来自release分支，而release分支都是经过QA回归过，有质量把关的。

3，master、release、feature这三个分支的签出与合并都由一个人来操作，其他人没有操作权限。我们把这个人称之为pudge，屠夫的意思，因为都是通过pudge切割出来一个个核心分支。一般pudge还有一个backup。

4，当有开发任务过来时，pudge按照具体的业务从当前的master分支签出带有业务标识的feature分支，比如 feature-finds-20161212 ，同时分支会带有时间戳来表达此分支大致的生命周期。

5，具体的开发人员按照自己的工种和定位，从 feature-finds-20161212 上签出自己的开发分支，我们称之为RD分支。即图中的RD1，RD2，RD3分支。RD分支一般而已都是相互独立的，分支名不作要求。因为除了开发者自己，其他人理论上是不会关注某一个具体的RD分支的。当然，同一个feature分支上可以签出多个RD分支，环境相互隔离。

6，经过一段时间的开发后，RD分支完成自己的开发任务了，开发者要主动将自己的RD分支合并至feature分支。这个合并过程中，在不同的场景下，可能会有一些额外的操作。比如RD分支游离的时间过长，开发者可以先同步feature分支到自己的RD分支，然后再合并。开发者也可以在合并的时候走Merge Request流程，将Code Reviewer指定为他人或自己。理论上MR在此环节的合并不作强硬要求。

7，RD分支合并进feature分支之后，通过测试人员针对feature分支进行QA。也就说，测试人员只关注feature分支，其他的RD分支不需要care。

8，若测试在feature上QA时发现有问题，通过相关的开发去修复。开发在自己的RD分支进行bugfix，完毕后再次合并到feature。通知测试人员进行回归。

9，若feature分支的测试无问题，确定可以上线。此时通知pudge从master签出带有日期版本号的release分支，然后通过Merge Request将feature分支合并进release分支。这一步有两个关键点，一个是由pudge从master签出release分支，另一个是由pudge来操作feature分支通过MR的方式合并进release分支。此外，当某一个release节点需要同时发布多个feature分支，那我们就针对多个feature分支重复7，8，9。

10，测试人员在release分支上进行回归。若无问题，即对release分支走上线流程（注意：这里是对release而不是master）。上线完毕，由pudge将release分支合并进master。若release的回归出现问题，则重复8，9。

11，若需要紧急处理线上问题或者一些小问题，比如文案修复之类的。由pudge从master签出release分支，通知相关开发人员评估工作量，能否直接在release上修改，还是需要走更多的分支流程，灵活处理。

主要的流程和场景如上所述，应该条理还是比较清晰的。所有的流程中，有一个关键角色，就是pudge。基本上核心分支的签出、合并、MR操作都是由这个人来完成。其他的开发和测试，只需要关注自己需要关心的分支即可，其他的不用关注。在具体的开发工作中，若遇到一些不太好处理的分支操作，也都交由pudge来处理。

Forking工作流

这种工作流不是使用单个服务端仓库作为『中央』代码基线，而让各个开发者都有一个服务端仓库。

效果就是一个分布式的工作流，能为大型、自发性的团队（包括了不受信的第三方）提供灵活的方式来安全的协作。也让这个工作流成为开源项目的理想工作流。

Git使用交流

莫名的错误

有好几次，发现莫名的错误，推荐不上代码，拉取不到代码，结果是本地使用者的git版本太久了，更新到最新版，或者比较新的版本，问题就解决了；类似情况我遇到过不下3次之多

记住git密码

设置记住密码（默认15分钟）：

git config --global credential.helper cache
如果想自己设置时间，可以这样做：

git config credential.helper 'cache --timeout=3600'
这样就设置一个小时之后失效

长期存储密码：

git config --global credential.helper store

如何判断已知的 commitId 是否已经合并到了master分支？

git log |grep commitId

or

git log master，然后直接搜索commitId就行