Programming/Git

Git is the current, most common way of applying Version Control to programming projects.

Effectively, it's like making backups of your code, but doing so in a very organized way that's universally accepted by the entire programming community.

While there are plenty of different GUI interfaces for using git, it's best to learn how to use it from the command line. That way, no matter what OS or environment you're in, you'll always know what you're doing.

Getting Started

If you've never used git before, I strongly recommend looking into https://learngitbranching.js.org/ before anything else.

At minimum, I recommend doing the first three lessons to get started. If you plan to do any coding with others, then the first row of the Remote lessons is also strongly encouraged.

Installation

Windows

Download the latest installer from https://git-scm.com/download/win

• Template:TODO

Arch Linux

sudo pacman -Syu git tk

Ubuntu

sudo apt update
sudo apt install git gitk

Setup

Once installed on your machine, you'll need to set some default values.

The two required defaults are:

git config --global user.name '<your_name>'
git config --global user.email '<your_email>'

Where <your_name> and <your_email> are your actual first+last name, and email, surrounded by single quotes.

Optionally, you can also change the default text editor for commands like git commit via:

git config --global core.editor '<text_editor>'

Where <text_editor> is your preferred text editor, such as notepad, nano, or vim.

Using Git

Once you get used to it, git really isn't as complicated as it might initially seem.

Having said that, here are some important concepts to keep in mind:

• Before you use any other git commands, you'll need to create or pull a git repo.
  • This can be done with either the git init or git clone <repo_url> commands.
• Committing - Committing a file essentially means "saving the changes to the git repo, so that it's preserved."
• Staging - Staging a file is an intermediary step between changing the file, and committing it.
  • The point of staging is that you can ensure you only commit changes you intended to add. And you can double check for typos/bugs, etc.

Gitk

Gitk is a common GUI extension to git, that can be brought up from the command line.

It shows all sorts of useful information, such as commits (with visual branch merges), who wrote the commit, date, files changed in commit, etc. Very strongly recommend learning to use.

Git Commands

Basic Commands

The most basic of commands. You'll use these often.

To check the current staging status of the project:

git status

To check more detailed status of the project:

gitk

To stage a single changed file:

git add <path_to_file>

To stage all changed files and subfolders in a given folder:

git add <path_to_folder>

To stage all changed files in repo:

git add -A

To unstage a file or folder:

git reset <path_to_file_or_folder>

To create a commit of all staged files:

git commit

Repo Management Commands

Commands that aren't used often, but are essential to managing git projects long term.

To create a new git repo with the current directory as root:

git init

To set a url for the current project:

git remote add origin <git_repo_url>

To change a url for the current project:

git remote set-url origin <git_repo_url>

To push all local commits to the project url:

git push

To pull all commits that aren't yet on the local machine:

git pull

Branch Commands

Commands that pertain to managing branches. Fairly essential for larger, group projects.

To display all existing local branches:

git branch

To create a new branch using the current commit:

git branch <branch_name>

To select a different branch:

git checkout <branch_name>

To merge the contents of a different branch into the current one:

git merge <branch_name>

To delete an existing branch:

git branch -d <branch_name>

Show all known branches, including from origin:

git branch -a

Remove any local references to remote branches that are now gone:

git remote prune origin

Tag Commands

Git tags are useful placeholders which target a specific commit, giving it the project meaningful label (such as a version number) at a given place in project history.

To create a tag at the currently checked-out commit:

git tag <tag_name>

To push all created tags from local to remote:

git push --tags

To delete a tag locally:

git tag -d <tag_name>

To delete a tag on remote:

git push origin --delete <tag_name>

Advanced Commands

Warn: These commands can potentially break your repo or make you lose code if you don't know what you're doing. But they can be very powerful if you're comfortable with git.

To tell git to assume a file is unchanged (Only persists on the local machine):

git update-index --assume-unchanged <path_to_file>

To undo the above command:

git update-index --no-assume-unchanged <path_to_file>

To completely reset the project to the status of the last commit (changes will be lost!):

git reset --hard

Rebasing

Rebasing is effectively a fancy way of saying "editing previous commits".

Generally, it's fine to do if the commits you're editing are all local, and not yet pushed up to the server yet. But unless you know what you're doing, it's strongly recommended to avoid rebasing if the commits you want to edit are already pushed.

To start a rebase:

• First, look at your commit history (either via something like gitk, or exploring the online repo).
• Find the commit directly prior to the one you wish to edit. Note the first 6 or so letters and digits of the commit hash.
• In a terminal, run:

git rebase --interactive <first_6_values>

At this point, a new view will open up with your text editor of choice. It will display all commits from the current one, all the way until it finds the commit indicated by those 6 hash values.

For each commit, you can choose one of multiple options. Most common are:

• pick - Leave commit as-is. No changes. This is the default.
• edit - Select commit for editing.
• drop - Remove commit and associated changes from project.

If you selected any commits for editing, then the project will go through them, in order of oldest to newest. Make the changes you wish, stage the files with git add, and then update the commit with:

git commit --amend

Once you're done editing the commit and wish to move on, use:

git rebase --continue

Git Log Tree

This is a long command that shows the git repo tree in a terminal-friendly output:

git log --graph --simplify-by-decoration --pretty=format:'\%d'\ --all

Recommended to save this to the .bashrc file, such as via:

gbtree='git log --graph --simplify-by-decoration --pretty=format:'\%d'\ --all'

Repo Statistics

Generally speaking, these commands aren't used much.
For example different developers will have different sizes of commits. And even if they were consistent, one person might have higher quality code than the other, which these can't measure.

Having said that, these commands may still be useful on rare occasion. More as a general approximation than a direct metric.

To see the number of total commits per author:

git shortlog -sne

To see the number of code lines updated by an author:

git log --numstat --pretty="%H" --author="<author_name>" <start_commit>..<end_commit> | awk 'NF==3 {plus+=$1; minus+=$2} END {printf("+%d, -%d\n", plus, minus)}'

• <author_name> - Should be replaced by the author's commit name. Can be seen when using the gitk command.
• <start_commit> - The hash for the commit to start checking from.
• <end_commit> - The hash for the commit to check up through.

Note: For the above, the first 6 or so characters of the hash should be enough. Commit hashes can be found via the gitk command. Most online repository sites (GitHub, Bitbucket, etc) also display commit hashes.