Rebase or merge for updating branches?

[paulheinr]

I have noticed that some people are merging the main branch into a feature branch and some rebase the feature branch onto the main branch. When you update a branch on github, it merges.

Do we have a policy for this? Merging creates a merge commit.

[kt86]

I think, that we do not have a policy for it. I am a bit in favor for "merge".
For me that additional commit, makes it a bit more easily to see/read, what has happened - without scrolling to the wide and long history.
Other people argue exactly the other way round, that they find all that "merge" commits confusing/enlarging the historie.

It is the same, when merging a PR: Most of us merge it, few (if any?) rebase it, and a few squash and merge*.

*Squashing is what I dislike most, because it puts all changes from commits before and creates a new commit with these changes, so you can end in a situation, where your parent commit does not exist anymore, when branching from one of this intermediate commits before squashing -.- On the other hand, I see,why peaople use it, to reduce the historie...

[sebhoerl]

I think it's not so much about squashing or not, but about the quality of the commits. IMO every change that is made to the code base should be somehow self-contained and not cut in a hundred pieces that partly replace each other, because somebody was just testing out things. One can think of squashing as somebody wanting to add a feature and then simply committing the final version, not every single development step.

Beyond that, and ideally, one could enforce to use conventional commits for the PR names and then use something like release-please that generates an automatic change log :)

PS: Sorry, I hit the close button ;)

[kainagel]

When I see the curved paths that I take until I have implemented something more or less correctly, I think it makes a lot of sense to not include this into the main history. If this means squash or merge I do not know.

[kt86]

@kainagel That would be "squash": It puts all your changes from all commits together as one new commit and throws away the old ones.
IMO: Totally fine for changes that have a limited size and are running with some curved paths, or one to x "fix/adapt test" commits....

---

For larger changes, maybe create locally another branch, cherry-pick your commits from the first develop-branch and then interactively rebase them, which allows also combining commits...Now you have a branch with a clear and straightforward commit history to merge into master/main...
(you can only do it locally. The new branch is only needed when you have pushed your changes before, because interactively rebasing will break the history of that branch, because it creates new commits and removes the old ones -- similar to "squash and merge")