11–20 of 108 posts
A significant amount of Git-isms are based around Linux kernel needs. Which is great. But closed source and typical open source needs are pretty different, and much simpler.
Google and Facebook both use trunk based development for nearly all code at both companies. This guide advises you to consider trunk based development if your release cycles are less than ~4 weeks. I'd suggest doing it no matter what. The only place where I've run into problems with this was managing very long term hold outs where we wanted to avoid changing user visible behavior. Instead of branches, we maintained l…
Wait so no develop branch? The utility gained by having “what’s in production” and “what we’re working on” as separated feels hard to part with.
It has its limitations, but for the the 90+% of places that aren't operating at Facebook scale, it's probably the right choice. It doesn't eliminate merge hell, but it does localize it, making it a lot easier to resolve conflicts without accidentally undoing somebody else's work.
It's especially well-suited for any projects that are in constant-iteration mode, where there's a steady stream of bugfixes and new developments getting deployed daily (or even multiple times a day).
You can even manage longer-lived branches after a fashion: the cleanest pattern seems to be to capture your changes into a patch, revert your branch to the commit immediately before your changes, merge/rebase main, then apply your patch on top. This is bad and lame because it rewrites history and requires a force push to get it into the remote, but it's also nice because it keeps your changes at the tip of the branch and makes review a bit easier in e.g. GitLab.
Every small shop I've worked with that has tried to use more complex branching models eventually hoses the repo and ends up burning a lot of dev hours one day trying to make sense of a git log that looks like a diagram of network sorting.
Google and Facebook both use trunk based development for nearly all code at both companies. This guide advises you to consider trunk based development if your release cycles are less than ~4 weeks. I'd suggest doing it no matter what. The only place where I've run into problems with this was managing very long term hold outs where we wanted to avoid changing user visible behavior. Instead of branches, we maintained l…
I have always been happiest in a trunk-based dev model, but in many orgs it is heresy to even mention it.
Earlier quoted context omitted.
if that's the only reason for the branch, you can just as easily determine which commit is on which environment with tags
So if the “deployed branch” were really just a “tag”, that would fit trunk based development? Because that’s basically what git is doing. It’s not like there are two sets of files anywhere, afaik. My understanding of this though is that there isn’t supposed to be a difference between “what we’re working on” and “what’s deployed”, which I think then means you don’t really do “long term” development.
Google and Facebook both use trunk based development for nearly all code at both companies. This guide advises you to consider trunk based development if your release cycles are less than ~4 weeks. I'd suggest doing it no matter what. The only place where I've run into problems with this was managing very long term hold outs where we wanted to avoid changing user visible behavior. Instead of branches, we maintained l…
How did the hold back end up working out? Was the learning worth the hassle?
Wait so no develop branch? The utility gained by having “what’s in production” and “what we’re working on” as separated feels hard to part with.
if that's the only reason for the branch, you can just as easily determine which commit is on which environment with tags
I have a mono-repo with one master branch - that auto-deploys to test - and one release branch that auto-deploys to staging. I can hot-swap my staging and production environment with the click of a button.
Simple, and it allows us to deploy a hotfix of needed, and we've done some major work on master that needs to be validated first...
But,... It all depends on your context and your needs...