Skip to main content

Posts

Showing posts with the label Git

Azure Pipelines–Failed to set a git tag

I mostly use the built-in functionality to set a tag on a specific commit after a successful release. However, in this case I was contacted by a colleague who was using the Git Tag task . Unfortunately, he couldn’t get the task working. A look at the build log made it obvious what the problem was: Starting: GitTag ============================================================================== Task         : Git Tag Description  : A simple task that tags a commit Version      : 7.0.0 Author       : ATP P&I IT Help         : tags the current commit with a specified tag. ### Prerequisites * Repository must be VSTS Git. * Allow scripts to access Oauth must be **Enabled** * Project Collection Build Service must have **Contribute** & **Create Tag** set to **Allow** or **Inherit Allow** for that particular repository =======...

Checkout a Git repository using a tag in VSCode

If you're working with Git repositories in Visual Studio Code, you might occasionally need to checkout a specific tag—perhaps to review a previous release, test an older version, or understand how the codebase looked at a particular milestone. While VSCode's built-in Git integration is powerful, checking out tags wasn't immediately obvious to me. Let me walk you through the process. What are Git tags? Before diving in, a quick refresher: Git tags are references that point to specific commits in your repository's history. They're commonly used to mark release points (like v1.0.0, v2.1.3, etc.). Unlike branches, tags are meant to be immutable snapshots of your code at a particular moment in time. Checkout a Git tag in VS Code Method 1: Using the Command Palette The quickest way to checkout a tag in VSCode is through the Command Palette: Open the Command Palette by pressing Ctrl+Shift+P (Windows/Linux) or Cmd+Shift+P (Mac) Type "Git: Checko...

Azure DevOps( Server) –Check repository health and usage

Azure DevOps offers a repository health feature, which allows to monitor multiple metrics that contribute to the health of your Git repositories. If you are using Azure DevOps services, you maybe already know this feature. But with the latest release of Azure DevOps server (December 2025) , it finally arrived on-premise as well. Reasons enough to have a deeper look at it and write this post. Let’s dive in! Why is this feature relevant for my team? Think of your Git repository like a living organism. As it grows with more commits, blobs, branches, and objects, it can become sluggish and unwieldy. Large repositories increase the load on Azure DevOps infrastructure, affecting performance and user experience. Without proper maintenance, your team could face slower clone times, degraded git operations, and even service disruptions. The repository health feature now provides visibility into key health metrics and offers actionable recommendations before problems escalate. Getting t...

Background agents in GitHub Copilot

A while ago I blogged about how we could setup our own multi-agent workflow by using Git worktrees. With Git worktrees you can setup a branch as a separate folder. If you combine this with the GitHub Copilot CLI you could have multiple agents all working simultaneously on multiple branches while you can continue development as well. Although the process I described works quite well, it remained somewhat cumbersome and was not well integrated into the VSCode development experience. Not anymore with background agents… The problem with foreground-only agents By defaullt, the Copilot agent operates in the foreground. When you ask Copilot to refactor a function or write tests, you're essentially blocked until the task completes. Your editor is locked into that conversation, that context, that task. This works fine for quick queries, but what about: Running comprehensive test suites while you continue development Refactoring an entire module while you work on a new featu...

Understanding your project architecture and how it evolves over time using Gource

Have you ever wanted to see your project's Git history come to life? Gource is a fantastic tool that transforms your commit history into a mesmerizing animated visualization, showing how your codebase grows and evolves over time. It's like watching a time-lapse of your project's development, with files appearing, changing, and moving as contributors work on different parts of the code. But Gource is more than just eye candy. I like to use this tool to spot architectural patterns, identify hotspots where code changes frequently, understand how the team collaborates, and even detect potential coupling issues before they become problems. It's a powerful lens for understanding not just what a team has built, but how they've built it. In this post, I'll walk you through everything you need to know to create your first Gource visualization and use it to gain valuable insights into your codebase's architecture. What is Gource? Gource is an open-source vis...

Git worktrees–A first step towards a multi-agent development workflow

