Graphic and text explain how to use Git+Github for team collaboration development

In team collaborative development, most of the version control software is used, such as Git, Svn, etc. This article will use an example to explain in detail how a team should use Git+Github for collaborative development in a real working environment, that is, to explain the Git workflow in detail. And answer the more difficult questions, such as how to resolve conflicts more appropriately, how to establish various types of branches, etc.

This article will not explain the introduction of Git, the principle of Git, the basic usage of Git, etc. If you don't understand, you can refer to "Git Reference Manual". We demonstrate the function of GitFlow workflow as an example. Here is a classic GitFlow workflow diagram:

The main branch types involved are:

• The master branch is the main branch. Any project must have this branch. Operations such as tagging or releasing versions of a project must be performed on this branch.

• The develop branch, the development branch, is checked out from the master branch. Team members generally do not directly change this branch, but check out their own feature branches from this branch, and merge the changes on the feature branch back to the develop branch after the development is completed. At the same time the release branch is checked out from this branch.

• The release branch, the release branch, is checked out from the develop branch. This branch is used as a pre-release test for simple bug fixes. If the bug fix is ​​complicated, you can merge it back to the develop branch and then fix the bug from another branch. After the test of this branch is completed, it needs to be merged to the master and develop branches at the same time.

• The feature branch, that is, the feature branch, is checked out from the develop branch. Each member of the team maintains a feature branch and performs development work. After the development is completed, this branch is merged back to the develop branch. This branch is generally used to develop new features or perform project maintenance, etc.

• The fix branch, that is, the patch branch, is checked out by the develop branch and used for bug fixes. After the bug fixes are completed, it needs to be merged back to the develop branch and deleted. So this branch is a temporary branch.

• hotfix分支，即热补丁分支。和fix分支的区别在于，该分支由master分支检出，进行线上版本的bug修复，修复完成后merge回master分支，并merge到develop分支上，merge完成后也可以将其删除，也属于临时性分支。

下边我们一步步拆分讲解各种类型分支的用法。

（1）假设团队就一个人“xianhu”，做一个叫TestGit的项目，并将其代码托管在Github上。首先需要在Github上新建一个项目TestGit：

按照Github上的提示，在本地新建一个项目，并关联到Github上的orgin/master。此时开发一个很小的demo功能，并提交到线上，并在master分支上进行打tag操作，并命名为v0.1。此时的GitFlow工作流为：

（2）如果此时master分支的代码正在线上运行，而且又需要开发新功能，则不能在master分支上直接修改。一个比较好的策略是在master分支上新建并检出develop分支，新功能的开发在develop分支上进行，此时记得将develop分支提交到远端：

git branch develop master    # 从master分支上新建develop分支
git checkout develop    # 检出develop分支
# 此处可进行功能开发，并add和commit到develop分支
git push origin develop    # 推送develop分支到远端的origin/develop

即Github上保持两个分支：master和develop。目的是为以后团队协作更新develop分支做准备。此时Github上为：

此时会出现两种情况：

• 线上版本的代码（master分支）出现了紧急bug，需要修复。这里用到了hotfix分支。

• git checkout master    # 切换回master分支
  git checkout -b hotfix master    # 新建hotfix分支，并切换到该分支
  # 做一些bug修复工作
  git checkout master    # 切换回master分支
  git merge --no-ff hotfix    # 合并hotfix分支，此时bug已被修复（无冲突）
  git tag v0.2    # 新建tag v0.2
  git push origin master    # 推送master分支代码到远端
  git push origin --tags    # 推送tag到远端

• develop分支上的功能开发完成了，需要进行测试和提交。这里用到了release分支。

• git checkout develop    # 切换回develop分支
  git checkout -b release01 develop    # 新建release分支，并切换到该分支
  
  # 做一些测试、bug修复等工作
  
  git checkout develop    # 切换回develop分支
  git merge --no-ff release01  # 合并release01分支到develop分支（无冲突）
  git push origin develop    # 推送develop分支到远端
  
  git checkout master    # 切换回master分支
  git merge --no-ff release01   # 合并release01分支到master分支（无冲突）
  git tag v0.3    # 新建tag v0.3
  git push origin master    # 推送master分支代码到远端
  git push origin --tags    # 推送tag到远端

此时GitFlow工作流为：

（3）这里可以继续develop分支，并不断push到远端。此时如果团队成员增加，多人需要开发不同的功能，这里就会用到feature分支。团队中的每个人都从Github克隆一个项目，然后新建自己的feature分支。

git clone xxxx.git
git checkout develop
git checkout -b feature-xx develop    # 从develop分支新建并检出feature分支

此时“xianhu”做如下操作，并首先第一个提交到了Github远端：

git checkout -b feature-hu develop    # 从develop分支新建并检出feature分支
# 这里可以进行一些功能开发，并不断的add和commit
git checkout develop    # 切换回develop分支
git pull origin develop    # 更新远端代码，看develop分支是否有更新（无更新）
git checkout feature-hu    # 切换回feature分支
git rebase develop    # 合并develop分支到feature分支，并解决冲突（无冲突）
git checkout develop    # 切换回develop分支
git merge --no-ff feature-hu    # 合并feature分支到develop分支
git push origin develop   # 推送develop分支到远端

此时的GitFlow工作流为：

对于团队其他成员，比如zz，操作如下，并打算在“xianhu”提交后进行push操作：

git checkout -b feature-zz develop    # 从develop分支新建并检出feature分支
# 这里可以进行一些功能开发，并不断的add和commit
git checkout develop    # 切换回develop分支
git pull origin develop    # 更新远端代码，看develop分支是否有更新（有更新）
git checkout feature-hu    # 切换回feature分支
git rebase develop    # 合并develop分支到feature分支，并解决冲突（有冲突）
# 这里需要进行冲突解决
git add .    # 解决完冲突之后执行add操作
git rebase --continue    # 继续刚才的rebase操作
git checkout develop    # 切换回develop分支
git merge --no-ff feature-zz    # 合并feature分支到develop分支（无冲突）
git push origin develop   # 推送develop分支到远端

如果团队成员在合并feature分支到develop分支后还需要继续开发，则检出自己的feature分支继续操作，并重复上述过程即可。这里需要注意--no-ff参数，其目的是让commit的流程更加清晰，具体为什么可自行百度。

xianhu这边进行pull操作，即可看到zz进行的操作。此时的GitFlow工作流为：

（4）如果此时需要进行测试、发版操作，则需要再次新建并检出release分支，重复（2）的步骤。完成之后的GitFlow工作流为：

这里就完成了从版本v0.1到v1.0的迭代开发，并详细解释了如何利用Git+Github进行团队协作开发。文章中没有用到fix分支，这种分支的用法和feature分支类似，大家可以自己体会。

最后详细解释一下上张图：

• xianhu在master分支上完成v0.1版本开发，“done demo in master”
• 发现master分支上有bug，需紧急修复。新建并检出hotfix分支进行bug修复，并merge回master分支，发布版本v0.2。
• xianhu新建并检出develop分支进行迭代开发，然后在develop分支上检出release01分支，进行发版前测试和bug修复。“fix bugs in release01”，完成后将release01分支merge回develop和master分支，并在master分支上发布版本v0.3。
• xianhu继续开发develop分支。此时团队成员增加，团队中的每个人都在develop的基础上新建并检出自己的feature分支，开发完成后merge回develop分支。这里利用到了rebase操作和冲突解决等，需要特别注意一点步骤。
• xianhu在develop分支上检出release02分支，再次进行发版前测试和bug修复，“fix bugs in release02”，完成后将release02分支merge回develop和master分支，并在master分支上发布版本v1.0。

这里只用到和解释了GitFlow工作流，团队协作开发也可以用Pull Requests或者其他方式，找一个合适自己团队和具体业务的协作方式即可。另外，Git博大精深，想要完全精通也绝非易事，只能是一边学一边用。

 

 

来自：https://zhuanlan.zhihu.com/p/23478654