Git workflow
As long as people are involved in the project, then you need to use the correct Git workflow.
Here's a simple and effective workflow.
Scenes
Suppose there is a project to develop the next generation of Facebook, you are the technical leader of the project, your team has three developers:
- Alice : 1 year experience
- Bob : 1 year experience
- John : 3 years of development experience
- By You : technical leader of the project
Git in the development process
Master branch of the main branch
1) always contains the code of the main branch line products.
2) Any person, including technical Leader, are not allowed to edit the code directly on the main branch, because the main branch line is a copy of the code.
3) the development of the code is done in other branches.
Release branch release branch
After 1) project started, first create a Release branch for the project, was created out of the Master branch.
2) All items will be on the code in this Release branch in this Release branch is just an ordinary branch, only to " Release / " at the beginning.
3) Release branch example to our project named " Release / fb ."
4) may also have a number of projects in development, therefore, create a separate Release branch for each item, for example, now there is a project called " Release / Messenger ."
5) Release branch purpose is not to affect between multiple projects.
Feature branch feature branch
1) creates a Feature branch when developing each function to ensure that this function is developed separately.
2）Feature branch 是以 “feature/” 为前缀名的普通分支。
3）你作为技术leader，现在让 Alice 去开发登录功能，所以 Alice 创建了一个新的 Feature branch，叫做 “feature/login”，然后在这个分支中开发登录功能。
4）Feature branch 通常是从 Release branch 中创建出来的。
5）你让 Bob 开发加好友的功能，Bob 就创建了一个 Feature branch，命名为 “feature/friendrequest”。
6）John 的任务是创建新闻 feed 流，他创建了 “feature/newsfeed”。
7）每个程序员都在自己的 Feature branch 中进行开发。
8）现在，Alice 的登录功能开发完了，需要把自己 feature/login 分支中的代码发到 release/fb 中，可以通过 pull request。
pull request
首先，不要把 pull request 和 git pull 混淆了。
开发人员不能直接把自己分支中的代码推到 release branch 中。
技术 leader 先要做个 review，检查一下代码。
这就是通过 pull request 做的。
例如 GitHub 中的操作流程：
点击 “New pull request” 后：
- compare 是 Alice 自己的 feature/login 开发分支。
- base 是项目的 release/fb 发布分支。
之后，Alice 输入一个标题和描述，最后点击 “Create Pull Request”。
Alice 需要为这个 pull request 分配一个 reviewer，就是你。
然后你就可以对 pull request 的代码进行 review 了，没问题后就可以把 feature/login 合并到 release/fb 了，此时 Alice 这个功能的代码就算成功提交了。
代码冲突
1）Bob 开发完了，也发起了一个 pull request，从 feature/friendrequest 到 release/fb。
2）因为 release branch 已经有了 Alice 提交的登录代码，所以代码冲突就发生了。你作为技术leader，有责任去解决冲突，然后合并分支。
3）现在 John 开发完了，因为 John 开发经验比 Alice 和 Bob 都丰富，John 自己处理了代码冲突。John 从 release/fb 拿到最新的代码放到自己的 feature/newsfeed （通过 git pull 或 git merge），并处理了所有的冲突。
4）John 发起了一个 pull request，这时你就省心了，不用你来解决代码冲突了。
所以，解决代码冲突的2个途径：
- 负责 pull request review 的人来处理。
- 开发人员自己处理，把最新的 release branch 合并到自己的 feature branch，解决掉所有代码冲突。
回到 Master branch
项目开发完成后，release 分支合并回 master 分支。
翻译整理自：
https://medium.com/free-code-camp/how-to-use-git-efficiently-54320a236369
推荐阅读：
