It's valuable in the same way that well structured code and good documentation is. In other words, it helps in terms of code base maintainability.
For example, I can run git blame on a line of code and see the reason it's there in the associated commit message. I can run git show on the sha value of the commit and see that line in the context of the change it's part of. That can help me in terms of not inadvertently introducing a regression by updating a particular line of code.
Of course, all that is highly dependent on well structured commits that only do one thing and have any informative commit message associated with them.
> You’re asking someone to do a lot of work by cleaning up their feature branch.
Not anymore than asking them to add proper documentation or additional test cases. It's not just about the change itself. It's how the change is presented in terms of documentation, organization, and in chunks that allow one to isolate a bug to a small part of the overall change.
> Personally, I prefer doing a single git revert <commit> and knowing that master is in a valid state.
Then you get a lot of churn that has to be filtered through to determine why a particular change was reverted. If you could add tests to verify the presence of a bug, and then just revert the part of the change responsible for the bug and update the assertions on the tests, then you can easily follow the sequence of events by looking at the history.
I think the difference between the two approaches comes down to the release cycle. For something like a backend that gets deployed multiple times a week, the most important thing is to get the backend working again once it breaks. Just as an example, for each minute that the Facebook ads backend is down, hundreds of thousands of dollars are lost. In this case, you really want to be able to remove changes entirely.
It's valuable in the same way that well structured code and good documentation is. In other words, it helps in terms of code base maintainability.
For example, I can run git blame on a line of code and see the reason it's there in the associated commit message. I can run git show on the sha value of the commit and see that line in the context of the change it's part of. That can help me in terms of not inadvertently introducing a regression by updating a particular line of code.
Of course, all that is highly dependent on well structured commits that only do one thing and have any informative commit message associated with them.
> You’re asking someone to do a lot of work by cleaning up their feature branch.
Not anymore than asking them to add proper documentation or additional test cases. It's not just about the change itself. It's how the change is presented in terms of documentation, organization, and in chunks that allow one to isolate a bug to a small part of the overall change.
> Personally, I prefer doing a single git revert <commit> and knowing that master is in a valid state.
Then you get a lot of churn that has to be filtered through to determine why a particular change was reverted. If you could add tests to verify the presence of a bug, and then just revert the part of the change responsible for the bug and update the assertions on the tests, then you can easily follow the sequence of events by looking at the history.