To make it easier for you to switch from TFVC to Git, Azure DevOps server now provides an out-of-the-box migration workflow, called import repository. The import repository option can be reached from the code hub. This allows you to migrate a TFVC repository into Git with history. However, the tool only allows you to migrate up to 180 days' worth of history from your TFVC repository. Not being able to migrate the entire history from the TFVC repository may be a dealbreaker for some. The following image shows you how to get to the import repository dialogue, the image also shows the migrate history options available to you:

Azure DevOps Server supports three secure ways to connect to your Git repositories—the first two work over HTTPS and the third option uses SSH:

• Git Credential Manager
• Personal Access Token
• SSH Public Keys

Git credential manager is the preferred option, since it lets you use the same credentials that you use with Azure DevOps Server web portal and also supports multi-factor authentication. In addition to supporting multi-factor authentication with Azure DevOps Server, the credential managers also support two-factor authentication for GitHub repositories. Once authenticated, the credential manager creates and caches a personal access token for future connections to the repo. Git commands that connect to this account won't prompt for user credentials until the token expires or is revoked through Azure DevOps...

If you already have a Git repository on GitHub that you want to port to Azure DevOps Server, you'll be delighted to know that Azure DevOps Server natively supports importing a Git repository with history from any Git-hosting platform, including GitHub. In this recipe, you'll learn how to import the parts unlimited GitHub repository with its complete history, including branches and tags, into Azure DevOps Server.

The PartsUnlimited GitHub repository (https://github.com/Microsoft/PartsUnlimited) that we'll be porting across needs to be accessible from the environment you are accessing in the Azure DevOps Server web portal. In the...

Git and Continuous Delivery is one of those delicious chocolate & peanut butter combinations we occasionally find in the software world: two great tastes that taste great together! Continuous Delivery of software demands a significant level of automation. It's hard to deliver continuously if you don't have a quality codebase. Git provides you with the building blocks to really take charge of quality in your codebase; it gives you the ability to automate most of the checks in your codebase even before committing the code into your repository. To fully appreciate the effectiveness of Git, you must first understand how to carry out basic operations on Git, such as clone, commit, push, and pull. 

The natural question is, how do we get started with Git? One option is to go native with the command line or...

Code issues that are found sooner are both easier and cheaper to fix. Therefore, development teams strive to push code quality checks as far left into the development process as possible. As the name suggests, branch policies give you a set of out-of-the-box policies that can be applied to the branches on the server. Any changes being pushed to the server branches need to comply with these policies before the changes can be accepted. Policies are a great way to enforce your team's code quality and change-management standards. In this recipe, you'll learn how to configure branch policies on your master branch.

The out-of-the-box branch policies...

Ryan Hellyer accidentally leaked his Amazon AWS access keys to GitHub and woke up to a $6,000 bill the next morning. Wouldn't you just expect a source control as clever as Git to stop you from making such a blunder? Well, in case you didn't know, you can put Git Hooks to work to address not just this but many similar scenarios. In the spirit of pushing quality left into the development process, you want to enable developers to identify and catch code quality issues when they are developing the code locally in their repository, even before raising the pull request to trigger the branch policies. Git hooks allow you to run custom scripts whenever certain important events occur in the Git life cycle, such as committing, merging, and pushing. Git ships with a number of sample hook scripts in the repo\.git\hooks directory...

It is not uncommon for projects to have include high quality images and videos that are large in size. If you have large files in your repository, such as images and videos, Git will keep a full copy of the file in the repo every time you commit a change to the file. Git is ultimately versioning the file, if many versions of these files exist in your repo, they will dramatically increase the time to check out, branch, fetch, and clone the code. 

Luckily git has solved this problem using Git Large File System (LFS). LFS is an extension to Git; it replaces large files, such as audio samples, videos, datasets, and graphics, with text pointers inside Git, while storing the file's contents on a remote server which commits data that describes the large files in a commit to your repo, and stores the binary file contents...

The purpose of writing code is to ship enhancements to your software. A branching model that introduces too much process overhead does not help in increasing the speed with which you can get changes out to customers. It is therefore important to come up with a branching model that gives you enough padding to not ship poor-quality changes but at the same time not introduce too many processes to slow you down. The internet is full of branching strategies for Git; while there is no right or wrong, a perfect branching strategy is one that works for your team! In this recipe, we'll learn how to use a combination of feature branches and pull requests to always have a ready-to-ship master branch and how to sync bug fixes fixed in fix of fail branches back into master to avoid regression.