A bit of history

At the very beginning of 2010, Vincent Driessen wrote an excellent article, A successful Git branching model . To understand what will be discussed further, of course, you need to get acquainted with the article. And for those who have difficulty with the language of the original article, there is an excellent translation of it in Habré.

From this point on, the described GitFlow branching model begins, as they say, to diverge around the world. It is adopted by many teams. Authors write many articles about its successful use. She gets support in most tools that developers use:

• Plugin for Git itself
• Plugins to various IDE: IDEA , Eclipse
• Native GUI client support: SourceTree and Git Extensions
• Plugins for build systems: Maven , Gradle , etc.
• Native support in repository managers: GitHub , BitBucket , GitLab , etc.

It seems that the model is perfect. Perhaps this is the case, if you have a small team, unchangeable scop releases, high culture of work with VCS . Then, indeed, GitFlow can and will satisfy all your needs. But, unfortunately, the conditions described are not suitable for all teams and not all projects. By the way, to find articles in which the authors would describe the problems of this model is not so easy even in 2016. But as we all know, there is no silver bullet , and this means that in this model everything is far from being good for everyone.

What's wrong with classic GitFlow ?

The story begins with the fact that classic GitFlow involves a large number of merge- commit. And the problem is not in the merge commits themselves (which, as you will see later, will still be present in the history), but in a huge amount of them. Debates on the topic “ Merge vs Rebase ” are often found on the Internet (search engines will prompt). Atlassian, by the way, has a good article that describes the difference between these two approaches. So what's the deal?

1. The history of commits is just awful. The photo below is just one day of the team.
   
   
   
   Yes, we have git log --first-parent and other options to filter the tree, but this doesn’t help a full analysis of the story. If the development team, apart from the classic GitFlow , does not have any other agreements on the maintenance of the Git repository, then in this story it will be possible to watch in whole batches of commits with absolutely meaningless messages " fix ", " refactoring ", "" , etc. This will make the commit history almost unusable even for the most superficial analysis.

   
   

2. If your release scoop changes (and this is not rare in Agile ), then classic GitFlow is unlikely to work for you. If in your workflow there are often phrases that fall under the pattern " The customer urgently needs an assembly, in which [\ w] * ", then with the history of commits, clearly presented in the previous paragraph, your life will turn into hell. I am not kidding.

   
   
3. Merge commits make it harder to use git bisect

And what would you like?

It is very difficult to explain why it is so important that the commit history is clean. Experienced developers do not need an explanation why the source code should be clean, for them this statement is an axiom. In my opinion, the analogy here is absolutely straightforward. As well as every line of clean code, every commit of history should be in its place and understandable to anyone, even an outsider, developer. Yes, dirty code can also be working, but how convenient is it to work with it? How quickly will a new employee be able to figure it out? The same with the commit history. Even a dirty story will know absolutely everything about all the changes in the project, but will it be convenient to work with it?

In order to work with the Git repository was simple, convenient and understandable, in my opinion only two things are needed:

• Linear change history . This property limits the thickness of the commit tree to a constant, making it as simple and intuitive as possible for analysis.

  
  
• The logical completeness of each commit . This property greatly increases the flexibility of the change history. In this case, if necessary, individual improvements can be easily transferred with the git cherry-pick command. Or completely canceled with the git revert command, which in the case of a simple commit is much easier than in the case of a merge commit.

If both properties are executed, the commit tree will look like this:

How to achieve this?

You don't need to edit much of classic GitFlow at all . At the same time, working with develop , master , release and hotfix branches remains exactly the same as in classic GitFlow . Edits will touch only work with feature- branches.

