Git Workflow - andela/asgard-rc GitHub Wiki

Overview

This work flow is not written in stone, we will have to do some things based on our discretion and the situation we find ourselves in.

  • These are some rough notes on a Git workflow that uses rebasing instead of merging for feature branches.

Git Visualization

  • Check out Git D3 Visualization - it is a great interactive tool to visualize exactly what git commands are doing.

A Rebase-Based Git Branching Model

This is a very simple git workflow. It (and variants) is in use by many people. It has been used effectively on many teams. GitHub does something similar; Zach Holman mentioned it in this talk.

The gist

  1. master or develop must always be deployable.
  2. all changes are made through feature branches
  3. rebase continually (before beginning work on a feature branch, after pushing to a feature branch) to avoid/resolve conflicts;
  4. merge feature branches back in to master or develop with --no-ff flag.

The workflow

IMPORTANT PREREQUISITES:

  • With this workflow, only ONE PERSON OR PAIR should work on a feature branch at a time.
  • After a rebase onto a feature branch, you will be required to force push to that branch. This is OK because only one person at a time is working on it.
# everything is happy and up-to-date in master / develop
git status # make sure your working directory is clean

# discarding all changes you don't want
# If you want to discard all changes in your working directory and start over:
git reset --hard
git clean -df

# checkout develop branch
git checkout develop
git pull origin develop

Branching and commiting

# let's branch to make changes (omit the -b if the branch already exists)
git checkout -b my-new-feature 

# make any more required changes...

# commit your (incremental, atomic) changes
git add -p
git commit -m "my changes"

# push your changes to the feature branch
git push origin my-new-feature

# keep abreast of other changes to master.
# rebasing keeps our code working, merging easy, and history clean.
# Do this often - at the beginning of every day, and after every
# push to the feature branch
git fetch origin
git rebase origin/develop
# IMPORTANT NOTE: If you have conflicts, always use '--continue', never '--skip'.
#                 See "DOs" and "DON'Ts" below.  If you are confused, ask for help

# push your branch to github after every commit
git push --force origin my-new-feature

important note: Note the "force" above in the push. This is necessary after a rebase, because the SHAs of the commits change. However, if you are the ONLY person/pair working on the feature branch (and you should be!), then it is fine to force push, because nobody else should have changed it.

Fixing a Commit Before You Push

  • Firstly, check for the status
  • git status
  • If there was a staged commit and changes was made to the directory, you can roll back the commit with
  • git reset HEAD^
  • Check to confirm all the changes you have made to the current project
  • git diff
  • Add the changes you intend to commit
  • git add -p
  • Do the commit and add your message
  • git commit -m "message"
  • Do the push
  • git push

DOs and DON'Ts

No DO or DON'T is sacred. You'll obviously run into exceptions, and develop your own way of doing things. However, these are guidelines I've found useful.

DOs

  • DO keep develop in working order.
  • DO rebase your feature branches.
    • DO pull in (rebase on top of) changes
  • DO push feature branches for discussion
  • DO learn to rebase
    • When rebasing in changes and resolving conflicts, always use '--continue' - never skip conflicts.

DON'Ts

  • DON'T EVER force push develop! This includes push +develop
  • DON'T rebase the remote develop (Note that doing pull --rebase prior to a push doesn't count at as "remote").
  • DON'T merge in broken code.
  • DON'T merge with conflicts. handle conflicts upon rebasing.
    • When rebasing, you should NEVER commit a merge conflict! If you end up with a merge conflict, you did something wrong, and should abort and start over.

Links