DevOps Tools - Version Control (Git)

 

What is Git?

Git is a distributed version-control system for tracking changes in source code during software development. It is designed for coordinating work among programmers, but it can be used to track changes in any set of files. Its goals include speed, data integrity, and support for distributed, non-linear workflows.

As with most other distributed version-control systems, and unlike most client–server systems, every Git directory on every computer is a full-fledged repository with complete history and full version-tracking abilities, independent of network access or a central server. Git is free and open-source software distributed under the terms of the GNU General Public License version 2. 

About Git

1. Branching and Merging

The Git feature that really makes it stand apart from nearly every other source control management (SCM) out there is its branching model.

Git allows and encourages you to have multiple local branches that can be entirely independent of each other. The creation, merging, and deletion of those lines of development takes seconds.

This means that you can do things like:

• Frictionless Context Switching. Create a branch to try out an idea, commit a few times, switch back to where you branched from, apply a patch, switch back to where you are experimenting, and merge it in.
• Role-Based Codelines. Have a branch that always contains only what goes to production, another that you merge work into for testing, and several smaller ones for day to day work.
• Feature Based Workflow. Create new branches for each new feature you're working on so you can seamlessly switch back and forth between them, then delete each branch when that feature gets merged into your main line.
• Disposable Experimentation. Create a branch to experiment in, realize it's not going to work, and just delete it - abandoning the work—with nobody else ever seeing it (even if you've pushed other branches in the meantime).

 

 

 

 

 

 

Notably, when you push to a remote repository, you do not have to push all of your branches. You can choose to share just one of your branches, a few of them, or all of them. This tends to free people to try new ideas without worrying about having to plan how and when they are going to merge it in or share it with others.

There are ways to accomplish some of this with other systems, but the work involved is much more difficult and error-prone. Git makes this process incredibly easy and it changes the way most developers work when they learn it. 
 

Small and Fast

Git is fast. With Git, nearly all operations are performed locally, giving it a huge speed advantage on centralized systems that constantly have to communicate with a server somewhere.

Git was built to work on the Linux kernel, meaning that it has had to effectively handle large repositories from day one. Git is written in C, reducing the overhead of runtimes associated with higher-level languages. Speed and performance has been a primary design goal of the Git from the start. 
 

Distributed

One of the nicest features of any Distributed SCM, Git included, is that it's distributed. This means that instead of doing a "checkout" of the current tip of the source code, you do a "clone" of the entire repository.

• Multiple Backups. This means that even if you're using a centralized workflow, every user essentially has a full backup of the main server. Each of these copies could be pushed up to replace the main server in the event of a crash or corruption. In effect, there is no single point of failure with Git unless there is only a single copy of the repository.
• Any Workflow. Because of Git's distributed nature and superb branching system, an almost endless number of workflows can be implemented with relative ease.
• Subversion-Style Workflow. A centralized workflow is very common, especially from people transitioning from a centralized system. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine. 

 

 

 

• Integration Manager Workflow. Another common Git workflow involves an integration manager — a single person who commits to the 'blessed' repository. A number of developers then clone from that repository, push to their own independent repositories, and ask the integrator to pull in their changes. This is the type of development model often seen with open source or GitHub repositories. 

 

 

 

 

• Dictator and Lieutenants Workflow. For more massive projects, a development workflow like that of the Linux kernel is often effective. In this model, some people ('lieutenants') are in charge of a specific subsystem of the project and they merge in all changes related to that subsystem. Another integrator (the 'dictator') can pull changes from only his/her lieutenants and then push to the 'blessed' repository that everyone then clones from again. 

 

 

 

 

 

Comparisons between: GitLab vs GitHub vs Bitbucket

At some point in any software project, you will need to share your code with other developers. If you’re using Git for source control, there are three primary options: Github, Bitbucket, or Gitlab. Understanding the differences and tradeoffs between these three repository management platforms is vital to choosing the best option for your team.
 

Pull (or Merge) Request Process

One of the core features in any team-based version control platform is the pull request process. This typically happens when a team member completes a new feature and wants to get their code merged into the development or production branch of the codebase.

 

 

 

 

 

The feature to be merged will typically be reviewed by another developer during a code review process, and they may want to use the pull request (called “merge request” in Gitlab) feature included in the repository management platform. Let’s take a look at the differences between Github, Bitbucket, and Gitlab in this area.
 

1. Github’s Pull Request Feature

The pull request process in Github is designed with team-based projects in mind. In order to facilitate that workflow, Github provides some interesting features:

• Assign pull requests to teammates
• Attach milestones, projects, and labels to provide context
• Subscribe to be notified when the pull request changes
• Diff of changes between source and base branch
• One-click merge and delete source branch
• Integration with external continuous integration tools
• Pull request templates to ensure contributing guidelines are being followed
• Conversations around parts of the code that require resolution
• Required reviews to ensure that every pull request is signed off by someone before the merge

2. Bitbucket’s Pull Request Feature

Bitbucket's pull requests are similar, although they do not offer quite as many features. Bitbucket does offer everything you need though:

• Assign pull requests to teammates
• Advanced text editor for comments and descriptions
• Subscribe to be notified when the pull request changes
• Diff of changes between source and base branch
• One-click merge and delete source branch
• Integration with external continuous integration tools
• Option to require reviewer approval before merge

3. Gitlab’s Merge Request Feature

While named differently, Gitlab merge requests work pretty much the same way as pull requests. You get most of the same core features:

• Assign merge requests to teammates
• WIP (Work In Progress) indicator to open merge requests before they're ready to be merged
• Integration with milestones/labels for merge request context
• Team members can subscribe to be notified when the request is merged
• Diff of changes between source and base branch
• Integration with external continuous integration tools
• One-click merge and delete source branch

One usablity difference in Gitlab is that you have to make a couple clicks to get to the diff of changes - they aren't shown by default.

While Github's pull request process has the most unique features, it may be distracting if your team doesn't need all of them. Creating a sustainable, repeatable workflow is often better than trying to do everything.
 

GitHub vs Bitbucket vs GitLab: What are the differences?

GitHub, Bitbucket, and GitLab are code collaboration and version control tools offering repository management. They each have their share of fans, though GitHub is by far the most-used of the three. Of the three, only GitLab is open source, though all three support open source projects. GitHub offers free public repositories; Bitbucket also offers free private repositories; GitLab offers a Community Edition which is entirely free.
 

1. What is Bitbucket?

Bitbucket gives teams one place to plan projects, collaborate on code, test and deploy, all with free private Git repositories. Teams choose Bitbucket because it has a superior Jira integration, built-in CI/CD, & is free for up to 5 users.
 

2. What is GitHub?

GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Over three million people use GitHub to build amazing things together.
 

3. What is GitLab?

GitLab offers git repository management, code reviews, issue tracking, activity feeds and wikis. Enterprises install GitLab on-premise and connect it with LDAP and Active Directory servers for secure authentication and authorization. A single GitLab server can handle more than 25,000 users but it is also possible to create a high availability setup with multiple active servers.