Browse Source

Add a section on rebashing and squashing

Peter J. Jones 2 years ago
Signed by: Peter Jones <> GPG Key ID: 9DAFAA8D01941E49
1 changed files with 75 additions and 0 deletions
  1. 75

+ 75
- 0 View File

@@ -59,6 +59,81 @@ Here are some tips for getting your changes merged into xmonad:
repository. Include a new configuration file that shows off your
changes if possible by creating a PR on that repository as well.

* Make sure you read the section on rebasing and squashing commits

## Rebasing and Squashing Commits

Under no circumstances should you ever merge the master branch into
your feature branch. This makes it nearly impossible to review your
changes and we *will not accept your PR* if you do this.

Instead of merging you should rebase your changes on top of the master
branch. If a core team member asks you to "rebase your changes" this
is what they are talking about.

It's also helpful to squash all of your commits so that your pull
request only contains a single commit. Again, this makes it easier to
review your changes and identify the changes later on in the Git

### How to Rebase Your Changes

The goal of rebasing is to bring recent changes from the master branch
into your feature branch. This often helps resolve conflicts where
you have changed a file that also changed in a recently merged pull
request (i.e. the `` file). Here is how you do that.

1. Make sure that you have a `git remote` configured for the main
repository. I like to call this remote `upstream`:

$ git remote add upstream

2. Pull from upstream and rewrite your changes on top of master. For
this to work you should not have any modified files in your
working directory. Run these commands from within your feature
branch (the branch you are asking to be merged):

$ git fetch --all
$ git pull --rebase upstream master

3. If the rebase was successful you can now push your feature branch
back to GitHub. You need to force the push since your commits
have been rewritten and have new IDs:

$ git push --force-with-lease

4. Your pull request should now be conflict-free and only contain the
changes that you actually made.

### How to Squash Commits

The goal of squashing commits is to produce a clean Git history where
each pull request contains just one commit.

1. Use `git log` to see how many commits you are including in your
pull request. (If you've already submitted your pull request you
can see this in the GitHub interface.)

2. Rebase all of those commits into a single commit. Assuming you
want to squash the last four (4) commits into a single commit:

$ git rebase -i HEAD~4

3. Git will open your editor and display the commits you are
rebasing with the word "pick" in front of them.

4. Leave the first listed commit as "pick" and change the remaining
commits from "pick" to "squash".

5. Save the file and exit your editor. Git will create a new commit
and open your editor so you can modify the commit message.

6. If everything was successful you can push your changed history
back up to GitHub:

$ git push --force-with-lease