Ryan Lanciaux and I were having a conversation about git rebase and I thought I would share the gist of it here.

Using Plastic SCM I created the scenario Ryan was explaining. The beauty of Plastic SCM is how few words I need for you to understand the scenario we were discussing

The Rebase Condition

For more infomration on git rebase see Atlassian page.

I have been using Plastic SCM for years now as my primary version control system. They have also implemented the git protocol and thus it works great with github, Visual Studio Online and bitbucket. Or any of the cloud providers that support git repositories. I highly recommend it.

Plastic does NOT do a rebase. Each changeset is considered immutable. And thus you can NOT change History! Think of all the mistakes we could rewrite in life if we could change history! Not to mention our code :).

You have two options.

Reintegrate main then merge

Merge main branch down to your feature branch then merge your feature back into the main. If you are doing conflict free pull requests this would be the best choice.

Pending Reintegration of main branch in FeatureY

main branch Reintegrated into Feature Y

Feature Y Merged into main

Direct Merge

Or Simply directly merge to the main branch.

some of the reasoning for the rebase is to "clean up the history". My first though was... "you mean lie about history".

Using Plastic SCM and it's awesome GUI (yes it all can be done via command line) Isn't the actual history pretty easy to understand?