Vytvoření pull requestu

Making a Pull Request

Pull requesty jsou funkce, která vývojářům, kteří používají Bitbucket, usnadňuje spolupráci. Poskytují uživatelsky přívětivé webové rozhraní k diskuzi o navrhovaných změnách před jejich integrací do oficiálního projektu.

Git Workflows: Pull Request in Bitbucket

Pull requesty jsou ve své nejjednodušší podobě mechanismus, který vývojáři umožňuje oznámit členům týmu, že dokončil feature. Jakmile je větev feature vývojáře připravena, může vývojář ve svém účtu Bitbucket zadat pull request. Díky tomu se všichni zúčastnění dozvědí, že je třeba zkontrolovat kód a provést jeho merge do větve master.

But, the pull request is more than just a notification—it’s a dedicated forum for discussing the proposed feature. If there are any problems with the changes, teammates can post feedback in the pull request and even tweak the feature by pushing follow-up commits. All of this activity is tracked directly inside of the pull request.

Git Workflows: Activity inside a pull request

Compared to other collaboration models, this formal solution for sharing commits makes for a much more streamlined workflow. SVN and Git can both automatically send notification emails with a simple script; however, when it comes to discussing changes, developers typically have to rely on email threads. This can become haphazard, especially when follow-up commits are involved. Pull requests put all of this functionality into a friendly web interface right next to your Bitbucket repositories.

Anatomy of a Pull Request

Zadáním pull requestu v podstatě jen žádáte (request), aby jiný vývojář (například správce projektu) přetáhl (pull) větev z vašeho repozitáře do svého. To znamená, že k zadání pull requestu je třeba poskytnout čtyři informace: zdrojový repozitář, zdrojovou větev, cílový repozitář a cílovou větev.

Git Workflows: Pull Requests

Many of these values will be set to a sensible default by Bitbucket. However, depending on your collaboration workflow, your team may need to specify different values. The above diagram shows a pull request that asks to merge a feature branch into the official master branch, but there are many other ways to use pull requests.

How it works

Pull requesty lze používat společně s workflow větve feature, workflow Gitflow nebo workflow forkování. Pull request však vyžaduje dvě odlišné větve nebo dva odlišné repozitáře, takže u něj nebude fungovat centralizovaný workflow. S každým z těchto workflowů se pull requesty používají trochu jinak, obecný proces však probíhá následovně:

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

  2. The developer pushes the branch to a public Bitbucket repository.

  3. The developer files a pull request via 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.

Feature Branch Workflow With Pull Requests

Workflow větve feature ke správě spolupráce používá sdílený repozitář Bitbucket. Vývojáři v tomto workflow vytváří feature v izolovaných větvích. Místo okamžitého merge do větve master však vývojáři zadávají pull requesty, kterými zahajují diskuzi o feature předtím, než se integruje do hlavní báze kódu.

Pull Request: Feature Branch workflow

Ve workflow větve feature je jenom jeden veřejný repozitář, proto je cílový a zdrojový repozitář pull requestu vždy stejný. Vývojáři obvykle určí větev své feature jako zdrojovou větev a větev master jako cílovou větev.

Když správce projektu obdrží pull request, musí se rozhodnout, co udělá. Pokud je feature připravená k použití, stačí provést její merge do větve master a pull request zavřít. Pokud jsou však s navrhovanými změnami problémy, může v pull requestu zadat zpětnou vazbu. Commity k vyřízení se zobrazí hned vedle relevantních komentářů.

It’s also possible to file a pull request for a feature that is incomplete. For example, if a developer is having trouble implementing a particular requirement, they can file a pull request containing their work-in-progress. Other developers can then provide suggestions inside of the pull request, or even fix the problem themselves with additional commits.

Gitflow Workflow With Pull Requests

The Gitflow Workflow is similar to the Feature Branch Workflow, but defines a strict branching model designed around the project release. Adding pull requests to the Gitflow Workflow gives developers a convenient place to talk about a release branch or a maintenance branch while they’re working on it.

Pull Requests: Gitflow Workflow Pull Requests: Gitflow Workflow 2

The mechanics of pull requests in the Gitflow Workflow are the exact same as the previous section: a developer simply files a pull request when a feature, release, or hotfix branch needs to be reviewed, and the rest of the team will be notified via Bitbucket.

Merge feature se obvykle provádí do větve develop a merge větví release a hotfix se provádí do větví develop i master. K formální správě těchto merge lze používat pull requesty.

Forking Workflow With Pull Requests

Ve workflow forkování vývojář provede push dokončené feature do svého vlastního veřejného repozitáře, nikoli do sdíleného. Poté dá prostřednictvím pull requestu vědět správci projektu, že je feature připravena ke kontrole.

The notification aspect of pull requests is particularly useful in this workflow because the project maintainer has no way of knowing when another developer has added commits to their Bitbucket repository.

Pull Requests: Forking workflow

