GitHub: How Developers Got to Run the World (sic)

by Olenka Van Schendel 

1. Remote coding for a remote workforce

Anyone who recalls the bad old days of centralized version control will remember that updating sources from any place away from the source control server was problematic. On a plane or somewhere else without internet access, unless you had planned ahead and acquired an offline version of code you wouldn’t be able to work at all. And even if you did, you would struggle to merge back your updates when you did reconnect.

Git changed all that. Designed by Linus Torvalds as a better way to build Linux, Git decentralized the management of source code making collaboration a distributed affair. GitHub seized the opportunity, building a website over Git to encourage you to freely develop anywhere and sync back easily. So thanks to Git and a very smooth collaboration interface of their own, GitHub overtook the other giants in the market like SourceForge and Google Code, becoming the global answer to remote coding in a distributed world.

Even Microsoft the « bête noire » of the open source world has turned to GitHub to host their most important open source projects.

2. Open source

Gone are the days of squirreling away your brilliant source code in case someone steals your bright idea. The world’s most successful companies have understood that it is better to multiply forces and have thousands of other developers sharing and improving the quality of their code. And with the advent of GitHub and « social coding », developers see that something much greater than the value of their code is their own reputation in the community.

3. Public vs. Private

But the value of Git and GitHub isn’t restricted to the open source community. It’s perfectly possible to have a private repository and only share parts of your source code. Or even keep all your source code private to your enterprise. Companies like Google and Microsoft do both and move code back and forth.

4. Is Git more complicated than other tools?

If there is one shadow still lingering over Git, it is the mistaken perception that it is more complicated than other source code management tools like SVN. This impression has slowed the uptake of Git in some traditional programming environments who sometimes see Git as a leap into the unknown.

5. Is there any truth in the rumour?

A typical Git workflow has a two-step commit, giving it extra power and a peer review. So you do have more commands in a typical Git workflow when compared to SVN.

Typical SVN workflow : Update, do work, Commit
Typical Git workflow : Pull, do work, Add (to staging area), Commit, Push

(But if you don’t need this feature, you can reduce this to one-step by combining the commands into a Git « commit -a ». That leaves you with only one command more in Git.).

Also some SVN users are reluctant to move over to Git because of a “fear of branching”. Though branching in SVN has improved since its early days, it is still harder to use than branching in Git. (Early SVN users tended to commit back to the trunk just to avoid the pain of a merge conflict).

Git is very good at branching and merging, and very fast with it. Unlike other tools, branching is a fundamental concept in Git not just a bolt-on. So it’s usually easy to resolve a merge conflict, and if not, you can very easily back out and try another merge strategy.

What’s more, Git remembers everything you do for 30 days or so. Nothing is deleted, so if you accidentally delete a branch, just find the hash and point back to it.

If you make a mistake and commit several times to the wrong branch, you can easily point back the old branch and re-commit onto a new one. It’s all made easy.

Consider also the smooth interface layer that GitHub brings to Git. GitHub makes it easy to store your Git projects, work with teammates, track issues, and keep things organized.

Still not convinced? We’d like to hear your opinion!
Email us at: info@arcadsoftware.com