0

I'm a bit confused by git rebase.

I have a develop branch and a staging branch. I've merged develop into staging

git checkout staging
git merge develop

But there are a bunch of duplicate commits because of cherry picks; I want to remove the duplicates. Should I do the following?

git checkout staging
git rebase develop

UPDATE: The git merge develop is local, so I haven't pushed it yet

Russell England
  • 9,436
  • 1
  • 27
  • 41
  • 1
    You'll need to look into `git rebase -i` (interactive). However, it is not advised to rebase a branch (or the part of it) that has already been pushed: you should only rebase purely local commits that have not been shared yet. A good introductory article is http://git-scm.com/book/en/Git-Tools-Rewriting-History – MicroVirus Aug 22 '14 at 09:56

1 Answers1

2

The general answer is: yes, rebase will squash your duplicate commits. Specifically, it will drop the cherry-picked commits, if the same commit exists in the staging branch.

However, I'd suggest to rebase your develop branch, and after that merge it to staging, i.e.

git checkout develop
git rebase staging
git checkout staging
git merge develop

It's better practice to rebase the branched off branches instead of the main branches.

I partially agree with @MicroVirus' comment above, but I think this is only important for the main branches (mostly master, in your case staging, ...), which should be stable and not change its history, as other people may already have cloned and checked them out and most importantly, base their work off them. For feature or development branches, which are work in progress anyway, it's ok to change the history.

EDIT

Sidenote: In general it's a better workflow to regularly rebase your develop branch to staging if you need newer commits from the staging branch instead of cherry-picking.

koffeinfrei
  • 1,985
  • 13
  • 19