Vzhledem k tomu, že má každý vývojář vlastní veřejný repozitář, liší se zdrojový repozitář pull requestu od cílového. Zdrojovým repozitářem je vývojářův veřejný repozitář a zdrojou větví je větev, která obsahuje navrhované změny. Pokud chce vývojář provést merge feature do hlavní báze kódu, bude cílovým repozitářem oficiální projekt a cílovou větví větev master.

Pull requesty lze také využít ke spolupráci s ostatními vývojáři mimo oficiální projekt. Pokud například vývojář pracuje na feature s kolegou, nemusí jako cílový repozitář při zadání pull requestu použít oficiální projekt. Místo toho použije repozitář Bitbucket kolegy. Pak mohou používat stejnou větev feature jako zdrojovou i cílovou větev.

Pull Requests: Forking workflow

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.

Example

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

Pull Requests: Fork the project

Když chce Marie začít pracovat na projektu, musí nejdříve provést fork (rozvětvení) Janova repozitáře Bitbucket. Udělat to může tak, že se přihlásí k Bitbucketu, přejde k Janovu repozitáři a klikne na tlačítko Provést fork (rozvětvení).

Pull Request: Fork in Bitbucket

After filling out the name and description for the forked repository, she will have a server-side copy of the project.

Mary clones her Bitbucket repository

Pull Request: Clone the Bitbucket repo

Next, Mary needs to clone the Bitbucket repository that she just forked. This will give her a working copy of the project on her local machine. She can do this by running the following command:

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

Mějte na paměti, že příkaz git clone automaticky vytváří ukazatel origin, který odkazuje zpět na Mariin rozvětvený repozitář.

Mary develops a new feature

Pull Requests: develop a new feature

Before she starts writing any code, Mary needs to create a new branch for the feature. This branch is what she will use as the source branch of the pull request.

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

Marie může k vytvoření feature použít tolik commitů, kolik chce. Pokud je historie její feature zaneřáděnější, než by chtěla, může u commitů, které nejsou nezbytné, provést odebrání nebo squash pomocí interaktivního rebasingu. Vyčištění historie feature u velkých projektů správci projektu výrazně usnadní orientaci v tom, o čem je daný pull request.

Mary pushes the feature to her Bitbucket repository

Pull Requests: Push feature to Bitbucket repository

Marie po dokončení feature provede push větve feature do vlastního repozitáře Bitbucket (ne do oficiálního repozitáře) pomocí obyčejného příkazu git push:

git push origin some-branch

This makes her changes available to the project maintainer (or any collaborators who might need access to them).

Mary creates the pull request

Pull Request: Create Pull Request

Až bude mít Marie v Bitbucketu vlastní větev feature, může pomocí svého účtu Bitbucket vytvořit pull request. To provede tak, že přejde k rozvětvenému repozitáři a klikne na tlačítko Pull request v pravém horním rohu. Ve výsledném formuláři se Mariin repozitář automaticky nastaví jako zdrojový. Marie bude muset určit zdrojovou větev, cílový repozitář a cílovou větev.

Marie chce provést merge své feature do hlavní báze kódu, proto jako zdrojovou větev určí větev své feature, jako cílový repozitář určí Janův veřejný repozitář a jako cílovou větev určí větev master. Také musí zadat název a popis pull requestu. Pokud kód mají kromě Jana schválit ještě další lidé, může je uvést v poli Reviewers (Hodnotící).

Pull Request: 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

Pull Request: Bitbucket pull requests

Jan si může ve vlastním repozitáři Bitbucket zobrazit všechny pull requesty, které lidé zadali, kliknutím na kartu Pull request. Když klikne na Mariin pull request, zobrazí se mu popis pull requestu, historie commitů feature a diff všech obsažených změn.

Pokud si myslí, že je feature připravena k provedení merge do projektu, stačí, aby kliknutím na tlačítko Merge schválil pull request a provedl merge Mariiny feature do své větve master.

But, for this example, let’s say John found a small bug in Mary’s code, and needs her to fix it before merging it in. He can either post a comment to the pull request as a whole, or he can select a specific commit in the feature’s history to comment on.

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.

To correct the error, Mary adds another commit to her feature branch and pushes it to her Bitbucket repository, just like she did the first time around. This commit is automatically added to the original pull request, and John can review the changes again, right next to his original comment.

John accepts the pull request

Jan nakonec přijme změny, provede merge větve feature do větve master a zavře pull request. Feature je nyní integrována do projektu a jakýkoli vývojář, který na ní bude pracovat, ji může provedením příkazu git pull přetáhnout do vlastního místního repozitáře.

Where to go from here

Nyní byste měli mít všechny nástroje, které k zahájení integrace pull requestů s existujícím workflow potřebujete. Mějte na paměti, že pull requesty nenahrazují žádný workflow spolupráce v Gitu, jedná se spíše o šikovný doplněk, který usnadňuje spolupráci pro všechny členy týmu.

Ready to try pull requests?

Try this interactive tutorial.

Začít