Author: Pranav Kanade

Version control (which, these days, almost always means Git) is vital to modern software development. Git is the mechanism that all (responsible) developers use to manage changes to their code and collaborate with others. Without Git, we just wouldn't be able to rapidly build and iterate software the way we do today, with constant experimentation by teams spread across the globe.

And yet, until last year, Git has not been a feature of app platforms. This three-part series explains why it took so long for Git to appear in app platforms, how Appsmith finally implemented this feature, and best practices you can adopt when bringing Git workflows to your own internal app development.

What is Git and why is it so useful to developers?

Git is an open-source distributed version control system. If you've done any software development in the last couple of decades, you'll already be familiar with the reasons Git is so popular:

• It lets you easily track code changes: Developers need to be creative to solve tough problems. Being able to easily experiment while keeping everything organized and reversible encourages this.

• It enables smooth collaboration: Team members can collaborate on Git repositories, no matter where they are in the world. Git allows you to work on multiple branches of the same codebase at the same time so that changes can be made without breaking others’ work.

• It helps you catch mistakes before they enter production: Git shows the history of every change that's been made to your code. This makes code review easier and helps developers spot problems before they are deployed to production. If a problem does sneak through, it's possible to quickly revert back to a previous version.

Git is a force multiplier for development teams, greatly improving the engineering process. Development teams using Git can be more creative and take greater risks, all while placing themselves under much less stress. From a product perspective, Git lets you evolve your code rapidly to respond to market needs and easily maintain different versions for different use cases.

Why don't other internal apps platforms have Git?

To be upfront, we think the reason Git hasn't become a cornerstone feature of other internal apps platforms is because they consider it too difficult a problem to solve, even if it would greatly improve the experience for the developers building with their products.

App platforms and low-code interface builders store their application logic, interfaces, and data in a database, rather than in files. Git, on the other hand, works on a filesystem. Bridging these two systems to track the changes to code generated by these platforms may not seem complicated, but once you factor in performance, safeguards against corruption, and implementation of additional Git-native functionality like authentication, branching, and merging, things can get pretty hairy.

Some platforms skirt around these problems by having ”Git-compatible” or ”Git-like” functionality provided by a home-baked version control system that avoids these pitfalls by just not providing certain functionality, but they are often locked behind enterprise plans and, frankly, they just aren't Git.

If you want version control and integration with your existing tools, syntax that every developer is familiar with, access control, thousands of compatible tools including GitHub, BitBucket, and Visual Studio Code, and plugins for almost everything... it has to be Git. There is just no substitute.

Every developer has a story about Git saving the day (or their project, or their job…)

Not using Git when it's available would be considered a massive oversight by any development team. So, despite the challenges of implementation, why hasn't its absence as a feature been considered a massive oversight by the developers of app platforms? Surely their own development teams are aware of its benefits — we've all been saved by Git at least once!

Git saves the enterprise: AWS spot instances nearly wipe out a month’s work

We've collected a couple of stories from our team to demonstrate just how important version control is. This story comes from the Appsmith internal Slack channel and shows how Git can help save a business from unexpected data loss (and an innocent mistake from a developer):

...So we had an enterprise customer who was building their internal tools on Appsmith. To save costs, they had decided to do this on an AWS spot instance, which they thought was surprisingly cheap! What the customer didn't know was that spot instances have no data persistence. If they are shut down or rebooted, or crash, or AWS decides to re-provision them, everything is gone (surprise!).

This particular spot instance had a pretty good uptime: it made it a whole month into development before it was unexpectedly wiped. All development progress was destroyed, or it would have been, if they hadn't been using Git. They were back up and running in an hour after setting up a new instance and syncing their repositories. Their Appsmith apps were all intact. As I understand it the phrase ”spot instance” is currently banned in that customer's meeting room.

Git goes hand-in-hand with backup best practices that stipulate that you should store backups in three separate physical locations to protect against data loss. As Git is distributed, it's easy to make sure that it is synchronized off site, where it is protected from theft, fire, or the dreaded rm -rf.

Git saves the developer...from Git (and themselves)

Another story from our support channels, again showing how Git is already making a big impact for developers building with Appsmith:

Git is popular because it's the best at what it does, but that doesn't mean it's without problems. Many of these problems are, however, not technical, but derive from PEBKAC, usually when two developers are working on a project and merge incompatible changes. Or a solo developer can do this too, I guess, by merging two of their own feature branches without double-checking things.

We had a user, not a corporate user, but someone on our Discord we were helping out. In this case, a merge of two Appsmith feature branches made a total mess. This developer was a little green and had maybe over-extended himself, and wasn't sure how to resolve the issue. We were able to jump in and help him sort out the mess and salvage the project in time for him to deliver it to his client without a delay. In a sense it was Git saving the developer from Git, letting us piece together a working version from a very messy, bad state.

Troubleshooting and code reviews for your internal apps are made much easier with Appsmith’s Git functionality. You can view exactly what has changed and pinpoint where an error or conflict has occurred.

Now imagine how these scenarios would have played out without Git. Nightmarish!

We took up the challenge — Appsmith's platform is now the only one with Git

As you've probably figured out by now, we're talking about Git because we're excited to have finally brought it to Appsmith. No compromises: it's as Git as Git gets.

This wasn't an easy journey. While this functionality was in high demand, early versions were frustrating to use. In our earliest implementations, it wasn't even possible to pinpoint where the conflicts were in a file. Even members of the Appsmith development team would avoid using our early Git implementations. We even had a rule for our internal “Hackathons” that using the Git feature was banned because it kept breaking! So we know why other app platforms had avoided fully implementing Git: it really was a challenge to get it working right.

It took three developers five months of rigorous work to get our Git implementation polished and working to our high standards, and, as you can see above, our customers are already benefiting. When we see disasters mitigated and workflows sped up with Git, we know it was totally worth the investment, and we're hoping, now that we have real Git integrated into our app platform, others will follow.

New to Appsmith? You can sign up for our free cloud hosted app platform, or self-host using Docker.