As AI coding assistants become more sophisticated, we're approaching a future where multiple agents might work on different parts of your codebase simultaneously. But there's a challenge: how do you let multiple processes work on the same repository without constantly stepping on each other's toes? One solution is to have agents work on dedicated machines like GitHub Copilot Agent does in a GitHub Codespace. But what if you want to have multiple agents working on your local machine? Enter git worktrees – a powerful Git feature that's been hiding in plain sight since 2015, and the perfect foundation for multi-agent development workflows. What are Git worktrees? Git worktrees allow you to check out multiple branches from the same repository simultaneously, each in its own directory. Think of it as having multiple working directories all sharing the same Git history, but each can be on a different branch. Here's the key insight: while the working directories...

Using Personal Access Tokens(PAT) to clone Azure DevOps Git Repositories

When working with Azure DevOps repositories, Personal Access Tokens (PATs) offer an alternative to traditional authentication. Although I would not recommend them for general usage, there are some scenario's where a PAT is a secure option providing security through scoped permissions, expiration dates, and the ability to revoke access without changing your primary credentials. I had a situation where I needed to clone a set of GIT repositories and run a scan on each repository. As the script would be running for a long time I thought it would be better to create and use a PAT instead of my own account. Creating a Personal Access Token (PAT) Sign in to your Azure DevOps organization Click on your profile icon in the top right corner Select "Personal access tokens" Click "+ New Token" Configure your token: Give it a meaningful name Set an expiration date Select the organization Under "Scopes," ...

Untrusted GIT repositories in Visual Studio

For security reasons I am switching to a different account on my development machine. After adding this new account to Windows and setting up the Visual Studio configuration for this new account, I thought I was good to go. So I opened a first solution inside my fresh Visual Studio instance. Everything looked OK at first sight, but then I noticed a small warning message at the right bottom corner of my Visual Studio: And when I took a look at the Git Changes window, no changes were shown:   What is going on? Starting from Git v2.35.2 , Git now checks for ownership of the folder trying to ensure that the folder you are using Git in has the same user as the owner as your current user account. As the original Git repo(and corresponding Windows folders) was created using a different account, Git considers this repository as unsafe. This check was introduced in Git to tackle a security issue which allows parent repositories directories to override permissions of child reposi...

Speed up your Git experience by enabling the commit graph algorithm

While working in Visual Studio today I noticed a message appear at the top my idea. The message stated the following: Speed up your git experience in Visual Studio by enabling the git commit graph algorithm. No idea what that exactly means but that sounds promising… so let’s find out Why this commit graph algorithm? Git repositories can become sluggish as they grow in size and complexity. If you've ever waited impatiently for git log to load or noticed that branch operations take longer than they should, you're not alone. Recently, Git introduced a powerful feature that can dramatically improve performance: the commit graph algorithm. The commit graph is a data structure that Git uses to store precomputed information about your repository's commit history. Instead of traversing the entire commit tree every time you run commands like git log , git merge-base , or git show-branch , Git can use this precomputed graph to answer queries much faster. Think of it ...

Git cherry-picking

Git is my 'go-to' version control tool for a long time. I switched from SVN & TFVS (Team Foundation Version Control) a long time ago and never looked back. One feature that I used sometimes in TFVC was the cherry-pick feature but since I started using GIT I never used cherry-pick anymore. Until today... What is cherry-picking? Cherry-picking refers to the process of selecting a specific, individual commit from one branch and applying it to another. Unlike merging or rebasing entire branches, cherry-picking lets you choose exactly which changes you want to incorporate. Think of it as picking cherries from a tree (hence the name): instead of harvesting all the fruit, you carefully select only the ripest, most desirable ones. When to use cherry-picking? I have some bad memories from using cherry-picking in TFVC as it was used a lot as a poor mans alternative to a good versioning strategy. But there are some scenarios where cherry-picking can be useful: Backpor...

Github- Create a new release–The manual approach

Being new to Github I decided to write a few post on how to create a new 'release' in Github. I'll start with a 100% manual approach(this post) and will continue with other posts showing a more and more automated process. But today we'll start simple and focus on creating a release by hand. This allows me to introduce the different elements that we can configure when using releases inside Github, knowledge that will be useful later when we go the automated route. Let’s dive in… Creating a new release (manually) Before you can create a release, make sure you are signed in to your GitHub account. Navigate to the repository where you want to create the release. Once you’re in the repository, click on Releases on the right of the list of files.   On the Releases page, you’ll see a button labeled “ Draft a new release .” Click on it to start creating your new release.   The first thing you need to do is to assign a tag to your release. A tag is usuall...

