In this writing, I like to aim to elucidate the distinctions between deleting and not-deleting sub-branches after squash_merge commit within the realm of Azure DevOps. Throughout this exploration, I deliberately tasked different users with creating sub-branches and committing changes to the main branch. Additionally, I configured branch policies to include two reviewers, and allowing the requestors to approve their own changes.
Commencing the journey!
To begin, incorporate users into the project within Azure DevOps.
When contemplating the choice of access level, consult the following guidelines, that I learned from the link,
Basic Access:
Who Gets It: Users with Visual Studio Professional subscription or an Azure DevOps Server CAL.
What It Offers: This level opens the door to most features, making it suitable for those with a paid subscription or specific access needs within the organization.
Stakeholder Access:
Who Gets It: Unlimited users for free.
What It Offers: Picture this as the free pass for broad collaboration. It gives partial access to private projects and nearly full access to public projects. Ideal for users without licenses or subscriptions who still need to dive into a set of features.
Visual Studio Subscriber Access:
Who Gets It: Users with an existing Visual Studio subscription.
How It Works: The system automatically identifies their Visual Studio subscription level (Enterprise, Professional, Test Professional, or MSDN Platform). Upon assigning Basic or Stakeholder access, they not only get those benefits but also unlock any additional features included in their subscription.
Finally, I added some new users.
Configure a branch policy.
Log in with using different user ID.
Create a sub-branch.
Make some changes in the sub-branch and commit the changes to the sub-branch. The changes in the sub-branch are shown like below.
I am still in the different user environment, and create PR (Pull Request) to main branch.
As described below, the branch policy is applied.
Log in as a project owner, and approve the pull request .
Complete the pull request.
As the project owner finalizing the pull request on behalf of another user, the option "Delete sub_branch after merging" is unavailable for me to click.
Sign in with another user's ID. As outlined below, the sub-branch remains undeleted and is NOT up-to-date compared to the main branch.
To ensure it is current compared to the main branch, follow the process outlined below.
As indicated below, there are no differences—neither behind nor ahead.
Now, let's delve into the process of choosing squash commit and deleting sub-branches after merging.
Generate new changes and commit them.
Create PR (Pull Request)
Approve the changes. Since two reviewers are needed as per the branch policy, the PR (Pull Request) is not yet finish.
Set Auto Complete, and select the option "Squash commit - delete sub branch after merging".
Sign in as the project owner and endorse the Pull Request (PR). With Auto Complete configured, the PR will automatically complete once two reviewers approve it, as illustrated below.
Returning to the alternate user ID, the Pull Request (PR) is successfully completed, as indicated below, and the sub-branch is now deleted.
Pros and Cons of Deleting Sub-Branches Post-Squash_Merge Commit in Azure DevOps:
Pros:
1. Clean History: Deleting sub-branches ensures a cleaner Git history. It simplifies the view by removing redundant branch references, making it easier to navigate and understand the project's development timeline.
2. Reduced Repository Clutter: By removing sub-branches, the repository is less cluttered. This streamlines the repository structure, enhancing its overall organization and reducing the likelihood of confusion for developers.
3. Enhanced Branch Management: Deleting sub-branches aligns with efficient branch management practices. It signifies that a feature or task has been successfully integrated, providing a clear signal to the team about the completion of a development cycle.
Cons:
1. Limited Rollback Options: Once sub-branches are deleted, the option to rollback to a specific branch state is limited. This could be a drawback if there's a need to revert to a previous state for debugging or addressing unforeseen issues.
2. Impact on Collaboration: Deleting sub-branches might impact collaboration if team members rely on branch references for discussions or contextual information. It requires clear communication and documentation to mitigate this potential issue.
Pros and Cons of Non-Deleting Sub-Branches Post-Squash_Merge Commit in Azure DevOps:
Pros:
1. Granular History Tracking: Retaining sub-branches allows for granular history tracking. Each branch represents a distinct development effort, providing a detailed record of changes and facilitating a more comprehensive understanding of the project's evolution.
2. Enhanced Collaboration Context: Non-deleting sub-branches provide a richer collaboration context. Team members can refer to specific branches for discussions, code reviews, and contextual information, fostering a more detailed and collaborative development environment.
3. Facilitates Rollback: Keeping sub-branches intact enables easier rollback to a specific state if needed. This flexibility can be crucial in scenarios where reverting to a previous version becomes necessary.
Cons:
1. Increased Repository Complexity: Non-deleting sub-branches can contribute to repository complexity. With a larger number of branches, it might become challenging to navigate the repository, especially if naming conventions are not consistently applied.
2. Potential for Misinterpretation: Without proper documentation and communication, non-deleting sub-branches may lead to misinterpretation or confusion about the status of specific features. Team members may find it challenging to distinguish completed from ongoing work.
3. Maintenance Overhead: Managing a larger number of sub-branches requires additional maintenance efforts. This includes periodic cleanup, ensuring branches are appropriately labeled, and providing clear documentation to guide developers.
Balancing the decision to delete or retain sub-branches depends on the specific needs and preferences of the development team. Clear communication, documentation, and a shared understanding of the project's version control strategy are essential for a successful implementation.
In summary, the blog post explores the options of deleting and non-deleting sub-branches after a squash_merge commit, highlighting the pros and cons of each approach. And it tells the significance of clear communication and documentation to ensure a seamless and effective workflow in collaborative Power BI development.
I trust this short writing enhances your enjoyment while exploring Power BI Git integration. By understanding the nuances of deleting and non-deleting sub-branches post-squash_merge commit in Azure DevOps, you're better equipped for a seamless collaboration. Remember, clear communication and documentation are your allies in this journey. Embrace the power of version control, and may your Power BI development adventures be both productive and enjoyable!
Comments