May 7, 2013 at 19:41Why do GIT users edit their commits
In the last two issues of Radio-T, the presenters tried to discuss GIT. Eugene (@Umputun) wondered why rebase was needed and was very surprised when I asked if he was editing commits. In my opinion, to understand GIT, it is enough to delve into the Linux Kernel development process, because it was created just for this.
Let's see how the changes get to the main repository. The developer clones git to himself and begins to develop new functionality. During development, he writes code, tests, finds bugs, fixes them. Probably doing some number of commits. When the feature is ready, you can’t just take and send all these commits in the form of patches, just as you can’t send all this in the form of a single patch.
The next goal of the developer is to break all the changes in such a way 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; The commit message must describe the changes in as much detail as possible.
This double job has its own motivation. Viewing patches (review) is not the most fascinating and interesting thing, so everyone should try to facilitate this process to the maximum. The 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, which will describe why this approach was chosen. Even less interesting are the bugs that you made during development.
Most often I create a new brunch, roll back all the commits (git reset) and start the breakdown with git commit --interactive. This command allows you to choose which changes go to which commit. When everything is ready, patches can be formed using the git format-patch command and send them 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, git rebase --interactive will come in handy, 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 the 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, so that all our changes remain on top, this is called rebase.
If the maintainer accepts patches, then it commits them to its repository. When the next merge window arrives, it sends a pull request to the upstream maintainer. Ideally, it would be possible to transfer each new change individually and have a linear history. We live in the real world, where changes can conflict with each other, but 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, a tool for binary search for a commit that broke everything. Suppose you know commits where there was no bug and where the bug already exists. The goal is to find the commit that planted this bug in the minimum number of steps. We 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. We repeat until we find it. The peculiarity of git bisect is that it can correctly process non-linear pieces of history, which we talked about above.
Let's see how the changes get to the main repository. The developer clones git to himself and begins to develop new functionality. During development, he writes code, tests, finds bugs, fixes them. Probably doing some number of commits. When the feature is ready, you can’t just take and send all these commits in the form of patches, just as you can’t send all this in the form of a single patch.
The next goal of the developer is to break all the changes in such a way 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; The commit message must describe the changes in as much detail as possible.
This double job has its own motivation. Viewing patches (review) is not the most fascinating and interesting thing, so everyone should try to facilitate this process to the maximum. The 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, which will describe why this approach was chosen. Even less interesting are the bugs that you made during development.
Most often I create a new brunch, roll back all the commits (git reset) and start the breakdown with git commit --interactive. This command allows you to choose which changes go to which commit. When everything is ready, patches can be formed using the git format-patch command and send them 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, git rebase --interactive will come in handy, 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 the 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, so that all our changes remain on top, this is called rebase.
If the maintainer accepts patches, then it commits them to its repository. When the next merge window arrives, it sends a pull request to the upstream maintainer. Ideally, it would be possible to transfer each new change individually and have a linear history. We live in the real world, where changes can conflict with each other, but 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, a tool for binary search for a commit that broke everything. Suppose you know commits where there was no bug and where the bug already exists. The goal is to find the commit that planted this bug in the minimum number of steps. We 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. We repeat until we find it. The peculiarity of git bisect is that it can correctly process non-linear pieces of history, which we talked about above.