Using a combination of these techniques we could easily reduce the amount of stale branches, and then provide the remaining list to the team to have them clean-up the dredges. It’s important to recognize this only includes the completed PRs, not the active or abandoned. This is roughly a 40% reduction, and I’ll take that for now. query "." –f $result.updateStatus)Īt first glance, this would remove about 50% of the remaining branches in our repository, leaving us with 10-20% recent branches and an additional 30-40% of branches without PRs. We can find the authors for the branches with the following PowerShell + Az DevOps CLI: $project = "" Simply track down the branch authors and ask them to determine if they’re done with them. One approach to cleaning-up stale branches is the old fashion way: nagging. If we want to run this from a pipeline, we would have to grant the Build Service the same permissions. See my last post on ways to apply this policy programmatically. You’ll need the “ Force push (rewrite history, delete branches and tags)” permission to delete the branch. You can change the default setting by adding the appropriate user or group to the repository’s permissions and the existing branches will inherit. If you don’t have permission, the option isn’t available to you in the user-interface, and this creates a missed opportunity to remediate the issue when someone other than the author completes the PR. In Azure DevOps, the default permission settings set up the creator of the branch with the permission to delete it. One of the reasons branches don’t get deleted might be a permissions problem. Finding branches that have completed Pull-Requests. Finding the Last Contributor to a Branch.This also opens up the possibility of running these activities in a PowerShell script in an Azure Pipeline, as outlined in my previous post. I want to use the Azure DevOps CLI and REST APIs for this instead of git-centric commands because I want to be able to run the scripts from any computer against the latest version of the repository. What’s the best way to find which branches can be safely deleted? This post will explore some approaches to find and delete stale branches.Īs there are many different ways we can approach this, I’m going to start with the most generic concepts and build up to a more programmatic solution. Please see the example below.If you have pull-requests, you likely have stale branches. To delete a tag remotely you need to use -delete option with push. If left to accumulate, these stale references might make performance worse on big and busy repos. The reason being Git has a default disposition of keeping data unless it’s explicitly thrown away this extends to holding onto local references to branches on remotes that have themselves deleted those branches. But just to cross check you'll run git tag -l to find A & C, but the result is again not what you're expecting. So you run git fetch or git pull which would sync all your remote changes. The next thought that comes to your mind would be to sync your repository with a remote one. The next day when you're working on your local repository and you want to check the tags available in this repository you type in git tag -l which will list A, B, C, D, E. And it also synched these tags with our remote repository but suddenly you felt that the tags B, D & E are not required. Now lets consider a repository which has some tagged commits A, B, C, D, E. You work on a local cloned repository on your macOS and push commits to remote repository, i.e. Let’s say you're are a programmer working on some project in GitHub. Your git repository will now be clean with only branches that have a remote tracking branch. git branch -vv | grep 'origin/.\*: gone]' | awk '' | xargs git branch -d
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |