Will I run into trouble with this Git rebase workflow?
I've just learned about rebase, and I've been strongly warned not to rebase commits after they have been pushed to a remote. I want to make sure I'm not going to explode my repository
Example commit history
foo W---X---Y
/ \
master A---B---C---D---E---Z---F---G
Here, all commits on the master branch will likely have been pushed to origin/master.
Z
is an automatic commit made by git-merge by merging the completed foo branch (Y) with the c开发者_开发问答urrent master (E).Since the completion of the foo module, master has made some updates (F and G).
Here's how I'd like to use rebase.
It's time to make some updates on the foo branch, but it's out of sync with the master branch.
Is it ok to simply
git rebase master
to include F and G commits on the latest foo branch?Can you modify my diagram to show me what my commit history will look like afterward?
Hypothetically, yes, it is okay to do because git will detect that
foo
has already merged to master and will fast-forwardfoo
to the statemaster
is in. This is the same thing thatgit merge master
would do, and also means that, quite simply, foo is the same thing as master.Knowing that, however, I would just use
git merge
here, since that makes more logical sense to me (you use merge to do fast-forwards, it even has an--ff-only
flag if you want to make sure you're not doing a real merge). The time to use rebase is when you're working onfoo
and have several commits there (and haven't pushed it) and someone has committed to master. Rebase will bring your branch up to date without doing a merge commit.I could, but it would be the same diagram, but with
foo
now pointing to master, or more accurately, commitG
. No new commits are created, so the repository would stay the same with the exception of moving whatfoo
references.
PS. I tested this locally on a fake repository to make sure, since using a rebase in this scenario was not something I had tried before.
精彩评论