git_flow

### Basics (3 main branches + Releases)
1. Master Branch
    - This is the cleanest code that is ready to deploy at any time.
    - Commits are tagged with version numbers.
    - It lives forever.
2. Development Branch
    - No development will happen here, only merges from Feature branches and Release branches.
    - It is never merged into any other branch.
    - Nobody will commit to this branch.  Depending on the project's structure and team culture, selected individuals will merge pull requests into the Development branch.
    - It never dies.
3. Feature Branches
    - Feature branches will be the place most work is done.
    - Feature branches could be for specific tasks or tickets, a bug fix, or development of new functionality.  
    - The specifics of how Feature branches are named and behave will vary according to team structure and culture.
    - When a feature branch has been merged into development it should be removed from Github.  Keep your local copy.
4. Release Branches
    - Release branches are split off from the Development branch.
    - No features should be developed here.
    - Bug fixes and adjustments for deployment environments can happen here.
    - When the release is ready it will be merged into master and tagged with a version.  It will also be merged back into the Development branch at the same time.
    - After a Release branch is merged into Master and Development we will no longer commit to it.
    
![](https://www.atlassian.com/fr/git/workflows/pageSections/00/contentFullWidth/0/tabs/02/pageSections/010/contentFullWidth/0/content_files/file/git-workflow-release-cycle-4maintenance.png)

### Developer Workflow
1. Git fetch all of the latest work from Github.
2. Create a Feature branch for the work you'll do.
3. Rebase your Feature with the latest work from development. Repeat this step at the beginning of every work session.
4. Check that all tests are passing. If there are failures communicate with the test writer and the last committer.
5. If possible write a test for the feature or bug fix you are addressing.
6. Work. Type. Work.
7. If you haven't written a test, and the code is testable, write tests now.
8. Make sure that all tests are passing.
9. Push your feature branch to Github and create a pull request. 
10. Communicate your pull request as appropriate.

### Keep in Mind
* Developers will always create and work in feature branches.
* Branch your feature off of the development branch.
* Once work is completed in a feature branch, make a pull request on Github.
* Before submitting pull request, feature branch should be rebased from development.
* Pull Requests will be from your feature branch to the development branch.
* Notify the chat room  about your pull request.
* Name your feature branch after a (pivotal | Jira | whatever) issue if possible, e.g. TAP-119.
* Start your commit message with the Jira issue designation, e.g. `git commit -m "TAP-119 Fix broken navigation links on home page."`
* Send pull requests early and often. Try not to build up a bunch of commits, as this leads to merge conflicts.