Over the last few years, Git has had considerable success and is now the preferred distributed VCS among the developer community.
There is great integration between Azure DevOps and Git, and you have some powerful and productive features at your disposal (https://www.visualstudio.com/en-us/docs/work/backlogs/connect-work-items-to-git-dev-ops), including the following:
- Git branches can be created from within your backlog or Kanban board.
- Git feature branches can easily be created for multiple work items, directly from the Azure DevOps website.
- Pull requests and commits are automatically linked to corresponding work items.
- A build Summary page shows work items, which are linked to a commit, as associated work items.
Let's see how to create a new Git repository, clone it locally, use it within Visual Studio 2019, and create your first commit:
- In your Azure DevOps project, click in the left-hand menu on Repos, and then click on the Clone in Visual Studio button:
- A new window will be displayed; select Microsoft Visual Studio Web Protocol Handler Selector:
- Visual Studio 2019 is started automatically, and you can authenticate with your work, school, or personal Microsoft account:
- Choose the destination folder for your local Git repository, and click on the Clone button to start the download:
- Go to Team Explorer - Home and click on Settings:
- In Team Explorer - Settings, click on Repository Settings:
- In the Ignore & Attributes Files section, click on Add for the ignore file and the attributes file:
- Return to Team Explorer - Home, and this time click on Changes, enter a comment for your first commit, and click on the Commit Staged button:
- Your first commit was created locally when you clicked on the Commit Staged button; click on the Sync link to push it to the server:
- Go to the Azure DevOps website and click on Code in the upper menu; you can see that your created files have been uploaded:
That's it! You have created and initialized your Git repository. It's as easy as that! From here, you have multiple paths you can follow. For instance, leaving everything in the same branch is not really a very good idea, especially when you have to maintain multiple versions of your application.