Git

2910 readers

1 users here now

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Resources

Rules

Follow programming.dev rules
Be excellent to each other, no hostility towards users for any reason
No spam of tools/companies/advertisements. It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.

Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.

founded 1 year ago

MODERATORS

Ategon

canpolat

jnovinger

When do people prefer merge versus rebase? (social.jvns.ca)

submitted 10 months ago* (last edited 10 months ago) by ericjmorey to c/git

9 comments fedilink hide all child comments

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.

top 9 comments

sorted by: hot top controversial new old

[–] [email protected] 12 points 10 months ago (1 children)

Man, these git commands. I don't think I will ever master them.

[–] silas 19 points 10 months ago (1 children)

Yeah it's rough. I'm having a hard time staying committed.

[–] charolastra 14 points 10 months ago (1 children)

You just have to push through

[–] [email protected] 7 points 10 months ago (1 children)

but don't squash your feelings

[–] [email protected] 6 points 10 months ago (1 children)

Pick cherries when you can

[–] noproblemmy 5 points 10 months ago (1 children)

Surely those cherries come from a remote origin.

[–] [email protected] 4 points 10 months ago

Then check-out their due date, specially if they have been left out in a stack for too long, before you pop one out.

[–] nous 12 points 10 months ago* (last edited 10 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.

[–] [email protected] 2 points 10 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.