Menu
I started to rewrite some of the Perl programs from the NASM source files. I have already done a few commits to my own working copy, and I was wondering if I should have instead of doing git pull, if I should have been doing git rebase.
I have pretty much decided that I should have been doing a git rebase, but I don't know how to rework my repository to achieve that effect, or even if it is possible.
234
With the rebase command, you can take all the changes that were committed on one branch and replay them on a different branch.
For each change you make, you'll need to perform a new commit, and you can do that by entering the git commit --amend command. When you're finished making all your changes, you can run git rebase --continue . As before, Git is showing the commit message for you to edit.
Git Rebase is one of the most commonly used ways to rewrite commit history on a branch. You can use it to clean up a feature branch before publishing or incorporate new commits from another branch.
If you don't want rebase to stop at each commit if you get any merge conflicts and want it to stop only once during the rebase process, you can squash all the commits into one in your fix/align-div-vertically branch by squashing them using interactive rebase before rebasing with the master.
It is possible, and the Git Magic tutorial will explain how to do it. But if anyone else has seen your branch, it is unsafe. Even if nobody else has seen your branch, let me urge you to reconsider.
The purpose of rebasing is to rewrite history so that your repository reflects the way you believe your software should have evolved instead of the way it actually did. When is this important? When you are a junior member of a distributed development team, and you don't have commit privileges—instead, all you can do is submit patches to a gatekeeper and hope that they are accepted. To maximize the chances of acceptance, you want to rewrite history to make your patches as clean and clear as possible. Is the development model sounding familiar?
Manoj Srivastava has written a fairly thoughtful analysis of rebase-vs-merge.
62
I've had success with the following method in the past:
For this method, I have added the following alias:
up = pull --rebase origin
When pulling in changes from the remote repo:
YMMV
27
git log
git reset HEAD^
Next time I recommend to do a git fetch and then the rebase as step 3.
I would recommend to create a small tarball of your current git repo, just in case the rebase goes wrong. You'll do that less often when you feel more confident (and usually you can fix almost everything with git, but sometimes the tarball is faster).
37
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
