Skip to content

Instantly share code, notes, and snippets.

@earlonrails

earlonrails/feature-flow.md

Last active August 31, 2018 07:56
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save earlonrails/24fab0351fd53affaa95 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save earlonrails/24fab0351fd53affaa95 to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. earlonrails revised this gist Oct 27, 2014. 1 changed file with 2 additions and 0 deletions.
    2 changes: 2 additions & 0 deletions feature-flow.md
    View file
    Original file line number Diff line number Diff line change
    @@ -35,6 +35,8 @@ To reduce the amount of labor invovled in pruning out commits and creating the r

    [https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow](https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow)

    ![](https://www.atlassian.com/git/images/tutorials/collaborating/comparing-workflows/feature-branch-workflow/01.svg)

    Feature workflow branches from master. Master is our known good source of code. This is to say that Master is the place where we assume that the code is bug free in master. This makes it the ideal canidate to branch from. Feature workflow looks like this:

    git pull origin master
  2. earlonrails created this gist Oct 27, 2014.
    115 changes: 115 additions & 0 deletions feature-flow.md
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,115 @@
    #Feature/Flow


    ##Git Flow

    Here is some good reading on gitflow for the basic concepts:

    [http://nvie.com/posts/a-successful-git-branching-model/](http://nvie.com/posts/a-successful-git-branching-model/)

    [https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow)

    [http://datasift.github.io/gitflow/](http://datasift.github.io/gitflow/)


    ![git flow](http://nvie.com/img/[email protected])

    Git flow works great when the team is working together on a package of features. You branch from develop and merge your features into develop when the features are complete.
    Here is an example:

    git pull origin develop
    git checkout -b feature_a
    # create feature a
    git push origin feature_a
    # create pull request on github
    # merge happens as below
    git checkout develop
    git pull
    git merge feature_a

    At the end of your sprint develop will have many features which have been integrated together in the develop branch. QA will be testing these features throughout the sprint in the develop integration branch. Once the branch passes QA develop can be branched from into a release branch. In this phase to have a clean release it will be necessary to pick only the commits which have passed QA to go into the release branch. This is usually done by cherry-picking only the commmits that are linked to Jira tickets which have been marked complete. This approach takes time and requires developers to tag their commits with the Jira ticket number to be most effective. Occasionally a commit could be over looked and the whole feature might not be in the release.

    To reduce the amount of labor invovled in pruning out commits and creating the release branch, we can use a combination of the feature workflow and gitflow.

    ##Feature Workflow

    [https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow](https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow)

    Feature workflow branches from master. Master is our known good source of code. This is to say that Master is the place where we assume that the code is bug free in master. This makes it the ideal canidate to branch from. Feature workflow looks like this:

    git pull origin master
    git checkout -b feature_a
    # create feature_a
    git push origin feature_a
    # create pull request on github
    # merge happens as below
    git checkout master
    git pull
    git merge feature_a

    The problem with feature workflow is that all the integration takes place in the master branch. This is not acceptable from a QA or devops perspective. The features have not been proven to work together.

    The answer is a hybrid between these two workflows.

    ##Feature/Flow
    Feature flow is the same as gitflow with the exception that you branch your features from master. The main idea we are taking from feature workflow is the portablity of the code. All the code for a feature is contained within the branch. I will work on my new feature branched from master, then when I am finished I will merge this feature branch to develop for QA. **I will not delete this feature branch!** QA will begin and if a bug is found, I will return to this feature branch to fix the bug. This makes the feature continue to be self contained. Once the feature is complete and QA is finished the feature can be moved to any other branch for further integration testing or staging for example:

    ###Creating a feature

    git pull origin master
    git checkout -b feature_a
    # create feature_a
    git push origin feature_a
    # create pull request on github
    # merge happens as below
    git checkout develop
    git pull
    git merge feature_a
    # a bug is discovered
    git checkout feature_a
    # fix bug
    # push and merge again
    git push origin feature_a
    # create pull request on github
    # merge happens as below
    git checkout develop
    git pull
    git merge feature_a


    ###Creating a release branch
    Creating the release branch is the same as creating a feature branch. We will start from our "known good source", master.
    Then we will look at our feature branches that have pasted QA. We will merge the into our release branch and that will be on staging for regression testing and further QA. When this release is ready it can be merged into master the same as with git flow. Example:

    git pull origin master
    git checkout -b release_a
    # merge features which pasted QA, this can be done by having developers make PRs on github or by the person creating the
    # release branch just finding the branches linked to the jira tickets
    git merge feature_a
    git merge feature_b
    ...
    git push origin release_a
    # regression/QA on staging

    ###Hotfixes
    Hotfixes are the same as feature branches.


    ##Tools
    Make gitflow and feature/flow easier.

    [http://datasift.github.io/gitflow/TheHubFlowTools.html](http://datasift.github.io/gitflow/TheHubFlowTools.html)

    I suggest to specify branching from master when creating the branch and to **not use** the `git hf feature finish` command.
    `git hf feature finish` deletes the branch after it has been merged to another branch ie master or develop. This step doesn't work with feature/flow because we will lose our self contained feature branch.
    Example:

    git hf update
    git hf feature start feature_a master
    # create feature_a
    git hf push origin feature_a
    # PR request on github
    ...