Git FAQs

First, ensure you have an origin repository configured. You should have this if you cloned your repo using git clone. When you check out a branch that doesn't exist locally, Git checks if there's a remote branch with the same name. If there is, 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've checked out. In Visual Studio, the status bar also displays the current branch when you're working with a project stored in a local Git repository.

It's best practice to 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 provides flexibility while keeping the commit history streamlined.

Large projects with many commits and contributors can result in a main branch history that reflects the development of topic branches more than the overall project. Git allows you to condense commits on branches through squashing commits and rebasing. Squashing commits makes the branch history less verbose, simplifying the commit history on the main branch once merged.

Use the git blame command to find out who made a particular change to a file. From your local repository, you can run git blame with the -L parameter, specifying which lines of interest. Blame produces formatted output showing 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 to a different branch in Git affects the state of files on your file system. Git uses the commit history to make sure you're working with the files that represent the state of your branch. If you try to change branches while you have uncommitted changes, those changes would be overwritten during checkout. Because Git doesn't want you to accidentally lose your changes, it prevents the checkout from happening. You have two 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 is related to merge conflicts in large binary files. The current limit for files is 100MB. The workaround is to resolve merge conflicts locally by merging the target into the source locally, resolving conflicts, and pushing the changes.

Git LFS (Large File Storage) is recommended for storing large binary files, not only to avoid conflicts but also to manage overall repository size, which affects clone and push times.

If you want to save your changes without committing them, use Git stash. Stash saves the current staged and unstaged changes in your branch and reverts your branch to the state of the last commit. You can then switch to another branch, do 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 get applied to your current branch. If there's a conflict, [stash] restores the changes for the files that don't conflict and creates conflict markers in the files that do. You should merge the changes manually in this case.

Once you're done 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 manipulation as you have to explicitly apply and drop stashes. Learn more from the Git Stash documentation.

By default, command-line Git uses a command-line editor when asking for commit messages, performing rebases, and other work that requires additional information to complete. The default editor is configured using 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 properly pass through the text from Git to Notepad. You can also specify

> git config format.commitMessageColumns 72 

To keep the text columns in the commit messages to the preferred 72 and line wrap after hitting that character limit on a line.

Git puts a user name and email address information inside each commit, and Azure Repos uses this information when viewing commits and when working with pull requests. If you're working on the command line, you can update the name and email information displayed using 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. If you want to change the settings for a single repository, you must change to the directory where the Git repository is located and run the above 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 provides a Git version control experience while maintaining the Team Explorer Git user interface. To use Team Explorer, uncheck Tools > Options > Preview Features > New Git user experience from the menu bar. You can exercise Git features from either interface interchangeably.

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