Having once again seen the GitFlow baseword, I freaked out and decided to translate the description of a simpler and less problematic scheme of working with branches called GitHub Flow. It makes sense to use it by default, moving to some other one only in case of insuperable circumstances.

Create a branch

While you are working on one project, you can have a bunch of different improvements implemented in parallel. Some of them are ready to work, while others are not. Branching allows you to manage this workflow.

When you create a branch in the project, an environment is created in which you can try out new ideas. Changes made in a separate branch do not affect the trunk (master branch). This allows you to experiment and commit changes safely, knowing that your branch will not affect others in any way until it is really ready.

Branching is a basic concept in git. The whole GitHub Flow is based on it and according to it there is only one rule: everything that is in the trunk is guaranteed to be stable and ready to deploy at any time.

Therefore, it is extremely important that any of your new branches are created precisely from the trunk. And the name of the branch was to be descriptive, so that others could understand what was going on in it. A few examples: refactor-authentication, user-content-cache-key, make-retina-avatars.

Commit changes

After creating a branch, start making changes to it. When adding, editing or deleting files, do not forget to make new commits in the branch. The sequence of fixations forms ultimately a transparent history of working on your task, according to which others can understand what you did and why.

Each commit has a related message, which is an explanation of why a change was made. Each commit is also considered a separate unit of change. This allows you to roll back the changes if an error is detected, or if you decide to go in another direction.

A clear description of the commit is very important, as it allows other developers to immediately understand your intentions and evaluate how much the changes made correspond to them. So, feedback from them will come faster and will be more useful.

Pour changes from the trunk into your branch as often as possible, so that it always remains relevant and ready for reverse merging. Resolving possible merge conflicts is the right and duty of the branch developer, since he is the one who knows best the changes recorded in it.

Open merge request

Pull requests initiate a discussion of your commits. Since they are closely integrated with the basic git repository, anyone can clearly understand what changes will be made to the trunk if they accept your request.

You can open a merge request at any time during the development process:

• when you have little or no code but want to share some screenshots or general ideas
• when you are stuck and need help or advice
• when you are ready for someone to check your work

Using the @GitHub mentions system in a merge request message, you can request feedback from specific people or entire teams, be it an office neighbor or someone in ten time zones from you.

Merge requests are useful not only within a single repository, but also as a tool for transferring code between forks. Simply create a merge request for a branch from one repository to a branch from another and proceed further.

Check and discuss the code

After opening a merge request, the team considers the changes, asking questions and leaving comments. Perhaps the coding style does not match the accepted agreement. Unit tests may be missing. And maybe everything looks good and is not satisfactory. The requests are intended to focus the discussion precisely on the proposed changes and group together with them.

Of course, you can continue to replenish the thread with updates in the light of the discussion that has arisen. If you are told that you forgot to do something or there is an error in the code, you can fix it in your branch and push (push) to the server. GitHub will show your new commits and any additional feedback on them all in the same unified representation of the merge request.

In the comments to the merge request, you can use markdown markup, which allows you to insert images and emoticons, use pre-formatted text blocks and other lightweight formatting.

Check in battle

After checking the merge request and passing the tests, the branch can be deployed in a combat environment to finally make sure that it is operational. If a branch causes any problems, then it can be quickly rolled back by deploying a guaranteed-functioning main trunk instead. Since the branch has not yet been poured in anywhere, its influence on other branches is still excluded and the problematic code will not be able to break other branches. so that you can continue to work on the task until it is really ready.

Pour in

Now that the changes have been tested in battle, it's time to pour the code into the main trunk.

When merging in the trunk, a commit is created with all the changes from the branch. Like any other commit, it is available for search and "time travel."

By including certain keywords in the text of a merge request, you can associate issues with the code. When the branches are infused into the trunk, related problems also close. For example, entering a phrase closes #32closes issue number 32 in the repository. For more information, see the related article .

And if frequent releases are not possible?

If you do not practice Continous Delivery, then it may be difficult for you to bring each branch separately to the trunk. In this case, just create integration branches where you pour only those branches that you think are ready. If changes to one of the branches cause problems, then the integration branch can always be rebuilt, but no longer including the problematic one. This will allow you not to disrupt the release schedule, even if any of the planned tasks were not fully prepared for the planned date.

What is the difference from GitFlow?

In GitFlow you have an additional branch developwhere all the branches currently being developed merge. developit is necessary to "stabilize" before the release, which often leads to either a postponement of the release, or a "release with comments."

What is the difference from GitLab Flow?

In GitLab Flow, you first pour a branch into the main trunk and only then deploy in a test, combat and other environments. If the release proves to be problematic and needs to be rolled back, then sometimes a very problematic "reverse merge" or "stabilization" of the trunk will be required, as in the case of GitFlow.