Skip to content

Instantly share code, notes, and snippets.

@jtulk
Created December 21, 2016 05:50
Show Gist options
  • Select an option

  • Save jtulk/89004ac8c4c19c8ff461a4b7f6b9789a to your computer and use it in GitHub Desktop.

Select an option

Save jtulk/89004ac8c4c19c8ff461a4b7f6b9789a to your computer and use it in GitHub Desktop.
A markdown styled explanation of basic GitFlow tasks for inclusion in a project's README.md

Git Strategy

We currently use Gitflow. Any features to the repository should be started as branches coming off the Development branch and be prefixed with feature/ (or an appropriate semantic prefix for commits that don't technically constitute a true 'feature', e.g. 'refactor/[refactor-description]' etc...). Any patches for production should be applied directly to Master AND Development and be prefixed with hotfix/. All branches should be associated with a pull request for merging back into Development or Master branches. For non-trivial commits (or in general), having someone else approve your pull request is preferred.

Workflow for new feature branch

  • Start on Development branch (git checkout development)
  • Pull recent changes (git pull)
  • Create new branch (git checkout -b feature/[feature-name])
  • Add changes (git status to see changes, git add . to add all changes)
  • Commit changes (git commit -m 'commit message')
  • [Rebase if necessary: see note below]
  • Push to Github (git push origin feature/[feature-name])

Once the local feature branch is pushed up to Github, initate a pull request to have it included into the main Development branch. As a general rule, you should not accept your own pull request.

Rebasing in a feature branch

Should other contributors commit changes to development while a feature branch is under development, a Rebase is required for a clean project merge. For a description of rebasing please see the docs. For a description of rebasing vs. plain old merging see this blog post. In short, rebasing ensures that your changes are applied on top of changes merged into development by other feature branches completed since the feature branch in question was split off. It isolates conflict resolution to the feature branches and keeps merge conflict resolution commits from polluting the primary development branch history.

To do a rebase, after your last commit into feature/[feature-description] please follow the following process:

  • checkout development git checkout development
  • refresh development branch to latest git pull
  • re-checkout feature branch git checkout feature/[feature-description]
  • apply rebase git rebase development NOTE - rebase must happen from WITHIN your feature branch
  • resolve any merge conflicts appropriately
  • push rebased feature branch to remote (see above)

Workflow for hotfix applied directly to Master

  • Start on Master branch (git checkout master)
  • Force pull Master (git pull -f)
  • Create new hotfix branch (git checkout -b hotfix/[hotfix-name])
  • Add changes (git status to see changes, git add . to add all changes)
  • Commit changes (git commit -m 'commit message')
  • Push to Github (git push origin hotfix/[hotfix-name])

Once the local hotfix branch is pushed up to Github, initate a pull request to have it included into the main Master branch. As a general rule, you should not accept your own pull request. Once approved, merge hotfix/[hotfix-name] into Development as well as Master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment