Should You Migrate to Git? Part 1

There are many factors to consider when making the decision whether to migrate your source code. Is it appropriate for the project? Will it work? How might it impact the quality and performance of the finished product?

Git can help make the decision easier. Git is an open source version control system for tracking changes in computer files and coordinating work on those files among multiple people (Wikipedia’s definition, not mine).

Git is gaining in popularity and many industries are now moving to it for a number of reasons. For one, Git’s design and performance are remarkably good among all distributed version control system (DVCS) tools. Also, Git can move work quickly between servers without losing history.

Git has a wide variety of plug-ins for IDEs, and it also comes equipped with a wide variety of tools to help users navigate the history system. Each occurrence of the source contains the complete history tree, which can be useful when developing without an internet connection.

Plus, Git was created by Linus Torvalds, who also created Linux, which gives it a certain caché.

Related Content:

5 Open Source SIEM Tools Worth Checking Out

Configuration Files and DevOps

Git’s popularity has been bolstered by killer apps and services such as GitHub, and some very popular projects used it, which further increased its visibility.

Git nowadays is very popular, but it is recommended companies don’t migrate tools so frequently. Also, there are challenges in  pre-migration and post migration worth considering.

Distributed revision control uses a peer-to-peer model rather than using a centralized server to store code updates. While a peer-to-peer model would work better for global, open source projects, it may not be ideal in other situations. The downside to a dedicated server approach is that when the server is down, no clients are able to access the code.

Pros:

• Great for those who hate centralized version control system (CVCS)
• Dramatic increase in operation speed
• Full history tree available offline
• Distributed, peer-to-peer model
• Cheap branch operations
• Attracting lot to non-technical due its open source features (Git is GPLv2)

Cons:

• Learning curve for those used to SVN
• Not optimal for single developers

Companies That Have Migrated

Many of today’s new enterprise technologies are centered around free, “open source” technology. As a result, many big companies, from financial giants to retailers to services firms, prefer open source platforms. With the introduction of GitHub many companies have migrated their code base to Git.

The most popular open source project serves as a “version-control system” for tracking changes and coordinating work between software developers.

Some very well-known names use Git, including:

• • AWS
  • Reddit
  • Twitter
  • PayPal
  • LinkedIn
  • Gnome
  • Adobe
  • HubSpot
  • Mozilla
  • DropBox

Terminology

Git has it own terminology that users, or those considering using it, should become familiar with. Here are some terms worth knowing:

• Master – the repository’s main branch. Depending on the workflow, it is the one people work on or the one where the integration happens.
• Clone – copies an existing Git repository, normally from some remote location to your local environment.
• Commit – posting files to the repository (the local one); in other VCSes it is often referred to as “check-in.”
• Fetch or pull – Also known as “update” or “get latest” in other VCSes. The variance between fetch and pull is that pull combines both fetching the latest code from a remote repo and performing the merging.
• Push –  submitting the code to a remote repository.
• Remote – these are “remote” locations of your repository, normally on some central server.
• SHA – every commit or node in the Git tree is known by a unique SHA key. You can use them in various commands to manipulate a specific node.
• head – a reference to the node to which our working space of the repository currently points.
• branch – similar to other VCSes; however, a branch in Git is actually nothing more special than a particular label on a given node. It is not a physical copy of the files as in other popular VCSes.

— Amit Anan