Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Git Flow

No description
by

Yosi Oren

on 8 September 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Git Flow

Git Flow
branching with logic
Git Flow stages
git-flow summary
Branch feature
Branch- hotfix
Branch- release
branch release (developer)
Creating feature (developer)
Working with hotfix branch
initialization
Introduction
Branch for code in the state "production-ready". Any code gets here must be "feature complete", tested, and released.
Usually there are few commits, each new version, minor (bug fixes) or major (new features).
To initialize Git Flow inside an existing repository :
git flow init
After running this command, configuration wizard for GitFlow is displayed, where you choose the name of branch sites of production and development, prefixes feature for branch sites, hotfixes, release and support, and prefix tags.
To create a new feature branch from development run:
git flow feature start XXX
when done working on the feature this command will check development merge the feature to it and delete the feature branch:
git flow feature finish XXX
To create a hot fix branch from master run this:
git flow hotfix start XXX
when hotfix is ready after testing to deploy run this command to merge the hotfix to master and development and delete the hotfix brnach
git flow hotfix finish XXX
to Branch from development to a new release QA run this:
git flow release start XXX
After testing the functionality, and make any fixes, runs the following command to close the branch and merge code to the development and master branch and create the release tag:
git flow release finish XXX
We use branch to feature for development of new functionality or modifying of existing one , or repair of errors involving the development of existing functionality, but not production fix.
If the task is relatively small, and has Subtask, and / or related tasks, we use feature's name to the atTask id, if not you can use a descriptive name, eg login, the home page, home-slider, etc ...
We use the hotfix branch for tasks involving repair of existing functionality production errors.
Use the hotfix name's task id's. this is for critical bugs who does not contribute changed or new functionality.
We use the branch to complete the release sites and publish a new version on production. This branch is deployed and tested on pre-live server, in order to test and fix bugs with live like environment.
Convention for branch sites
Git flow uses the following branch names:
master
development
feature/XXX
hotfix/XXX
release/XXX
master
Branch for code that complete the functionality feature QA test waiting to be hardened and published on the master branch.
development
branch for develop code for new functionality. XXX is the name of functionality. upload to QA server for regular drop testing
feature/XXX
Branch for small bugs in master . XXX is the name of the bug. result tested will merge to master and development branch
hotfix/XXX
When all the features for a new version are completed, this branch hold the hardning QA process to merge to master and pushed to live servers. XXX is the name of that release.
release/XXX
Sample solution tree in Git Flow
What is Git-Flow
Git Flow is a set of over Git commands that simplify working with branch sites, unifying and simplifying the syntax for creating / closing and merging branch sites

git push origin fix78
When you push branch to remote
All git-flow branches should be pushed to remote repository. if you like to test something out you can branch from git-flow branch , and then if test are showing all well then merge to your feature or hot-fix branch.
you should never merge to development directly.
To delete a remote branch on:
git push <remote> :<remote_branch>
Ex: git push origin :feature/login
To push the remote branch:
git push <remote> <local_branch>:<remote_branch>
Ex: git push origin feature/login:feature/login
Create Feature
Deploy Test to QA server
1.Create tag feature/<feature_name>/build.<build1>> on feature/<feature_name> branch
2.Deploy the tag to QA environment (git aws.push)
Fix bugs
fix bugs opened by QA and push to QA server
QA approval
done by QA
QA create tag feature/<feature_name>/build.<build1>>.approved from tag feature/<feature_name>/build.<build>
developer do merge tag feature/<feature_name>/build.<build>.approved into develop branch (may be several tags, i.e. several features) :
git flow feature finish XXX
Create tag release/ver.<major.minor.build2> from develop branchDeploy tag to Pre-Live environment
Fix the bugs opened by QA and push to release branchWhen the bugs are fixed, create tag release/ver.<major.minor.build>Deploy tagged version to Pre-Live environment
QA release approval
QA create tag release/ver.<major.minor.build>.approved on release branch from tag release/ver.<major.minor.build>
done by QA
Deploy to Live
done by developer
execute
git flow release finish XXX
This will :
Merge tag release/ver.<major.minor.build>.approved from release branch into master branch
Merge tag release/ver.<major.minor.build>.approved from release branch into develop branchDelete release branch
deploy from MASTER with label approved to pre-live
Run Go-Live to deploy pre-live to live
to download :
https://github.com/nvie/gitflow
More Reading
http://nvie.com/posts/a-successful-git-branching-model/
Thank you
<build> – build number, should be incremented on each creation (except buid.approved).
<major.minor.build>:
Major – current major version, defined by Product Owner on significant new version
Minor – current minor version, incremented on every new release to live
Build – current build version, incremented on every new build
Full transcript