Source Code Management

Version control systems

Version control systems are a category of software tools that help a software team manage changes to source code over time. Version control software keeps track of every modification to the code in a special kind of database. If a mistake is made, developers can turn back the clock and compare earlier versions of the code to help fix the mistake while minimizing disruption to all team members.

Version Control Systems (VCS) have seen great improvements over the past few decades and some are better than others. VCS are sometimes known as SCM (Source Code Management) tools or RCS (Revision Control System).

There are two types of version control: centralized and distributed.

Centralized version control

With centralized version control systems, you have a single “central” copy of your project on a server and commit your changes to this central copy. You pull the files that you need, but you never have a full copy of your project locally. Some of the most common version control systems are centralized, including Subversion (SVN) and Perforce.

Distributed version control

With distributed version control systems (DVCS), you don’t rely on a central server to store all the versions of a project’s files. Instead, you clone a copy of a repository locally so that you have the full history of the project. Two common distributed version control systems are Git and Mercurial.

GIT

One of the most popular VCS tools in use today is called Git. Git is a Distributed VCS, a category known as DVCS, more on that later. Git is free and open source. Primary benefits you should expect from version control are as follows.

A complete long-term change history of every file. This means every change made by many individuals over the years. Changes include the creation and deletion of files as well as edits to their contents. Having the complete history enables going back to previous versions to help in root cause analysis for bugs and it is crucial when needing to fix problems in older versions of software.
Branching and merging. Individuals working on their own can benefit from the ability to work on independent streams of changes. Creating a “branch” in VCS tools keeps multiple streams of work independent from each other while also providing the facility to merge that work back together, enabling developers to verify that the changes on each branch do not conflict. Many software teams adopt a practice of branching for each feature or perhaps branching for each release, or both.
Traceability. Being able to trace each change made to the software and connect it to project management and bug tracking software such as Jira, and being able to annotate each change with a message describing the purpose and intent of the change can help not only with root cause analysis and other forensics.

Why GIT over TFVC?

VSTS or Team services offers 2 types of version control

Git
TFVC

Git is a distributed version control system. Each developer has a copy of the source repository on their dev machine. Developers can commit each set of changes on their dev machine and perform version control operations such as history and compare without a network connection. Branches are lightweight. When you need to switch contexts, you can create a private local branch. You can quickly switch from one branch to another to pivot among different variations of your codebase. Later, you can merge, publish, or dispose of the branch.

Team Foundation Version Control (TFVC) is a centralized version control system. Typically, team members have only one version of each file on their dev machines. Historical data is maintained only on the server. Branches are path-based and created on the server.

Here is why; Git is so popular and attracting enterprises, individuals and communities

Get social with powerful code reviews Keep track of feedback with threaded discussions and comment status. Continuous integration for each change to a pull request. Merge how you want with custom messages, squash, and more. @mentions for people and work items keep everyone up-to-date.

Track your code from idea to release Create a branch right from your backlog or Kanban board. Easily track the build and release status for your code. Pull requests and commits are automatically linked and appear on work items.

One solution for your cross platform team Built-in continuous integration and support for Jenkins and others tools. Powerful integration in Visual Studio and Visual Studio Code. Extensions for Android Studio, Eclipse, IntelliJ, and all other JetBrains IDEs.

Maintain quality with branch policies Guarantee changes build before they get to master. Limit who can contribute to specific branches. Automatically include the right reviewers for every code change. Enforce best practices with required code reviewers.

Free git repos Scale your projects with unlimited free private git repositories.

Extension Marketplace Find extensions in our marketplace to integrate with many other services.

Customizable Dashboards Keep up with your team’s data and the progress of your projects at-a-glance.

Branch Updates View your commits history by pull requests and pushes to understand how code flows and find bad merges.

Enterprise-Grade Security Leading security with SOC compliance and multi-factor authentication.

Active Directory Azure Active Directory makes it easy to manage people and permissions, including support for on-prem Active Directory.

Semantic Code Search Find things fast. Search a single or multiple repositories and based on code constructs like classes, variables, etc.

Web Hooks & API Integration Build your own extensions using web hooks & REST APIs.

GIT

The most widely used modern version control system in the world today is Git. Git is a mature, actively maintained open source project originally developed in 2005 by Linus Torvalds, the famous creator of the Linux operating system kernel. A staggering number of software projects rely on Git for version control, including commercial projects as well as open source. Git is an example of a DVCS (hence Distributed Version Control System). Git has been designed with performance, security and flexibility

