Julia Evans (@[email protected])
social.jvns.ca
i've been trying to figure out why some people prefer merge and some people prefer rebase. I feel like there must be some systematic reasons, like "people in situation X tend to prefer rebase, people in situation Y tend to prefer merge” my only thought so far is that small short-lived changes work well with rebase, and longer-lived branches are maybe better to merge (not looking for why you think rebase/merge is better here or why the people who disagree with you are wrong) (1/?)

Julia Evans (@[email protected]) writes:

i’ve been trying to figure out why some people prefer merge and some people prefer rebase. I feel like there must be some systematic reasons, like "people in situation X tend to prefer rebase, people in situation Y tend to prefer merge”

my only thought so far is that small short-lived changes work well with rebase, and longer-lived branches are maybe better to merge

(not looking for why you think rebase/merge is better here or why the people who disagree with you are wrong)

similarly, I’m trying to figure out why some folks prefer a linear commit history and some folks prefer to preserve the history as it actually happened

I feel like there are also some systematic reasons for this (like in situation X a linear history is more appropriate but in situation Y it’s more appropriate to preserve what actually happened) but I haven’t worked it out

for example maybe “preserve what actually happened” is more appropriate for open source projects? not sure.

  • nous@programming.devEnglish
    11·
    11 months ago

    I suspect the answer for most people is habbit. It is what they are used to and have always done.

    Personally I lean towards more linear history as it creates a cleaner commit graph and is close enough to what really happened and the exact details of small meaningless commits and merges that were created during development of something don’t matter that much. If anything they add a lot of noise to commit graphs that make it harder to see what actually happened and when. I have seen code bases where the git commit graph takes up more than a full screen to render because of all the merging and it is not fun to navigate to understand what happened at some point.

    Far nicer to just step back in a mostly linear history that jump around back and forth on various difference branches and merge commits. Even if it is not technically what really happened during development - as generally I only care what happened when something was merged into master, not on individual branches.

    But I also prefer to work on small feature sets at a time and frequently merge back into master and not spend weeks or months working on a different branch that contains loads of changes not yet in master. My goto command for pulling from upstream is git pull --rebase=interactive --autostash origin master (no need to fetch with a pull, though my local master tends to get behind origin - not that it matters) and I will quite often git commit --amend or squash/reorder/edit things to give a simpler history before creating a PR.

    But at the same time, on smaller projects it really does not matter that much. Follow the conventions of the projects you work on and do whatever you want on your own projects.

  • unknowing8343@discuss.tchncs.de
    2·
    11 months ago

    I rebase for small things, specially if no changes have happened on the “main” branch. I merge feature branches or stuff that has suffered changes in both branches, so as to have a commit that basically shows what had to be done to successfully merge them.