利用可能なワークフローがいくつもあることにより、Git を開発現場に組み込むに当たって何から着手するかの判断が困難になることがあります。このページでは、エンタープライズチーム向けの一般的な Git ワークフローを概観し、その着手点を明らかにします。

読み進めると分かることですが、ここで示すワークフローは厳密な規則ではなく、ガイドラインとして作成したものです。ここでは利用可能なワークフロー例を示しますので、各種ワークフローの様々な要素を組み合わせてお客様のニーズに合わせて利用してください。

集中化ワークフロー

Git ワークフロー: SVN スタイルのワークフロー

Transitioning to a distributed version control system may seem like a daunting task, but you don’t have to change your existing workflow to take advantage of Git. Your team can develop projects in the exact same way as they do with Subversion.

However, using Git to power your development workflow presents a few advantages over SVN. First, it gives every developer their own local copy of the entire project. This isolated environment lets each developer work independently of all other changes to a project—they can add commits to their local repository and completely forget about upstream developments until it's convenient for them.

第二は、Git の強力なブランチおよびマージモデルを利用することができる点です。SVN とは異なり、Git におけるブランチはコードの統合やリポジトリ間での変更の共有に当たってフェイルセーフメカニズムが機能するように設計されています。

動作の概要

Like Subversion, the Centralized Workflow uses a central repository to serve as the single point-of-entry for all changes to the project. Instead of trunk, the default development branch is called master and all changes are committed into this branch. This workflow doesn’t require any other branches besides master.

Developers start by cloning the central repository. In their own local copies of the project, they edit files and commit changes as they would with SVN; however, these new commits are stored locally—they’re completely isolated from the central repository. This lets developers defer synchronizing upstream until they’re at a convenient break point.

To publish changes to the official project, developers “push” their local master branch to the central repository. This is the equivalent of svn commit, except that it adds all of the local commits that aren’t already in the central master branch.

中央リポジトリとローカルリポジトリ

競合の管理

中央リポジトリはプロジェクトを公式に代表するものであり、そのコミット履歴は大切に扱わなければならず、また安易に改変してはなりません。開発者のローカルなコミット履歴が中央リポジトリと分岐状態にある場合は、中央リポジトリに誤書き込みを起こす可能性があるため、変更のプッシュは Git によって拒否されます。

競合の管理

この場合開発者は、フィーチャーを公開する前に最新の中央リポジトリをフェッチしてその先端にローカルな変更をリベースする必要があります。この操作は、「私の変更作業は皆が変更を完了したものをベースとして行いたい」と言うに等しいものです。その結果、履歴は従来の SVN ワークフローの場合と同様に完全に直線的になります。

If local changes directly conflict with upstream commits, Git will pause the rebasing process and give you a chance to manually resolve the conflicts. The nice thing about Git is that it uses the same git status and git add commands for both generating commits and resolving merge conflicts. This makes it easy for new developers to manage their own merges. Plus, if they get themselves into trouble, Git makes it very easy to abort the entire rebase and try again (or go find help).

典型的な小規模チームの場合にワークフローを利用してコラボレーションを行う方法をステップごとに説明します。ここでは、二人の開発者、John と Mary が別々のフィーチャーで作業を行ない、中央リポジトリを経由してその成果を共有する場合を考えます。

誰かが中央リポジトリを作成します

Git ワークフロー:中央リポジトリの初期化

最初に、誰かがサーバー上に中央リポジトリを作成しなければなりません。新規プロジェクトの場合は誰がそれを実行しても構いません。既存プロジェクトの場合は、既存の Git または SVN リポジトリをインポートする必要があります。

中央リポジトリは必ずベアリポジトリでなければならず (作業ディレクトリがあってはなりません)、そのようなベアリポジトリは次のようにして作成します:

ssh user@host git init --bare /path/to/repo.git

Be sure to use a valid SSH username for user, the domain or IP address of your server for host, and the location where you'd like to store your repo for /path/to/repo.git. Note that the .git extension is conventionally appended to the repository name to indicate that it’s a bare repository.

全員が中央リポジトリをクローンします

Git ワークフロー:中央リポジトリをクローンする

Next, each developer creates a local copy of the entire project. This is accomplished via the git clone command:

git clone ssh://user@host/path/to/repo.git

