Skip to content

Instantly share code, notes, and snippets.

@twolfson
Created January 18, 2013 12:17
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save twolfson/4564232 to your computer and use it in GitHub Desktop.
Save twolfson/4564232 to your computer and use it in GitHub Desktop.
Ideal Git Workflow

Git Workflow

This is a guide for how we manage our version control.

Naming schema

General naming

For consistency between branch naming, we use /s for delimiting namespaces and .s over spaces and underscores.

Stable

master is required to be always stable and ready for production.

This is the branch that most (if not all) development branches should originate from.

Development

dev/* is the naming pattern for any development branch. The * portion should be a semantic name for the feature you are building. For example, dev/forgot.password.modal is would indicate this branch is for building out the "Forgot password modal".

You are allowed to sub-namespace your branch if you are working on a specific portion of the code base. For example, dev/css/refactor.reports indicates that this branch is for refactoring the css of reports.

Issues

bug/* is similar to Development. The * portion should be a semantic name for the issue you are fixing. For example, bug/deploy.disable.failing indicates that disabling a deployment is failing.

Additionally, you can include a ticket number in the branch. For example, bug/24/cannot.login indicates the issue is #24 and the user cannot login.

Branch resolution

Gatekeepers

Each project has at least 1 gatekeeper. Any and all commits to master must go through him/her. This provides a step for code review and guarantees a set standard for code quality.

Contributors

Contributors are developers that the Gatekeeper(s) trust to commit directly to master. They have proven that they know the coding style and properly test their code every time.

If you are uncertain if you are a contributor, ask a gatekeeper.

Pull requests

If you are neither a gatekeeper nor a contributor, you must submit your work via a pull request. If you do not follow this procedure, your commits to master will be discarded.

Notes for gatekeepers

Gatekeepers, since pull requests are submitted as merges from separate branches. It makes the most sense to use git merge over git rebase. This provides an additional commit step to indicate who made the merge onto master, which as stated must be a gatekeeper.

Attribution

  • YUI team - Good semantic names and namespacing for bugs. However, does not distinguish bugs and features as easily.
  • Git Flow - Extremely robust set of git branches. Not used due to CLI restrictions.
  • GitHub Flow - Same story as YUI.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment