Git のワークフローでシンプルに

Nicola Paolucci
Nicola Paolucci
リストに戻る

数多くのチームが既に git に移行し、さらに多くのチームが現在移行中です。個々の開発者を訓練し、git の採用を支援する優秀な人材を任命するだけでなく、物事が複雑になりすぎないように、適切で簡単なコード コラボレーション手法を選ぶことが欠かせません。Gitの場合、非常に複雑なワークフローをあっという間に作り出すことが実際に可能です。私はそうしたワークフローをじかに見てきました。

A manual on workflows does not come pre-installed with git, but maybe it should seeing how many people have questions on the topic. The good news is that we're working hard to write material that helps.

ワークフローに関する最近のウェビナーおよびガイド

If you prefer reading and pretty pictures, one of the most popular sections of our git tutorial site is the workflows section.

ただし、これらのセクションを探索する前に、もうしばらくお付き合い下さい。非常にクールな話をお伝えします。

I want to detail a terse but complete description of a simple workflow for continuous delivery. The prerequisite is that you and your team are at least a little bit acquainted with git, and have good knowledge of the rebase command in the two forms (interactive and not).

継続的デリバリーにおけるブランチ ワークフローの基本中の基本

私が説明したい簡単なワークフローには、二つのガイド的な原則が存在します。

  • master is always production-like and deployable.
  • rebase during feature development, explicit (non fast-forward) merge when done.

Pulling change-sets using rebase rewrites the history of the branch you're working on and keeps your changes on top.

Simple git-workflow

The rebase you want in this workflow is the one in the second picture.

これらのガイド的な原則を学んだところで、七つのステップを解説していきましょう。

1. Start by pulling down the latest changes from master

This is done easily with the common git commands:

git checkout master
git fetch origin
git merge master

I like to be more explicit and use fetch/merge but the two commands are equivalent to: git pull origin master.

2. フィーチャー分離あるいはバグ修正作業のためにブランチを作成する

次に、機能あるいはバグ修正のためにブランチを作成します。

git checkout -b PRJ-123-awesome-feature

ここでお見せしているブランチ名構造は単に我々が使用しているものであり、皆さんは慣れ親しんだやり方を選んで頂いて結構です。

3. フィーチャーに関する作業を開始する

必要なだけの時間を割いて、機能の作業を行って下さい。必ず、コミットは有意義なものにして、別々の変更内容のクラスタリングを行わないで下さい。

4. To keep your feature branch fresh and up to date with the latest changes in master, use rebase

Every once in a while during the development update the feature branch with the latest changes in master. You can do this with:

git fetch origin
git rebase origin/master

In the (somewhat less common) case where other people are also working on the same shared remote feature branch, also rebase changes coming from it:

git rebase origin/PRJ-123-awesome-feature

この時点で、リベースから出現する一切のコンフリクトを解決します。

Resolving conflicts during the rebase allows you to have always clean merges at the end of the feature development. It also keeps your feature branch history clean and focused without spurious noise.

5. フィードバックを受ける準備が整ったら遠隔的にブランチをプッシュして、プルリクエストを作成する

作業内容を共有して、フィードバックを受ける準備が整った場合、以下の方法でブランチを遠隔的にプッシュします

git push -u origin PRJ-123-awesome-feature

(if the branch is already set as 'upstream' and your remote is called 'origin', 'git push' is enough)

Now you can create a pull request on your favorite git server (for example Bitbucket Server or Bitbucket Cloud).

最初のプッシュ後は、リモートブランチに何度もアップデートをプッシュし続けられます。これは、フィードバックに対する反応、あるいは機能開発がまだ終了していない場合に発生する可能性があります。

6. Perform a final rebase cleanup after the pull request has been approved

After the review is done, it's good to perform a final cleanup and scrub of the feature branch commit history to remove spurious commits that are not providing relevant information. In some cases – if your team is experienced and they can handle it – you can rebase also during development, but I strongly advise against it.:

git rebase -i origin/master

(At this point if you have rewritten the history of a published branch and provided that no one else will commit to it or use it, you might need to push your changes using the --force flag).

7. 開発の完了後は、明示的なマージを記録する

When finished with the development of the feature branch and reviewers have reviewed your work, merge using the flag --no-ff. This will preserve the context of the work and will make it easy to revert the whole feature if needed. Here are the commands:

git checkout master
git pull origin master

git merge --no-ff PRJ-123-awesome-feature

If you followed the advice above and you have used rebase to keep your feature branch up to date, the actual merge commit will not include any changes; this is cool! The merge commit becomes just a marker that stores the context about the feature branch.

For more information have a look at my recent article on the pros and cons of enforcing a merge vs rebase workflow.

Useful .gitconfig option to toggle:

You can instruct git so that any pull uses rebase instead than merge and it preserves while doing so:

git config --global branch.autosetuprebase always 
git config --global pull.rebase preserve #(this is a very recent and useful addition that appeared in git 1.8.5)

Not everyone likes to change the default behavior of core commands so you should only incorporate the above if you understand its implications. See Stack Overflow for details on preserve merges.

結論

This should give you plenty of material to get acquainted with workflows, branching models and code collaboration possibilities. For more git rocking follow me @durdn and the awesome @AtlDevtools team. Credits: Inspiration for this post comes partially from this concise and well made gist.

Git を学習する準備はできていますか?

この対話式チュートリアルを利用しましょう。

今すぐ始める