Gitのワークフロー
限り、人々がプロジェクトに関与しているとして、あなたは正しいGitのワークフローを使用する必要があります。
ここでは、シンプルで効果的なワークフローがあります。
シーン
Facebookの次の世代を開発するプロジェクトがあるとし、プロジェクトの技術的リーダーである、あなたのチームは、3人の開発者があります。
- アリス：1年の経験
- ボブ：1年の経験
- ジョン：開発経験の3年
- あなたすることでプロジェクトの技術リーダー：
開発プロセスでのGit
メインブランチのmasterブランチ
1）常にメイン支線製品のコードが含まれています。
主枝ラインは、コードのコピーであるため、2）技術的なリーダーを含む任意の人物は、メインブランチ上で直接コードを編集することはできません。
3）コードの開発は、他の支店で行われます。
リリースブランチリリースブランチ
1）プロジェクト開始後、最初のプロジェクトのリリースブランチを作成し、masterブランチから出て作成されました。
2）すべての項目は、このリリースのブランチでは、このリリースブランチのコードになりますのみ「に、普通のブランチでリリース/先頭に」。
名前の私たちのプロジェクトへの3）リリースブランチの例「リリース/ FB。」
4）また、そのため、例えば、今と呼ばれるプロジェクトがあり、項目ごとに別々のリリースブランチを作成し、開発中のプロジェクトの数を有していてもよい「リリース/メッセンジャーが。」
5）リリースブランチ目的は、複数のプロジェクト間で影響を与えることはありません。
フィーチャーブランチ機能ブランチ
この機能は別々に開発されていることを保証するために、各機能を開発するとき1）機能ブランチを作成します。
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
推荐阅读：
