Julia Evans (@b0rk@jvns.ca)
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 (@b0rk@jvns.ca) 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.

  • unknowing8343
    2·
    1 year 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.