Mitch Fincher: The Distracted Programmer: Git Examples and Notes

Every programmer has a git cheatsheet. This is mine.

What is Git?

Git is a distributed version control system written by Junio Hamano and Linus Torvalds. Linus said the name came from British slang for an argumentative, pig-headed person.

Where to Get Git?

You can download Git from git-scm.com/downloads

Tools

You can download a visual GUI for Git at www.atlassian.com/software/sourcetree.
"gitk" is a handy GUI tool installed with some systems.
"git citool" will open a GUI tool.

Documentation

Scott Chacon's and Ben Straub's book, ProGit is downloadable for free at git-scm.com/book/en/v2
Atlassian has a great tutorial at www.atlassian.com/git/tutorials
An interesting interactive visual demo of Git is at https://onlywei.github.io/explain-git-with-d3/#push
Git from the Bottom Up: https://jwiegley.github.io/git-from-the-bottom-up/
A great interactive cheatsheet: http://ndpsoftware.com/git-cheatsheet.html

Editors note: I will use <hashid> and <commit> interchangably. In some contexts it's clearer to use <hashid>. Both refer to a 40 character SHA-1 number, like 74c195b84d7ec5fcf2bc9d59b83b7b538c8ec60d.

Getting Started By Downloading Repository

git init: creates .git directory and machinery to create a git repository
git clone https://github.com/jquery/jquery.git: clones (copies) repository and creates a local repository with all the commits, trees, blobs, branches, and tags, but not the remotes. For that use the "-mirror" switch.
git clone <repository> <new-repository>: Goes to the directory above your working directory and then issues this command to create a copy of your current repository.

Saving Your Basic Information For Future Sessions

"git config" allows you to put information into the "~/.gitconfig" file for future sessions. This tells "git" things like your name and favorite editor.

git config --global user.name "Mitch Fincher"
git config --global user.email "me@myhost.org"
git config --global core.editor vim
git config --global help.autocorrect 1
git config --global color.ui auto
git config --global --list

Saving Aliases into ~/.gitconfig

You can create aliases to reduce typing. This next command will create a shorthand for "cma" which will add a line to your ~/.gitconfig file.

$ git config --global alias.cma "commit --all -m"
$ git cma "adding twelve.txt"

You can also edit your ~/.gitconfig file directly and create multi-line scripts that take parameters. The alias below takes a branch name, checks it out, and then merges in the previous branch. You would invoke it like this: "git qm master".

#quick merge
qm = "!f() { branchName=$1; git checkout ${branchName} && git merge  @{-1}; }; f"

Background: Git has Four Object Types

Git Database has four types: Blobs, Trees, Commits, and Annotated Tags

Blob A "blob" is a compressed file with no meta-data. All the meta-data, like name and time-stamp, are stored in a tree. The blob, may, and probably is, referenced by many trees.
A blob has a header record consisting of it's type, "blob", a space, the number of bytes, followed by a null byte. Git prepends this to the contents of the actual file and then calculates it's SHA-1 hash value. Git then compresses the contents using zlib and writes it to the file system using the hash value as the name into the .git/objects/directory.
To create a hash from a string or file use the "git hash-object" command.
To play with this online visit https://www.movable-type.co.uk/scripts/sha1.html
Tree A "tree" contains references to blobs and other trees. Using "ls-tree" we can see the tree inside a commit.
```
$ git ls-tree master
100644 blob 1f0d9c362b635efe4f321a92d6715f00530ed2b2    greetings.txt
100644 blob 586d7ab779c9fcd2d171ca012a6186144beea379    one.txt
040000 tree 584d1a5650d8b2f5d7c71f1373c884569cad0cbf    spanish
100644 blob 4adbf7c8f4d643d31800f4b3780c602ed455f993    three.txt
```
Each line contains a mode, hashid, and filename.
Git uses three modes for blobs, 100644 is a normal file, 100755 is an executable file, and 120000 is a symbolic link.
We can also use "ls-tree" to look directly at a tree, like the one above,
```
$ git ls-tree 584d1a5650d8b2f5d7c71f1373c884569cad0cbf
100644 blob c5027f551f410b6a2438b285fd0cebff4c05cef4    greeting.txt
```
The argument to "ls-tree" is a "tree-ish" object - either the hashid of a tree, or an object that can easily have a tree extracted from it, like a commit.
Commit A "commit" is a snapshot of the working tree. It contains a tree hash, usually a parent, an author and committer info, date info, a blank line, and finally a commit message.
```
git cat-file commit 107b22915830203ff40d0d8dfbf8e950961bc490
tree 21e1ce7f2888871854a6a54e7f37853626331eb9
parent cedfd274bc5fc6ed23baf7eb93d81a5f0e8416e8
author Mitchell Fincher  1507926633 -0500
committer Mitchell Fincher  1507926633 -0500

adding spanish
```
You can try this yourself, use "git log" to get a recent hash.
Commits only reference parents, never children.
Annotated Tags Unlike a lightweight tag, which is merely a reference to a commit, an annotated tag is an object. To create one, use the "-a" option.
```
git tag -a rel1.1 cedfd274bc5fc6ed23baf7eb93d81a5f0e8416e8
```
git will present you with the option to add a description, like "release 1.1".
To see the new object reference to rel1.1, cat the file contents:
```
$ cat .git\refs\tags\rel1.1
ad9fea1c206def283ba24549ddf1979703f176a2
```
Use cat-file to inspect the comments:
```
git cat-file -p ad9fea1c206def283ba24549ddf1979703f176a2
object cedfd274bc5fc6ed23baf7eb93d81a5f0e8416e8
type commit
tag rel1.1
tagger Mitchell Fincher  1508168418 -0500

release 1.1
```

Deep Magic Commands

Git has "porcelain" commands, pretty things to be seen and used by everyone like these: "git add", "git commit", "git push", "git pull".
Git also has many "plumbing" commands to be used by experts and the Morlocks who keep the Eloi happy, like "git cat-file", "git hash-object", "git count-objects". The porcelain command under the covers and made up of the plumbing commands.

A little background, git uses SHA-1 which reads any file or string and returns 20 bytes which is 40 hex digits. You can convert a string to its SHA1 hex value using hash-object.

echo "The fault, dear Brutus, is not in our stars" | git hash-object --stdin

2e72face651312aa9a4232ba28c1c1871cee403f

You can write a string into git's database by using the "-w" option.

 echo "The fault, dear Brutus, is not in our stars" | git hash-object --stdin -w 
 2e72face651312aa9a4232ba28c1c1871cee403f

$ ls .git\objects\2e\72face*
.git\objects\2e\72face651312aa9a4232ba28c1c1871cee403f

Git will write objects to its ".git/objects" directory. This is why git is called a "content-addressable file system".
Use "git hash-object <filename>" to show the SHA-1 hash created by the contents of <filename>.
A great course on the internals is https://app.pluralsight.com/library/courses/how-git-works/table-of-contents

Plumbing commands:

git cat-file -t <object>

returns the type of the object: "blob","commit","tree", or "tag"

git cat-file <type> <object>

shows the contents of the file associated with the object.

git cat-file blob 5f831d630dd069aca58b3a164ff526b53c142456
'Hello, world!'

git cat-file commit <commit>

shows the contents of a commit e.g., "git cat-file commit a7cc8785c5bd3594c9659b779ed56487097281b4":

tree a822836950b935d16f8ee572429dd1d754a85a73
parent 640f3af9f9e883a5ed0102154e453170f04267b7
author Mitchell Fincher <mitchf@fincher.org> 1505507251 -0500
committer Mitchell Fincher <mitchf@fincher.org> 1505507251 -0500

texas greeting

The object does not have to be the "type" requested, if the "type" can be easily deferenced from the object, like asking for a commit from a "tag".

$ git cat-file commit v4.0
tree 71dea1ed6141af0acfc61e8e145612255924723d
parent 888c1884b879ef34da6685ac0158c0e3f830d040
parent 872c5443db65734a507201b514b3ae80c6c32d2c

The pretty-print, "-p" option, will do its best to determine the type of object you want. Here we look at an annotated tag:

$ git cat-file -p v4.0
object d4c9f8f2fe56221002113dcfcb7082913d7e9921
type commit
tag v4.0
tagger Mitchell Fincher  1509128823 -0500

    added four.txt

Here we use the magic "-p" option to look at a tree:

$ git cat-file -p 9a9e2826ac8ed12d43ca0a23fbe5c26af4e64bab
100644 blob b5244467192a2cb0e94b6cee014d007a1b439b68    README.md
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391    eight.txt
100644 blob 5bace8b1cedb799bfac944e5a65fd301de784700    eleven.txt

git ls-tree <tree-ish>

shows all the objects in the "tree-ish" object. A tree-ish object can be a tree or an object that contains a tree.

$ git ls-tree master
100644 blob 5f831d630dd069aca58b3a164ff526b53c142456    greeting
100644 blob b6d99afd00cffebbd33e6a99c946e4bf54319ec4    texas

git ls-files

shows info about the files on the stage (index) and the working directory. It does not distinguish between the two.

git rev-parse HEAD

HEAD is usually a reference to a branch which contains a pointer to a commit. "rev-parse" derefences the branch and shows the hash id of the commit without having to go through the intermediate branch.

$ git rev-parse HEAD
3a9aae03b78bb617e9ec7822289e4a991ea7c2d8

$ cat .git/HEAD
ref: refs/heads/master

$ cat refs/heads/master
3a9aae03b78bb617e9ec7822289e4a991ea7c2d8

git write-tree

takes the contents of the index (staging area) and creates a tree.

echo "My comment" | git commit-tree <hashid>

commit-tree takes a tree hashid and creates a commit from it. By suppling the comment, git can do its work without asking you for it.

git update-ref refs/heads/master <hashid>

writes the hashid into the file refs/heads/master, making that commit hashid the current one for the branch master. This could be done manually:

$ echo <hashid> > .git/refs/heads/master

You can also use update-ref to create a branch manually. To create a new branch pointing to a hash you enter:

git update-ref refs/heads/rel2 eafd8ea4563a802f6ad9dd65bf1222689785af26

git symbolic-ref HEAD

shows the value of the HEAD reference

$ git symbolic-ref HEAD
 refs/heads/develop

git symbolic-ref HEAD refs/heads/master

sets the value in .git/HEAD to be "refs/heads/master". You can try to do it manually with "echo", but it may put a space at the end of the line. To do this manually you should edit in your fav editor.

echo ref: refs/heads/branch1> .git\HEAD
C:\Users\mfincher\gittest (master ) #notice space at the end

What's in Them Files?

When you create a new repository with "git init", git will create a new directory, ".git" which is kind of a parallel dimension storing all the info that git needs. If you are into "Stranger Things", the .git directory is the "upside down" world. ".git" contains these directories and files:

$ ls -F
HEAD         description  info\        refs\
config       hooks\       objects\

HEAD

This file typically contains one line of textshowing the branch currently checked out. Usually this a symbolic link like "ref: refs/heads/develop", but can point directly to a commit hash.

description

you can edit this file to describe your repo

config

contains project specific settings and the URLs for your remotes, e.g., where does "origin" point.

info

keeps a list of file patterns to ignore.

C:\Users\mitchf\gitdemo2\.git (master)
$ cd info

C:\Users\mitchf\gitdemo2\.git\info (master)
$ ls
exclude

C:\Users\mitchf\gitdemo2\.git\info (master)
$ cat exclude
# git ls-files --others --exclude-from=.git/info/exclude
# Lines that start with '#' are comments.
# For a project mostly in C, the following would be a good set of
# exclude patterns (uncomment them if you want to use them):
# *.[oa]
# *~

hooks

contains hook scripts

index

a single file which is a mini-file system containing all the staged changes

objects

stores all the contents of your repository objects in "blobs". The files do not have names. Their SHA-1 hash id is their name. The file's real name is stored elsewhere in the tree. So, if two files have the identical contents, the contents will be stored only once. The two trees will point to the exact same file because Git is a content-addressable file system.
Inside the objects directory is the top layer of subdirectories named the first two characters of the SHA-1 hash. Underneath that directory are files named with the remaining 38 character hash.

$ ls objects
1f    48    5e    76    81    93    ab    ce    f3    pack
3f    4a    64    7a    8a    99    bb    d6    f4
47    58    6f    7c    8e    a6    cd    ea    info

$ ls objects/lf
025359eec40ca200dc800f72ff78f6153a502a  82622d17e916d82b3badc38fbe8e025cd4a7d9
1621638abb2fbf888eef4e5a9314e74e055e99  8d7e0431e16b7f03856a5a9ac874d1bea13bcb
1af4d5ff8194432203d4bfd7b78f07426d8362  905c34c72391fa21571b54dd1a8d2711186975

refs

stores reference pointers to objects like heads, remotes, stashes and tags.

checkout


git checkout <branch-name>: sets the current branch to <branch-name>. This updates the index, the files in the working tree, and sets the HEAD pointer (.git/HEAD) to the branch. Modified files in the working tree are not updated.
git checkout -b <new-branch>: creates a new branch from the current branch. It is equal to doing a "git branch <new-branch>" and then a "git checkout <new-branch>"
git checkout -- <file-name>: checkout a copy of <file-name> from the current branch and overwrite the working copy.
git checkout -- .: remove all the unstaged changed files and replace with original.
git checkout <commit>: detachs the HEAD and sets directly to this commit, "git checkout 661d5fd32".
git checkout -: checkout previous branch used
git checkout <branch-name> -- <path-to-file>: command to checkout a specific file from another branch
git checkout -- <mydeleteddirectory>: if you delete a directory and want git to fetch it back, "git pull" will not do it. It just transfers commits between remote and local. You need to do this instead.

What's Going On?

git status: shows your current branch and any interesting files
git status --short: shorter list with first two cols significant
git config --list: shows the combined settings from four files: .git/config file, ~/.gitconfig, /etc/gitconfig, and $XDG_CONFIG_HOME/git/config.
git log: see the changes
git log --oneline: to show quick one line summary
git log -2: see last two changes
git log --pretty=oneline: will not show commits that are reset over
git log --pretty="%h | %d %s (%cr) [%an]": You can create your own log format using items like "%s" which is the "subject". Complete list of codes is at http://git-scm.com/docs/pretty-formats.
git log --pretty="%Cblue%h%Creset | %Cred%d%Creset %s (%cr) %Cgreen[%an]%Creset": you can spice it up with color
git log --oneline --graph --decorate --all: pretty graph
git shortlog -sn: shows how often people are committing
git show head: shows last commit
git show HEAD~1: shows previous commit
git show-ref master: shows all commits for branches with master in name

Branch

git branch <new-branch>

creates new branch named <new-branch>. Typically you would then enter "git checkout <new-branch>" right afterwards. Or you can do both in one command with "git checkout -b <new-branch>".

git branch

shows all your local branches

git branch -r

shows all remote branches

git branch -a

shows all remote and local branches

git branch -vv

shows a verbose listing of the last commit on each branch

git branch --merged

shows all branches that have been merged into HEAD

git branch --merged master

lists branches merged into master

git branch --no-merged <commit>

lists branches that have not been merged i.e., list branches whose tips are not reachable from the commit (HEAD is used if commit not specified)

Misc

list of files needed to be merged: git diff --name-only --diff-filter=U
git remote update origin --prune: removes from your local list the branches that have been deleted in origin
git ls-files: shows all the files in the repo
git ls-file "**/<file-name>": gets the full path to file
git fsck --full: checks for a corrupt git database. It will find things like a tag reference to an object that has been deleted.
git whatchanged: shows what has changed
remove all files from the stage:: git reset HEAD -- .
unset user password:: git config --global --unset user.password
remove permantly file from git and the file system:: git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch news/2021/2021-04-02-IMG_4423.jpg_original' --prune-empty --tag-name-filter cat -- --all
see what files you are about to push:: git diff --stat --cached origin/master
unstage files:: git reset

Help Me

git help: gets general help
git help config: gets help on the "config" command

Adds and Commits

git add <filename>: adds file to the stage
git add <file1> <file2>: adds multiple files to the stage
git add '*.txt': adds using wildcards, but must have single quotes
git add --all: adds all new, deleted or modified files
git add -A: stages All files, same as "--all"
git add .: stages new and modified, without deleted
git add -u: stages modified and deleted, but not new files
git commit -m "my commit message": commits staged files to repo

Deleting and Renaming Files

git rm <filename>: deletes the file and stages the deletion
git rm --cached <filename>: removes the file from version control, but keeps it on the filesystem.
git rm '*.txt': stages the removal of all the txt files
git mv <filename> <new-filename>: renames a file

Remoting

git remote

returns the name of the current remote site

$ git remote
origin

git remote -v

use the verbose option to see the URLs for reading and writing

$ git remote -v
origin  https://mysite.com/myproject (fetch)
origin  https://mysite.com/myproject (push)

git remote show origin

shows the URL for "origin" and remote branches.

git remote set-url origin git@github.com:User/UserRepo.git

changes a remote location's value

git push -u origin master

pushes your code to the master branch of the repository defined by "origin"

git remote rename <old-name> <new-name>

renames the remote

git remote remove <branch-name>

removes branch-name from your list of remotes

git remote add <remote-name> <URL>

adds a new remote reference. This will add a section in your "config" file to map the name to the URL. For example after adding "demo" with "git remote add demo https://github.com/fincher42/demo.git", "config" contains:

[remote "origin"]
        url = https://github.com/fincher42/demo.git
        fetch = +refs/heads/*:refs/remotes/origin/*

The value of "fetch" is called the "refspec". It has an optional "+" (directing git to update the reference even if it's not a fast-forward) followed by <src>:<dist>. "src" is a reference to where the data is on the remote site and "dist" is where to put the files locally.

What's Changed - git diff

git diff: shows only unstaged changes, defaults to HEAD
git diff --staged: shows only staged changes (those in the index)
git diff --cached: "cached" is an alias for "staged"
git diff HEAD: shows staged and unstaged changes
git diff <branch-name>: see changes between current branch and <branch-name>
git diff origin/master: see the difference with the origin master branch
git diff <commit>: see changes from <commit>
git diff HEAD~1..HEAD: see changes from previous commit
git diff --name-only <branch-name>: show only the names of the files that have changed

Reset

"reset" is confusing because it can edit the references, the index (stage), and trees. Note: "--mixed" is the default.
What do the reset options affect?

reset option	working tree	index	HEAD
--soft			X
--mixed		X	X
--hard	X	X	X

git reset HEAD: remove changes in the index ("the stage") and resets the HEAD pointer. (default option is "--mixed")
git reset -- <filename>: removes <filename> from the staging area, but preserves its contents in the working directory
git reset --soft HEAD^: moves HEAD to its parent, leaving the index and working directory files untouched.; unstages the <files>
git reset --mixed HEAD^: moves HEAD to its parent, and resets the index, but leaves the working directory files untouched.
git reset --hard HEAD^: moves HEAD to its parent, and resets the index and the working files. (You should do a "git stash" before doing this reset)
git reset --hard eb70244: sets HEAD to specific commit and erases all changes in current working tree. Use "git checkout eb70244" to preserve changes.
git reset --hard eb70244: sets HEAD to specific commit and erases all changes in current working tree. Use "git checkout eb70244" to preserve changes.
git update-ref HEAD HEAD^: same as "git reset --soft HEAD^"
git reset HEAD^: undoes last commit and leaves files ready to be staged
git reset origin/master: restores to origin's version

If you need to rollback the origin's HEAD to a previous version (e.g., 12cdeee in master), you can do it this way:

git checkout master
git reset --hard 12cdeee
git push -f origin master

Revert

Revert will reverse the effects of previous commits.

git revert <commit>: removes the changes created by <commit>
git revert HEAD~5: removes the changes from the fifth last commit and creates a new commit to reflect that.

Merge

git merge <feature>

merges changes from the <feature> branch into current branch. The current branch is updated, but the target branch, "<feature>", is unaffected. Here is a typical flow to merge changes from a feature branch into master with no conflicts:

$ git checkout master
$ git checkout -b feature1
  # make edits and commits on feature1
$ git checkout master
$ git merge feature1
  #cleanup by deleting feature1 branch
$ git branch -d feature1

Deleting a Branch

git branch -d <branch-name>: delete branch <branch-name>
git branch -d branch1 branch2 branch3 ...: multiple branches can be specified
git branch -D <branch-name>: delete branch <branch-name> even if unsaved changes will be lost. (-D is short for "--delete --force")
git push origin --delete <branch-name>: delete branch <branch-name> on remote
git push origin :feature4: delete branch feature4 on remote (prefixing with ":" does the same as "--delete" in this case)

Clean

"git clean" will remove untracked files and directories.

git clean -n: show which files will be deleted by a "clean" command
git clean -f: delete untracked file "-f" is needed to force deletion
git clean -df: delete untracked files and directories; useful for getting rid of build products.
git clean --dry-run: Shows what files would be deleted.

Push

"push" copies local refs to the remote and sends the objects necessary to complete the refs.

git push: usually pushes the current branch to origin unless config has a value for "branch.<name>.remote".
git push <repository>: pushes the current branch to <repository>, which can be a URL or the name of a remote
git push origin: pushes local changes to origin. With no further arguments, git looks in the ".git/config" file for the '[remote "origin"] merge' value.
git push -f: forces local changes to origin overwriting others changes. Not recommended except in extreme cases.
git push origin :<branch-name>: pushes an empty branch over "<branch-name>" causing it to be deleted.
git push origin <local-branch-name>:<remote-branch-name>: push a branch to origin with a different name

Fetch

Fetch does several things:
1. Copies the commit values from the remote branches to the .git/refs/remote/<repository>/<branch> files.
For example, assume the remote "master" branch is ahead by one commit at "cf2c3d9ccb6fb349543ee788ea27b48b2b63cf7a", and the local pointer to the remote "master" branch is at "a5d236166a2607841549bbbe1ff50ac13a3305ca" (meaning the contents of "gitdemo/.git/refs/remotes/origin/master" is "a5d236166a2607841549bbbe1ff50ac13a3305ca").
If we do a

  "$ git fetch origin master"

then the contents of "gitdemo/.git/refs/remotes/origin/master" is now updated to the value at the remote, "cf2c3d9ccb6fb349543ee788ea27b48b2b63cf7a".

2. Downloads any new objects referenced from the new commits on the remote branch into the local object database (.git/objects).
3. Downloads tags that reference the new items.
Fetch does not change the contents of your working directory or your local refs like "HEAD".
A great visual example of fetch is at https://onlywei.github.io/explain-git-with-d3/#fetch.

Pull

git pull: same as doing a "git fetch" + "git merge"

Rebase

git rebase <branch-name>: make <branch-name> the "base" of the current branch. Conflicts may need to be resolved.
git rebase -i HEAD~3: to go back three commits, note lines in reverse order now
git rebase --abort: stop the rebase and roll back

Stash - store changes off to the side

"stash" saves your changes into a genuine commit onto a side stack that can be used like any other commit.

git stash save: stashes staged and unstaged changes onto stash queue (but not untracked files) and reverts current branch to last commit
git stash save "message": stash to a name
git stash: appends "save" at the end for you
git stash apply: brings back the stash
if you enter "git stash && git stash apply", it will create a snapshot of your system.
git stash list: shows list of stashes with previous commit
git stash list --stat: shows more info, log options can be used e.g., "--oneline"
git stash apply stash@{1}: brings back stash 1. Does not pop off the top of the queue - leaves it there
git stash drop: removes top stash frame in queue
git stash pop: restores most recently stashed files and removes them from the stack of changesets
git stash save --save-index: keeps staged files, but stashes unstaged
git stash show: shows info on last stash
git stash show stash@{2}: info on 2
git stash clear: removes all stashes

jwiegley recommends this clever use of stash for linux systems:

$ cat <<EOF > /usr/local/bin/git-snapshot
#!/bin/sh
git stash && git stash apply
EOF
$ chmod +x $_
$ git snapshot

Cherry Picking

git cherry-pick <commit>: will pick that commit into our current branch
git cherry-pick --edit <commit>: allows changing message
git cherry-pick --no-commit <commit> 55aed374: pulls in changes to staging
git cherry-pick -x <commit>: adds in previous SHA-1 number in comments
git cherry-pick --signoff <commit>: adds picker's id

Genealogy, Searching the Family Tree

a3d5fca12: to reference a commit you only need to type enough characters to make it unique, usually 6 or 7 characters are enough.

name^

the parent commit, if more than one parent, the first is used

name^^

the grandparent

name~8

the eighth ancestor, or name^^^^^^^^

name^2

If more than one parent this will get the second parent.

--grep=pattern

matches all commits whose message matches this pattern.

$ git log --grep puppies

--author=pattern

matches all commits whose author matches this pattern

$ git log --author=Linus

--no-merges

matches all commits which have only one parent, i.e., no merged commits

Reflog

"Reflog" is a backup system that keeps track of all our commits, even if we delete branches. The commits will stay around for about 30 days and then get really deleted.
"Reflog" is a history of where HEAD has been pointed.

git reflog: shows commits. Only local to user

generates error, not fully merged

$ git branch -D zoo //overrides and deletes $ git log --walk-reflogs //gives more info $ git branch zoo <commit> //creates new branch pointing to deleted branches' last SHA-1 $ git branch zoo HEAD@{1}//same as above $ git checkout zoo

Squash multiple commits into one tidy commit

You can group your commits into a meaningful one before a merge, but it takes two steps:
Step 1:

  git rebase -i HEAD~n //where n is a number of commits to merge (squash)

The "i" option is for interactive.
Step 2: Git will present you with a text file like this:

pick 8a18f54 one
pick 64156a7 two
pick f4a9307 3

# Rebase cd97cab..f4a9307 onto cd97cab (3 commands)
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit

Leave the first line as is, but in the following lines change "pick" to "squash". Then save, and exit the editor. [In vim, ESC -> :wq! (save changes)]
Git will then present a message file where you can delete all the checkin comments and replace with a new one for all commits. Save and exit. Enter "git log" to see the change.

Notes

"git gc" will garbage collect and repack your database.
Git has three types of references: tag, branch, and HEAD.
Git may reduce storage space by using a base file and "diffs" from that base file. These are stored in the "pack" subdirectory.
The parent of the current commit is the SHA-1 value of the reference that HEAD points to.
HEAD is usually a symbolic reference to the last commit in the currently checked-out branch. HEAD points to the current branch. In the .git directory, the file "HEAD" contains a pointer to the current branch, which in turn references a commit hash id. Example:

$ cat .git/HEAD
ref: refs/heads/Mitch_895553_MyBranchName

$ cat .git/refs/heads/Mitch_895553_MyBranchName
a3d5fc559d4ba4183964ca6d17e658812eafb141

The HEAD can be set directly to a commit. This is called a "detached head".
A directory named "index" holds all the files to be committed. This is called the "stage", where files are staged before being committed. Files do not go from the working tree to the repository, they have to be added to the staging area first with a "git add " command.
The "working tree" is where the normal files are kept on your filesystem. It has a ".git" directory which contains all the .git objects.
A "hash id" is a SHA-1 hash, a 40 character hex hash. SHA-1 takes text and reduces it down to 40 characters. The hash of a file is just based on contents, name is not hashed. See "git hash-object file". You can usually use abbreviate the hash with the first few characters. The abbreviation needs to be unambiguous and have at least 4 characters.
Almost all operations in Git add data to the db, it doesn't delete or change the database, so it's very forgiving
For passwords setup in Visual Studio, see: https://www.visualstudio.com/docs/git/set-up-credential-managers
Three Rules of Branches

Current branch tracks new commits
When you move to another commit (branch), Git updates the files in your working directory
Unreachable objects may be garbage collected

Tuesday, September 12, 2017

Git Examples and Notes