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

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.