Git question: merge or rebase?

  • Topic Archived
You're browsing the GameFAQs Message Boards as a guest. Sign Up for free (or Log In if you already have an account) to be able to post messages, change how messages are displayed, and view media in posts.
  1. Boards
  2. Game Design and Programming
  3. Git question: merge or rebase?

User Info: scar the 1

scar the 1
1 year ago#1
Hey all, I was talking to a friend who wound up going into the software industry the other day and we talked a little about git.
As we went through uni we kinda taught ourselves how to use it, and we figured that workflow would essentially be something along the lines of
1. Create a branch for the new feature you're adding
2. Do your feature
3. Merge it with the main branch. If the main branch has been updated, do a double merge.

Now what he said the other day was essentially that he's now using git "the right way", i.e. with git rebase instead. I've googled it a little bit and I might have a cursory idea of what it's all about, I was just wondering what all you git users think? Is there one "right" way about this, or what does it depend on?

https://www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview/
Everything has an end, except for the sausage. It has two.

User Info: TrueKu

TrueKu
1 year ago#2
this seems reasonable:
http://blogs.atlassian.com/2014/01/simple-git-workflow-simple/

rebase nonpublic feature branch on changes from main branch.
when feature is done, pull-request(code review)?, non-fast-forward merge changes from feature into main.
Chief Scientician

User Info: ReconditePhreak

ReconditePhreak
1 year ago#3
I feel like this does a good job explaining when/where to use rebase vs merge.

https://medium.com/@porteneuve/getting-solid-at-git-rebase-vs-merge-4fa1a48c53aa#.lwbhttalg

As an aside, I would caution your friend about thinking in terms of right and wrong, it's a really bad habit for a software developer. Optimal and suboptimal are better ideas to use when making decisions.
Believes the individuals who report to moderators wish they had more control than they do.

User Info: scar the 1

scar the 1
1 year ago#4
Thanks!
Yeah, I'm not sure he's really that serious about it being the "right" way, since he's usually somewhat sensible.
Another one of my former classmates worked his way into the gaming industry, and apparently what's cool there is Perforce. It seems to have a more granular approach to version control, as in being able to roll back/review things on a file by file basis instead of commit by commit. Is it possible to do similar things with git without completely bending over backwards?
Everything has an end, except for the sausage. It has two.

User Info: flussence

flussence
1 year ago#5
The question is nonsense. You usually use *both* with a feature branch workflow.
https://gitlab.com/flussence/GFCSS
Remove Kebab

User Info: Cheezmeister

Cheezmeister
1 year ago#6
I don't understand how merging and rebasing are construed to be competitors. Rebasing doesn't even make sense without merging. Well, actually it's useful for a lot of other things as well, but the main reason it exists is to make merges appear less messy by doctoring up the commit history. Which is fine, and sometimes you totally want five mini-commits to appear as one for posterity. But it's not "wrong" not to use it.

As a side note, if you continually merge to your feature branch and encounter conflicts along the way, you probably do NOT want to rebase onto master as you'll be forced to relive every manual resolve you dealt with, and possibly other fake ones. Instead, you might wish to reset --soft master, then commit all of your (now unstaged) changes at once, one operation, no nonsense, happy happy. However, you can't keep your itemized commit history this way, so really it's best judgment.

> Another one of my former classmates worked his way into the gaming industry, and apparently what's cool there is Perforce. It seems to have a more granular approach to version control, as in being able to roll back/review things on a file by file basis instead of commit by commit. Is it possible to do similar things with git without completely bending over backwards?

Careful. P4 is a power tool more like a sawzall to git's penknife. It's "cool" (read: necessary) in gamedev because it works well with large binary blobs and is crazy fast. If you try to put 10GB worth of uncompressed textures into a git repository, you're gonna have a bad time. Perforce is not more granular than git. If you revert a single file, that still records as one commit. Unlike git, you can partially check out the depot, but only because, unlike git, there is one depot to rule them all, and you're not ever supposed to get the entire sproinking thing.

You can revert single files with git, it's just that the syntax varies based on branch, state, version, and phase of the moon. You can even revert at the sub-file level with `reset -p`
I make games!
http://luchenlabs.com

User Info: scar the 1

scar the 1
1 year ago#7
Alright, thanks for the insight.
I think he construed rebase and merge as competitors because as we started out and taught ourselves, we only used merge. Now he's completely blown away by how rebase makes the commit history look so much better.
Everything has an end, except for the sausage. It has two.
  1. Boards
  2. Game Design and Programming
  3. Git question: merge or rebase?

Report Message

Terms of Use Violations:

Etiquette Issues:

Notes (optional; required for "Other"):
Add user to Ignore List after reporting

Topic Sticky

You are not allowed to request a sticky.

  • Topic Archived