If you were to do a file compare between the two branches, there would be no differences in the source files. You see, any time that you do a Merge in Git, it will generate a new commit. When you go back to VSCode and merge main back into dev, you would notice that the source files themselves have not changed, even though Git has created two extra commits just from the Merge actions. The Merge Type of ‘Merge’ created its own commit in the target branch, main in this case. ![]() Wait, what? Didn’t I just merge 2 commits from dev into Main? The purpose of the PR was to synchronize the branches, but it appears that dev now a commit behind main. ![]() When the PR completes, you go back to the Branches view in Azure DevOps, and you notice that the dev branch is 1 commit behind on Main…. The Azure DevOps default Merge Type is set to ‘Merge’ and all looks well, so then I click the ‘Complete Merge’ button. The PR has been approved and I have clicked the ‘Complete’ button on the PR. I’ve committed a couple of changes in dev and I have created a pull request to move that change into the main branch to be released. The main branch requires a reviewer, which in Azure DevOps means that changes can only be made through pull requests. I have a simple project in Azure DevOps, with a repo that has a default branch called ‘main’ and a ‘dev’ branch. In this post I will show you how to limit the number of commits. As you are putting in place branch policies to prevent just anybody from committing changes, you notice a pattern of commits being created just by merging a change into ‘main’. ![]() You have created a ‘dev’ branch to keep work in progress away from the ‘main’ branch, and maybe you are even using feature branches or branches per developer. So you’re evolving your source control practice.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |