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.
Zis 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 masterto 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
foohas already merged to master and will fast-forwardfooto the statemasteris in. This is the same thing thatgit merge masterwould do, and also means that, quite simply, foo is the same thing as master.Knowing that, however, I would just use
git mergehere, since that makes more logical sense to me (you use merge to do fast-forwards, it even has an--ff-onlyflag if you want to make sure you're not doing a real merge). The time to use rebase is when you're working onfooand 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
foonow pointing to master, or more accurately, commitG. No new commits are created, so the repository would stay the same with the exception of moving whatfooreferences.
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.
加载中,请稍侯......
精彩评论