![]() ![]() “Squash and merge” works well if you don’t care about the back and forth that lead to the final implementation shipped with the pull request. On the GitHub website, #3 would be a link to the related pull request.įor example, this commit in the Administrate repository is the result of a pull request containing multiple commits. The nice thing with GitHub is that it also automatically adds a reference to the pull request number at the end of the commit title. (Alternatively, one could switch to the main branch and cherry-pick the single, combined commit.) You could achieve the same manually by first doing an interactive rebase: The combined commit is then added “on top” of the commits from the main branch. ![]() This combines all commits from the branch into a single one. In hindsight, tagging commits on release would have provided a similar benefit, assuming each pull request is deployed immediately after merging. I have used merge commits successfully to denote blocks of changes like in the example above. Keep you history tidy, even splitting commits if it will make review easier. ![]() Please use git rebase to keep on top of updates from the main branch. If the pull request author has been using git merge (or GitHub’s “update branch” button on the pull request page) to regularly bring changes from the main branch back into theirs, I have a hard time understanding their train of thought. Merge commits irritate me particularly during code review. All of the merge commits are noise in that case. Sometimes you read the git history in search of specific changes and git blame doesn’t help (“What was the commit where we deleted this feature?”). Merge pull request #3 from redacted/automatic-deploymentĪutomatically deploy to production on successful staging deployment Merge pull request #4 from redacted/playlists-pagination ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |