SingleStone
Published in

SingleStone

A Git Workflow Using Rebase

How I learned to stop worrying and love the rebase

Why rebase?

Why squash?

4d7269c (HEAD -> issue-1) added missing semicolon, lol
ae37a28 my code is broken
30cd73d syntax error ugh
cf5ff68 syntax error2
44962e5 syntax error
26a6423 Broke linter
2a9a75d Fix issue in method
7d0be0e Get tests passing
bd23847 Add some more code
8f34218 Implement feature XYZ
4cb7063 (master) Initial commit
c27766b (HEAD -> issue-1) Implement feature XYZ
4cb7063 (master) Initial commit
commit c27766b4006fa5b1680803748ecfae07b17f1454 (HEAD -> issue-1)
Author: Chris Belyea <chris@chrisbelyea.com>
Date: Fri Jan 12 10:42:08 2018 -0500
Implement feature XYZImplements feature XYZ which does blah blah blah. This includes:
- this
- that, and
- the other
Closes #1.

Ground rules for this workflow:

  • You’re using the Git CLI. The CLI is consistent across platforms. Most Git GUIs, on the other hand, have too many vague abstractions that would make following this guide difficult. If you want, have a GUI tool like Sourcetree, GitUp, or gitk running side-by-side to help you visualize what’s happening.
  • You’re using GitHub, GitLab, Bitbucket, or another Git platform that supports the concept of GitHub-style pull requests.
  • You have a Git repository that contains the code that you and your team are working on. For the purposes of this guide, we’ll call that repository pebble.
  • Every contributor forks the repository and works in their own fork. On public projects where you don’t have write access this is the only way to do it. But forking also works well for internal projects because it gives each contributor their own private workspace. Forks are free, so there isn’t a compelling reason not to use them. Forking prevents two developers from collaborating on the same branch without granting additional permissions, but you shouldn’t do that anyway because you increase your chances of encountering merge conflicts. If you think you need more than one person working in a single feature branch, then your feature is too big and should be broken into smaller units of work.
  • The most important rule: Don’t rebase a branch that multiple people have access to! Only rebase branches in your fork. As I’ve already mentioned, rebasing is a destructive operation. If you’re doing it in your repository, which only you can access, then there’s no issue. If you rebase a branch that other people have access to, you’re going to run into trouble. So only rebase your own branches, and only push those rebased branches to your own fork.

Roles

  • Maintainer(s). These people have write permissions to the repository. They review pull requests and accept or reject them as appropriate. They also create Git tags for releases.
  • Contributor(s). These people have read (and therefore, fork) permissions to the repository. They can view and create issues and submit pull requests for review. Contributors are also responsible for resolving any merge conflicts. A contributor can only push to his or her own fork.

Setup

git clone git@github.com:chrisbelyea/pebble.git
cd pebble
git remote add upstream git@github.com:singlestone/pebble.git
origin git@github.com:chrisbelyea/pebble.git (fetch)
origin git@github.com:chrisbelyea/pebble.git (push)
upstream git@github.com:singlestone/pebble.git (fetch)
upstream git@github.com:singlestone/pebble.git (push)

The Workflow

  1. Fetch upstream changes.
  2. Merge upstream/master branch into local master branch.
  3. Create a branch.
  4. Write code and commit to your branch as you go.
  5. Fetch from upstream again (in case upstream master has had new commits since you started your branch).
  6. Rebase and squash your branch against upstream/master, resolving any merge conflicts.
  7. Push your branch.
  8. Open a pull request.
git fetch upstream
git checkout master
git merge upstream/master
git checkout -b issue-1
git fetch upstream
# Now your local `upstream/master` branch contains any new commits that are in upstream's master branch.
pick c42629e Add feature XYZ
pick 6fa213d Make an update
pick fdcc8a6 Do some more stuff
# Rebase e342e4d..fdcc8a6 onto e342e4d (3 commands)
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like “squash”, but discard this commit’s log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out
pick c42629e Add feature XYZ
squash 6fa213d Make an update
squash fdcc8a6 Do some more stuff
# Rebase e342e4d..fdcc8a6 onto e342e4d (3 commands)
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like “squash”, but discard this commit’s log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

--

--

We are a technology consulting company. Our mission-oriented approach to consulting is driven by the belief that there's a smarter way to do business and a better way to serve customers.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store