tag:blogger.com,1999:blog-8221886912876606828.post2647835167233628215..comments2023-06-23T00:44:05.938-07:00Comments on Elided Branches: Branching Is Easy. So? Git-flow Is Not Agile.Camille Fournierhttp://www.blogger.com/profile/05090020862261633248noreply@blogger.comBlogger25125tag:blogger.com,1999:blog-8221886912876606828.post-50622115420102492592016-11-09T07:06:38.915-08:002016-11-09T07:06:38.915-08:00The way we work has a direct impact on our ability...The way we work has a direct impact on our ability to change, and some ways of working make change easier than others.Camille Fournierhttps://www.blogger.com/profile/05090020862261633248noreply@blogger.comtag:blogger.com,1999:blog-8221886912876606828.post-75095464214952200222016-11-08T11:08:01.847-08:002016-11-08T11:08:01.847-08:00This is nonsense. Branching strategies are neither...This is nonsense. Branching strategies are neither agile nor non agile. Agility has to do with ability to change, not how one branches ones code.Unknownhttps://www.blogger.com/profile/00035792430883584893noreply@blogger.comtag:blogger.com,1999:blog-8221886912876606828.post-63179410438890523262016-07-12T13:24:57.874-07:002016-07-12T13:24:57.874-07:00Hi. I agree with you that GitFlow is not natural. ...Hi. I agree with you that GitFlow is not natural. Could you make a blog of another branching strategy? I was thinking that it would be more natural to use master branch be the (dev branch) and instead have productions branches. That way you avoid the noobs that checkout and pushes directly to the master branch.Unknownhttps://www.blogger.com/profile/11413200282177259936noreply@blogger.comtag:blogger.com,1999:blog-8221886912876606828.post-42841159699034071162016-06-27T05:49:48.824-07:002016-06-27T05:49:48.824-07:00I see that you think feature branching is a must b...I see that you think feature branching is a must but I have not seen that to be the case and your argument does not seem to even address that conclusion let alone support it.Camille Fournierhttps://www.blogger.com/profile/05090020862261633248noreply@blogger.comtag:blogger.com,1999:blog-8221886912876606828.post-70653816609272421242016-06-26T23:12:26.109-07:002016-06-26T23:12:26.109-07:00Each time you release, you should be creating a re...Each time you release, you should be creating a release branch - i.e. release/v6.2.x. You would patch that branch as you are releasing, and once the final release is ready to go LIVE (i.e. 6.2.45), you tag the repo with that release number (git tag v6.2.45), then merge the release branch into master, and DELETE the release branch.<br /><br />You can then use that tag to check out the production code at any point for hotfixes (i.e. git checkout -b hotfix/v6.2.46 remotes/origin/tags/v6.2.47) and promote that hotfix as necessary.<br /><br />Each disparate version you are hosting in a live environment would need its own hotfix - you'd just check out the relevant tag and do the fix. If you're lucky, a single hotfix may be possible for different versions - in that case, you could fix in one hotfix branch, then cherry-pick the commit into the other hotfix branches for testing.<br /><br />I assume by downporting you mean downgrade? The best way to achieve this - unless you are /very/ careful in your release and feature orchestrations - is to check out the tag, then revert the changes. You could revert / reset commits, or manually make the changes and make an additional commit. Either way, I would recommend increasing the version.<br /><br />If you want to downgrade to a previous version, a third way would be to simply check out the old tag in a release branch, then push the release branch to your CI / CD server.Chris "Spikeh" Sebokhttps://www.blogger.com/profile/06403874631055393888noreply@blogger.comtag:blogger.com,1999:blog-8221886912876606828.post-47884466604101405592016-06-26T23:04:15.180-07:002016-06-26T23:04:15.180-07:00Generally, you wouldn't update your feature br...Generally, you wouldn't update your feature branch from master. You'd merge it into master once complete - then sort any problems out. Alternatively you /can/ rebase your feature branch on master before you do the merge - which is more sensible (as long as your feature branch isn't shared - in that case, you would just merge master into your feature branch and put up with the potential additional commit). You wouldn't "keep in sync" until you needed to work on it again - and even then, it's not completely necessary - depending on what you're working on.<br /><br />Of course, ideally you don't want to be pulled off a feature, but business needs are usually the driver - depending on the type of company you work for.<br /><br />Regardless of the amount of time you're working on a feature branch, feature branching is a must. You could spend an hour working on a bug fix, only for another urgent bug fix to come in that needs to be added to the next release immediately. Mind, that kind of work is usually done on release branches, or as a hotfix taken from your release tag.Chris "Spikeh" Sebokhttps://www.blogger.com/profile/06403874631055393888noreply@blogger.comtag:blogger.com,1999:blog-8221886912876606828.post-87969073249356335432016-06-26T14:52:41.622-07:002016-06-26T14:52:41.622-07:00So, when you get pulled off in week 2 to work on s...So, when you get pulled off in week 2 to work on something else, what happens to that feature branch? Are you continuing to update it with changes from master? Are you keeping it in sync so that when you finally get back to it, you can pick up where you left off?<br />I just don't think that an environment where you have a lot of small changes works well simultaneously with people going off on feature branches for multiple weeks. If you're getting pulled off the feature after 2 weeks, it is better to have the code written in master so that it is being kept up to date for when you return. If the code base is slow-moving or has fewer developers overlapping their work, feature branches can work fine (aka, the OSS process that I explicitly mentioned in the post). But for most product development teams, this is not the case.<br />Hopefully, getting pulled off of a 3 week project 2 weeks in is a very rare occurrence. If not, you've got bigger problems than the way git is being used!Camille Fournierhttps://www.blogger.com/profile/05090020862261633248noreply@blogger.comtag:blogger.com,1999:blog-8221886912876606828.post-5878750908486282912016-06-26T14:37:47.633-07:002016-06-26T14:37:47.633-07:00Ok, we switched to agile and CI. But how do you su...Ok, we switched to agile and CI. But how do you support several prod releases of a framework which are in turn being used by different development projects and even older releases used by apps already in production? How do you promote hot fixes to some, but not all? And how do you downport new features to those releases? Does CI cater for this?Thomas W.https://www.blogger.com/profile/02030644649567013785noreply@blogger.comtag:blogger.com,1999:blog-8221886912876606828.post-71899969981392243402016-06-20T02:25:38.544-07:002016-06-20T02:25:38.544-07:00This comment has been removed by the author.Chris "Spikeh" Sebokhttps://www.blogger.com/profile/06403874631055393888noreply@blogger.comtag:blogger.com,1999:blog-8221886912876606828.post-60151545819718735832016-06-20T02:23:26.609-07:002016-06-20T02:23:26.609-07:00For completeness, I don't use "develop&qu...For completeness, I don't use "develop" branches either - master with release tags, plus release and feature branches. Develop is completely superflous.Chris "Spikeh" Sebokhttps://www.blogger.com/profile/06403874631055393888noreply@blogger.comtag:blogger.com,1999:blog-8221886912876606828.post-15655427821948785892016-06-20T02:22:34.759-07:002016-06-20T02:22:34.759-07:00I agree with everything you say about git-flow, ap...I agree with everything you say about git-flow, apart from the dismissal of feature branches. They are required in order to keep your features separate until they are ready to be merged into the main pipeline / deployed (regardless whether you have CD or just CI).<br /><br />What if a developer is working on a 3 week long feature, only to be asked in week 2 to park it and work on something else? If they worked directly in master, they would have half a feature developed and deployed. Stashing only goes so far, but feature branching solves the problem entirely - whether your working on a binary distribution or a website.<br /><br />This also rings true if a developer wishes to follow the recommended "Commit small, commit often" mantra. You may be in the middle of a feature (with several commits), but need to push the changes in order to work on them on another machine; I do this a lot - I switch between a VM for work, my laptop, and my desktop PC at home. I need access to my feature branches before they're ready for other developers, and pushing my commits to master is absolutely not acceptable.<br /><br />Yeah, feature branches can become stale, and they can be overly complex for simple developments, but when you have anything even remotely complex you have to learn to deal with this, and feature branching is the only sensible way to do it.<br /><br />There's also the commit history argument - I may very well make 200 commits in a feature branch; when I want to merge that feature into master the best way is often to rebase my feature branch on master, fix any resulting "gremlins" - as you put it, then merge my feature into master (I can even squash those commits into one single commit for the entire feature if I want). That means my commit history is clean, readable and maintainable.Chris "Spikeh" Sebokhttps://www.blogger.com/profile/06403874631055393888noreply@blogger.comtag:blogger.com,1999:blog-8221886912876606828.post-39870581420154833592015-12-09T19:42:32.030-08:002015-12-09T19:42:32.030-08:00Great post!
So gitflow(tm) introduces the long li...Great post!<br /><br />So gitflow(tm) introduces the long lived development branch. Any developer worth their salt knows that long lived branches are inherently evil. Things get into the branch early, then for some reason, not released. So now the development branch is different from prod (master). This causes all sorts of problems as new code introduced to the branch depends on code not in master. Hilarity ensues, but actually it is not funny.<br /><br />The correct way to work is master is what is in production. Period. All new work is done on a branch from production (master). The branch goes through the complete QA cycle. Any discrepancies can be compared against master with the same data, since no other branches are involved. Once the branch is approved, it can be merged with other tickets into a new release branch. That branch is then QA'ed. Any problem tickets can be removed and a new release branch can made from the remaining tickets and tested. Once the release branch is approved, it is merged to master and deployed. <br /><br />Any branches existing after a deploy are rebased against or merged with the new master branch. Hotfixes are done against master and merged immediately. Outstanding branches are rebased or merged against master. All branches are based off master at all times. The release branch only exists while it is being QA'ed as a whole, as every ticket was QA'ed alone.<br /><br />This is agile. Adapt or die.BrewCoderhttps://www.blogger.com/profile/04501537453181588978noreply@blogger.comtag:blogger.com,1999:blog-8221886912876606828.post-81835138785047821432015-12-08T11:18:32.997-08:002015-12-08T11:18:32.997-08:00Well said! +1Well said! +1Anonymoushttps://www.blogger.com/profile/01511046986308297396noreply@blogger.comtag:blogger.com,1999:blog-8221886912876606828.post-9811696794790334572015-07-17T06:32:25.353-07:002015-07-17T06:32:25.353-07:00So to summarize your opinion, branching is too muc...So to summarize your opinion, branching is too much overhead for Agile?Anshulhttps://www.blogger.com/profile/04535663075749969690noreply@blogger.comtag:blogger.com,1999:blog-8221886912876606828.post-77647408175304929442015-02-16T16:26:14.532-08:002015-02-16T16:26:14.532-08:00Thanks for the post, I couldn't have said it b...Thanks for the post, I couldn't have said it better!Anonymoushttps://www.blogger.com/profile/16650888579599458329noreply@blogger.comtag:blogger.com,1999:blog-8221886912876606828.post-62512112966990923742014-04-24T16:02:18.385-07:002014-04-24T16:02:18.385-07:00A big part of agile is continuous integration. Bra...A big part of agile is continuous integration. Branching, as often implemented, makes true continuous integration hard. I believe that fundamentally a development approach that relies heavily on long-lived branches is generally not an agile flow.Camille Fournierhttps://www.blogger.com/profile/05090020862261633248noreply@blogger.comtag:blogger.com,1999:blog-8221886912876606828.post-18567035093339274662014-04-24T15:55:42.609-07:002014-04-24T15:55:42.609-07:00It seems entirely unrelated to "Agile", ...It seems entirely unrelated to "Agile", merely buzzwords to draw readers in.Robin Hhttps://www.blogger.com/profile/11203418577239532507noreply@blogger.comtag:blogger.com,1999:blog-8221886912876606828.post-34927922920107242632014-03-26T11:18:25.796-07:002014-03-26T11:18:25.796-07:00The title of this post is puzzling, what does this...The title of this post is puzzling, what does this discussion have to do with Agile?Pedle Zelniphttps://www.blogger.com/profile/06059503102842745467noreply@blogger.comtag:blogger.com,1999:blog-8221886912876606828.post-30308033276442195072013-06-06T14:06:23.131-07:002013-06-06T14:06:23.131-07:00A major refactoring is a rare exception case, beca...A major refactoring is a rare exception case, because it is not a feature but it (occasionally) is an act that crosses releases. There's not a great solution to that case, and I am not suggesting that you never ever branch, merely that branching isn't something that regularly needs to happen as part of an agile development flow. <br /><br />Note that if you're branching for a major refactor, you've got a lot of pressure on to make sure that all changes are pulled into your branch and it doesn't start to conflict heavily with master. Honestly even with branching major refactoring that crosses releases is likely to be a nasty situation if other changes are happening to the code base simultaneously. Camille Fournierhttps://www.blogger.com/profile/05090020862261633248noreply@blogger.comtag:blogger.com,1999:blog-8221886912876606828.post-91867988573022425292013-06-06T13:10:42.013-07:002013-06-06T13:10:42.013-07:00A developer is refactoring code. You come along a...A developer is refactoring code. You come along and ask him to fix a production bug. There is no flag. How do you address this situation?<br /><br />I suppose you could flag every change you did to the code and then remove it and the old code once it was in and stable, but what is the advantage over branching? Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8221886912876606828.post-9339422289174682872013-06-03T06:37:38.913-07:002013-06-03T06:37:38.913-07:00Right on! The "git branching model" is s...Right on! The "git branching model" is simply the textbook description of the waterfall development process.Eric Radmanhttps://www.blogger.com/profile/02599566078553087220noreply@blogger.comtag:blogger.com,1999:blog-8221886912876606828.post-867845305656719612013-02-12T19:35:10.539-08:002013-02-12T19:35:10.539-08:00I wrote this post because I have folks constantly ...I wrote this post because I have folks constantly putting forward the argument that git supports branching -> feature branching should be part of the workflow. So whether or not you've seen it, I hear that argument enough to write a blog post on why I don't like it so I can save myself some typing next time it comes up.<br /><br />You make a great point about branching being easy making local branching productive for local development, which is totally true and a great feature of git. But it's sort of orthogonal to whole team workflow requiring lots of branching.Camille Fournierhttps://www.blogger.com/profile/05090020862261633248noreply@blogger.comtag:blogger.com,1999:blog-8221886912876606828.post-19938704623073788442013-02-12T15:03:48.739-08:002013-02-12T15:03:48.739-08:00I don't think I've seen anyone put forward...I don't think I've seen anyone put forward the argument "git supports feature branching, therefore you should use feature branches". It's more "git supports any workflow, whether or not it involves feature branches, therefore you should use git".<br /><br />I can't imagine *not* taking advantage of the ease of branching in git though. In addition to the work I do at my day job, I'm involved in an open source project and I use git for both. I'd be half as productive if I didn't make use of branches at least for local development.<br /><br />But certainly every team needs to come up with the workflow that best suits its own needs, and then choose a tool that supports it, not the other way around. It just so happens that many workflows do involve branching, and git makes this easy, whereas other VCSs make it a complete nightmare. At my day job we decided that git-flow didn't in fact suit our particular needs, and we now use the branching strategy described here: http://dymitruk.com/blog/2012/02/05/branch-per-feature/ It's working pretty well for us.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8221886912876606828.post-28722405749216527302013-02-11T15:35:03.137-08:002013-02-11T15:35:03.137-08:00Yes, this is exactly right. Unfortunately many dev...Yes, this is exactly right. Unfortunately many developers seem to read the git-flow blog post referenced here and take it as The Way without realizing that it is in fact only applicable for a specific scenario.Camille Fournierhttps://www.blogger.com/profile/05090020862261633248noreply@blogger.comtag:blogger.com,1999:blog-8221886912876606828.post-15473492445190571082013-02-11T15:11:35.473-08:002013-02-11T15:11:35.473-08:00Whatever git flow is used has to align with whatev...Whatever git flow is used has to align with whatever deploy flow is being used. The flow you reference is clearly for rare deploys (monthly or more). It's not my preference, but for people working in that context, feature branches can be very helpful.<br /><br />In the other direction, not even a release branch is necessary as it can be simulated by the checkout of master on the deploy server.<br /><br />Source control workflows and deploy workflows are part of the same thing. They can't mixed and matched when they don't fit and it's necessary to update one when the other changes.Anonymousnoreply@blogger.com