Git FAQs

First, verify that 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 and produces a cleaner main branch after you merge.

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 showing the commit that last updated each line and the author of that change.

> 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. 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 you want to examine. 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 make sure your working directory matches the selected branch. If you try to change branches while you have uncommitted changes, those changes get overwritten during checkout. To prevent accidental data loss, Git blocks the checkout. You have the following options:

• Abandon the changes and return to the most recent commit. See undoing changes in Git for instructions on rolling back to the most recent commit.
• Commit the changes. See saving your work in Git with commits.
• Stash your current work to save the changes for later and reset 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 any files conflict, stash restores the nonconflicting files and creates conflict markers in the remaining files. Resolve any conflicts manually.

When you no longer need the stash, delete it with git stash drop. This command removes the most recent stash.

You can have multiple stashes, but you must explicitly apply and drop each one. For more information, see the Git Stash documentation.

By default, Git uses a command-line editor when it prompts for commit messages, performs rebases, and handles other tasks that require input. 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 handle Git text editing. You can also specify a preferred column width for commit messages:

> git config format.commitMessageColumns 72 

This setting wraps commit message text at the preferred 72-character column width.

Git includes a username and email address in each commit, and Azure Repos uses this information when it displays commits and pull requests. To update the name and email 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, navigate to the repository directory 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.

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 determine whether the failure relates 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 Windows trusts your server's certificate or CA, 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.

Related content

• Azure Repos Git documentation
• Clone an existing Git repo
• Save your work with commits
• Use Git branches