1. Before introducing a feature- branch into the final one, it needs to make an interactive rebase with the git rebase -i develop command, with all the intermediate commits in the brunch merged ( squash 'it) into one. There are cases when the history of commits in the feature- branch makes sense to leave, but these cases are very rare in practice. With a good task decomposition, each small task is an atomic and logically complete change of the system that fits perfectly in one commit. Considering that all changes within a task can be combined into one commit at the very last moment, while working on a task, the developer can still freely create many of the intermediate commits needed for a potential rollback. Well, it would not be superfluous to add that there is a great rerere command that helps developers who often perform the rebase operation.

   
   

2. You need to upload a feature- branch to a remote repository using the git push --force , as in the previous paragraph we rebranded the branch.

   
   
3. You need to add a feature- branch to the final one with the git merge --ff-only feature command, since only in this case it will be possible to preserve the linearity of the commit history and avoid the appearance of a merge- commit.

As you can see, there are very few changes in working with the repository. And, summing up some of this part of the article, I want to share a link to a great article, which also discusses the pros and cons of classic GitFlow and Rebase Flow .

Rebase Flow support in repository managers

As I mentioned at the very beginning of the article, there is support for classic GitFlow in a variety of tools, including various repository managers. Therefore, I will consider further the question of how things are now with the support of Rebase Flow in popular repository managers. In this case, my assessment will be in the format of a regular university mark.

Github

Rebase Flow Support: GOOD

In fact, GitHub has almost everything you need. In the repository settings there is a tick "Allow squash merging".

It allows you to select the appropriate item during the pull request and edit the final message to the commit

As a result, the pull request will be dead linearly and all the commits will be closed into one.

The only minus that I see on the side of github is

1. inability to merge pull request without merging commits. Very rarely, but this is still required and, in the case of GitHub, this merge will have to be done manually.

All of the above applies to GitHub Enterprise , which can be deployed on your company's servers.

Bitbucket

Rebase Flow Support: UNSPECIFICALLY

And in fact it simply is not. If you want to use Rebase Flow in your work, then BitBucket will not help you with this, you have to do everything yourself.

And this is surprising, given that in the text of this article I have repeatedly referred to excellent articles from the Atlassian website. Let's hope that in the future the situation with Rebase Flow support will change, especially since the tasks for this have long been initiated

• Forced non fast forward merge of pull request?
• "Git merge --squash" for pull requests
• Force fast forwarding
• Detect and handle rebasing and auto-merge in more situations
• etc.

Let's now see what with Rebase Flow support for a paid product from Atlassian.

Atlassian BitBucket Server (aka Atlassian Stash)

Rebase Flow Support: SATISFACTORY

I am considering BitBucket v4.5.2 and maybe in future versions the situation will change for the better. Now with support in BitBucket Server is somewhat better than in its cloud brother. If you have access to administrators, you can kindly ask them in the bitbucket.properties file bitbucket.properties change the pull request settings for your project / repository ( documentation )

• plugin.bitbucket-git.pullrequest.merge.strategy.KEY.slug - setting for a specific slug repository in the KEY project.
• plugin.bitbucket-git.pullrequest.merge.strategy.KEY - setting for a specific KEY project.
• plugin.bitbucket-git.pullrequest.merge.strategy - global configuration for the entire BitBucket Server.

The settings may be as follows.

• no-ff - no fast-forward . This is the default value.
• ff –– if possible, fast-forward merge will be executed.
• ff-only - always fast-forward merzh. You simply cannot pull pull request if it cannot be done linearly.
• squash - merges all commits into one and does not create a merge commit.
• squash-ff-only - merges all commits into one and does not create a merge -commit, but does so only if fast-forward merzh is possible.

As you can see, the settings are quite flexible, but there are two problems.

1. There is no web-interface settings, and requests to administrators complicate the work process.
2. You cannot select a behavior for a specific pull request , the minimum configured entity is a repository.

Once these two problems are resolved, BitBucket’s support for Rebase Flow will be excellent. In the meantime ...

Gitlab

Rebase Flow Support: GOOD

Evaluating the support at https://gitlab.com , we, in fact, appreciate the support in the GitLab EE product, on the basis of which it is implemented. As for the support of Rebase Flow in GitLab CE , it is simply not there.

To understand how Rebase Flow support is organized, take a look at the project settings.

As you can see, there is even an intermediate version of the semi-linear history, when merge- commits remain, but the ability to accept a pull request appears only if the feature- branch is a linear continuation. If this option with a semi-linear history or “Fast-forward merge” is selected, we have the additional ability to manage the pull request 'om. Namely, the “Rebase onto ...” button appears, which allows you to make a feature from the feature branch a linear continuation of the story.

After that, you can easily accept a pull request , which will be interrupted without creating a separate merge- commit.

A more detailed description of this functionality can be found in the documentation ( one , two ). Despite the fact that the screenshots in it are a bit outdated, it has not lost its relevance. At this, in principle, support Rebase Flow ends. The fact that it exists at all is, of course, a plus, but it clearly lacks

1. Ability to select behavior for a specific pull request . Yes, before accepting a pull request, you can change the settings of the project itself, but this is not very convenient.
2. Possibilities of automatic merging of commits by feature -branch into one.

What is the result?

Now the majority of Git repository managers implement Rebase Flow support in some form. And the convenience of working in them is now much higher than a few years ago. But still, in my opinion, all the products still have disadvantages, and I continue to believe that they will fix them in the future.