Linus and Git

Why does it seem that so much of the best software gets built in a weekend?

In April 2005, Linux creator Linus Torvalds was frustrated with the proprietary source control tool (SCM) that Linux kernel developers had been using – BitKeeper. However, there were no other distributed SCMs that met their needs.

Legend has it that Torvalds went off one weekend and started addressing the problem head on. The next week he returned triumphantly with Git. An open source SCM with three simple criteria:

  1. Patching should take no more than 3 seconds - as opposed to 30 seconds on other systems
  2. The new tool should support for a distributed workflow
  3. The new tool should Include safeguards against corruption

Torvalds says that it actually took him about 10 days to finish creating Git, but within a day he was able to commit to Git using Git.

GitHub

In 2008, Tom Preston-Werner, Chris Wanstrath and PJ Hyett teamed up to create GitHub - an online service for hosting Git repositories. The result was sensational. By February 2009, there were 46,000 public repos hosted on GitHub.

The success of Git with GitHub led others to follow suit and now there are a number of tools for hosting your Git repositories online (GitLab, Bitbucket).

Today, Git has emerged as the dominant player in SCM today. It’s even called a de facto standard by companies like Atlassian. Large and small teams across the world now use Git to manage their code.

What Makes Git So Awesome?

Git became popular because it was a vast improvement on previous SCMs.

Git is fast

Written in C, you’ll notice that patches take less than a few seconds. This was a key part of Torvalds’ original vision. Patches on previous SCMs took 30 seconds or more.

Git lets you work offline

With Git you don’t need to be connected to the source code host in order to do work. This was not the case with many other SCMs around before Git showed up on the scene.

Git is Distributed

Source control can get messy if you have large commits with lots of code changes. Git encourages small frequent commits related to just one feature. It’s much easier to merge commits that pertain solely to one feature rather than a large commit that touches several features. This is what makes Git such a great tool for collaboration.

Collaboration

Collaboration with Git is very simple. Tools like GitHub have made Pull Requests a standard part of any developer’s workflow. It’s easy to track changes and do code reviews with Git’s diffing tools. This makes it easy for large teams to collaborate on software projects without colliding or clobbering each other’s code.

Back ups

Every clone of your repo serves as a working copy. Rolling back to previous states in your repo is also supported by Git. So you can always have confidence that your repo is in a good state.

Git and Force.com

As we discussed in a previous post, there are some significant issues with source control and deployments on the Force.com platform. Git is especially useful for Salesforce developers.

One of the major frustrations for Force.com developers is code clobbering. This is when one developer’s code overwrites another’s.

Git abandons the linear development workflow that is common with centralized version control systems. In a linear workflow, developers are working on the same code base at the same time. This causes problems where commits related to one issue are interspersed with commits related to other issues. When it comes time to release, this becomes a problem because not every feature is stable enough for a release.

This is also a problem when you have a broken build. Salesforce requires that 75% of Apex code be covered by unit tests. This is a great thing. However, if you are doing linear development, a broken build means that all developers will be unable to continue doing their work, causing mass consternation and unproductive time.

Git solves the problems associated with a linear workflow with branching and merging.

Git allows you to keep a stable master branch that is always deployable. Feature development happens on isolated feature branches. These feature branches are then only merged into the master code base once all tests are passing, keeping the team moving and happy.

Diffs, Code Reviews and Rollbacks

Another nice feature of Git for Force.com is that it vastly improves the experience around code diffs. Git keeps a running history of all the changes that you’ve made with your code so that you can always keep track of changes over time. This is especially useful when trying to debug or understand an issue that may have slipped through to production.

Tools like GitHub, Bitbucket and GitLab all have excellent UIs highlighting diffs.

Diffing in Git featuring Salesforce Aura repo

Code diffs makes code reviews, an emerging software development best practice, much easier to perform. Before any code is merged into the master branch more and more teams are requiring mandatory code reviews. This helps keep the quality of your releases high. Git makes it simple.

Git also makes it easy to rollback to a previously stable version of the code base at any time.

SourceTree

Git is an incredibly powerful tool and has taken it’s place at the top of the SCM ladder. Most popular developer tools/IDEs have excellent support for Git. There are a number of great tools out there for learning Git. In addition to the cloud hosted Git repo services like GitHub and Bitbucket, there are tools like Atlassian’s SourceTree.

SourceTree is a graphical user interface for working with Git. It let’s you get all the power Git without having to touch the command line.

Moving faster, more safely with Git

Using Git for Force.com development is a must. Salesforce developers that are doing so are seeing faster releases, less downtime, fewer manual errors on deploys, and better collaboration between team members.