Skip to content

Instantly share code, notes, and snippets.

@earlonrails
Last active August 31, 2018 07:56
Show Gist options
  • Save earlonrails/24fab0351fd53affaa95 to your computer and use it in GitHub Desktop.
Save earlonrails/24fab0351fd53affaa95 to your computer and use it in GitHub Desktop.
gitflow + feature workflow together at last! Git workflow

#Feature/Flow

##Git Flow

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

http://nvie.com/posts/a-successful-git-branching-model/

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

http://datasift.github.io/gitflow/

git flow

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

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

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
...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment