a simplified gitflow

Post on 13-Jul-2015

1.051 Views

Category:

Technology

0 Downloads

Preview:

Click to see full reader

TRANSCRIPT

Simplified GitFlow

Branch it, tag it, release it, merge it

Geshan ManandharQuality and Maintenance Lead, Namshi.com

@geshan

geshan.com.np

IndexPrerequisitesStart a feature or bug fix on a new branchWork done, lets pushPushed the code? Let's open a merge/pull requestTeam Lead reviews codeAfter review is ok, code is deployed to staging then liveHow to name tagsMerge the tag to master when all tests are fineThings to considerConclusion

PrerequisitesYou are aware of what git is, what it does and its benefitsYou know about basic git commands like add, commit, branch etcMaster is the stable branch which can be deployed anytimeYou have already watched the video.git happens

Start a feature or bug fix on anew branch

Always follow a naming convention when create new branchLike: OP-21 (where OP is short for OpenData and 21 is the ticketid from redmine/trello)Always get the latest master branch before you start any issueBy typing: git checkout master && git fetch && git pull --rebase origin masterThen get a branch out of the latest masterThe command will be: git checkout -b OP-21Now you can start working onf OP-21 - add blog content type

Work done, lets pushSo you finished working on OP-21Then you do the following to commit the changes:git add .git add -u - if files have been deletedgit commit - then write a commit messageKeep in mind commit messages need to be meaningfulYou can do multiple logical commits.git push origin OP-21

Pushed the code? Let's open amerge/pull request

It is recommended that you your commits to single onesquashTo a merge request, always get latest master then rebase yourbranchBe in your branch git checkout OP-21, then execute: git rebasemaster.As you just rebased with master, you may need to force push : gitpush -f origin OP-21Browse to gitlab open a merge requestPut the issue in right status/column on redmine/trello and put themerge request link in the comment.

Team Lead reviews codeTeam/Project Lead should always check and review code for eachpull/merge requestCode review is done to ensure coding standards, coding and namingconventions.It is also done to ensure code is maintainable on the long run.If there are comments, it needs to be addressed by the softwareengineer by re-working.If the code matches standards, does the work and tests are passing itcan be deployed.

After review is ok, code isdeployed to staging then liveFirst deployed to StagingFor staging, its ok to deploy the branch with a deployment process.If all tests are fine, then code is deployed to live.For live/productions, always create a tag and deploy the tagGiven you are on OP-21 branch, execute git tag 1.11.2Then push the tag: git push origin 1.11.2 and deploy it live

How to name the tagsTags are basically pointers to a particular commitNaming depends on the version conventions.1.11.2-p0 can mean 1st Year of operation, month of November,date is 2 - p0 for second release of the day1.44.3 can mean 1st Year of operation, week no. 44 and release no3, if you follow weekly sprints.If you use tags for staging you could suffix it with rc-1, rc forrelease candidate

Merge the tag to master whenlive is stable

After testing and monitoring the live deployment, tag can bemerged to masterTo merge the tag to master, get the latest masterThen run: git merge --no-ff 1.11.2 know why --no-ffAll the changes that were deployed are in master right nowThen you can deploy another branch after tagging it.Next tag for the same day will be 1.11.2-p0Here p0 means patch 0 or 2nd deployment of the day.

Things to considerNever force push on masterYou can force push on your branch provided others have notbranched out from your branch.If tickets/issues are related, you can branch out from a differentbranch than masterIf you branched out of OP-10, you can send a merge/pull request toOP-10 as well.Always align your branch from your source branch which isgenerally master.Hot-fix branches have not been covered.

Conclusion/RecapGit flow is easier than it looks, with single ticket deployments.Git flow encourages rigorous code reviews.It helps to follow a standard procedure.Rollbacks are easier as you know the last deployed live tag.

Questions???

Creditshttp://hades.name/blog/2010/01/22/git-your-friend-not-foe-vol-2-branches/https://www.flickr.com/photos/oberazzi/318947873/

Some programming mantras to remember.

top related