Frequently Asked Git Questions

First, make sure you have an origin repository configured. You should have such a repository if you cloned git clone) your repo. When you check out a branch that doesn't exist locally, Git determines if there's a remote branch with the same name. If there is, Git creates a local branch with a reference to the remote branch of that name. Use git pull to download the commits and have Git catch up on the branch history locally.

git branch with no arguments shows the local branches and highlights the ones 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.

Accepted practice is to make separate commits for logically separate changes. Think of commits as entries in a logbook. Whenever you make a change that's worth noting, record it in a commit. A popular option is to allow everyone to commit locally as much as they want, but before they push the local commits, they squash them first through rebasing. This option provides users with flexibility to make frequent commits, while keeping the commit history streamlined.

Large projects with many commits and a range of contributors can result in commit histories for the main branch that represents the development history of the topic branches merged into main more than the development history of the overall project. Git provides a facility for condensing commits on branches through squashing commits and rebasing. When you squash commits, the commit history on a branch becomes less verbose, which makes for a simpler 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 foo.js -L 20,+40  # show the blame output for the next 40 lines starting at line 20

215d1108 (Francis Totten 2015-11-21 09:54:23 -0800 20) line 20 of the code
215d1108 (Francis Totten 2015-11-21 09:54:23 -0800 21) line 21 of the code
215d1108 (Francis Totten 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 will show a complete commit history for that file on the current branch.

Checking out to a different branch in Git will affect 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.

Sometimes you want to keep the changes, but not commit them because they aren't at a point where you're comfortable doing so. Use Git stash. Stash takes the current staged and unstaged changes in your branch and saves the work, then returns your branch back to the state of the last commit. You can change to the other branch, do your work, then when you return to this branch 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 will be applied to your current branch. If there's a conflict applying the stashed changes, stash will restore the changes for the files that don't conflict and create conflict markers in the files that do conflict for you to resolve. 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 doing so requires more manual manipulation as you have to explicitly apply and drop stashes. Learn more from Git Stash documentation.

By default, command-line Git will use 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 "frank@fabrikam.com"
> git config --global user.name "Francis Totten"

The --global option will set 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.