Git Refresher

* * * PLEASE NOTE * * *

?As of June 2020, GitHub now refers to the "master" branch as the "main" branch by default. This will affect some of the commands in this article in reference to newer repositories; however, since most classic repositories will still use the name "master," I am going to leave the commands as is for the time being.

Introduction

While pouring through various Git materials for my work's transition from SVN, I compiled this " Git refresher" for quick reference. There are a lot of great resources out there on the subject, but this is the information I find most useful on a daily basis.

Top resources

• Introduction to Git (Team Treehouse)
• Git Merging and Branches (Team Treehouse)
• Git cheat sheet (GitHub)

Document contents

• Section 1: Basic Git info
• Section 2: Quick Git terminology
• Section 3: Git merge conflict markers
• Section 4: Connect a local Git repo to a remote Git repo
• Section 5: Git commands, arguments, options, and flags

Section 1: Basic Git info

The .git folder

• This file is created in your project when you run git init (this makes it a Git repository.)
• Modifications shouldn't be made to this file manually-- It is automatically updated by Git as it tracks your project's status, progress, and history.
• To blow away a Git repository, delete its .git file. Since this is a hidden file, you may need to pass the "all" flag (-a) in the command line or enable hidden file extensions in your file system to do so.

Git local states

• Modified - changed since last commit
• Staged (added) - ready to be committed
• Committed - ready to be pushed

.gitignore files - These are files in which you can specify what resource(s) should be left out of version control when you interact with a remote repository, like "scratch" files (where you're just trying things out and don't want to commit anything) or anything you wouldn't want someone else to pull down if they were to clone your remote. When you create one in a local Git repo, simply name it .gitignore (no additional name or extension), and most IDEs will recognize it automatically.

Section 2: Quick Git terminology

For the list dedicated Git commands, arguments, options, and flags, see the next section.

• fetch

to connect to and request information from the remote branch regarding where your local branch's status is in relation to its status

If you're up-to-date with the remote repository and main branch (typically "origin" and "master"), you can proceed with pushing to or pulling from it without hesitation. If you are out of sync and behind on commits in relation to the remote repository, you may need to pull and/or merge code before you interact with it further.

• HEAD

the working directory, aka. the branch the repository is currently sitting on

• HEAD (detached)

when a repository is currently pointed to a commit in history rather than the latest commit to the branch

• master

typically the "source of truth" branch for a repository, the one that is kept up to date with the latest production code and production-ready code

When a repository is cloned (becomes a parent), Git will automatically assign the name "master" to the branch it was on when cloned in relation to the new child repository (i.e., the child will refer to this branch as the "master.") This name can be changed, but typically isn't.

• origin

the repository (parent) from which another repository (child) was cloned

When a repository is cloned (becomes a parent), Git will automatically assign the name "origin" to the it in relation to the new child repository (i.e., the child will refer to its parent as "origin.") This name can be changed, but typically isn't.

• upstream (-u)

typically the parent repository (the one from which a local repository was cloned); also can be thought of as the one you push "up" to and the one you pull "down" from

The upstream flag (-u) tells Git that the repository you are issuing the command to is the upstream repository in relation to yours and that it should always be considered so unless explicitly told otherwise. You should only have to pass this flag with name of the repository (typically "origin") and branch (typically "master) once, and from then on you can interact with the upstream repository through regular Git commands without telling it which repository/branch to connect to.

Section 3: Git merge conflict markers

When Git finds merge conflicts, it will mark your code with the following syntax. Git ignores this, but your program probably will not, as it will be read as code. You can manually merge by removing the markers and combining the code in a logical way that satisfies the conflict.

<<<<<<< HEAD

// conflicting code that's in the HEAD branch (working directory)

=======

// conflicting code that's in the master branch (remote directory)

<<<<<<< master

Section 4: Connect a local repo to a remote repo

* Note: These instructions are for use in Visual Studio Code, but the concept should be similar in other IDEs.

1. Create a new, blank project in your local file system using Visual Studio.

• Go to File > Open Folder
• When your File System opens, go to the location you want your project to reside in and create a New Folder.
• Select Open Folder to open the folder as a project workspace in Visual Studio.

2. Create a repo on a source control plaform like GitHub or Azure DevOps (usually with the same name as the local project it will be connected to) to serve as the remote. You can choose to configure this however you want (e.g., by generating a README or .gitignore file, etc.)

3. In Visual Studio, use the following command to initialize the project as a Git repository:

git init

4. In the source control platform housing your remote repo, copy the clone URL.

5. In Visual Studio, use the following command to add the source control repo as a remote on your local. (Tip: Use the shortcut ctrl + ~ to open the integrated terminal.)

git remote add origin <GitHub repo clone URL>

6. Perform a pull from the remote repo to make sure your local has anything that was created in the remote repo (e.g., a README file).

git pull origin master

7. Issue the following command to set up tracking on the remote repository. This will allow you to use commands like push and pull without specifying the remote repo’s name and branch every time.

git branch --set-upstream-to=origin/master

Section 5: Git commands, arguments, options, and flags

The git keyword is an executable command. Commands that follow it are subcommands.

All angle brackets < > in this table contain example or explanatory information. They are not part of the syntax.

• git add

Stages a file

• git branch
• git branch <name of new branch>
• git branch -d <name of branch to delete>
• git branch --set-upstream-to="<origin>/<master>"

By itself, it will list all branches in the current repository (the active branch will have an asterisk (*) next to it). When you specify a branch name, it will create a new branch with that name (based on the branch that you are currently on, which should typically be the master), but you will not be switched to it automatically (see checkout -b, below.) Passing the -d flag with the name of an existing branch will delete that branch.

With the --set-upstream-to option, after you pull from a remote repo for the first time (which will create a master branch in your local to match the master branch in your remote), you will be able to use this command to set the "upstream" source to the remote repo (typically named origin) and its master branch (typically named master). This will make it so you can use commands like git push and git pull without specifying the name and branch of the remote repo your are interacting with each time.

• git config | config user.name "<name>" | config https://www.dhirubhai.net/redir/general-malware-page?url=user%2eemail "<email>"

This allows you to edit Git configurations. A username and email are sometimes required before you can begin interacting with a remote repository that you've cloned from.

• git checkout <name of existing branch>
• git checkout -b <name of new branch>
• git checkout <sha-1 checksum>

When you specify the name of an existing branch, you will be switched to that branch. When you pass the -b flag and the name of a non-existent branch, a new branch by that name will be created, and you will automatically switch to that branch. When you specify a SHA-1 checksum (from any branch in the repository), you will checkout the commit associated with that checksum (note: you don't need the whole sum, just the first 4 characters.)

To get a list of checksums associated with specific commits, either use git log or look in the remote repository's GUI.

• git clone <URL to parent>

Clones a remote (parent) repository to use as a local repository

• git commit
• git commit -m "<message>"

This will move files from the staged state to the committed state, in which it is ready to be pushed. The -m flag allows you to type a message in the command line; if you don't pass it, Git will open an in-terminal text editor in which you type your commit message.

•  git diff <commit checksum>
• git diff <branch name>
• git diff <older checksum> <newer checksum>
• git diff <older branch> <newer branch>

This is the difference command. You can provide it with a single commit checksum to compare it to your HEAD, a single branch name to compare it to your current branch, two checksums to view the differences between them, or two branches to see the differences between them.

The checksums can be viewed with git log or git log -p. You can use an abbreviated form of the checksum (the first 5 characters) in this command.

• -f

Use this flag to force an operation to complete. For example, git push -f origin master will force Git to push changes from your local repository (i.e., to overwrite) to its origin, which is, in this case, master.

• git fetch

View information regarding the status of the working directory (local repository) in relation to the remote repository (origin)

Doesn't actually do anything besides retrieve comparative information

• git init

Initialize a project as a Git repository

• git log
• git log -p

This will show you a list of commits and some metadata about them, such as their SHA-1 checksums. If you pass the -p flag, you will also see the lines that were changed under each commit.

•  git merge <branch to merge into current branch>
• git merge --abort

This command will allow you to merge changes from the specified branch into your current branch. If you pass the --abort option, the merge will be terminated. If you try to merge and are denied due to merge conflicts, you will need to resolve them before continuing.

• git pull
• git pull <origin> <master>
• git pull --allow-unrelated-histories <origin> <master>

This command will pull changes "down" from the remote repository. Specifying the remote repository (usually origin) and branch (usually master) to pull from without passing the upstream flag (-u) will do a one-time pull from that source. Specifying these with the upstream flag (-u) will set them up as the default source to pull (and push) from, which only has to be done once; after setting this up, you can just use git pull unless you want to pull from a different repository or branch. You can also use the git branch --set-upstream-to="<origin>/<master>" command and option to set the upstream.

When finagling with repos (e.g., when trying to migrate a project from one remote repo to another), you may get an error that says something to the effect of "fatal error: refusing to merge unrelated histories." The solution to this is to pass the --allow-unrelated-histories option on the initial pull. The you should be able to push normally.

• git push
• git push <origin> <master>
• git push -u <origin> <master>
• git push <origin> HEAD:<branch>

This command will push changes "up" to the remote repository. Specifying the remote repository (usually origin) and branch (usually master) to push to without passing the upstream flag (-u) will do a one-time push to that source. Specifying these with the upstream flag (-u) will set them up as the default source to push (and pull) from, which only has to be done once; after setting this up, you can just use git push unless you want to pull from a different repository or branch.

The command for push <origin> HEAD:<branch> is for committing to the branch when your local is working off of a detached HEAD (e.g., if you checked-out a previous commit and made changes based on that commit that you now wish to push.)

The --delete command with push allows you to specify the remote name (usually origin) and local branch name in order to delete them both in one action.

• <not a git command!> q

Quit the in-terminal text editor (e.g., VIM, nova, etc.)

Not a Git command but often needed when using it

• remote -v
• git remote add <origin> <URL>
• git remote rm <origin>

-v will tell you what remotes you are connected to.

add adds a remote repository (typically referred to as origin) by providing a URL to it in order to establish the connection.

rm will allow you to remove the specified remote connections (often origin) so you can connect to new ones.

• git reset HEAD <file name>

Unstage a file

• git reset --hard HEAD
• git reset --hard <origin>/<branch>

Reset the local branch to the current state of the HEAD or the current state of the remote <branch> that it was originally built-off of (i.e., its <origin>)

•  git revert <commit checksum>
• git revert HEAD

This will allow you to revert a specified commit by providing its checksum or to revert the latest commit by specifying HEAD. This in itself is also a commit, so you will be required to enter a commit message for this action.

The checksums can be viewed with git log or git log -p. You can use an abbreviated form of the checksum (the first 5 characters) in this command.

• git show

Shows the commit you’re currently sitting on

• git stash

"Stashes" work-in-progress changes that aren't ready to be committed yet but that you don't want blown-away during a pull or merge.

• git status

Show the status of the repository in relation to the remote repository it is connected to and with regard to what files have been updated (not staged) and staged for commit.

Make sure to push and pull as appropriate so Git status is up-to-date when run.