Senior Software Engineer
Subscribe to the newsletter
As organizations modernize their DevOps practices, shifting from centralized version control systems like TFVC to distributed systems like Git has become a strategic priority, especially for teams working on Microsoft Dynamics 365 Finance & Operations (F&O). Git not only enables better collaboration and faster delivery cycles but also integrates seamlessly with Azure DevOps Git, making it the preferred choice for development teams.
In this blog, we’ll walk you through everything you need to know to start with Git for Dynamics 365 F&O projects. You’ll learn how to configure Git, use key commands in Visual Studio, adopt best practices for commits and pull requests, and execute a smooth migration from TFVC to Git. Whether optimizing your version control practices or planning a full migration, this guide offers actionable steps to help you modernize your DevOps approach confidently.
Why do we use Repos in DevOps for D365 F&O development?
In DevOps for Dynamics 365 Finance and Operations (F&O) development, repos (repositories) are used primarily for version control. This allows developers to track changes to their code over time, collaborate effectively with other team members, and manage different codebase versions. It also ensures smooth development and deployment processes by facilitating branching, merging, and code reviews, all within a centralized system like Git Azure DevOps.
Key benefits of using Repos in D365 F&O development
- Collaboration
Multiple developers can work on the same codebase simultaneously, each making changes on their own branch and merging them into the main codebase to avoid conflicts.
- Version control
Track every change made to the code, allowing you to revert to previous versions if needed easily.
- Code review process
Enable team members to review each other’s code changes before merging them into the main branch, improving code quality.
- Branching strategies
Create different branches for development, testing, and production environments. This allows for isolated testing and deployment of new features without affecting the live system.
- Automated build and deployment
Integrate with CI/CD pipelines in Azure DevOps to automatically build, test, and deploy code changes to different environments based on commits to the repo.
- Git as the preferred version control system
Most modern D365 F&O development teams use Git as the underlying version control system within their repos, due to its flexibility and popularity.
- Branching strategy
Choosing a suitable branching strategy (like feature branching, trunk-based development) is crucial for efficient collaboration and managing different code versions.
Importance of Git
Git is a modern, distributed version control system that is critical in today’s software development practices. It allows developers to work independently with a complete copy of the codebase, enabling faster performance and offline access. Git simplifies collaboration by supporting efficient branching and merging, which helps teams develop features, fix bugs, and experiment safely without affecting the main codebase.
It also provides detailed history tracking, making it easy to audit changes and roll back if necessary. Widely integrated with DevOps tools and CI/CD pipelines, Git ensures smooth automation of build, test, and deployment processes. Its open-source nature and strong community support have made Git the industry standard for version control.
Use of Git fetch, pull, push, and sync for version control in Visual Studio
- Fetch
It is important to fetch and pull before you push. Fetching checks for any remote commits you should incorporate into your local changes. If you see any, pull first to prevent any upstream merge conflicts. When you fetch a branch, the Git Changes window has an indicator under the branch drop-down, which displays the number of unpulled commits from the remote branch. This indicator also shows you the number of unpushed local commits.
- Pull
Always pull before you push. When you pull first, you can prevent upstream merge conflicts.
- Push
When you create commits, you have inherently saved local code snapshots. Use Push to push the commits to GitHub, where you can store them as backups or share your code with others.
- Sync
You push commits if your local branch is behind the remote branch. If you try to push, a dialog prompts you to pull before pushing.
Use this operation to both pull and then push, sequentially.
Azure DevOps Git vs TFVC
| Key Points | TFVC | Git |
| Architecture | Centralized Version Control System (CVCS) | Distributed Version Control System (DVCS) |
| Repository Structure | A single centralized repository | Each developer has a full copy of the repository |
| Branching Model | Heavyweight, branching is less frequent | Lightweight, branching is fast and encouraged |
| Offline Work | Limited offline capabilities | Full offline capabilities |
| Performance | Slower due to network dependency | Faster due to local operations |
| Merging | More complex merging process | More flexible and efficient merging |
| Storage Model | Tracks changes per file | Tracks changes per commit (snapshot-based) |
| Collaboration | Developers check in changes to a central server | Developers commit locally and push to a shared repository |
| Learning Curve | Easier for beginners | Fine-grained permission control at the file and folder level |
| Security & Access Control | Fine-grained permission control at file and folder level | Permissions are typically repository-wide |
| Use Case | Best for large enterprises with strict control | Ideal for open-source and distributed teams |
Comparable actions in TFVC and Git
| TFVC | Git | |
| Map Code | ⟷ | Clone |
| Check In | ⟷ | Commit, Push |
| Code Review | ⟷ | Pull Request |
| New Branch | ⟷ | Fork |
| Get Latest | ⟷ | Pull |
Git review process
Git configuration
Let’s begin with the practical part of Git configuration and its usage. Setting up Git correctly is the first step to ensuring smooth collaboration, version control, and code management in your development workflow. In this section, we’ll walk through how to configure Git on your machine, set global settings like username and email, and understand how these configurations help manage your commits and contributions effectively.
- Create a new repository.
- Select Git as your repository type and select the check box “Add a README.”
- After creating the repo, click the clone button to clone the repo locally.
- Select Visual Studio from the IDE option.
- Copy the clone URL of the repository.
- Click on the clone repository option from Visual Studio.
- Paste the clone URL in the repository location section and click on the clone button.
- Cloning the repository from the server to your local machine.
- Click on the Git repository button under the Team Explorer tab. Right-click on the main branch and click on New local branch.
- Enter the name of the local branch and click “create.” Your local branch will then be created and shown under the branches section.
- Create a new model.
- Copy the newly created model.
- Copy and paste the new model into the metadata folder of the local repos.
- Open a command prompt and write a make link command to make the link.
- The link of the model has now been created successfully in AOSService.
- Create a new project.
- To commit the newly created model and project to the local branch, click on the Git changes tab. Select the local branch, add the model and project files in the staged changes section, and commit the initial commit. The initial commit has been checked into the local branch.
- To see the history of the local branch, select the local branch and view the history tab.
- After committing an initial check-in, right-click on the local branch and then click on push. This action saves the commit as a local snapshot.
- You can see the newly created local branch on Azure.
- To create a pull request for the initial commit, right-click on the local branch and then click on “create pull request.” A pull request is used to merge the code from one branch to another branch.
- Verify the artifacts that need to be added to a pull request, and after giving the pull request a name, click on the create button.
- To view the pull request on Azure, select the pull request tab.
- After verifying the elements, click on pull request and then the complete button to merge the initial commit from the local branch to the main branch or default branch.
- This dialogue box will open after clicking on the complete button of the previous image. In this dialogue box, select merge as the merge type and select the “complete associated work items after merging” option. And click on the complete merge button.
- Verify the results by viewing the main branch.
Work with Git
After the initial commit, the configuration part of Git has been completed. Now, see the commit for the very first task. Take a runnable class as an example.
- Create a class and then go to the Git changes. In the staged changes section, take a class, and after giving the name of the commit, click on commit staged.
- Right-click on the local branch and click on push.
- Right-click on the server local branch, select create pull request, and then create the pull request.
- After creating a pull request, click Complete the pull request.
- Click on complete merge.
- To verify the result, go to the main branch and find the elements of the recent pull request.
Migrate repositories from TFVC to Git
You can migrate code from an existing TFVC repository to a new Git repository within the same organization.
Why migrate from TFVC to Git?
Over the past several years, we added no new features to Team Foundation Version Control (TFVC). Git is the preferred version control system in the Azure DevOps Git Repository. Furthermore, all the improvements we made in the past few years regarding security, performance, and accessibility were only made to Git repositories. We have seen a continuous decline in the usage of TFVC over these years. A few customers still use TFVC, and we do not plan to remove this feature set for those customers. However, we plan to phase out TFVC in all new projects and organizations or projects that do not currently use it.
As a step in that direction, we will introduce a setting to “Disable creation of TFVC repositories.” It only changes the creation of new TFVC repositories; existing ones have no impact. The setting is available at the organization and project levels; the organization setting has a priority over the project level. By default, the toggle will be enabled. This means you can no longer create TFVC repositories in these new projects. But if you have a strong reason, you can have your administrator turn off the toggle. We will not allow you to turn off the toggle in the future.
Prerequisites of the migration
Before beginning the method of importing the repository, numerous prerequisites need to be met to facilitate migrations:
- Only a single branch is migrated. When planning the migration, we should use a new branch strategy for Git.
- Import only the latest version of the source control. You can optionally migrate some history, up to 180 days.
- Your repository does not have binary assets like images and scientific data. These assets should use the Git LFS (large file support) extension, which the import tool does not configure.
- The imported repository cannot exceed 1 GB in size.
Migrate repositories from TFVC to Git
The process to migrate from TFVC is simple:
- Create a new repository where you’d like to store the code for migration.
- Select Git as your repository type and unmark the “add a README” option for the migration.
- Click on the Import button under the Import a repository
- Select the type TFVC and give the repository path with the branch. ($/Repository/Branch). If you also want to migrate history, mark the migrate history check box ‘yes’ and enter the history up to 180 days.
- The migration procedure will begin after you click the Import button.
- The migration has been completed successfully.
- It takes a while to finish, and then the outcome is shown. Click on the Contents button to view the items in that moved repository.
- It takes a while to finish, and then the outcome is shown. Click on the History button to view the history of that repository.
Conclusion
Successfully transitioning from TFVC to Git within Microsoft Dynamics 365 F&O environments is a foundational step toward building a more agile and future-ready DevOps setup. By adopting Git, development teams gain better control over versioning, enable seamless collaboration, and accelerate delivery cycles through modern branching strategies and CI/CD integration.
At Confiz, we’ve helped organizations streamline their version control practices by aligning the right tools with proven methodologies. Our experience shows that careful planning, hands-on configuration, and team enablement are key to unlocking Git’s full potential in enterprise environments.
If you’re looking to modernize your DevOps workflows or need expert guidance with Git implementation, contact us at marketing@confiz.com.
