Netlify isn't only about the JAMstack — there are a host of other design principles that inform the developer experience and product strategy users know and love. Git-Centric Workflow is a core philosophy embraced by Netlify, and listed as a JAMstack Best Practice, yet there hasn't been an attempt to define it or explain it's benefits. Let's try to!

Provider and Platform Agnostic

The first thing to note about using Git is that it belongs to everybody and nobody. As open source software, anyone may use it and build on top of it. So although GitHub has a leading market share, you can take your code and move over to Bitbucket and GitLab, or even a self-hosted solution, at any time.

Similarly, as a result of asking you to base your workflow in Git rather than on proprietary APIs, there is nothing preventing you from building and deploying your code with any other provider. Everyone can do static asset hosting; Netlify has to continually win your support with other features.

Extreme Continuous Deployment

Continuous Deployment is widely recognized to be a best practice, but it is still not the default in many environments and is still too hard to set up as a result. A Git-centric workflow in this context means deploying when you make a valid commit to Git (aka tests pass and build steps succeed), and, implicitly, push it to your Git hosting provider (so your code can survive catastrophic damage to your laptop).

Immutable. If Continuous Deployment means that the latest valid commit on your master branch is deployed on yoursite.com, it is a short step to Immutable Deploys, which means that EVERY deploy gets an always-live, immutable ID. Deployments are atomic, meaning we first upload every file, and only take the entire site live once they are all done. Domains like yoursite.com or yoursite.netlify.com are effectively references to a Git commit, just like HEAD or origin/HEAD might be. You can even roll back to an old version at any time for any reason, just like with Git.

Previews. Git's standout feature of branching and merging also means there is an inbuilt, extremely familiar collaboration model to your workflow, which platforms like Netlify or Heroku can then leverage. Open source projects and team marketing sites love the idea of Deploy Previews, where every PR gets its own build with a publicly available URL that you can preview.

Branches. Not comfortable with Continuous Deployment? Prefer a staging and uat environment multistage deployment process? I've been there. Why stop at two environments? Have as many as you like! Branch Deploys let you set up a new environment with no more API than git checkout -b staging. If you use Netlify DNS you can even set them up as a subdomain like staging.yoursite.com!

Split Testing. If you're already comfortable with feature branches, then you already know all the API you need to A/B test your features. Netlify's Split Testing is Git-centric too, which means that setting up an A/B test is also as simple as running git checkout -b staging and then moving sliders around to determine traffic splits. What's amazing is: there is nothing else to learn! 🤯 Pro Tip: If you don't want to randomly roll out features based on traffic split, you can even go for an opt-in private Beta release, using JavaScript to set the nf_ab cookie for users you want to launch darkly to!

Not just Frontend Code: Git For Everything

Apart from Git as the API for everything deployment related, Git-centric workflow also means checking some things into Git that you might not have thought to do before.

Atomic Deploys of Backend and Frontend. The Git analogy for deployment extends beyond just your frontend code. Your serverless Netlify Functions are code too! If your frontend changes require backend changes, the lockstep movement of backend and frontend is assured with Atomic Deploys. In practice, truly non-breaking change between backend and frontend is hard to achieve. Deploy Previews can help test functionality in production and Netlify Dev can help test locally even before you commit.

Content. Beyond just writing code, you may be writing documentation, or landing page copy, or a team blog. You need to draft, edit, preview, publish, and revert changes with content just like with any code you write. So it's no surprise that the editorial process can work excellently with Git-centric workflow as well! In fact this very blog itself uses NetlifyCMS to write and publish content, alongside any code edits needed to make that content display the way we need it to. NetlifyCMS is site generator and framework agnostic, but sets itself apart from other Headless CMS solutions by putting all content in Git. Version control and publication of content has never been easier.

Large Files. At the extremes, Git does have scalability issues. Even if you're not Google, you may be a photographer that needs to store large media files in their raw, highest quality format, even though you may not display them all the time and may need to size them down for better browsing performance. Netlify Large Media still achieves this with Git-centric Workflow, by leveraging the wonderful Git LFS project, offering easy APIs for Image Transformation for faster browsing without busting data limits or performance budgets.

So... What is Git-Centric Workflow?

As you can see, what we mean when we talk about a Git-Centric Workflow is a single analogy that applies throughout your entire architecture — from putting as much as makes sense in Git (e.g. Serverless Functions, Content, and Large Files), to taking continuous deployment to its logical extreme with no additional API to learn. Lastly, the ultimate expression of freedom from vendor lock-in: Git as the ultimate Provider- and Platform-Agnostic workflow.

In short: Everything lives in Git, and Git for Everything, for your site and deployment infrastructure to survive as long as Git does. That's a pretty good bet!