-
-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Force Git Squash and Git Rebase before every PR being merged #6802
Comments
I'm not sure what the benefit of doing this would be and I feel like squashing commits erases history and context to a merge, not to mention the PR author's authorship. If a particular issue stems from the middle of a PR, we have no easy way of tracking it down. In addition, having to go through the repo locally for every PR to do the squash and rebase is a bit too much and isn't practical in my opinion. |
I think there's a squash and merge option in GitHub's UI that we could enable if we want: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/about-merge-methods-on-github#squashing-your-merge-commits
For me the benefit would be easier browsing of the history of a file: individual commits within a PR are a lot less likely to have useful context for me personally rather than info about the PR in general. If I want to check the context of a line of code, I usually go to the commit, and then click through to the PR it came from. This is still possible without squash & merge, just more cumbersome. I don't have a strong opinion on this one, I'd be ok either way. |
Yeah I get that and I do that as well but to give a bit of context in terms of what the full commit history can be useful for, what I often use when there is a regression or a bug introduced some time in the past but I'm not sure where and when, I will do a From that commit I got from |
I am more open to considering a rebase merge but there are some downsides to rebase merge as well (at least GitHub's version of it, we won't be using local rebase and merge as mentioned before). GitHub rebase and merge takes individual commits from the head branch and apply them onto the base branch as new commits, this means that the commit hash in the original branch and in the PR itself will be different from what is merged into the base branch. Once we identify a problem commit in the merged base branch, its hash does not existing on the original branch. The lack of a merge commit also makes it a bit more difficult to identify the original PR from the commit, ie. we no longer have a commit that tells us "Merge pull request #____ from _____", I'm not sure if GitHub keep track of this information separately itself but it won't be part of the git history of the repo. |
Improve Git commit History
Issue
As of now, the entire p5.js repository does not follow squashing down all of the commits of a PR to one commit and then rebasing the branch with main branch before merging a PR.
This creates a messed up commit history. Squashing down commits improves readability throughout the git log.
Steps to squash Down Commits to one commit
To squash down 'n' number of commits:
git rebase -i HEAD~n
This will open up your editor of choice for Git. The default is Vim.
Now, you need to replace all those pick with squash (or simply s) apart from the first one.
Note -
pick
orp
will only use those commits, butsquash
ors
will use them and combine them all together.Steps to rebase the PR branch with main branch
git pull upstream main
git rebase upstream/main
git add .
git commit -m “Original commit message that you used earlier”
git rebase --continue
git push -f origin [branch name]
The text was updated successfully, but these errors were encountered: