Why do GIT users edit their commits?

In the last two issues of Radio-T, the presenters tried to discuss GIT. Eugene (@Umputun) wondered why he needed a rebase and was very surprised when I asked if he was editing commits. In my opinion, to understand GIT, it is enough to penetrate into the development process of the Linux Kernel, that is, it was created just for this.

Let's follow the changes to the main repository. The developer clones his git and starts developing new functionality. During the development process, he writes code, tests, finds bugs, fixes them. Probably makes some commits. When the feature is ready, you cannot simply take and send all these commits in the form of patches, just as you cannot send all this in the form of a single patch.
The developer’s next goal is to break all the changes so that they are understandable to the maintainer and other team members. There are several rules in this process: each patch contains only one logical change; each patch should not be destructive; A commit message should describe changes as precisely as possible.

This double work has its own motivation. Viewing patches (review) is not the most exciting and interesting, so everyone should try to facilitate this process to the maximum. Maintainer, like the rest of the team, is not interested in watching your thoughts float in search of the right solution. It is enough for them to read the commit message, where it will be described why this approach was chosen. Even less interest are the bugs that you made during development.

I most often create a new brunch, roll back all the commits (git reset) and start a breakdown with git commit --interactive. This command allows you to select which changes go to which commit. When everything is ready, patches can be created using the git format-patch command and sent using git send-email.
')
It’s good if the patches were immediately accepted, but sometimes someone finds errors in them, asks for comments or something else to fix. In this case, we need git rebase --interactive, which allows you to change the order of commits, combine two or more commits, or stop at any commit to edit it. After fixing all the shortcomings, we form and send patches a second time, and so on, until they are accepted. By the way, before sending patches to the newsletter, you need to update your repository, and in such a way that all our changes remain on top, this is called a rebase.

If the maintainer accepts patches, he commits them to his repository. When the next merge window arrives, it sends a pull request to a superior maintener. Ideally, you could transfer each new change individually and have a linear history. We live in the real world, where changes may conflict with each other, and there is no time for each individual change. Therefore, git pull comes to the rescue, in which all changes are committed in one piece, and conflicts are fixed once, although in history (git log) everything looks linear.

Also in the podcast, git bisect was mentioned, it is a tool for a binary search for a commit that broke everything. Suppose you know commits where there was a bug and where the bug already exists. The goal is to find the commit that put this bug in the minimum number of steps. Roll back to the commit, which is exactly in the middle. If there is no bug at this point, then the problem commit is on the right, otherwise it is on the left. Repeat until we find. The peculiarity of git bisect is that it can correctly handle non-linear chunks of history, which we talked about above.