Performance: The raw performance characteristics of Git are very strong when compared to many alternatives. Committing new changes, branching, merging and comparing past versions are all optimized for performance.

Security: Git has been designed with the integrity of managed source code as a top priority. The content of the files as well as the true relationships between files and directories, versions, tags and commits, all of these objects in the Git repository are secured with a cryptographically secure hashing algorithm called SHA1.

Flexibility: Git is flexible in several respects: in support for various kinds of nonlinear development workflows, in its efficiency in both small and large projects and in its compatibility with many existing systems and protocols.

GIT Install

Windows:

Git for Windows stand-alone installer

Download the latest Git for Windows installer.
When you’ve successfully started the installer, you should see the Git Setup wizard screen. Follow the Next and Finish prompts to complete the installation. The default options are pretty sensible for most users.
Open a Command Prompt (or Git Bash if during installation you elected not to use Git from the Windows Command Prompt).
Run the following commands to configure your Git username and email using the following commands. These details will be associated with any commits that you create:

$ git config –global user.name “Abc”

$ git config –global user.email ” Abc@organization.com”

Install the Git credential helper on Windows (Optional)

Bitbucket supports pushing and pulling over HTTP to your remote Git repositories on Bitbucket. Every time you interact with the remote repository, you must supply a username/password combination. You can store these credentials, instead of supplying the combination every time, with the Git Credential Manager for Windows.

Git for Mac Installer

The easiest way to install Git on a Mac is via the stand-alone installer:

Download the latest Git for Mac installer.
Follow the prompts to install Git.
Open a terminal and verify the installation was successful by typing git –version:

$ git –version

git version 2.9.2

Configure your Git username and email using the following commands. These details will be associated with any commits that you create:

$ git config –global user.name ” Abc “

$ git config –global user.email ” Abc @atlassian.com”

To make Git remember your username and password when working with HTTPS repositories, configure the git-credential-osxkeychain helper. (Optional)

GIT Repository:

A Git repository is a virtual storage of your project. It allows you to save versions of your code, which you can access when needed.

Setting up a repository

This resource will walk you through initializing a Git repository for a new or existing project.

Git init:

To create a new repo, you’ll use the git init command. git init is a one-time command you use during the initial setup of a new repo. Executing this command will create a new .gitsubdirectory in your current working directory. This will also create a new master branch.

If you want to create repo for an existing project, You’ll first cd to the root project folder and then execute the git init command.

cd /path/to/your/existing/code

git init

Pointing git init to an existing project directory will execute the same initialization setup as mentioned above, but scoped to that project directory.

git init <project directory>

Git Clone:

If a project has already been set up in a central repository, the clone command is the most common way for users to obtain a local development clone. Like git init, cloning is generally a one-time operation. Once a developer has obtained a working copy, all version control operations are managed through their local repository.

git clone <repo url>

git clone is used to create a copy or clone of remote repositories.

Git supports a few different network protocols and corresponding URL formats. In this example, we’ll be using the Git SSH protocol. Git SSH URLs follow a template of: git@HOSTNAME:USERNAME/REPONAME.git

An example Git SSH URL would be: git@bitbucket.org:vinaysandela/javascript-data-store.git where the template values match:

• HOSTNAME: bitbucket.org

• USERNAME: vinaysandela

• REPONAME: javascript-data-store

When executed, the latest version of the remote repo files on the master branch will be pulled down and added to a new folder. The new folder will be named after the REPONAME in this case javascript-data-store. The folder will contain the full history of the remote repository and a newly created master branch.

Saving changes to the repository: git add and git commit

Now that you have a repository cloned or initialized, you can commit file version changes to it. The following example assumes you have set up a project at /path/to/project. The steps being taken in this example are:

• Change directories to /path/to/project

• Create a new file CommitTest.txt with contents ~”test content for git tutorial”~

• git add CommitTest.txt to the repository staging area

• Create a new commit with a message describing what work was done in the commit

cd /path/to/project

echo “test content for git tutorial” >> CommitTest.txt

git add CommitTest.txt

git commit -m “added CommitTest.txt to the repo”

After executing this example, your repo will now have CommitTest.txt added to the history and will track future updates to the file.

Configuration & set up: git config

Once you have a remote repo setup, you will need to add a remote repo url to your local git config, and set an upstream branch for your local branches. The git remote command offers such utility.

git remote add <remote_name> <remote_repo_url>

This command will map remote repository at <remote_repo_url>to a ref in your local repo under <remote_name>. Once you have mapped the remote repo you can push local branches to it.

