Git
Git is the most used version control system. Git records the changes you make to files so you have a record of what has been done and may roll back to particular versions if necessary. Git also facilitates cooperation by allowing several people's modifications to be merged into a single source. In Git, your local code copy serves as an entire version control repository. These fully complete local repositories make operating both locally and remotely simple. You commit your work locally, then sync your repository copy with the server's copy.
Git is standard Git in Azure Repos. You may utilise your preferred clients and tools, such as Git for Windows and Mac, partner Git services, and tools like Visual Studio and Visual Studio Code.
Check out most important Git Interview Questions here.
Features of Git in Azure Repos
Git features assist programmers in collaborating, coordinating work, and working collaboratively on complicated code and development projects. Git keeps track of changes and allows teams to collaborate remotely on complex systems. Let us learn about various features useful of Git in Azure Repos.
Connecting your favourite development environment
Connect your preferred development environment to Azure Repos to access and manage your repositories. Therefore, you can share your code by:
- Command-line
- Microsoft Visual Studio Code
- Xcode
- Visual Studio
- Eclipse
- IntelliJ
Code Reviewing with pull requests
Before merging code, review it with your team to ensure that changes compile and pass tests. Hence, the following steps can be used for reviewing the code among various users.
- Create a pull request
- Link work items to pull requests
- Set up branch policies
- Squash merge pull requests
- Git branch and pull request workflows
- Leave comments
- Vote on the changes
Protecting branches with policies
Your master branch is one of the essential branches in your repo that the team relies on to stay in excellent condition. Any modifications to these branches should be made via pull requests. Developers who directly push modifications to the protected branches will have their pushes refused.
Conditions should be included to pull requests to ensure a higher degree of code quality in your critical branches. Extra conditions you may specify to help secure your critical branches include a clean build of the merged code and approval from multiple reviewers. You may refer to the following official links for further information regarding branch policies.
Extending pull request workflows with the pull request status
Pull requests and branch policies allow teams to enforce various best practices for code review and automated builds. However, many teams have extra coding requirements and validations to fulfil. Azure Repo provides pull request statuses to meet these particular and bespoke requirements.
The status of pull requests is integrated into the PR procedure. They enable other services to programmatically sign off on a code change by linking simple success/failure information with a pull request.
Isolating the code with forks
Forks are an excellent approach to separate experimental, risky, or sensitive modifications from the source codebase. A fork is a full copy of a repository that includes all files, commits, and (optionally) branches. The new fork behaves like the old repository was cloned and then pushed to a new, empty repository.
When a fork is formed, new files, folders, and branches are not shared between repositories unless they are brought along by a pull request. When you're ready to share your changes, use pull requests to simply push them back to the original source.
Team Foundation Version Control (TFVC)
Azure Repos also support Team Foundation Version Control. TFVC is a version control system that is centralised. Team members typically have only one version of each file on their development workstations. Only the server retains historical data. Branches are formed on the server and are path-based.
Create a project, configure your workspace, and then review and share your code to get started. You can use any of the following clients or IDEs:
- Eclipse
- Visual Studio
- Xcode
Key Concepts that are useful in Azure Repos
Following are some of the key concepts related to the git and its commands that are quite essential in Azur environments:
Branch
Branches are lightweight references that keep track of commits and allow you to separate modifications for a feature or bug repair from your main branch and other work. Changes made to one branch do not affect other branches. You can push and share branches with other team members without merging the changes into the main branch.
It is simple and quick to switch between branches. When you work with branches, Git does not make multiple copies of your source code; instead, it leverages the history information saved in commits to re-create the files in a branch when you begin working on it.
Branch Policies
Branch policies are an essential component of the Git process. You utilise them to assist and preserve critical branches in your development, such as the main.
You may use branch policies to:
- Separate work in progress from finished work on your primary branch.
- Ensure that updates are built before they are released to the public.
- Restriction on who can contribute to particular branches.
- Enforce who may establish branches and the branch naming conventions.
- Include the appropriate reviewers for every code change automatically.
- Use needed code reviewers to enforce the best standards.
Clone
Clone an existing Git repository to make a full local copy of it. Cloning a repository downloads all commits and branches in the repository and creates a named association with the previously cloned repository. To share code with your team, use this connection to communicate with the current repo, pushing and pulling changes.
Commit
A commit is a collection of changes saved to your local repository. You may share these modifications with the remote repository by pushing the code.
Fork
A fork is basically a full copy of a repository that includes all files, commits, and (optionally) branches. The new fork behaves like the old repository was cloned and then pushed to a new, empty repository. When a fork is formed, new files, folders, and branches are not shared between repositories unless they are brought along by a pull request. When you're ready to share your modifications, utilise pull requests to submit them back to the original repository.
Notifications
You will receive an email notification when various changes are made to work items, code reviews, pull requests, source control files, or builds. You can, for example, be alerted when a bug you reported is addressed or when a work item is allocated to you. You receive notifications depending on the rules or subscriptions you set up for yourself, your teams, or the project.
Pull Request
Create pull requests in a Git project to evaluate and merge code. Pull requests enable your team to evaluate code and provide input on changes before merging them into the main branch. Pull requests may originate from subject branches within the same repository or a branch in a fork of the original repository. Reviewers can review the proposed modifications, comment, and vote on whether the code should be approved or rejected.
Pull Commands and Push Command
A pull command merges changes from other team members in the remote repository into the code in your local repository.
You may share changes made in commits and branches using the push command. Git pushes the stored commits in your checked branch to the remote repository. If the code branch already exists on the remote repository, Git takes the commits and adds them to that branch. Git generates a new branch with the same commits as your local branch if that branch does not exist.
Projects
A project, formerly known as a team project, serves as a repository for source code. A project is a location for a group of individuals to plan, track progress, and cooperate on developing software solutions. An Azure DevOps Services organisation or a TFS project collection defines a project. It may be used to focus on the items described in the project.
Public Projects
When a project built within an Azure DevOps Services organisation is made public, it is known as Public Project. Everyone on the planet can find them and execute limited operations on them. To get a list of projects, utilise the Azure DevOps CLI. Administrators have control over who may fully contribute.
Conclusion
This article extensively discussed the Azure Repos, its Version Control and Key Concepts of Azure Repos. We hope this blog has helped you enhance your knowledge relating to Azure Repos.
To learn more, check out our Azure CDN, Azure Media Service, and Azure Storage Monitoring articles. Practice makes a man perfect. To practice and improve yourself for the interviews, you can check out Top 100 SQL problems, Interview experience, Coding interview questions, and the Ultimate guide path for interviews. Do upvote our blog to help other ninjas grow. Happy Coding!
34+ registered 
