Sourabhh Sethii's Blog

Angular Elements Build the twelve factor Application w...

Git — Git Flow a efficient and productive way of version control

Git flow is a branching model for Git, well suited for scaling a development team. One can go-though GitHub flow pattern as well. let’s get started with gitflow.

Main Branches

Master branch contains the latest production code that has been deployed, and versioned with appropriate tags for each release.

Develop (develope) branch that gets branched off master and contains the latest code for the next feature that is being developed. For each new feature there might be lots of feature branches (always branched off the “develop” branch).
Beside the main branches, there are supporting branches also.

Supporting Branches

Feature branches contain the development state for a single feature of the overall product (i.e. a user story). They are merged off the develop branch.

we will merge feature back to develop when we definitely want to add the new feature to the upcoming release, if the feature is unstable or incomplete do not merge feature in to develop branch.we will delete feature branches when they are finished.

Release branch is a branch for preparing the next release. No new features will be developed on this branch but rather it contains some last fixes (also bugfixes) and adjustments for going into production.

we should merged release branch into master.we should delete release branch after merging.

Hotfix branches are branches for quick and severe bugfixes. they are usually branched off the master branch, fixed in the hotfix branch and then merged back in master and develop as well.

Do bug fixing in hotfix branch, bug fixes may be continuously merged back into the develop branch to origin/master.If release branch exists then, we should merge the hotfix to release branch, first.Production branch

let’s see production oriented branching strategy

master branch which contains the actual development code (corresponds to the “develop” branch in the git-flow model)

production branch contains the deployed code.

Decentralized but centralized

Each developer pulls and pushes to origin but besides the centralized push-pull relationships, each developer may also pull changes from other peers to form sub teams. For example, this might be useful to work together with two or more developers on a big new feature, before pushing the work in progress to origin. There are subteams of Sourabh and Rohit, Sourabh and Gaurav, and Maria and Gaurav. Technically, this means nothing more than that Sourabh has defined a Git remote, named Rohit, pointing to Rohit’s repository, and vice versa.

Let’s start with creating new repository with a master branch and no commits by default. We would create new readme.md file, add it to a repo, and commit it. We would also add a remote origin from GitHub and push our initial commit upstream.

git init

init

git config — global user.email “sourabhhsethii@linux.com”
git config — global user.name “Sourabh Sethi”

ADD README to Repository and Commit

D:\Repo\github\README>type nul > README.MD

git add README
git commit -m “Initial commit”

git commit -m “Initial commit”

We would add a remote origin from GitHub and push our initial commit upstream.

git remote add origin https://github.com/Sourabhsethi/gitfl...

git push -u origin master

push to masterCreate the Develope branch

Now we will create the develope branch always contains completed features and fixes. Therefore, it is considered the working tree for our source repository.

git checkout -b develope

create develope branch

git push -u origin develope

push develope branch

develpe branchCreated the feature branch — feature/gitflowdemo

Now all new development is built within a feature branch. Feature branches are always branched off of the develope branch and prefixed with a feature slash. All work within this feature is now completed within the feature/gitflowdemo branch.

git checkout -b feature/gitflowdemo develope

git push -u origin feature/gitflowdemo

Lets add feature.js in feature/gitflowdemo branch

type nul > feature.js

git add feature.js

git commit -m “New feature file added to feature branch”

Created the another feature branch-feature/gitflowdemoUI

Let’s create another feature, this time named feature/gitflowdemoUI. Keeping feature branches separate keeps all commits related to a specific task or feature isolated. When you’re complete with your feature, it is merged back into the develop branch. This is usually accomplished with a pull request so it can pass through a proper code review by another peer, but for now, we will just merge this feature back into the develop manually. It is a good idea to do a Git pull on the develop branch often to refresh your local working tree from the remote origin.

git checkout -b feature/gitflowdemoUI develope

git push -u origin feature/gitflowdemoUI

Lets add featureUI.js in feature/gitflowdemoUI branch

type nul > featureUI.js

git add featureUI.js

git commit -m “New featureUI.js file added to feature/gitflowdemoUI branch”

You will want to rebase your branch from develop if you believe updates from a remote origin could potentially cause conflicts with your changes or if you just wanted to pull down the latest updates from develop.

If you check the log of the feature/gitflowdemoUI branch, you will see that this branch has just the new featureUI.js file. Let’s rebase from develop. This will rewind your feature/gitflowdemo branch, apply the updates from develop, and then replay your commits on top of the last commit. We can verify this by checking the logs again and see that the new feature.js file has been placed before our new featureUI.js file commit.

Let’s go ahead and merge our feature/gitflowdemoUI branch into develop and then push it upstream. It looks like our code is now ready for release, so we will create a new release branch.

merge feature branches to develope

git merge feature/gitflowdemoUI

Every release branch contains the release version, in this case, 1.0 Since the release is in its own branch, we don’t have to worry about updates from develop conflicting with a specific release. We can now push this upstream and deploy the code to a staging environment for testing.

Merge feature branches to develope

git checkout -b release/1.0 develope

git push -u release/1.0

release/1.0

We’ll push the release repository upstream and repeat the process until our release branch has passed into a testing phase on staging and is ready to be released to production. When the updates to this release will complete, the release branch is merged back into develop as we want to make sure any updates or bug fixes that were applied in our release testing are merged back into the working tree.

Merge release to origin/master and Tag the release

Since the code in the release branch is fully tested and ready to be released to production, we also want to merge it into our master branch which should only ever contain production ready code. Then we tag the release. We can then push the tag upstream and then use that tag to deploy our code to production.

merge release branch into master and tag it after production release

git checkout master

git merge release/1.0

git tag v1.0.0

git push origin v1.0.0

git push origin v1.0.0

Hot fixes branches

Hot fixes are intended only for emergency fixes and follow a similar format to feature branches, prefixed with a hot fix slash. we would create hotfix branch from master. We then merge the hot fix back in the master. Then tag and push our new release. We also want the hot fix to be applied back into our develop branch so it’s not lost with the future updates.

The master branch tracks released code only. The only commits to master are merges from release branches and hotfix branches.

git checkout -b hotfix/fix master

git checkout master

git merge hotfix/fix

git tag v1.0.1

git push origin v1.0.1

TAG v1.0.1

When releases are complete, it’s usually good practice to delete all previously merged in branches. If we’re following a pull request model, you can remove these at the time of the merger pull request acceptance. Otherwise, you can just manually remove these branches locally and remotely.