Git - Merge vs Rebase用于我的工作流程

Question

I've been doing some reading on how both the git merge and git rebase operations work, and I think I have a very basic understanding of the differences. I've seen the diagrams :-) Despite that, I'm still not clear on what would be the best of the two to use for my current worflow.

My work is using perforce as it's SCM system, but I'm using git locally to keep track of local changes, do refactoring, and a bunch of other cool stuff that git can bring to bring to the table. I know there already exists a tool to help facility working with git and perforce (ex p4-git) but I don't necessarily want/need that overhead, so I'm trying to keep things as simple as possible. Here's a brief description of my current workflow for creating local git branches and eventually integrating back into our main perforce depot:

1. I have a master git branch, which does a nightly p4 sync to our codebase. After the perforce sync, I commit all changes to the master branch. In effect, my master git branch is essentially a snapshot of the latest code committed to our perforce mainline.

2. For local changes I'm working on, I always create a git branch first, and checkout this branch while working on the change.

3. Every now and then I want to update my branch to the latest from the master . Until now I've just been issuing a git merge master command to do that and it's been working out fine.

4. When I'm ready to commit to the actual perforce depot, I merge my branch back into my master branch, by checking out the master and issuing git merge BRANCH and then submit using regular perforce commands

Given my workflow, should I really be using a git rebase master command for Step#3 instead of a git merge master ? From my understanding of the rebase command, this would only be necessary if say our perforce mainline (remote depot) was branched, and I wanted to create a new master based off this branch (say I call it master-newbranch) and apply my changes to this new branch. I would need to rebase off this branch first?

In general, does my current workflow make sense, or have I already picked up some bad habits?

Answer 1

I have much the same workflow and prefer using git rebase -i master. This keeps all the perforce resyncs at the bottom of the change list. Thus it appears I checked out the latest version and made a ton of changes. Also only changes that pertain to the branch show up after a resync. Seems more intuitive, but it sounds more like style thing than a correctness thing. ~Ben

Answer 2

You should not (necessarily) be using rebase over merge in this case. Remember, rebase essentially re-writes your history. It's useful in cleaning up multiple branches and providing a more linear history, but from your use case you're not gaining anything by using rebase. The behavior you've described is a normal git workflow which merge was designed for.

The tricky thing about rebase is when you're rebasing (re-writing history) commits that you've already pushed. This can cause major headaches in collaboration with others, but you're using perforce for collaboration, so you're unlikely to run into this problem.

Answer 3

Rebase is rewriting your history. So really depends on how you want to keep your history. Rebase keeps history more clearer in general.

History shows what has happened in your project. But, you don't have to expose everything you have done. Imagine you are writing a book. You don't have to show users your writing history including draft versions.

In my case, I usually prefer rebase over merge when it comes to merging master to branches.