When you clone a repository, Git automatically adds a shortcut called origin that points back to the “parent” repository, under the assumption that you'll want to interact with it further on down the road.

John がフィーチャー開発作業を開始します

Git ワークフロー:編集、ステージ、コミット機能のプロセス

John は、このローカルリポジトリ上で、編集、ステージ、コミットなど通常の Git でのコミット操作を駆使してフィーチャー開発を行います。ステージになじみの薄い方のために説明を付け加えますが、ステージとは作業ディレクトリ内の変更の一部を取り出してそれをコミットする準備をすることです。このステージという機能により、多数のローカルな変更があったとしても焦点の明確なコミットを行うことができます。

git status # View the state of the repo
git add <some-file> # Stage a file
git commit # Commit a file</some-file>

既に説明したように、これらのコマンドはローカルなコミットを行うものであり、従って John は中央リポジトリで起こっていることを気にすることなくコミットを何度でも繰り返すことができます。これは、作業を単純で小規模な部分に分割する必要のある大規模フィーチャーの場合に特に有用な機能です。

Mary もフィーチャー開発作業を開始します

Git ワークフロー:編集、ステージ、コミット機能

Meanwhile, Mary is working on her own feature in her own local repository using the same edit/stage/commit process. Like John, she doesn’t care what’s going on in the central repository, and she really doesn’t care what John is doing in his local repository, since all local repositories are private.

John がフィーチャーを公開します

Git ワークフロー:フィーチャーの公開

Once John finishes his feature, he should publish his local commits to the central repository so other team members can access it. He can do this with the git push command, like so:

git push origin master

Remember that origin is the remote connection to the central repository that Git created when John cloned it. The master argument tells Git to try to make the origin’s master branch look like his local master branch. Since the central repository hasn’t been updated since John cloned it, this won’t result in any conflicts and the push will work as expected.

Mary がフィーチャーの公開を試みます

Git ワークフロー:プッシュコマンドエラー

John がローカルな変更を首尾よく中央リポジトリに公開した後で Mary がフィーチャーのプッシュを試みるとどうなるでしょうか。全く同様にプッシュコマンドを使用することはできます:

git push origin master

しかしながら、Mary のローカルリポジトリが中央リポジトリと分岐状態にあるため、プッシュリクエストは拒否され、長文のエラーメッセージが表示されます:

error: failed to push some refs to '/path/to/repo.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

この機能により、Mary が中央リポジトリに対して誤書き込みを起こすことが防止できます。Mary は、John による変更をローカルリポジトリにプルしてそれにローカルな変更を統合し、再度プッシュを試みなければなりません。

Mary が John のコミットの先端にリベースします

Git ワークフロー: Git Pull リベース

Mary can use git pull to incorporate upstream changes into her repository. This command is sort of like svn update—it pulls the entire upstream commit history into Mary’s local repository and tries to integrate it with her local commits:

git pull --rebase origin master

The --rebase option tells Git to move all of Mary’s commits to the tip of the master branch after synchronising it with the changes from the central repository, as shown below:

master に対するリベース

このフラグを指定しない場合もプルは可能ですが、その場合は中央リポジトリとの同期を行うたびに余計な「マージコミット」が発生します。このワークフローにおいては、三方向マージを行うのではなく常にリベースを行うことが推奨されます。

Mary がマージの競合を解決します

Git ワークフロー:コミットをリベースする

Rebasing works by transferring each local commit to the updated master branch one at a time. This means that you catch merge conflicts on a commit-by-commit basis rather than resolving all of them in one massive merge commit. This keeps your commits as focused as possible and makes for a clean project history. In turn, this makes it much easier to figure out where bugs were introduced and, if necessary, to roll back changes with minimal impact on the project.

Mary と John が作業しているフィーチャーが無関係なものであった場合は、リベースの際に競合が起こる可能性は小さいものと考えられます。それでも競合が起こった場合、リベース動作は処理中のコミットで停止され、次のようなメッセージと関連情報を表示します

CONFLICT (content): Merge conflict in <some-file>
競合の解決

The great thing about Git is that anyone can resolve their own merge conflicts. In our example, Mary would simply run a git status to see where the problem is. Conflicted files will appear in the Unmerged paths section:

# マージされていないパス:
# ("git reset HEAD <some-file>..." を使用してアンステージします)
# (必要に応じて "git add/rm <some-file>..." を使用し解決状況にマークを付けます)
#
# 両方とも修正済み: <some-file>

Then, she’ll edit the file(s) to her liking. Once she’s happy with the result, she can stage the file(s) in the usual fashion and let git rebase do the rest:

git add <some-file>
git rebase --continue

これがすべてです。Git の処理は次のコミットに移り、その後競合を発生するコミットがあれば同一の処理を繰り返します。

If you get to this point and realize and you have no idea what’s going on, don’t panic. Just execute the following command and you’ll be right back to where you started before you ran [git pull --rebase](/tutorials/syncing/git-pull):

git rebase --abort

Mary がフィーチャーの公開に成功しました

Git ワークフロー:中央リポジトリとの同期

中央リポジトリとの同期が完了すると、Mary は変更を公開することができるようになります:

git push origin master

次のステップ

ここまで説明してきたように、少数の Git コマンドのみを使用して Subversion を利用した従来型の開発環境を踏襲することが可能です。これは、SVN からの移行過程にあるチームにとっては非常に有用ですが、これではGit の分散的特質を活用できません。

If your team is comfortable with the Centralized Workflow but wants to streamline its collaboration efforts, it's definitely worth exploring the benefits of the Feature Branch Workflow. By dedicating an isolated branch to each feature, it’s possible to initiate in-depth discussions around new additions before integrating them into the official project.

フィーチャー ブランチ ワークフロー

フィーチャー ブランチ ワークフロー

Once you've got the hang of the Centralized Workflow, adding feature branches to your development process is an easy way to encourage collaboration and streamline communication between developers.

The core idea behind the Feature Branch Workflow is that all feature development should take place in a dedicated branch instead of the master branch. This encapsulation makes it easy for multiple developers to work on a particular feature without disturbing the main codebase. It also means the master branch will never contain broken code, which is a huge advantage for continuous integration environments.

Encapsulating feature development also makes it possible to leverage pull requests, which are a way to initiate discussions around a branch. They give other developers the opportunity to sign off on a feature before it gets integrated into the official project. Or, if you get stuck in the middle of a feature, you can open a pull request asking for suggestions from your colleagues. The point is, pull requests make it incredibly easy for your team to comment on each other’s work.

動作の概要

The Feature Branch Workflow still uses a central repository, and master still represents the official project history. But, instead of committing directly on their local master branch, developers create a new branch every time they start work on a new feature. Feature branches should have descriptive names, like animated-menu-items or issue-#1061. The idea is to give a clear, highly-focused purpose to each branch.

Git makes no technical distinction between the master branch and feature branches, so developers can edit, stage, and commit changes to a feature branch just as they did in the Centralized Workflow.

In addition, feature branches can (and should) be pushed to the central repository. This makes it possible to share a feature with other developers without touching any official code. Since master is the only “special” branch, storing several feature branches on the central repository doesn’t pose any problems. Of course, this is also a convenient way to back up everybody’s local commits.

プルリクエスト

Aside from isolating feature development, branches make it possible to discuss changes via pull requests. Once someone completes a feature, they don’t immediately merge it into master. Instead, they push the feature branch to the central server and file a pull request asking to merge their additions into master. This gives other developers an opportunity to review the changes before they become a part of the main codebase.

コードレビューができることはプルリクエストの最大の利点ですが、そもそもプルリクエストはコードに関する議論を広く行う一般的な手法として設計されています。従ってプルリクエストは、そのブランチを対象として広く議論する手段であると考えても構いません。このことは、プルリクエストを開発プロセスの初期段階から活用できることを意味します。例えば、開発者があるフィーチャーに関して何か助言が欲しくなった場合にもプルリクエストを送ることが効果的です。通知は自動的に届くため、関心のある者は問題としているコミットの次に書かれている質問事項を読むと期待されます。

Once a pull request is accepted, the actual act of publishing a feature is much the same as in the Centralized Workflow. First, you need to make sure your local master is synchronized with the upstream master. Then, you merge the feature branch into master and push the updated master back to the central repository.

Pull requests can be facilitated by product repository management solutions like Bitbucket Cloud or Bitbucket Server. View the Bitbucket Server pull requests documentation for an example.

