git cheatsheet

Merely a 'blog article' since I want access to these short notes from other places than my home computer

clone, pull, create#

git clone <url>

• clones a repo into a newly created directory
• create remote-tracking branches for each branch in cloned repo
  • to view them: git branch --remotes
  • git fetch (w/out args) updates all remote-tracking branches
  • git pull (w/out args) in addition merges remote master into current master

git pull <options> <repo>

• runs git fetch + depending on config/options will rebase/merge to reconcile diverging branches

git init

• creates empty git repository (creates .git/ subfolder)
• git branch -m master (set default name)
• git remote add origin <url> (add remote URL)

basic snapshotting#

git add .

• updates index which holds snapshot of working tree
• changes are 'staged for commit'

git status

• displays paths w/ diff between index and HEAD commit
• displays yet untracked (not-added/not-staged) paths

git diff

• w/out options shows diff of working tree and index

git commit -m "message"

• 'commits' stashed changes to the working tree
• create commit containing current contents of index and given message

`git reset

• resets current branch head to <commit-hash> (including reverting the tree/index)

git rm <file>

• removes file from index (in effect: delete from repo, but not file itself)
  • (file can be re-added)

git mv <file>

• a file rename w/ mv is considered a file deletion + creation
• as such the new file will not contain any previous git history
• git mv preserves the git history of the file in question
  • (note: compared to git rm is does modify the underlying file!)

stash

• think of the stash as a simple cache in which you can temporarily put aside changes that "get in the way" but you don't want to commit yet
  • example: when switching branches
  • git stash: saves current local modifications to stash and reverts working dir to HEAD
  • git stash list: list stashes
  • git stash apply: applies most recent stash and keeps it in stash list
  • git stash pop: applies most recent stash and removes it from stash list
  • git stash apply stash@{2}: applies specific stash (here stash <2>)
  • git stash branch <new-name> stash@{2}: creates branch from stash
  • git stash drop stash@{2}: remove specific stash from stash list
  • git stash clear: clear all stashes

branching, merging#

git branch: list, create, delete branches

• git branch: lists local branches
• git branch -a: list all (including remotes)
• git branch <new>: creates new
• git branch -d <name>: deletes a branch, branch must be fully merged upstream
• git branch -D <name>: deletes even if not fully merged

git checkout <name>

• updates file in working tree to mach version in index or specified tree
• git checkout -b <new>: creates & checks out (so switches to it)

git merge

• incorporates changes from named commits (since divergence) into current branch
• default automatic action when git pull pulls in conflicting changes

git log

• show commit logs

git tag

• a tag creates a clear reference to a certain state (post-unchangeable, as opposed to a standard branch)
• git tag: lists tags
• git tag <name>: creates a tag
• git tag <name> <HASH>: creates a tag for a specific commit
  • git log can be used to inspect hashes of commits
• git tag -a <name>: creates an annotated tag (more metadata, can be potentially signed as well)
• git tag -f <name>: if <name> is already an existing tag, updates the tag
• tags need to be explicitly pushed to remote, happens via
  • git push origin v1.4
  • git push --tags pushes all local tags to remote

Notes on rebase:

• rebasing a <feature> into <master> means all <feature> commits are applied one after another on top of <master>
• Advantages
  • very clean commit graph, project history
  • no merge commits
• Disadvantages
  • more complicated conflict resolution
    • and risk of loss, inadvertent non-recoverable errors w/ complex rebases
  • bad traceability: removes "when code was written" with "when was it placed on top"
  • requires finer developer understanding and discipline

sharing, updating#

git fetch

• fetches branches and/or tags (collectively "refs") from a repository
• git fetch -all: all branches and tags
• git fetch -n: no tags
• git fetch --atomic: use an atomic transaction to update local refs
• git fetch <name>: fetch specific repo

git pull

• fetches & integrates !
• (mybranch)$ git pull origin/master
  • fetches master
  • applies default integration action (merge by default, rebase if so set)

git push

• updates remote refs using local refs, sending objects necessary
  • in other words: pushes local branches/tags not yet pushed to remote
• git push --all: push all branches
• git push origin master: pushes local to remote master
  • origin is the default name of the remote
• (master)$ git push synonymous with git push origin master
• if remote changes have been applied locally, pull is needed before pushing
• Note: (my-branch)$ git push origin master will not push local my-branch into remote master; it will push the local master to remote master (which as stated, is even rejected if remote has changes that haven't been applied locally); it's safe and non-destructive

git remote

• manage the set of repositories (remotes) you track
• git remote add adds a remote
  • can have multiple remotes at once (have the same repo automatically on multiple platforms/servers, and push to all of them simultaneously)
• git remote get-url --all will list all URLs for the repo
• git remote set-url change urls of the remote

inspection, comparison#

• git log: shows the commit logs
• git diff: shows changes between working tree and HEAD

issues: line endings on Windows#

• on windows line endings will be \r\n but git will usually normalize to \n when pushing and re-adjust to \r\n when pulling (normal modus operandus)
• merging via git bash however can still lead to whole files showing as conflicted due to a file ending difference (the merge potentially overwrites a whole file)
• Two things
  • show line endings to detect such issues; on Windows in vscode consider (as time of writing) https://marketplace.visualstudio.com/items?itemName=medo64.render-crlf
  • use git merge branchB -X renormalize ; from man git-merge:

This runs a virtual check-out and check-in of all three stages of any file
which needs a three-way merge. This option is meant to be used when merging
branches with different clean filters or end-of-line normalization rules.

Resources#

• official
• Atlassian's documentation
• git-beej-guide.pdf

merge conflict resolution#

(careful w/ vim from git bash (will use \n not clrf)

Notes on fully resolving merge conflicts from command line, let's assume:

• git push
  • potential conflict
  • "Updates were rejected because the remote contains work that you do not have locally."
• git pull
  • potential conflicts to resolve
• git status
  • to see conflicted files
  • alt: git diff --name-only --diff-filter=U
    • lists only conflicted files
• vim conflicted_file.txt
  • conflicts are clearly marked
  • edit file, keep wanted content, save
• (add it singularly) (or do so for all at end via add .)
• repeat for all files
• then git add . && git commit "resolved" && git push

additional notes#

• git merge --abort at any point before you have committed to abort merge completely
• Example of marked conflict

<<<<<<< HEAD
your local changes
=======
incoming changes
>>>>>>> branch-name