How Workflow Works with Pull Request

Question

I’m willing to work with Pull Request in Git, but I don’t understand how it works, I know when I contribute to a project, I have to do Fork, Branch, Commit and Pull Request, and then the owner of Repositorio, analyzes and accepts or refuses. Ok, but when working as a team, how does this flow?

Ex: each team person, need to make one fork project? Then it has to commit, create branch, send a pull to the fork and just send the pull request?

Answer 1

There are some levels to give an answer that I consider appropriate to your question:

1. what is the pull request?
2. which gains to use pull request?
3. we often see this in portals that work on git, as Gitlab, Github and Bitbucket... has some relation to git itself?

What is the pull request?

It’s a smooth way for you to send code to the project. It will only enter upon approval from the repository maintainer.

What gains to use pull request?

Every code of a pull request undergoes revision before entering. This guarantees a lot. See Law of Linus (by Eric Raymond):

Given enough eyeballs, all bugs are Shallow

In free translation:

given enough eyes, all bugs are shallow

What does Linus' Law mean? That the more people reviewing a piece of code, the more easily bugs are found. Somewhere there is a metric (maybe false or biased) that at least 50% of bugs could be detected/avoided at code review level; my professional experience indicates that it is at least 90% of bugs (of the other 10%, 9% are broken down into bad specification, heisenbugs and no established performance requirement).

Besides, this workflow ensures the separation of team development, so each programmer can do their job alone and only integrate into the code at the end. Isolate yourself ensures you don’t need at all times fix what broke compatibility with others, just need to do this in the end.

In Gitlab, this process is called merge request, but it is exactly the same purpose.

Example using pull request

Here’s a single-person commit tree using pull request with herself:

by the way, I’m still working on this fork, is still very incipient

Another example:

An example of the company’s private repository commit tree:

Note that the person works on your branch, alone, and only then when "enough is done", opens the pull request and then the reviewer approves/criticizes the amended code. Note that there is no need for history to be "linearizable", with absolute precedence between any two commits.

Has some relation to git itself?

Really? No, it’s not about git. It’s about source code distribution, bazaar philosophy and code review.

Distributed version control (DVCS) systems facilitate the pull request, but not required. Any version control that accepts branches, even SVN in its centralized mode of existing, is suitable for using this stream; just have a tool that facilitates =D

"Bazaar philosophy" is an antagonistic view of "cathedral philosophy", both drawn from the Open Source way of developing. Read more, if applicable buy the book written by Eric Raymond.

The "cathedral" is the sacred repository: everyone can see, but only the saints can change. In the "bazaar", anyone picks up and changes, anyone launches his version and owns his own code. And then send contributions to the other repository, where the maintainer can accept or not.

The bazaar way of being stimulates to create forks of projects. And the contribution upstream, from the child repository to the original repository, is one of the ways pull request. But she’s not the only one.

Another form is an intermediary between bazaar and cathedral, often more suited to the business world. All work in the same repository, in separate branches, and contributions are accepted by the maintainer, to release the version.

How to work properly with this pull request?

There are a few ways. It depends on how you want the lifecycle of your project.

If it’s a very agile project that you don’t have to worry about stabilizing, you’ll have a branch master where the final versions come from, and correction branches and new features. These branches are born and flow into master. That flow they usually call feature branch.

The gitflow (plus about the subject matter) provides for another life cycle:

• branch master for the stable version
• branch develop for the development version
• release process, where develop -> master happens

In the master, hot corrections are born (hotfix), and they should go back to master and be propagated in the develop. Of develop, in the development phase, the functionalities are born (features) and corrections from himself (bugfix) and shall return only to develop. In the process of release, a freeze is made (freeze) of develop in a branch of release. When this branch is stabilized, it should be merged into the master and propagated in develop.