When do people prefer merge versus rebase?
When do people prefer merge versus rebase?
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 ...
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.
You're viewing a single thread.
Man, these git commands. I don't think I will ever master them.
Yeah it's rough. I'm having a hard time staying committed.
You just have to push through
but don't squash your feelings
Pick cherries when you can
Surely those cherries come from a remote origin.
Then check-out their due date, specially if they have been left out in a stack for too long, before you pop one out.