下の例ではプルリクエストをコードレビューの手段として説明していますが、先に説明したようにプルリクエストは様々な目的に利用できることに留意してください。

Mary が新たなフィーチャー開発作業を開始します

新しいフィーチャーブランチ

Before she starts developing a feature, Mary needs an isolated branch to work on. She can request a new branch with the following command:

git checkout -b marys-feature master

This checks out a branch called marys-feature based on master, and the -b flag tells Git to create the branch if it doesn’t already exist. On this branch, Mary edits, stages, and commits changes in the usual fashion, building up her feature with as many commits as necessary:

git status
git add <some-file>
git commit

Mary が昼食休憩を取ります

Git ワークフロー:フィーチャーのコミット

Mary adds a few commits to her feature over the course of the morning. Before she leaves for lunch, it’s a good idea to push her feature branch up to the central repository. This serves as a convenient backup, but if Mary was collaborating with other developers, this would also give them access to her initial commits.

git push -u origin marys-feature

This command pushes marys-feature to the central repository (origin), and the -u flag adds it as a remote tracking branch. After setting up the tracking branch, Mary can call git push without any parameters to push her feature.

Mary がフィーチャーを公開します

Git ワークフロー:プルリクエスト

When Mary gets back from lunch, she completes her feature. Before merging it into master, she needs to file a pull request letting the rest of the team know she's done. But first, she should make sure the central repository has her most recent commits:

Git のプッシュ

Then, she files the pull request in her Git GUI asking to merge marys-feature into master, and team members will be notified automatically. The great thing about pull requests is that they show comments right next to their related commits, so it's easy to ask questions about specific changesets.

Bill がプルリクエストを受け取ります

Git ワークフロー:フィーチャーのプルリクエスト

Bill gets the pull request and takes a look at marys-feature. He decides he wants to make a few changes before integrating it into the official project, and he and Mary have some back-and-forth via the pull request.

Mary が修正を行います

Git ワークフロー:中央リポジトリにプッシュする

Mary は、フィーチャーを最初に開発したときと全く同じ操作で修正を行います。即ち、編集、ステージ、コミットを行ない、最後に更新内容を中央リポジトリにプッシュします。すべての修正内容はプルリクエストに表示され、Bill は逐次コメントすることができます。

If he wanted, Bill could pull marys-feature into his local repository and work on it on his own. Any commits he added would also show up in the pull request.

Mary がフィーチャーを公開します

フィーチャーブランチをマージする

Bill がプルリクエストを承認可能と判断した場合、誰か (Bill または Mary のいずれかで構いません) がフィーチャーを中央リポジトリにマージします:

git checkout master
git pull
git pull origin marys-feature
git push

First, whoever’s performing the merge needs to check out their master branch and make sure it’s up to date. Then, git pull origin marys-feature merges the central repository’s copy of marys-feature. You could also use a simple git merge marys-feature, but the command shown above makes sure you’re always pulling the most up-to-date version of the feature branch. Finally, the updated master needs to get pushed back to origin.

This process often results in a merge commit. Some developers like this because it’s like a symbolic joining of the feature with the rest of the code base. But, if you’re partial to a linear history, it’s possible to rebase the feature onto the tip of master before executing the merge, resulting in a fast-forward merge.

Some GUI’s will automate the pull request acceptance process by running all of these commands just by clicking an “Accept” button. If yours doesn’t, it should at least be able to automatically close the pull request when the feature branch gets merged into master

この間に John も作業を進行させていました

While Mary and Bill are working on marys-feature and discussing it in her pull request, John is doing the exact same thing with his own feature branch. By isolating features into separate branches, everybody can work independently, yet it’s still trivial to share changes with other developers when necessary.

次のステップ

For a walkthrough of feature branching on Bitbucket, check out the Using Git Branches documentation. By now, you can hopefully see how feature branches are a way to quite literally multiply the functionality of the single master branch used in the Centralized Workflow. In addition, feature branches also facilitate pull requests, which makes it possible to discuss specific commits right inside of your version control GUI.

フィーチャーブランチワークフローは、プロジェクト開発に大幅な柔軟性をもたらします。問題点は場合によっては柔軟過ぎることです。チーム規模が大きいときは、それぞれのブランチに決まった役割を持たせる方が有利な場合があります。Gitflow ワークフローは、フィーチャー開発、リリース準備、メンテナンスなどに対応できる汎用的なワークフローです。

Gitflow ワークフロー

Gitflow ワークフロー

The Gitflow Workflow section below is derived from Vincent Driessen at nvie.

The Gitflow Workflow defines a strict branching model designed around the project release. While somewhat more complicated than the Feature Branch Workflow, this provides a robust framework for managing larger projects.

このワークフローでは、フィーチャー ブランチ ワークフローに使用されているもの以外の概念や命令は必要としません。その代わり、異なるブランチに対して個別にロールを割り当て、それらが相互に作用する手順や条件を定義します。またフィーチャー ブランチに加え、リリースの準備、保守、記録を行うためにそれぞれのブランチを使用します。言うまでもなくプルリクエストや隔離実験等のフィーチャー ブランチ ワークフローのすべての特長を利用可能であり、コラボレーションのさらなる効率化が実現できます。

動作の概要

The Gitflow Workflow still uses a central repository as the communication hub for all developers. And, as in the other workflows, developers work locally and push branches to the central repo. The only difference is the branch structure of the project.

ブランチにおける履歴の記録

Instead of a single master branch, this workflow uses two branches to record the history of the project. The master branch stores the official release history, and the develop branch serves as an integration branch for features. It's also convenient to tag all commits in the master branch with a version number.

ブランチにおける履歴の記録

このワークフローにおいてはこれらの二つのブランチの相違点が重要な役割を果たします。

フィーチャー ブランチ

Each new feature should reside in its own branch, which can be pushed to the central repository for backup/collaboration. But, instead of branching off of master, feature branches use develop as their parent branch. When a feature is complete, it gets merged back into develop. Features should never interact directly with master.

フィーチャー ブランチ

Note that feature branches combined with the develop branch is, for all intents and purposes, the Feature Branch Workflow. But, the Gitflow Workflow doesn’t stop there.

リリース ブランチ

リリース ブランチ

Once develop has acquired enough features for a release (or a predetermined release date is approaching), you fork a release branch off of develop. Creating this branch starts the next release cycle, so no new features can be added after this point—only bug fixes, documentation generation, and other release-oriented tasks should go in this branch. Once it's ready to ship, the release gets merged into master and tagged with a version number. In addition, it should be merged back into develop, which may have progressed since the release was initiated.

このようなリリース専用ブランチを利用することにより、あるチームでは進行中のリリース準備を行いつつ他のチームでは次のリリースに向けたフィーチャー開発を同時に行うことが可能となります。またこの機能により開発のフェーズをより明確にすることができます (例えば、「今週はバージョン4.0の作業をする」と明確に定義することができると同時にそれがリポジトリの実際の構造に反映されます)。

