Keeping a beautiful commit history. What for?

If the question sounds like "why use cherry-pick when there is a merge ?", Then the answer is: there is no need. Usually, branches are created to isolate work on some feature, and there is not much point in flattening the history of commits at the end of work. It is rather even harmful, as it prevents the tracking of development dynamics.

If the question sounds like “what practical uses does cherry-pick ?”, Then here are a couple of options. Firstly, you can accidentally commit to the wrong branch, then cherry-pick will help you quickly and beautifully fix the situation. Secondly, suppose such a situation: development is carried out simultaneously in two branches, which for some reason cannot yet be done, and you must simultaneously fix a bug in both. In this situation, cherry-pick again helps the developer.

Bonus can be mentioned rebase . On the one hand, the transfer of a whole branch is a rewriting of history, which makes it difficult to track the development dynamics. On the other hand, it is possible to include in the branch a part of commits with a new (corrected) functionality that is needed in development, without confusing the story by the Merge.

Git is good because it allows you to solve the same tasks in different ways, adjusting to the needs and tastes of the developer. The specific policy of using merge / cherry-pick / rebase may differ in different projects, so there can be no clear answer to your question.

In short, it happens that you need to climb into the jungle of the history of the repository in order to understand why this or that edit was made. To be able to understand what is happening the whole story must be "beautiful", that is, visual. What does it mean? This means that the descriptions of commits should be detailed, and the merge is obvious (I wrote about it in more detail here )

As for the cherry-pick and rebase side branches before the merge - in my opinion this is not the best choice, because for the sake of "beauty", the real story is lost. Ie in this way decreases the possibility of a full analysis of the causes and sequence of changes.

Regarding the feasibility of a beautiful history of commits in principle: it gives a number of advantages:

1) repository order - if several developers worked on the project, it allows you to visually evaluate which developer performed which task and how long it took, for example, for further analysis of the adequacy of the assessment. It is also convenient if you need to roll back to the previous version, or if you need to find a piece of functionality that has been removed but you need to find it again, or find the place where the error occurred.

2) reduce the number of conflicts when merging

Further about the cherry-pick - it usually serves to pull a single commit from one branch to another. To ensure a beautiful story, rebase is more often used, well, or its version, rebase with pull: git pull -r

One of the reasons for combing commits is keeping a certain level of granularity. This makes it possible to track the development history from a single viewing height.

Convenience is about the same grade as convenience from the same call depth in the code within the same method. Or convenience from the same granularity of the classes in the package. It seems that in programming this is called the principle of minimal awareness.

In general, the history of commits should linearly guide us through the history of the project from the beginning to the current commit. Or the question is, which practical problems can be solved using this story?

UPD. By the way, one conceptual problem is connected with rewriting the history of commits. And this problem is with the correctness of rewritten commits. Suppose we put on the beauty and srabeyzili branch features with a dozen commits to the main. As a result, it may turn out that an attempt to build some commits from this dozen will end in failure, despite the fact that the head commit goes through the whole integration. In this case, it’s not such a beautiful story. Here's what to do with it?

When you do merge, it merges a branch (last commit) with the branch with which you merge.

In the case of the cherry-pick, the commits from the branch are applied sequentially. Those are the merge of the current branch with each commit from another branch sequentially.

In addition, this is not all the features of cherry-pic - you can add only a certain sequence of commits and so on to the branch.

More information can be found in the documentation.