After seeing the GitFlow baseword once again, I got into a fuss and decided to translate the description of a simpler and less problematic scheme for working with branches called GitHub Flow. It makes sense to use it by default, moving on to some other only in case of insuperable circumstances.

Create a branch

While you are working on a single project, you may have a bunch of different implementations in parallel with improvements. Some of them are ready for work, while others are not. Branching allows you to manage this workflow.

When you create a branch (branch) in the project creates an environment in which you can try out new ideas. Changes made to 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 until it is really ready.

Branching is a basic concept in git. The whole GitHub Flow is based on it and it’s only one rule for it: everything in the trunk is guaranteed to be stable and ready for deployment at any time.

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

Commit changes

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

Each commit has an associated message that explains why a change was made. Also, each fix is ​​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 a different direction.

A clear description of fixing is very important, as it allows other developers to immediately understand your intentions and evaluate how the changes made correspond to them. So the 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 to reverse merge. Resolving possible merge conflicts is the right and responsibility of the branch developer, since it is he who best knows the changes recorded in it.

Open a merge request

Pull requests initiate a discussion of your commits. Since they are tightly integrated with the base 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 you want to share some screenshots or general ideas
• when you are stuck and need help or advice
• when you are ready for anyone to check your work

Using the system @ mentioning GitHub in a merge request message, you can request feedback from specific people or entire teams, be it your officemate 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 request to merge a branch from one repository to a branch from another and proceed further.

Check and discuss code

After opening a merge request, the team reviews the changes, asking questions and leaving comments. Perhaps the coding style does not match the accepted agreement. Perhaps there are no unit tests. And maybe everything looks good and does not cause complaints. Inquiries are intended to focus the discussion precisely on the proposed changes and grouping along with them.

Of course, you can continue to replenish the branch 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 correct it in your branch and push (push) to the server. GitHub will show your new commitments and any additional feedback on them all in the same unified view of the merge request.

In the comments to the request for a merge, 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 the combat environment in order to finally make sure that it works. If a branch causes any problems, then it can be quickly rolled back, deploying instead of it a guaranteed workable main trunk. Since the branch has not yet been injected anywhere, its any influence on other branches is still excluded and the problem code will not be able to break other branches. so you can continue working on the task until it is really ready.

Pour in

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

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

By including certain keywords in the merge request text, you can associate issues with the code. When a branch is infused into a trunk, related problems also close. For example, entering the phrase closes #32 closes problem number 32 in the repository. For more information, read the relevant article .

And if frequent releases are not possible?

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

What is the difference from GitFlow?

In GitFlow, you have an additional branch to develop where all the branches currently being developed merge. develop necessary to develop to "stabilize" before release, which often leads either to a transfer of a release, or to a release with remarks.

What is the difference from GitLab Flow?

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