{"id":1985,"date":"2011-04-27T16:31:09","date_gmt":"2011-04-27T19:31:09","guid":{"rendered":"http:\/\/blog.plataformatec.com.br\/?p=1985"},"modified":"2016-09-28T10:31:14","modified_gmt":"2016-09-28T13:31:14","slug":"a-successful-git-branching-model","status":"publish","type":"post","link":"https:\/\/blog.plataformatec.com.br\/2011\/04\/a-successful-git-branching-model\/","title":{"rendered":"A (successful) git branching model"},"content":{"rendered":"<p><em>*This blog post tells about how we improved a VCS workflow to another one that suited our and the consumer needs. It was a great result: we minimized the chances of occurring one of the worst problems for a developer in a project: big integration while we maintained an &#8216;almost releasable branch&#8217; all the time<\/em><\/p>\n<p>In the last months we&#8217;ve been working on a project with a mixed development team (Plataformatec&#8217;s team and the customer&#8217;s team). We, of course, used a version control system (specifically git) and we set up a nice git branching model for our team. As agilists, we know that we should not use anything that requires a lot of bureaucracy (things like opening a ticket to integrate a branch into the trunk).<\/p>\n<p>Using <a href=\"http:\/\/nvie.com\/posts\/a-successful-git-branching-model\/\">nvie guide<\/a> as base, we developed a git workflow. First of all, we had three main branches:<\/p>\n<ul>\n<li><strong>production<\/strong>: contains the code that is currently on production. We also have a production server that contains, obviously, the production code up and running.<\/li>\n<li><strong>staging<\/strong>: contains the code that is being tested before going to production (we used this branch to deploy to a production-like environment that worked as a final test until production, this environment is also called staging)<\/li>\n<li><strong>master<\/strong>: contains the already accepted features. To consider a feature as &#8220;accepted&#8221; we deployed to another environment (called &#8220;dev&#8221;) and asked a QA analyst to test it. Once approved we merged the commits. This &#8220;dev&#8221; environment is used for this kind of approval and also for general purposes like when we say: &#8220;take a look at this new awesome feature we&#8217;re developing&#8221;.<\/li>\n<\/ul>\n<p>For each feature that we developed, we created a git branch (almost all of them we pushed it to the remote server to facilitate code review and to deploy to the &#8220;dev&#8221; environment). Everyday, we ran <code>git rebase master<\/code>, to update our branch code (except for features developed by more than one developer). Once the feature is complete, we rebased master into it, and merge it using &#8211;no-ff (to create a merge commit). For the branches that more than one developer worked on, we usually talked and set up a &#8220;rebase period&#8221; where one does the rebase, forces the push (because you changed your local tree so git does not accept it as a non forced push) and updates the remote branch.<\/p>\n<p>Close to the production deploy, we merged (always using &#8211;no-ff) master branch into staging branch and deploy to staging. Once approved, we merged to production, and created a tag telling the current version of the application and then we do the deploy. When we deployed to production we also removed the merged branches from the remote repository.<\/p>\n<p>One of the great advantages of this schema is: Master is always &#8220;almost&#8221; ready for a release. Yeah, some features really deserves to be validated right before the deploy, because another feature can break them, but we kept the master as an &#8220;always releasable stable&#8221; branch (and also we used a continuous integration tool in order to enforce all tests passing). Another great advantage is: as we updated our code everyday, it was very\u00a0unusual\u00a0for us to face big integration scenarios.<\/p>\n<p>For the &#8220;dev&#8221; environment deploy we also set up a capistrano task that asks which branch we want to deploy to be possible to deploy something from any branch.<\/p>\n<p>This workflow has worked really well for us and maybe it is useful to you (maybe for you to adapt it to something that works better for you as we did with the workflow suggested on <a href=\"http:\/\/nvie.com\/posts\/a-successful-git-branching-model\/\">nvie<\/a>).<\/p>\n<p>To summarize, this is our git workflow in commands (supposing that we are on master branch):<br \/>\n<code><br \/>\ngit checkout -b my-awesome-feature<\/p>\n<h1>(... you do some code and some commits and you go home to have some sleep or maybe play some starcraft 2 ...)<\/code><\/h1>\n<p><code>#(arrived at the office on the next day)<br \/>\ngit rebase master<\/code><\/p>\n<p><code>#(... continue working and commiting and sleeping (or maybe playing some starcraft 2 ...)<br \/>\ngit rebase master<\/code><\/p>\n<p><code># (... some commits ... and voila ... you've finished...)<br \/>\ngit push origin my-awesome-feature<br \/>\ncap dev deploy<br \/>\n<\/code><\/p>\n<p><code># (...YAY!  QA analyst just approved it ...)<br \/>\ngit pull origin master<br \/>\ngit rebase master<br \/>\n<\/code><\/p>\n<p><code># (run the tests to ensure all of them pass)<br \/>\ngit checkout master<br \/>\ngit pull --rebase origin master<br \/>\ngit merge --no-ff my-awesome-branch<br \/>\ngit push origin master<\/code><\/p>\n<p><code>#(... it is time to validate on staging)<br \/>\ngit checkout staging<br \/>\ngit pull origin staging<br \/>\ngit merge --no-ff master<br \/>\ngit push origin staging<br \/>\ncap staging deploy<\/code><\/p>\n<p><code>#(... QA analysts validate the staging ...)<br \/>\ngit checkout production<br \/>\ngit merge --no-ff staging<br \/>\ngit tag -a v1.4.2 -m \"Releasing on 13th February\"<br \/>\ngit push origin production<br \/>\ngit push --tags origin production<br \/>\ncap production deploy<br \/>\n<\/code><\/p>\n<p>Well, this is how we improved a git workflow based in another one. As almost everything, there is no bullet proof for it, but we found interesting to share this experience with you as it was a success (every developer on the team enjoyed it). But please, we would like to receive some feedback about it :-). Have you used something similar in your team? Do you have any ideas on how we can improve it?<\/p>\n","protected":false},"excerpt":{"rendered":"<p>*This blog post tells about how we improved a VCS workflow to another one that suited our and the consumer needs. It was a great result: we minimized the chances of occurring one of the worst problems for a developer in a project: big integration while we maintained an &#8216;almost releasable branch&#8217; all the time &#8230; <a class=\"read-more-link\" href=\"https:\/\/blog.plataformatec.com.br\/2011\/04\/a-successful-git-branching-model\/\">\u00bb<\/a><\/p>\n","protected":false},"author":12,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[1],"tags":[147,149,148],"aioseo_notices":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/1985"}],"collection":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/users\/12"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/comments?post=1985"}],"version-history":[{"count":36,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/1985\/revisions"}],"predecessor-version":[{"id":5706,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/1985\/revisions\/5706"}],"wp:attachment":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/media?parent=1985"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/categories?post=1985"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/tags?post=1985"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}