![]() ![]() (And later, when you benefit from the hindsight of peer reviews and/or your own realisations about how to make things better, you simply force-push a new final candidate.) Consequently, people reviewing your PR don’t have to waste time reviewing anything unless it was a candidate for merging, and nor do CI systems. In other words, if you do your history rewriting locally, there will be a substantial increase in the quality of what you publish to the PR, because you will only ever publish commits which (at the time) you believed to be the final candidate, ready for merging. I have previously blogged about why this way is better, but one way of quickly summarising it is: don’t wash your dirty linen in public any more than you have to. The new version of the branch can then be force-pushed to GitHub via git push -f, which is an operation GitHub understands and in many situations handles reasonably gracefully. If an existing PR needs to be amended, make the change and then rewrite local history so that it’s clean. That is why there is a whole section in the “Pro Git” book dedicated to explaining how to rewrite local history, and why git-commit(1) and git-rebase(1) have native support for creating and squashing “fixup” commits into commits which they fix. However the real problem here is that that kind of mess should have never made it onto GitHub in the first place – not even onto a PR branch! It should have instead been fixed in the developer’s local repository. master) with these fine-grained commits, and instead only have larger, less fine-grained commits merged.īut where does this desire come from? Well, if the fine-grained commits which accumulate on a PR branch are frequently amendments to earlier commits in the same PR (like “oops, fix typo I just made” or “oops, fix bug I just introduced”) then this desire is entirely understandable, because noone wants to see that kind of mess on master. In other words there is a desire to not pollute the target/trunk branch (e.g. So what are the underlying problems which made this such a frequently requested feature? From reading the various links above, it seems that by far the biggest motivator is that people frequently submit pull requests (or merge requests, in GitLab-speak) which contain multiple commits, and these commits are seen as too “noisy” / fine-grained. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |