Git FAQs

First, make sure you have an origin repository configured. If you cloned your repo with git clone, you already have one. When you check out a branch that doesn't exist locally, Git determines whether a remote branch with the same name exists. If so, Git creates a local branch that references the remote branch. Use git pull to download the commits and update the branch history locally.

Run git branch with no arguments to show the local branches and highlight the one you checked out. In Visual Studio, the status bar displays the current branch when you work with a project stored in a local Git repository.

Make separate commits for logically distinct changes. Think of commits as entries in a logbook. Whenever you make a change worth noting, record it in a commit. A popular approach is to allow frequent local commits but squash them through rebasing before pushing. This approach provides flexibility while keeping the commit history streamlined.

In large projects with many commits and contributors, the main branch history can reflect topic branch development more than overall project progress. You can condense commits on branches through squashing commits and rebasing. Squashing commits simplifies the branch history, which makes the commit history on the main branch cleaner after merging.

Use the git blame command to find out who made a particular change to a file. From your local repository, run git blame with the -L parameter to specify the lines of interest. Blame produces formatted output that shows the commit that last updated the line and the name of the person who made the commit.

> git blame Example_repo -L 20,+40  # show the blame output for the next 40 lines starting at line 20

215d1108 (Example User 2015-11-21 09:54:23 -0800 20) line 20 of the code
215d1108 (Example User 2015-11-21 09:54:23 -0800 21) line 21 of the code
215d1108 (Example User 2015-11-21 09:54:23 -0800 22) line 22 of the code

Blame searches the commit history for you. You can also review a file's history in the web portal to determine who made a change and when. Open Code Explorer for your repository and branch, then select the file of interest. Azure Repos shows a complete commit history for that file on the current branch.

Checking out a different branch in Git affects the state of files on your file system. Git uses the commit history to ensure you work with files that represent the state of your branch. If you try to change branches while you have uncommitted changes, those changes get overwritten during checkout. To prevent accidental loss of changes, Git blocks the checkout. You have these options:

• Abandon the changes and return to the most recent commit. See undoing changes in Git for instructions on how to roll back to the most recent commit.
• Commit the changes. See saving your work in Git with commits.
• Stashing your current work, saving the changes for later and cleaning up the workspace to the last commit.

This issue occurs because of merge conflicts in large binary files. The current file size limit is 100 MB. To work around this issue, merge the target into the source locally, resolve conflicts, and push the changes.

Use Git LFS (Large File Storage) for large binary files to avoid conflicts and manage overall repository size, which affects clone and push times.

To save changes without committing them, use Git stash. This command saves the current staged and unstaged changes in your branch and reverts the branch to the state of the last commit. You can then switch to another branch, complete your work, and later run stash apply to restore your changes.

git stash
Saved working directory and index state WIP on feature1: be26067 updated endpoint docs
HEAD is now at be26067

When you run git stash apply, the most recently stashed changes apply to your current branch. If there's a conflict, stash restores the changes for files that don't conflict and creates conflict markers in files that do conflict. Merge the changes manually in this case.

After you finish with the stash, delete it with git stash drop. This command removes the last set of stashed changes.

You can have multiple stashes, but managing them requires more manual work because you must explicitly apply and drop each stash. For more information, see the Git Stash documentation.

By default, command-line Git uses a command-line editor when it requests commit messages, performs rebases, and carries out other work that requires additional information. Configure the default editor with git config:

> git config core.editor _path_to_editor_ _options_to_editor_

Git for Windows makes it easy to set Notepad as the editor:

> git config core.editor notepad

This command configures Windows Notepad to edit Git information as needed and pass the text correctly between Git and Notepad. You can also specify

> git config format.commitMessageColumns 72 

This setting keeps the text columns in commit messages at the preferred 72-character width and wraps lines at that limit.

Git includes a username and email address in each commit, and Azure Repos uses this information when displaying commits and working with pull requests. To update the name and email information on the command line, use the git config command:

> git config --global user.email "example-user@example-site.com"
> git config --global user.name "Example User"

The --global option sets the email and name included in commits for all Git repositories on this system. To change the settings for a single repository, go to the directory where the Git repository is located and run the preceding commands without the --global flag.

You can also change the name and email settings from Visual Studio. From the Git menu, select Settings. In the Options dialog, select Git Global Settings or Git Repository Settings > General.

Visual Studio 2019 version 16.8 and later versions provide a Git version control experience while maintaining the Team Explorer Git user interface. To use Team Explorer, clear Tools > Options > Preview Features > New Git user experience from the menu bar. You can use Git features from either interface.

In Team Explorer, choose Settings and under Git, select the Global Settings or Repository Settings link.

Enable verbose tracing to get detailed error information. Set the following environment variables before running your Git command:

set GIT_TRACE=1
set GIT_TRACE_PACKET=1
set GIT_CURL_VERBOSE=1

The trace output helps identify whether the failure is related to network connectivity, proxy configuration, SSL certificates, or authentication. For more information about Git environment variables, see Git Internals - Environment Variables.

If you're behind a proxy server and Git isn't configured to use it, clone and push operations fail with 407, 502, or "unable to access" errors.

Run git config --list to check whether a proxy is already configured. If not, set the proxy globally:

> git config --global http.proxy http://proxyUsername:proxyPassword@proxy.server.com:port

To configure a proxy for a specific URL only:

> git config --global http.https://dev.azure.com.proxy http://proxyUsername:proxyPassword@proxy.server.com:port

For more information, see Git config documentation.

If your password changed or cached credentials are stale, Git clone or push operations fail with authentication errors. Reset the Git Credential Manager (GCM) to resolve the issue:

> git config --global --unset credential.helper
> git config --global credential.helper manager

You can also remove cached credentials directly in Windows Credential Manager:

1. Open Control Panel > User Accounts > Credential Manager.
2. Select Windows Credentials.
3. Find and remove entries for git:https://dev.azure.com/<orgname>.

Alternatively, use the command line:

> cmdkey /list | findstr "git"
> cmdkey /delete:git:https://dev.azure.com/<orgname>

On macOS, run git credential reject to clear stored credentials:

echo url=https://dev.azure.com/<orgname> | git credential reject

After clearing credentials, retry the clone or push operation. Git prompts you to reauthenticate.

When you clone or push to an Azure DevOps Server instance that uses a self-signed or internal-CA certificate, Git fails with:

fatal: unable to access '...': SSL certificate problem: unable to get local issuer certificate

Option 1: Use Windows SChannel (recommended on Windows)

Configure Git to use the Windows certificate store instead of its bundled OpenSSL CA bundle. If your server's certificate or CA is trusted by Windows, no further steps are needed:

> git config --global http.sslBackend schannel

For more information about configuring the SSL backend in Visual Studio, see Git settings - Cryptographic network provider.

Option 2: Point Git to your CA certificate

Export your root or intermediate CA certificate as a Base-64 encoded .crt file, then tell Git where to find it:

> git config --global http.sslCAInfo C:/Users/<yourname>/my-ca-cert.crt

You can also append the certificate to Git's existing CA bundle (typically at C:\Program Files\Git\mingw64\etc\ssl\certs\ca-bundle.crt) instead of overriding the entire bundle.

For pipeline agent scenarios with self-signed certificates, see Run a self-hosted agent behind a proxy or with self-signed certificates.