Git - using rebase to merge public branch to master

Question

We are currently 3 devs working on a feature branch. We kept committing and pushing WIP commits to the feature_branch (and to origin/feature_branch) and every other day we merged the master to the feature_branch to make sure we are up to date with all the other changes that are happening.

Our feature_branch now contains ~100 commits (including lots of merge-commits) that can be easily squashed into one or two commits. Up until now, when a work is done on a feature branch, we just merged it back master and that resulted in spaghetti logs and checkpoint commits being pushed to master.

Instead, we want to rebase. If we decided that our work on the feature_branch is done, and no developer will ever pull or push new commits from/to this branch - and that it's time to merge our changes back to master, will rebase violate the golden rule of rebasing ?
After reading on the subject, rebase interactive on top of master sounds like a good idea (and then merge back to master which will be a ff merge) but I just want to make sure I'm not missing anything.

Also, is there anything wrong with rebasing feature_branch after we kept merging the master into it (in order to keep it updated)? Is it okay to squash merge-commits?

Thanks!

Answer 1

The choice of rebase vs merge is to some extent a matter of taste. The link you have (with the "golden rule of rebasing" saying to avoid rebasing published commits) uses a tasteful rule that keeps things simple for casual users. However, there's nothing that says that you and your co-workers cannot agree in advance to allow rebasing published commits, as long as you and they all know how to deal with them.

The git repository for git has several deliberately-rebased branches within it, called next and pu ( pu stands for Pick Up, not skunk-odor :-) ). When you git fetch the latest git, you will often see things like this:

 + 104e649...1352ede next       -> origin/next  (forced update)
 + cf10e94...a619c8c pu         -> origin/pu  (forced update)

Note the forced update , which git fetch prints because the update is not a fast forward and occurs only because of the + in the fetch refspec.

Answer 2

Actually it depend on your usual workflow and i don't think that rebasing is always wrong.

For example if you use a Garrit based workflow usually is normal to rebase with the master, squash your commits in a single commit and then push it into the master in order to merge it. (Basically you are providing to master a patch containing your code already partially merged due to your rebase operation). Here you can find a more detailed explanation of this workflow that use rebasing all the time.