Git is a popular version control system. In it, an atomic change of one or several files is called a commit, and several consecutive commits are combined into a branch. Branches are used to implement new ideas (features).
It happens that the idea turns out to be a dead end, the developer turns the wrong way, and there is a need to roll back to the original version, to do this, forget about the new branch and switch to the main dev or master , and then continue to work as if nothing had happened. In this case, the “scion” will hang forever, as will the desire to remove it. But how to remove if this is part of the story? This process shows the efforts of the hard-working programmer, albeit in vain. So it is easier to report to the authorities, because an unfortunate result is also a result!
I hasten to rejoice: the Git developers in version 3 will introduce a new command to close such homeless branches. Let me remind you that the current current version is 2.21.0 .
How to use this command, what does it give and what do IT companies think? The article answers these and other questions.
Now you can close an unsuccessful branch with one of the previous commits. Closed arcs are colored in yellow in the pictures below.
Here, commit 4
is the last unsuccessful feature. He was closed with 1
, and then returned to the master and went the other way, with a commit 5
.
You can also lock a commit into yourself, thus creating loops :
You can lock into any commit - smart Git will calculate the difference by itself and combine everything correctly:
The merge
command does not hold the functionality of closures, since for the first case the branch will be fast-ford and will not do anything for the second ( git already up to date
).
In order not to change the old behavior, the developers decided to enter a command for closure:
git closure -s $source_commit -d $dest_commit -m $message
The first argument, -s $source_commit
sets the hash of the commit from which you want to stretch the "loop", and the second, optional -d $dest_commit
, sets the commit to which you want to close the loop. If it is absent, the closure occurs in the current check-out branch. The -m $message
parameter sets the closure message, such as failed feature, revert to origin
. However, the --allow-empty-message
option is also --allow-empty-message
, allowing commits without the message text. By default, Git allows exactly one closure for a pair of commits. To bypass this restriction, the option --allow-multiple-closures
.
After the command is executed, the git will calculate the changes itself, and a double diff will be visible in the final commit: from the base and closing branches. In the general case, this is an n-dimensional diff, that is, it can be closed as many times as desired. closure-commit is similar to merge-commit with the difference that it contains several messages, not just one.
Unfortunately, existing GUIs for working with Git do not yet fully support closures. The preview version of GitExtensions builds curves like a merge instead of a beautiful arc. Check out the new fields Closure message
and Closure diff
:
It is worth noting that the closure
team always changes the history (still, now Git is a full-fledged time machine!), So now you can --force
branches only with the --force
option, or with the help of the safe --force-with-lease
.
Ribeys for hinged branches are also available, but the logic for recalculating commits in them is complicated.
Also the auto
option allows you to automatically close all the old branches. In this case, the closing commit is the one from which the fork has gone. With plugins for Git IDE, closures can be run periodically. In GitExtensions, the similar Delete obsolete branches plugin deletes obsolete branches.
Large IT companies: Google, Facebook, Apple, DeepMind, Positive Technologies, and especially Microsoft, are eagerly awaiting closures, because now it will be possible to formalize the life cycle of branches, including unmerited ones.
One of Microsoft's top managers, Michael Richter, writes :
A new feature of the gita will certainly reduce the chaos in the world of open source development and more. There are a lot of "hanging" branches in our repositories. For example, in vscode there are more than 200, and in TypeScript there are generally more than 300! And this problem is not only Microsoft. Closures not only improve the organization, but also allow you to track the programmer's reasoning, sometimes completely incomprehensible even to colleagues :) The closures reminded me of the film "Back to the Future" - there the characters traveled to the past and the future. I love this film, I revised it several times. And I think I will love git because of this even more :)
If earlier the commite graph was a directed acyclic graph (DAG), then the closures extend it to a generalized directed graph . With Git, you can describe regular expressions in which the states are commits, and the alphabet is the set of all messages. But this smacks of the “abnormal programming” hub, and therefore goes beyond the scope of the article. However, if this is interesting to you, then read the article describing how to store family trees inside Git.
Source: https://habr.com/ru/post/445676/
All Articles