git push -u <remote_name> <local_branch_name>

This command will push the local repo branch under <local_branc_name> to the remote repo at <remote_name>.

In addition to configuring a remote repo URL, you may also need to set global Git configuration options such as username, or email. The git config command lets you configure your Git installation (or an individual repository) from the command line. This command can define everything from user info, to preferences, to the behavior of a repository. Several common configuration options are listed below.

Git stores configuration options in three separate files, which lets you scope options to individual repositories (local), user (Global), or the entire system (system):

• Local: <repo>/.git/config – Repository-specific settings.

• Global: /.gitconfig – User-specific settings. This is where options set with the –global flag are stored.

• System: $(prefix)/etc/gitconfig – System-wide settings.

Define the author name to be used for all commits in the current repository. Typically, you’ll want to use the –global flag to set configuration options for the current user.

git config –global user.name <name>

Define the author name to be used for all commits by the current user.

Adding the –local option or not passing a config level option at all, will set the user.name for the current local repository.

git config –local user.email <email>

Define the author email to be used for all commits by the current user.

git config –global alias.<alias-name> <git-command>

Create a shortcut for a Git command.

This is a powerful utility to create custom shortcuts for commonly used git commands. A simplistic example would be:

git config –global alias.ci commit

This creates a ci command that you can execute as a shortcut to git commit. To learn more about git aliases visit the git configpage.

git config –system core.editor <editor>

Define the text editor used by commands like git commit for all users on the current machine. The <editor> argument should be the command that launches the desired editor (e.g., vi). This example introduces the –system option. The –system option will set the configuration for the entire system, meaning all users and repos on a machine.

Basic Git commands

To get you started, here are a list of some basic Git commands to get you going with Git:

Git task	Notes	Git commands
Tell Git who you are	Configure the author name and email address to be used with your commits.Note that Git strips some characters (for example trailing periods) from user.name.	git config –global user.name “Abc” git config –global user.email abc@example.com
Create a new local repository		git init
Check out a repository	Create a working copy of a local repository:	git clone /path/to/repository
	For a remote server, use:	git clone username@host:/path/to/repository
Add files	Add one or more files to staging (index):	git add <filename>git add *
Commit	Commit changes to head (but not yet to the remote repository):	git commit -m “Commit message”
	Commit any files you’ve added with git add, and also commit any files you’ve changed since then:	git commit -a
Push	Send changes to the master branch of your remote repository:	git push origin master
Status	List the files you’ve changed and those you still need to add or commit:	git status
Connect to a remote repository	If you haven’t connected your local repository to a remote server, add the server to be able to push to it:	git remote add origin <server>
	List all currently configured remote repositories:	git remote -v
Branches	Create a new branch and switch to it:	git checkout -b <branchname>
	Switch from one branch to another:	git checkout <branchname>
	List all the branches in your repo, and also tell you what branch you’re currently in:	git branch
	Delete the feature branch:	git branch -d <branchname>
	Push the branch to your remote repository, so others can use it:	git push origin <branchname>
	Push all branches to your remote repository:	git push –all origin
	Delete a branch on your remote repository:	git push origin :<branchname>
Update from the remote repository	Fetch and merge changes on the remote server to your working directory:	git pull
	To merge a different branch into your active branch:	git merge <branchname>
	View all the merge conflicts:View the conflicts against the base file:Preview changes, before merging:	git diff git diff –base <filename> git diff <sourcebranch> <targetbranch>
	After you have manually resolved any conflicts, you mark the changed file:	git add <filename>
Tags	You can use tagging to mark a significant changeset, such as a release:	git tag 1.0.0 <commitID>
	CommitId is the leading characters of the changeset ID, up to 10, but must be unique. Get the ID using:	git log
	Push all tags to remote repository:	git push –tags origin
Undo local changes	If you mess up, you can replace the changes in your working tree with the last content in head:Changes already added to the index, as well as new files, will be kept.	git checkout — <filename>
	Instead, to drop all your local changes and commits, fetch the latest history from the server and point your local master branch at it, do this:	git fetch origin git reset –hard origin/master
Search	Search the working directory for foo():	git grep “foo()”

Some of the helpful and more detailed documentation for GIT can be found at –

https://git-scm.com/doc

https://www.atlassian.com/git/tutorials/what-is-version-control

Some of the suggested Branching Strategies for GIT can be found at – Click Here

If you want to read more about using GIT repository on Team Foundation Server/Azure DevOps – Click Here