Making a pull request

プルリクエストを実行する

Pull requests are a feature that makes it easier for developers to collaborate using Bitbucket. They provide a user-friendly web interface for discussing proposed changes before integrating them into the official project.

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

In their simplest form, pull requests are a mechanism for a developer to notify team members that they have completed a feature. Once their feature branch is ready, the developer files a pull request via their Bitbucket account. This lets everybody involved know that they need to review the code and merge it into the master branch.

しかし、プルリクエストは単なる通知機能ではありません。提案されたフィーチャーを議論するための専用フォーラムです。変更に何か問題があれば、プルリクエストに対してチームメンバーがフィードバックを投稿し、追加コミットをプッシュすることでフィーチャーの微調整さえ可能です。このすべての内容をプルリクエストで直接トラッキングできます。

Git Workflows: Activity inside a pull request

この正規のコミット共有ソリューションは、他のコラボレーションモデルと比べて非常に無駄のないワークフローです。SVN や Git でも、単純なスクリプトを使って通知メールを自動送信できます。しかし、変更の議論に関しては、開発者はメールスレッドに頼らざるを得ないことが多いです。これは、追加コミットが関わってくる場合などに、混乱したものにもなりえます。プルリクエストは、使いやすい Web インターフェイスで、この機能をすべて Bitbucket リポジトリのすぐ隣に表示します。

プルリクエストの構造

When you file a pull request, all you’re doing is requesting that another developer (e.g., the project maintainer) pulls a branch from your repository into their repository. This means that you need to provide 4 pieces of information to file a pull request: the source repository, the source branch, the destination repository, and the destination branch.

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

これら変数の多くは、Bitbucket によって適切なデフォルト値に設定されます。しかし、利用しているコラボレーションワークフローによって異なる変数を指定する必要がある場合もあります。上記の図は、あるフィーチャーブランチの公式 master ブランチへのマージを要請するプルリクエストを表しています。しかし、プルリクエストを使う方法は 他にも数多くあります。

仕組み

Pull requests can be used in conjunction with the Feature Branch Workflow, the Gitflow Workflow, or the Forking Workflow. But a pull request requires either two distinct branches or two distinct repositories, so they will not work with the Centralized Workflow. Using pull requests with each of these workflows is slightly different, but the general process is as follows:

  1. A developer creates the feature in a dedicated branch in their local repo.

  2. 同開発者が、ブランチを Bitbucket 公開リポジトリにプッシュする。

  3. 同開発者が、Bitbucket でプルリクエストを送信する。

  4. The rest of the team reviews the code, discusses it, and alters it.

  5. The project maintainer merges the feature into the official repository and closes the pull request.

The rest of this section describes how pull requests can be leveraged against different collaboration workflows.

フィーチャー ブランチ ワークフローでのプルリクエスト

The Feature Branch Workflow uses a shared Bitbucket repository for managing collaboration, and developers create features in isolated branches. But, instead of immediately merging them into master, developers should open a pull request to initiate a discussion around the feature before it gets integrated into the main codebase.

Pull Request: Feature Branch workflow

There is only one public repository in the Feature Branch Workflow, so the pull request’s destination repository and the source repository will always be the same. Typically, the developer will specify their feature branch as the source branch and the master branch as the destination branch.

After receiving the pull request, the project maintainer has to decide what to do. If the feature is ready to go, they can simply merge it into master and close the pull request. But, if there are problems with the proposed changes, they can post feedback in the pull request. Follow-up commits will show up right next to the relevant comments.

未完成のフィーチャーのプルリクエストを送信することもできます。例えば、開発者が特定の機能の実装に行き詰まった時、作業中のフィーチャーのプルリクエストを送信できます。他の開発者はそのプルリクエストに助言を提供し、追加コミットで問題を修正することさえ可能です。

Gitflow ワークフローでのプルリクエスト

Gitflow ワークフローはフィーチャー ブランチ ワークフローに類似していますが、プロジェクトのリリースに関連した利用を想定して設計された厳密なブランチモデルを定義しています。Gitflow ワークフローにプルリクエストを追加すると、作業中の開発者にリリース ブランチやメンテナンス ブランチに関して議論する便利な場を提供できます。

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

Gitflow ワークフローでのプルリクエストの構造は、前項とまったく同じです。開発者は、フィーチャー/リリース/hotfix ブランチに対するレビューが必要な時にプルリクエストを送信するだけです。 他のチームメンバーには Bitbucket で通知が届きます。

Features are generally merged into the develop branch, while release and hotfix branches are merged into both develop and master. Pull requests can be used to formally manage all of these merges.

フォーク型ワークフローでのプルリクエスト

In the Forking Workflow, a developer pushes a completed feature to their own public repository instead of a shared one. After that, they file a pull request to let the project maintainer know that it’s ready for review.

プロジェクトメンテナーは、他の開発者それぞれが独自の Bitbucket リポジトリにコミットを追加したことを知る手段はないので、このワークフローでは、プルリクエストの通知機能が特に役立ちます。

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

Since each developer has their own public repository, the pull request’s source repository will differ from its destination repository. The source repository is the developer’s public repository and the source branch is the one that contains the proposed changes. If the developer is trying to merge the feature into the main codebase, then the destination repository is the official project and the destination branch is master.