Git–Dubious ownership

Today I had a strange Git error message I never got before. When I tried to execute any action on a local Git repo, it fails with the following error: git status fatal: detected dubious ownership in repository at 'C:/projects/examplerepo' 'C:/projects/examplerepo' is owned by: 'S-1-5-32-544' but the current user is: 'S-1-5-21-1645522239-329068152-682003330-18686' To add an exception for this directory, call: git config --global --add safe.directory C:/projects/examplerepo Image generated by AI What does this error mean and how can we fix it? Let’s find out! This error means that the current user is not the owner of the git repository folder. Before git executes an operation it will check this and if that is not the case it will return the error above. The reason why this check exists is because of security reasons. Git tries to avoid that another user can place files in our git repo folder. You can check the owner of a directory by executing ...

Git–Discard local changes

Git offers a wide range of possibilities to discard local changes. In this post I like to share some of the available options. Before I dive into the details, it is important to make the distinction between untracked and tracked files. From the documentation : Git has something called the "staging area" or "index". This is an intermediate area where commits can be formatted and reviewed before completing the commit.   Untracked files live in the git working directory but are not managed by git until you stage them. Tracked files Here are some options to discard changes in tracked files: Discard Changes in a Specific File: If you want to discard changes in a specific file, you can use the following command: git checkout -- filename This will replace the changes in the specified file with the last committed version of that file. Discard Changes in All Modified Files: To discard changes in all modified files in the wo...

AKS–The single biggest reason why you should apply a GitOps approach

GitOps is an approach to software delivery that uses Git as a single source of truth for declarative infrastructure and application deployment. With GitOps, all changes to infrastructure and applications are made through pull requests that are reviewed and approved before they are applied to the target environment. This approach offers several benefits, including improved visibility, traceability, but the single biggest reason why you should apply a GitOps approach is (enhanced) security compared to a traditional Continuous Delivery approach. Flux In Azure you can use GitOps in Azure Kubernetes Service (AKS) and Azure Arc-enabled Kubernetes clusters.Behind the scenes this uses Flux , a popular open-source tool set. Flux provides support for common file sources (Git and Helm repositories, Buckets, Azure Blob Storage) and template types (YAML, Helm, and Kustomize). GitOps vs traditional Continuous Delivery(CD) In a traditional CD setup, the CD tooling is running outside the AK...

Azure DevOps Server- Update Git credentials

Oh no, after writing a lot of posts about what I thought would be an easy operation, I'm back again with a last follow up post on moving an Azure DevOps Server instance from HTTP to HTTPS. If you missed the previous posts: Azure DevOps Server–Switch from HTTP to HTTPS–Part 1 – IIS changes Azure DevOps Server–Switch from HTTP to HTTPS–Part 2 – Version Control changes Azure DevOps Server–Switch from HTTP to HTTPS–Part 3 – Build changes Azure DevOps Server–Switch from HTTP to HTTPS–Part 4 – NuGet changes In this last post(I really promise) I want to talk about Git Credential Manager . Git Credential Manager simplifies authentication with your Azure Repos Git repositories. Credential managers let you use the same credentials that you use for the Azure DevOps Services web portal. It can be installed as part of Git for Windows and thanks to it you don’t need use SSH keys or Personal Access Tokens to connect to your Azure DevOps G...

Visual Studio –Git line staging

Visual Studio supports staging files from the moment Git support was introduced and most of the time that is sufficient. But sometimes it can be useful to stage chunks of changes in a file instead of a complete file. This feature (also known as interactive staging) was introduced in Visual Studio 2022 v17.2. I never used the feature before so let's see how this works... Git line staging is still marked as a preview feature but if you are using Visual Studio 2022 v17.2 or higher, it should be enabled by default. The first thing you should notice when line staging is enabled, is that individual changes are visible in the editor margin. Added, edited or deleted lines are all shown using a different color and annotation: If we now click on a color margin, an inline Peek Difference view is opened. Now you can  stage the selected change by clicking on the + Stage Line <LineNumbers> button: You can also select one or more lines in the Peek Difference view, right...