共通規則

  • branch off: develop
  • merge into: master
  • naming convention: release-* or release/*

メンテナンスブランチ

メンテナンスブランチ

Maintenance or “hotfix” branches are used to quickly patch production releases. This is the only branch that should fork directly off of master. As soon as the fix is complete, it should be merged into both master and develop (or the current release branch), and master should be tagged with an updated version number.

Having a dedicated line of development for bug fixes lets your team address issues without interrupting the rest of the workflow or waiting for the next release cycle. You can think of maintenance branches as ad hoc release branches that work directly with master.

一つのリリースサイクルにおける本ワークフローの使用例を次に示します。セントラルリポジトリは既に作成されているものとします。

Develop ブランチの作成

Develop ブランチの作成

The first step is to complement the default master with a develop branch. A simple way to do this is for one developer to create an empty develop branch locally and push it to the server:

git branch develop
git push -u origin develop

This branch will contain the complete history of the project, whereas master will contain an abridged version. Other developers should now clone the central repository and create a tracking branch for develop:

git clone ssh://user@host/path/to/repo.git
git checkout -b develop origin/develop

これにより、開発者全員がそれ以前に設定されたブランチのコピーをローカルに保有することができます。

Mary と John が新規フィーチャー開発を開始します

新しいフィーチャーブランチ

Our example starts with John and Mary working on separate features. They both need to create separate branches for their respective features. Instead of basing it on master, they should both base their feature branches on develop:

git checkout -b some-feature develop

二人は、編集、ステージ、コミットという通常の方法でフィーチャーブランチにコミットを行ないます:

git status
git add <some-file>
git commit

Mary がフィーチャーを公開します

フィーチャーブランチをマージする

After adding a few commits, Mary decides her feature is ready. If her team is using pull requests, this would be an appropriate time to open one asking to merge her feature into develop. Otherwise, she can merge it into her local develop and push it to the central repository, like so:

git pull origin develop
git checkout develop
git merge some-feature
git push
git branch -d some-feature

The first command makes sure the develop branch is up to date before trying to merge in the feature. Note that features should never be merged directly into master. Conflicts can be resolved in the same way as in the Centralized Workflow.

Mary がリリースの準備を開始します

リリースの準備

John が自分のフィーチャー開発作業を続けている間に、Mary はプロジェクトの最初の公式リリースの準備を開始します。Mary は、フィーチャー開発の場合と同様にリリース準備作業をカプセル化するための新しいブランチを作成します。このステップではリリースのバージョン番号も決められます:

git checkout -b release-0.1 develop

このブランチでは、リリースのクリーンアップ、すべてのテスト、ドキュメンテーションの更新、その他リリースのための準備事項のすべてを行います。これはちょうどリリースのための仕上げ作業専用のフィーチャーブランチを作ったようなものです。

As soon as Mary creates this branch and pushes it to the central repository, the release is feature-frozen. Any functionality that isn’t already in develop is postponed until the next release cycle.

Mary がリリースを完了しました

リリースを master にマージする

Once the release is ready to ship, Mary merges it into master and develop, then deletes the release branch. It’s important to merge back into develop because critical updates may have been added to the release branch and they need to be accessible to new features. Again, if Mary’s organization stresses code review, this would be an ideal place for a pull request.

git checkout master
git merge release-0.1
git push
git checkout develop
git merge release-0.1
git push
git branch -d release-0.1

Release branches act as a buffer between feature development (develop) and public releases (master). Whenever you merge something into master, you should tag the commit for easy reference:

git tag -a 0.1 -m "Initial public release" master
git push --tags

Git comes with several hooks, which are scripts that execute whenever a particular event occurs within a repository. It’s possible to configure a hook to automatically build a public release whenever you push the master branch to the central repository or push a tag.

エンドユーザーがバグを発見しました

メンテナンスブランチ

After shipping the release, Mary goes back to developing features for the next release with John. That is, until an end-user opens a ticket complaining about a bug in the current release. To address the bug, Mary (or John) creates a maintenance branch off of master, fixes the issue with as many commits as necessary, then merges it directly back into master.

git checkout -b issue-#001 master
# Fix the bug
git checkout master
git merge issue-#001
git push

Like release branches, maintenance branches contain important updates that need to be included in develop, so Mary needs to perform that merge as well. Then, she’s free to delete the branch:

git checkout develop
git merge issue-#001
git push
git branch -d issue-#001

次のステップ

By now, you’re hopefully quite comfortable with the Centralized Workflow, the Feature Branch Workflow, and the Gitflow Workflow. You should also have a solid grasp on the potential of local repositories, the push/pull pattern, and Git's robust branching and merging model.

以前にも説明したように、ここで示したワークフローは実際にありうる例に過ぎず、開発現場で Git を利用するに当たっての厳密な規則ではありません。従ってワークフローの一部のみを採用してそれ以外は無視しても構いません。目的はあくまでもお客様のために Git を役立てることであり、その逆であってはならないのです。

フォーク型ワークフロー

The Forking Workflow is fundamentally different than the other workflows discussed in this tutorial. Instead of using a single server-side repository to act as the “central” codebase, it gives every developer a server-side repository. This means that each contributor has not one, but two Git repositories: a private local one and a public server-side one.

Git ワークフロー:フォーク型ワークフロー

The main advantage of the Forking Workflow is that contributions can be integrated without the need for everybody to push to a single central repository. Developers push to their own server-side repositories, and only the project maintainer can push to the official repository. This allows the maintainer to accept commits from any developer without giving them write access to the official codebase.

その結果、このワークフローは大規模て組織的な開発チーム (信頼性の低いサードパーティーが含まれる場合も含みます) 向けの、安全なコラボレーションが可能でかつ柔軟な分散型ワークフローとなります。またこれは、オープンソースプロジェクトにおいても理想的なワークフローです。

動作の概要

他の Git ワークフローと同様に、フォーク型ワークフローもサーバー上に公式リポジトリを作成することから始まります。ただし、開発者は公式リポジトリを直接クローンすることはできません。

Instead, they fork the official repository to create a copy of it on the server. This new copy serves as their personal public repository—no other developers are allowed to push to it, but they can pull changes from it (we’ll see why this is important in a moment). After they have created their server-side copy, the developer performs a git clone to get a copy of it onto their local machine. This serves as their private development environment, just like in the other workflows.

ローカルなコミットが公開可能となった場合、まずそれを公式リポジトリではなく、各々の公開リポジトリにプッシュします。次に公式リポジトリへのプルリクエストを送り、変更内容を統合する準備が整ったことをプロジェクトメンテナーに通知します。プルリクエストはまた、作業成果のコードに問題があった場合にそれに関する議論を行う便利な手段ともなります。

To integrate the feature into the official codebase, the maintainer pulls the contributor’s changes into their local repository, checks to make sure it doesn’t break the project, merges it into his local master branch, then pushes the master branch to the official repository on the server. The contribution is now part of the project, and other developers should pull from the official repository to synchronize their local repositories.

公式リポジトリ

フォーク型ワークフローにおける「公式」リポジトリという表現は単なる習慣であることを理解してください。技術的には Git において各々の開発者の公開リポジトリと公式リポジトリとの間には何の相違もありません。公式リポジトリを「公式」と呼ぶのは単にそれがプロジェクトメンテナーの公開リポジトリだからです。

フォーク型ワークフローにおけるブランチ

All of these personal public repositories are really just a convenient way to share branches with other developers. Everybody should still be using branches to isolate individual features, just like in the Feature Branch Workflow and the Gitflow Workflow. The only difference is how those branches get shared. In the Forking Workflow, they are pulled into another developer’s local repository, while in the Feature Branch and Gitflow Workflows they are pushed to the official repository.

プロジェクトメンテナーが公式リポジトリを作成します

フォーク型ワークフロー:公式リポジトリ

他の Git ベースプロジェクトと同様、すべてのチームメンバーがアクセス可能なサーバー上に公式リポジトリを作成することから始まります。通常、このリポジトリはプロジェクトメンテナーの公開リポジトリになります。

Public repositories should always be bare, regardless of whether they represent the official codebase or not. So, the project maintainer should run something like the following to set up the official repository:

ssh user@host
git init --bare /path/to/repo.git

Bitbucket や Stash では、上記コマンドと同等の操作が可能な便利な GUI が提供されています。この作業は、このチュートリアルで説明した他のワークフローにおける中央リポジトリの作成作業と全く同じです。またコードベースが既に存在している場合、メンテナーは必要に応じてそれをこのリポジトリにプッシュします。

開発者が公式リポジトリをフォークします

フォーク型ワークフロー:公式リポジトリをフォークする

Next, all of the other developers need to fork this official repository. It’s possible to do this by SSH’ing into the server and running git clone to copy it to another location on the server—yes, forking is basically just a server-side clone. But again, Bitbucket let developers fork a repository with the click of a button.

これが完了すると各々の開発者はそれぞれサーバーサイドリポジトリを保有することになります。公式リポジトリと同様、これらのリポジトリもすべてベアリポジトリでなければなりません。

開発者がフォークしたリポジトリをクローンします

フォーク型ワークフロー:フォークしたリポジトリのクローン

Next each developer needs to clone their own public repository. They can do with the familiar git clone command.

この例では、これらのリポジトリのホストとして Bitbucket を利用するものとします。以前に説明したように、この場合すべての開発者がそれぞれの Bitbucket アカウントを保有する必要があり、次のコマンドを使用してそれぞれのサーバーサイドリポジトリをクローンします:

git clone https://user@bitbucket.org/user/repo.git

Whereas the other workflows in this tutorial use a single origin remote that points to the central repository, the Forking Workflow requires two remotes—one for the official repository, and one for the developer’s personal server-side repository. While you can call these remotes anything you want, a common convention is to use origin as the remote for your forked repository (this will be created automatically when you run git clone) and upstream for the official repository.

git remote add upstream https://bitbucket.org/maintainer/repo

各々の開発者は上記のコマンドを使用して upstream へのリモート接続を自分で作成しなければなりません。この方法により、公式プロジェクトの進行に伴って、ローカルリポジトリを簡単に最新のものに維持することができます。なお、upstream リポジトリが認証を必要とする場合は (即ちオープンソースではない場合は)、次のようにユーザー名を付加する必要があります:

git remote add upstream https://user@bitbucket.org/maintainer/repo.git

このコマンドを実行すると、公式リポジトリのクローンやプルを行ったときに有効なパスワードの入力を求められます。

開発者がそれぞれのフィーチャー開発作業を開始します

フォーク型ワークフロー:それぞれのフィーチャー開発作業

In the local repositories that they just cloned, developers can edit code, commit changes, and create branches just like they did in the other workflows:

git checkout -b some-feature
# Edit some code
git commit -a -m "Add first draft of some feature"

All of their changes will be entirely private until they push it to their public repository. And, if the official project has moved forward, they can access new commits with git pull:

git pull upstream master

Since developers should be working in a dedicated feature branch, this should generally result in a fast-forward merge.

開発者がそれぞれのフィーチャー開発作業を開始します

フォーク型ワークフロー:開発者がフィーチャーを公開

Once a developer is ready to share their new feature, they need to do two things. First, they have to make their contribution accessible to other developers by pushing it to their public repository. Their origin remote should already be set up, so all they should have to do is the following:

git push origin feature-branch

This diverges from the other workflows in that the origin remote points to the developer’s personal server-side repository, not the main codebase.

Second, they need to notify the project maintainer that they want to merge their feature into the official codebase. Bitbucket provides a “Pull request” button that leads to a form asking you to specify which branch you want to merge into the official repository. Typically, you’ll want to integrate your feature branch into the upstream remote’s master branch.

プロジェクトメンテナーが開発者のフィーチャーを統合します

フォーク型ワークフロー:フィーチャーの統合

プロジェクトメンテナーがプルリクエストを受け取ると、それを公式リポジトリに統合 (マージ )するべきか否かを判断します。この作業を行うには次の二つの方法があります:

  1. プルリクエストの情報を元にコードを調べる

  2. 開発者のフィーチャーブランチをメンテナーのローカルリポジトリにプルし、手作業でマージする

The first option is simpler, as it lets the maintainer view a diff of the changes, comment on it, and perform the merge via a graphical user interface. However, the second option is necessary if the pull request results in a merge conflict. In this case, the maintainer needs to fetch the feature branch from the developer’s server-side repository, merge it into their local master branch, and resolve any conflicts:

git fetch https://bitbucket.org/user/repofeature-branch
# 変更の検査
git checkout master
git merge FETCH_HEAD

Once the changes are integrated into their local master, the maintainer needs to push it to the official repository on the server so that other developers can access it:

git push origin master

Remember that the maintainer's origin points to their public repository, which also serves as the official codebase for the project. The developer's contribution is now fully integrated into the project.

他の開発者が公式リポジトリとの同期をとります

フォーク型ワークフロー:公式リポジトリとの同期

メンテナーによる上記の作業で公式リポジトリに進行が生じたため、他の開発者は公式リポジトリとの同期を行なわなければなりません:

git pull upstream master

次のステップ

If you’re coming from an SVN background, the Forking Workflow may seem like a radical paradigm shift. But don’t be afraid—all it’s really doing is introducing another level of abstraction on top of the Feature Branch Workflow. Instead of sharing branches directly though a single central repository, contributions are published to a server-side repository dedicated to the originating developer.

This article explained how a contribution flows from one developer into the official master branch, but the same methodology can be used to integrate a contribution into any repository. For example, if one part of your team is collaborating on a particular feature, they can share changes amongst themselves in the exact same manner—without touching the main repository.

このように、フォーク型ワークフローは特に緩やかに連携している開発チームの場合には極めて強力なワークフローです。いずれの開発者も他のいずれの開発者との変更の共有が可能であり、あらゆるブランチを効率的に公式リポジトリにマージすることができるのです。

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

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

今すぐ始める