Git workflow for faster development

[avacariu]

I think this has been brought up before, but I've been thinking of creating a new workflow for this project to speed up development (since sometimes some features depend on others, and it'd be nice to have somewhere to merge them so development can continue without affecting the master branch).

My idea a somewhat simplified version of this: http://nvie.com/posts/a-successful-git-branching-model/ Since we don't really have releases, we can ignore the release branches.

So the workflow is the following (bold means mandatory naming style):

• master is the main (stable) branch that is only merged into when we want to release an update to the site
• develop is the branch where we have the current version of the site in development (should be fairly stable, but not ready for the main site)
  • Branches off master
  • Always exists
  • This should be what's on the staging version of the site
  • This should be automatically deployed so we can see features as soon as they're merged in.
• hotfix-* are branches that implement a fix for an issue on the main site
  • Branch off master
  • Merge into master and develop (PR against master is mandatory, PR against develop is optional if you contact the maintainer of that branch separately).
• feature branches implement a certain feature. Name should reflect the feature being implemented
  • Branch off develop
  • Merge into develop (create a PR)
  • Try to rebase before creating the PR (to avoid merge conflicts)
  • Don't push to this github repo before it's done (so that you can safely rebase)
  • you can use a another repo (GitHub, Bitbucket, self-hosted) for backup.
  • it usually a good idea to split large features into smaller ones to avoid having to rebase too many commits (and potentially have to fix a lot of conflicts)

For consistency’s sake (since GitHub will always create merge commits for PRs), we must use git merge --no-ff. This also helps if we want to revert the site back to a previous version.

Don't merge develop/master into your branch before creating a PR. We don't need two merge commits for one merge. If there are going to be merge conflicts, rebase (which is why you don't want to push to this repo before your feature is done), or the maintainer of the branch you're merging into can fix it on the command line. Rebasing is always preferable (you get all the benefits of a merge + cleaner commit history).

If you've already pushed, but you want to rebase, delete the remote branch, rename your local branch, and then rebase.

What this workflow requires is someone to manage the master branch, and someone to manage the develop branch; otherwise if you have multiple people pushing to the same branch, you get all kinds of conflicts.

Thoughts?

[avacariu]

I'll assume this is alright, and create a CONTRIBUTING.md file documenting it.

[anoopsarkar]

Sounds good. Go ahead.

[avacariu]

This is now in the develop branch, so I'll close this commit.