![]() ![]() We ended up basing our branching strategy off of Three-Flow. Android doesn’t support continuous deployment.We only release one version of the software at a time to production we never need to maintain old legacy releases.We release three builds regularly: internal, beta, and production.We want to be able to test/fix a release on its own branch before shipping.įinally, a couple facts about our environment:.We avoid long-running feature branches (instead using feature flags).Then we listed out the cultural preferences of the team: Our strategy should scale for more than a handful of developers.We need a well-defined strategy for all situations.Creating a SOX-compliant branch is expensive.Here are the problems we were trying to fix: Thus, for our first step, we made a list of factors to take into consideration. It’s fantastically simple! But… GitHub Flow relies on continuous deployment and Android apps can’t do that. Your context, goals, and constraints will guide you to the correct tool for the job.įor example, GitHub Flow is great! The only shared branch is main, you merge features via pull request, and bam - it’s deployed immediately. I don’t believe in a one-size-fits-all solution for basically anything and that’s especially true for code management strategies. With all this in mind, we set out to find a better branching strategy. This problem was compounded by a growing team the amount of communication required on where to merge code grows exponentially with the number of developers. ![]() In other words, the “simple” solution, when faced with unfortunately common circumstances, became quite complex and lacked a well-defined strategy. (I tried to make a chart demonstrating the above but it was such a clusterfuck I’ve spared you all from it.) Let’s hope the hotfix doesn’t require any further hotfixes or things get really ugly. We’d fix that on hotfix/1.2.1, oh but how do we make sure that bug fix makes it into main and release/1.3.0, fuck it let’s just cherry-pick everything. Suppose we were preparing release/1.3.0, but it turns out release/1.2.0 had a severe bug. Thus, release branches were now a gigantic PITA to create and delete.Īlso, our old strategy had a propensity to create nightmare situations when fixing release bugs. Creating a new SOX-compliant branch had a lot of overhead and deleting one was even more heinous. For us, that meant we had to make release branches SOX-compliant, adhering to additional rules and constraints. main was intended to be releasable at all times, though we would occasionally create a release/x.y.z branch, if we felt some set of features needed extra testing time.Īfter being acquired by Atlassian, we ran into a couple problems with our process.įirst, Atlassian is a publicly traded company, and thus it must comply with the Sarbanes-Oxley Act (SOX). We would develop entirely off main using pull requests. Starting with the fact that git doesn't store diffs.Many years ago, Trello Android used a fairly simple git branching strategy - or so we thought at the time. Reading new #git guide managed to fill in more than a few blanks in my understanding of how git actually works. If u r like me who restricted ur git usage to clone/commit/push/pull because u don't want to waste ur time because of weird git issues, then you should definitely read it. I bought and read this "Git Merge & Rebase: An unconventional guide" by and it's mind blowing. You can do too with Marcos unconvential guide - Michael Simons January 17, 2022 ![]() Thanks to I learned in stunning detail what's behind the scene… (Very much graph related, btw). In our team we use rebase, squash and cherry-picking squashed commits on a daily basis. ![]() Learning git almost only by trial and error, I was always under the impression that the git internals are too complex □ new git guide provides dead-simple explanations for what seems to be complicated (merging, rebasing, cherry-pick) □ - Philip Riecks January 28, 2022 ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |