You will find that some open source projects will encourage this, such as the Office 365 CLI who operate a One PR = One Commit rule for pull requests helping keep the commit history nice and clean for all to see.īy using something called, git interactive rebase, which we can use to help re-write the commit history in our local repository.Ĭonsider this scenario, I am writing a blog post in a new feature branch, I create the basic page for the post with a title and commmit this change. Therefore it is good practice that before submitting a pull request, you tidy the history of your feature branch to just represent all the changes you have made in a single commit. ![]() This level of detail may make great sense to someone who has written the code, however this maybe confusing the someone who is required to review those changes as part of a pull request code review.ĭoes the reviewer really need to know that you made 5 commits to get something working or another 3 commits to fix typos? Probably not. That said, commiting frequently does have its drawbacks, it can lead to pull requests being created with several or if it is a larger change, potentially hundreds of commits. ![]() It is good practice to commit changes frequently as we work in our feature branches so that we can keep track of the changes we have made and make it easier to roll back to a working state. ![]() This post will show you how to merge all of your commits into one to help make your pull requests lighter and help keep the history clear for others to track changes.Įvery commit you make, saves any changes to a local git repository, helping build up a history log of what has happened over time. Squash your commits using git interactive rebase 10 March 2020
0 Comments
Leave a Reply. |