howto.yml

### YamlMime:FAQ
metadata:
  title: Git frequently asked questions
  titleSuffix: Azure Repos
  description: Find answers to frequently asked questions about Git in Azure Repos, including branch management, commit practices, proxy and SSL configuration, and authentication troubleshooting.
  ms.service: azure-devops-repos
  ms.topic: faq
  ms.date: 04/21/2026
  ai-usage: ai-assisted
  monikerRange: '<= azure-devops'  
  ms.subservice: azure-devops-repos-git
title:  Git FAQs 
summary: | 
  [!INCLUDE [version-lt-eq-azure-devops](../../includes/version-lt-eq-azure-devops.md)]

  Find answers to frequently asked questions about using Git with Azure Repos, including branch management, commit practices, configuration, and troubleshooting clone, push, proxy, SSL, and authentication issues.
sections:
  - name: Ignored
    questions:
      - question: |
          How can I easily download a remote branch to my local repository?
        answer: |
          First, verify that you have an `origin` repository configured. If you cloned your repo with [`git clone`](clone.md), 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.
                
      - question: |
          How can I find out which branch I'm working in?
        answer: |
          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.
      
      - question: |
          When should I make Git commits?
        answer: |
          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](rebase.md) before pushing. This approach provides flexibility while keeping the commit history streamlined.
                
      - question: |
          If every branch retains its full commit history, doesn't that make the commit history of *main* hard to follow over time?
        answer: |
          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](rebase.md). Squashing commits simplifies the branch history and produces a cleaner main branch after you merge.
      - question: |
          How can I find out who made a specific change to a file?
        answer: |
          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.
          
          > [!Div class="tabbedCodeSnippets"]
          ```Git CLI
          > 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.
          
      - question: |
          I made changes to some files and now I can't check out to a different branch or rebase my work.
        answer: |
          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](undo.md) for instructions on rolling back to the most recent commit.  
          - Commit the changes. See [saving your work in Git with commits](commits.md). 
          - [Stash](howto.yml#i-did-some-work-but-need-to-switch-to-something-else--how-can-i-save-my-work-for-later-without-committing-the-changes-) your current work to save the changes for later and reset the workspace to the last commit.

      - question: |
          Pull request is unable to merge with this message: 'Unable to merge automatically: One of internal git objects (blob, tree, commit, or tag) is too large, which caused TF401022 exception. You can try to use LFS, split your merge or large commit into several small.'
        answer: |
          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.
      
      - question: |
          I did some work but need to switch to something else. How can I save my work for later without committing the changes?
        answer: |
          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 CLI
          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](https://git-scm.com/book/en/v2/Git-Tools-Stashing-and-Cleaning).
          
      - question: |
          How can I change the default editor for Git command-line tools?
        answer: |
          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`:
          
          > [!Div class="tabbedCodeSnippets"]
          ```Git CLI
          > git config core.editor _path_to_editor_ _options_to_editor_
          ```
          
          Git for Windows makes it easy to set Notepad as the editor:
          
          > [!Div class="tabbedCodeSnippets"]
          ```Git CLI
          > 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:
          
          > [!Div class="tabbedCodeSnippets"]
          ```Git CLI
          > git config format.commitMessageColumns 72 
          ```
          
          This setting wraps commit message text at the preferred 72-character column width.
          
      - question: |
          How can I change the username and email displayed in my commits?
        answer: |
          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:
          
          > [!Div class="tabbedCodeSnippets"]
          ```Git CLI
          > 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**.

      - question: |
          How can I troubleshoot Git clone or push failures?
        answer: |
          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](https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables).

      - question: |
          How do I configure Git to connect through a proxy server?
        answer: |
          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:

          > [!Div class="tabbedCodeSnippets"]
          ```Git CLI
          > git config --global http.proxy http://proxyUsername:proxyPassword@proxy.server.com:port
          ```

          To configure a proxy for a specific URL only:

          > [!Div class="tabbedCodeSnippets"]
          ```Git CLI
          > git config --global http.https://dev.azure.com.proxy http://proxyUsername:proxyPassword@proxy.server.com:port
          ```

          For more information, see [Git config documentation](https://git-scm.com/docs/git-config).

      - question: |
          How do I fix authentication errors when cloning or pushing to Azure DevOps?
        answer: |
          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:

          > [!Div class="tabbedCodeSnippets"]
          ```Git CLI
          > 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:

          > [!Div class="tabbedCodeSnippets"]
          ```Git CLI
          > 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.

      - question: |
          How do I fix SSL certificate errors when connecting to Azure DevOps Server?
        answer: |
          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:

          > [!Div class="tabbedCodeSnippets"]
          ```Git CLI
          > git config --global http.sslBackend schannel
          ```

          For more information about configuring the SSL backend in Visual Studio, see [Git settings - Cryptographic network provider](git-config.md).

          **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:

          > [!Div class="tabbedCodeSnippets"]
          ```Git CLI
          > 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.

          > [!WARNING]
          > Avoid setting `http.sslVerify` to `false` except for temporary testing. Disabling SSL verification removes protection against man-in-the-middle attacks.

          For pipeline agent scenarios with self-signed certificates, see [Run a self-hosted agent behind a proxy or with self-signed certificates](../../pipelines/agents/certificate.md).

additionalContent: |

  ## Related content
  
  - [Azure Repos Git documentation](index.yml)
  - [Clone an existing Git repo](clone.md)
  - [Save your work with commits](commits.md)
  - [Use Git branches](./create-branch.md)