Pull requests can also be used to collaborate with other developers outside of the official project. For example, if a developer was working on a feature with a teammate, they could file a pull request using the teammate’s Bitbucket repository for the destination instead of the official project. They would then use the same feature branch for the source and destination branches.

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

The two developers could discuss and develop the feature inside of the pull request. When they’re done, one of them would file another pull request asking to merge the feature into the official master branch. This kind of flexibility makes pull requests very powerful collaboration tool in the Forking workflow.

The example below demonstrates how pull requests can be used in the Forking Workflow. It is equally applicable to developers working in small teams and to a third-party developer contributing to an open source project.

In the example, Mary is a developer, and John is the project maintainer. Both of them have their own public Bitbucket repositories, and John’s contains the official project.

Mary forks the official project

プルリクエスト:プロジェクトをフォークする

To start working in the project, Mary first needs to fork John’s Bitbucket repository. She can do this by signing in to Bitbucket, navigating to John’s repository, and clicking the Fork button.

プルリクエスト:Bitbucket でのフォーク

フォークしたリポジトリに名前と説明を記入したら、Mary はサーバーサイドにこのプロジェクトのコピーを保有することになります。

Mary がフォークした Bitbucket リポジトリをクローンします

プルリクエスト: Bitbucket リポジトリをクローンする

次に、Mary はフォークした Bitbucket リポジトリをクローンする必要があります。クローンにより、Mary はローカルマシンに作業用のプロジェクトのコピーを保有することになります。Mary が使用するコマンドは次のようになります。

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

Keep in mind that git clone automatically creates an origin remote that points back to Mary’s forked repository.

Mary develops a new feature

プルリクエスト: 新しいフィーチャーの開発

Mary はコードを書き始める前にまず、作業フィーチャー用に新しいブランチを作成する必要があります。このブランチは、Mary によってプルリクエストのマージ元ブランチとして使われることになります。

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

Mary can use as many commits as she needs to create the feature. And, if the feature’s history is messier than she would like, she can use an interactive rebase to remove or squash unnecessary commits. For larger projects, cleaning up a feature’s history makes it much easier for the project maintainer to see what’s going on in the pull request.

Mary が自分の Bitbucket リポジトリにフィーチャーをプッシュします

プルリクエスト: フィーチャーを Bitbucket リポジトリにプッシュする

After her feature is complete, Mary pushes the feature branch to her own Bitbucket repository (not the official repository) with a simple git push:

git push origin some-branch

これで、 プロジェクトメンテナー (または、変更を入手する必要がある他の協力者) は Mary の変更を見れるようになります 。

Mary がプルリクエストを作成します

プルリクエスト:プルリクエストの作成

After Bitbucket has her feature branch, Mary can create the pull request through her Bitbucket account by navigating to her forked repository and clicking the Pull request button in the top-right corner. The resulting form automatically sets Mary’s repository as the source repository, and it asks her to specify the source branch, the destination repository, and the destination branch.

Mary wants to merge her feature into the main codebase, so the source branch is her feature branch, the destination repository is John’s public repository, and the destination branch is master. She’ll also need to provide a title and description for the pull request. If there are other people who need to approve the code besides John, she can enter them in the Reviewers field.

プルリクエスト: Bitbucket

After she creates the pull request, a notification will be sent to John via his Bitbucket feed and (optionally) via email.

John reviews the pull request

プルリクエスト: Bitbucket のプルリクエスト

John can access all of the pull requests people have filed by clicking on the Pull request tab in his own Bitbucket repository. Clicking on Mary’s pull request will show him a description of the pull request, the feature’s commit history, and a diff of all the changes it contains.

If he thinks the feature is ready to merge into the project, all he has to do is hit the Merge button to approve the pull request and merge Mary’s feature into his master branch.

しかし、例えば、John が Mary のコードに小さなバグを発見し、マージ前に Mary にそのバグを修正させる必要があるとします。この場合、John は、プルリクエスト全体に対してコメントを投稿するか、または、フィーチャー履歴の特定のコミットを選択してコメントを書く事ができます。

Pull Request: Comment

Mary adds a follow-up commit

If Mary has any questions about the feedback, she can respond inside of the pull request, treating it as a discussion forum for her feature.

バグを修正するには、Mary は自分のフィーチャー ブランチに新しいコミットを追加し、最初に実行したように、そのコミットを自分の Bitbucket リポジトリにプッシュします 。コミットは、自動的にオリジナルのプルリクエストに追加され、John は、自分のオリジナルのコメントのすぐ隣で再度レビューできます。

John accepts the pull request

Finally, John accepts the changes, merges the feature branch into master, and closes the pull request. The feature is now integrated into the project, and any other developers working on it can pull it into their own local repositories using the standard git pull command.

次のステップ

You should now have all of the tools you need to start integrating pull requests into your existing workflow. Remember, pull requests are not a replacement for any of the Git-based collaboration workflows, but rather a convenient addition to them that makes collaboration more accessible to all of your team members.

Ready to try pull requests?

Try this interactive tutorial.

今すぐ始める