My Cheatsheet on git

Each snapshot has some number of parents. Each parent may have more than one child.

git defines an object, which is a blob, or a tree, or a commit.

All objects are content addressed, they are a set of objects maintained as this content addressed store. You put it into the store via a key which is the hash of the object. i.e. a sha1 hash of the object itself.

• remember a sha1 is a 160 bit hash (Hexadecimal strings, 40 characters

long) (40 hex characters is 20 bytes which is 20*8bits or 160 bits.)

In pseudo code, from MIT missing lecture video:

type object = blob | tree | commit
objects = map<string, object>

# git stores each object by first storing it's hash (id) and then the
# object itself, as follows:
def store(o)
   id = sha1(o)  # the sha 1 hash of the object o
   object[id] = o   # this actually stores to disk i.e. saves the object[id]

# to retrieve an object, you need its id. so a retrieval 
def load(id)
   return object[id]

git doesn't actually store the whole tree or commit in each object. Rather it stores pointers to the object. So you are not duplicating all these commits and trees and blobs, just pointing from one to the other to the other.

So summariziing:

Git's on-disk datastore is a content addressable memory store where objects are addressed by their unique hash.

so you can change a reference "fix bug 7" from one commit to another, but you don't change the commit itself. The references can point to particular nodes in a graph. and You can change them at a latter time.

A file can be in one of three states:

1. modified file has changed but has not been added to the staging area yet
   • in both cases the command git add filename transitions it to 2)
2. staged file has been added and ready to be committed to the repository
   • the command git commit transitions it to 3)
3. committed file is saved in local repo (.git directory)

If you create a new file in a directory that is under git control, that file will not yet be added to git. It will be in the "normal" space, and appear as a UNTRACKED file in a git status output. This is a very similar state to the modified state, in that git is not doing anything to these files.

Files can be in (1) the repository, (2) in a staging area, or (3) in a working directory.

git has a concept of a staging area. Any changes added to git, stay in the staging area. You can redo changes, make more changes etc to any files. They still stay in the "staging" area. You can then decide what changes to include in the next snapshot that you create. git status will tell you what files will NOT be included in the next snapshot by saying "untracked files".

The files that are "added" to git are in the staging area. The directory where you are working and editing files is called the working directory. This is NOT to be confused with the staging area.

Like 'master' 'head' is a special reference. Head points to the current commit. i.e. where you are looking right now, which might not be the latest most up to date version. "points to" means "is referencing the hash for a commit" Usually Head and master point to the latest commit hash.

These are the human readable names, called references. They are mutable and as the project moves along will change and "point" to different commits.

Either by editor, or all on one line

• git commit # editor
• git commit -m "this is my commit message" # all-in-one-line

It is important to write good commit messages. They have several features. Good commit messages follow these principles and are meant to help others, or your future self understand why some change was made. Not to neccessarily describe the change itself, because that could be done by looking at the code itself or a git diff. The message tells you why.

• short
• gives motivation, answers the question why?
• meant for future programmers
• be consistent in style through the git log
• be consistent in syntax, wrap margins, grammer, capitalization, punctuation
• be consistent in content (that is really the same as 2)
• have consistent metadata, i.e. include tracking ids? change mgt tickets?

Given these rules, a possible git log convention for an organization could be the following:

1. Separate subject from body with a blank line
2. Limit the subject line to 50 characters
3. Capitalize the subject line
4. Do not end the subject line with a period
5. Use the imperative mood in the subject line *
6. Wrap the body at 72 characters
7. Use the body to explain what and why vs. how
8. imperative mood is used when saying "Hey you! Fix the bug" Same thing is achieved if you use: "if applied correctly, this change

will fix the bug"

Summarize changes in around 50 characters or less
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.

Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequences of this
change? Here's the place to explain them.

Further paragraphs come after blank lines.

 - Bullet points are okay, too

 - Typically a hyphen or asterisk is used for the bullet, preceded
   by a single space, with blank lines in between, but conventions
   vary here

If you use an issue tracker, put references to them at the bottom,
like this:

Resolves: #123
See also: #456, #789

If the change is very straightforward, then a single line is all that is needed, so skip the body. For example: "Fix typo in intro message"

See git log section, re command git log --oneline

Will add all the files already tracked in to a commit (without needing to add the files before). However new files will NOT be committed with -a

Typically though you probably want to control which files you put in a commit, and NOT add temporary files that you will be deleting later anyway.

If you want to revert this commit, you can use the git rest HEAD command. it will remove commit from your local repository and move changes done in that commit to your working directory

You can alway type git help at any level, for example:

• git help init
• git help commit
• git help add

This is the first step to run within that folder. It initializes a git branch with all the files in that folder. If the folder is empty (i.e. you are just starting a new project) the git repository will be empty, but if there are some files already in that folder, the repository will already be "checked in" with those files as version 1

git init will create a new hidden folder, .git If you delete this folder, you will delete all the change history of the programs in the root folder of the repository, but you will NOT delete the programs themselves.

Because of that, git is not by itself a backup of your code. You would need to use a remote (i.e. github) repository to sync up your code to have a backup. If you wish to keep files local only, you have to rely on another mechanism of backup, i.e. time machine that backs up the programs in the main repository as well as the change history that is stored in the .git directory.

You can also zip the folder, and send it to someone to let that person have immediate access to your repository, changes history included. Cool!

If you create a new program in the main repository, git will not itself start tracking changes to this program. You can confirm that with git status. You must git add the file which moves the file into the staging area. After which you can commit changes to that file when you are ready. You may have to re-add the file so that your latest changes are committed when it is time.

Whenever possible, one should try using branches rather than updating the code directly in the master branch. That way you can recover from edits that break the code you already had running.

The following workflow should be used in Git to be able to apply fixes to your code and develop new features:

• Never develop new features or apply bug fixes directly to the main branch.
• Always create separate branch for a new feature or bug fix.
• Apply frequent merges of the main branch to your feature or bug fix branch to avoid merge conflicts.
• When the feature or bug fix is ready, merge it back to the main branch.

You can add another branch branching off of master.

1. checkout master
2. git branch covid-plots; git checkout covid-plots
   • git checkout -b covid-plots # the above 2 steps in a single shortcut.
3. git log shows covid-19 where it was before, covid-plots pointing to HEAD and master.

Read up what each argument does. but useful command!

• git log --all --graph --decorate --oneline Is another useful ßargument to the git log command.

This create a new branch called plots, and then switches into it at once. This can be done in one step:

• git checkout -b plots

Make sure you are not on it, and that you have merged any changes you want from that branch.

git branch -d branchname # only deletes branch if it has been fully merged

git branch -D branchname # deletes branch using force (whatever the merge

When run in unified diff mode with the -u option you get:

First two lines are

--- from-file from-file-modification-time
+++++ to-file to-file-modification-time

--- from-file    from-file-modification-time
+++ to-file        to-file-modification-time

Next come one or more chunks of differences with this syntax:

@@ from-file-line-numbers to-file-line-numbers @@
line-from-either-file
line-from-either-file…

If a chunk and its context contain two or more lines, its line numbers look like ‘start,count’. Otherwise only its end line number appears.

The lines common to both files begin with a space character.

The lines that actually differ between the two files have either a + or a - characters in the left print column:

‘+’
A line was added here to the first file.

‘-’
A line was removed here from the first file.

Here is a larger example:

$ diff -u 1stfile 2ndfile
--- 1stfile     2020-05-22 11:32:48.000000000 -0400
+++ 2ndfile     2021-02-02 16:20:15.000000000 -0500
@@ -1,12 +1,10 @@
 # The first file has twelve lines in this block
 # The second file ends up with only 10 lines in this block
 #
-# macOS Notice
+# macOS Notice  This line was changed on the 2nd file.
 # 
 # This file is not consulted for DNS hostname resolution, address
 # resolution, or the DNS query routing.
 #
-# This line is in the first file, but will be removed in 2nd file
-# This line also will be removed in 2nd file.
 #
@@ -17,3 +15,5 @@
 nameserver 208.67.220.220
 You can get so confused that you'll start in to race
 down long wiggled roads at a break-necking pace
+#  And        # Two new lines added to second file,
+# On and on . # hence now we are looking at a block of 5 lines in 2nd.

will send local changes to the remote repo

• git push <remote> <local branch>:<remote branch>

• git push zp-origin covid-19:covid-19

this sends the changes from my local branch to the remote server, on that specified branch.

git push zp-origin master:master

Every time you want to get the remote repo updated with your latest changes you could run git push zp-origin master:master again. However….. git has a shortcut for this and it is by saving this parameter permanently:

So if you have cloned a remote repository and then want to refresh any new files or changes from that remote repository, simply git fetch. This will fetch any new changes from the default repository, in our case zp-origin.

The git fetch will download the remote repository files into your local repository, NOT your current working directory, so there is no danger of overwriting files in your working directory.

If you have several remote repositories, you can git fetch <remote>

After a fetch, your local master reference will NOT have changed, so if you like the new (more recent) changes you downloaded from the remote repo, you can run git merge to move your local master reference up to the latest new changes you just downloaded.

The git fetch;git merge combo happens so often, git has made a shortcut for this, called git pull. Actually it is more like a

• git fetch
• git checkout
• git merge

You will see that you are "fast forwarding" your local repo to be up to date with the remote.

From developer.cisco.com this info on git pull

Local copies of the Git repository do not automatically get updated when another contributor makes an update to the remote Git repository. Updating the local copy of the repository is a manual step. Git provides a git pull command to get updates from a branch or repository. git pull can also be used to integrate the local copy with a non-parent branch.

1. The local repository (.git directory) is updated with the latest commit, file history, and so on from the remote Git repository. (This is equivalent to the Git command git ~fetch~.)
2. The working directory and branch is updated with the latest content from step 1. (This is equivalent to the Git command git merge) So, you are in danger of files in your working directory being overwritten.
3. A single commit is created on the local branch with the changes from step 1. If there is a merge conflict, it will need to be resolved.
4. The working directory is updated with the latest content.

You can download a *entire* remote repository with all the files in it down to a local repo by by using the git clone <url> <folder name> So in our simulated remote repo case we can run git clone ./gitlabzp testing which could be "cloning from the remote repo into a directory called testing"

So your local repository becomes truly like a clone of the remote repository. Usually done when you join a project that has been ongoing by remote users. Or, when you want to simply create a local repository for learning purposes, but want to start with a bunch of public code.

To set up your personal preferences. or just vim ~/.gitconfig file (accomplishes the same as git config.)

You can also enter config commands from the command line as follows:

• git config --global user.name "<user's name>"
• git config --global user.email "<user's email>"

This is a requirement. Git uses this info in git blame

can be fairly big, but –shallow will only get you the master.

This will interactively check each line of changed text to see if you want to include that in the commit. Perfect for the times you have a bunch of temporary debug print statements that you don't need to commit. git diff before you git add -p will also show you all the possible changes before you interatively stage each edit individually. so 'y' or 'n' for each line and you are done.

• git diff
• git add -p
• say 'y' to a few changes, 'n' to a few changes
• git diff --cached # to see what changes are due for a commit
• git commit # only the 'y' changes are committed
• git checkout filename <see note>

<note> the checkout is needed because The local file still has the rejected changes, so we would need to discard them, by overwrittig the direcotry contents with the newly committed git version

find who made the change in a give line, find who made the commit and which was the commit that saved that line You can then see the hash (id) of the commit and then git show 252abacef to see all the detail of that change.

temporary save some editing changes without committing them. Suppose that you are in the middle of development, and you have not staged any changes yet because your code is not ready to be committed. You are assigned to a more urgent request, so you have to focus on other files, but you do not want to lose changes that you have done so far. You can use the git stash command to temporarily save your current changes. Once you finish with other work, you can then use the git stash pop command to retrieve your previously saved changes.

• git stash list to show you what's going on.

Let's you automate going back through each commit to find when a version broke some function that was working before.

/Users/zintis/git-local[10] % cd ..
/Users/zintis[11] % cd bin
/Users/zintis/bin[12] % git clone https://github.com/duosecurity/duo_unix.git
Cloning into 'duo_unix'...
remote: Enumerating objects: 9, done.
remote: Counting objects: 100% (9/9), done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 2609 (delta 1), reused 1 (delta 1), pack-reused 2600
Receiving objects: 100% (2609/2609), 1023.65 KiB | 1.78 MiB/s, done.
Resolving deltas: 100% (1597/1597), done.
/Users/zintis/bin[13] % 

should show the file as "modified", under "Changes not staged for commit:"

Also git add -A to add all the files in the local directory

To undo a git add, before being committed.

should now show the file under "Changes to be committed"

Asks for you to edit a note explaining the changes, then commits them

Will create a local copy of the files in the repository into the local dir.

• A minus ("-") sign at the beginning of the line refers to the state in your local repository
• a plus ("+") sign at the beginning of the line refers to currently made changes in your actual live file in the directory

git diff filename will show you what has changed in the file specified, compared to the file as saved in the last commit (i.e. snapshot). Or, more accurately, git diff filename compares current filename to the filename pointed to by HEAD. So you can be explicit and say git diff =HEAD= hello.txt

To look at the diffs from earlier commits, you have to specify the hash of that commit i.e. the commit id

for example git show 2097655d8d0d1737a0da7f27ff07d78e797c89e8

commit 2097655d8d0d1737a0da7f27ff07d78e797c89e8
Author: Zintis Perkons <zintis@icloud.com>
Date:   Sat May 9 16:38:35 2020 -0400

    Improved the clarity of the internal links section in orgmode.org.

diff --git a/orgmode.org b/orgmode.org
index bf26b8d..005a468 100644
--- a/orgmode.org
+++ b/orgmode.org
@@ -133,32 +133,38 @@
     It can also be specific lines in files, like my python [[file:emacs.org::*Elpy][Elpy in emacs.org]]

 ** adding links from specific =head=ings in other org files
-   When in the target org file, at the chosen link, type
+   When in the target org file, (or in the current file) at the chosen link, type
    ~C-c l~ for "org-store-link", which was previously set in init.el as follows:

but since humans don't like 40 character long names, git creates the concept of "references"

will give you information of the object that has the key specified (i.e. the hash) For instance you can use git cat-file -p to drill down into the git data structure using this command.

Here's an example

ansible@c8host ~/playground/demo[1027] $
git commit
[master (root-commit) d8235c4] adding hello.txt to a brand new git repository
 1 file changed, 1 insertion(+)
 create mode 100644 hello.txt

ansible@c8host ~/playground/demo[1028] $
git log
commit d8235c40b7e6e78cdfe80b40339d4242ce95581f (=HEAD= -> master)
Author: Zintis Perkons <ansible@zintis.ops>
Date:   Fri May 15 15:15:26 2020 -0400

    adding hello.txt to a brand new git repository

ansible@c8host ~/playground/demo[1029] $
git cat-file -p d8235c4                            <<<<<=========  * * * 
tree 9f5a7a63c2b6f9e5381cf4cfdb03b0ee55da6b9e
author Zintis Perkons <ansible@zintis.ops> 1589570126 -0400
committer Zintis Perkons <ansible@zintis.ops> 1589570126 -0400

adding hello.txt to a brand new git repository

ansible@c8host ~/playground/demo[1030] $
git cat-file -p 9f5a7a63c2b6f9e5381cf4cfdb03b0ee55da6b9e
100644 blob 9075408ae349c4b9df8e277ce0cd31e7c8a83156	hello.txt

ansible@c8host ~/playground/demo[1031] $
git cat-file -p 9075408ae349c4b9df8e277ce0cd31e7c8a83156
hello wlrd

You can use git cat-file -p hash repeatedly to drill down into the tree as deep as you want. Every deeper object return you can cat-file its hash, and keep going. Start with git log to see the most recent changes, and get that hash and off you go.

refernces = map<string, string> Where you create a map of the 40 character hex sting to a human readable string.

The strings are what you write in a commit. A reference is also called a "pointer" They are the same thing.

The git tree and commits is immutable, but references are mutable and typically get moved from one commit to another.

This is actually a shortform for two commands:

1. git branch covid-19
2. git checkout covid-19

You can create custom references, which as all other references are, are simply labels attached to a git hash.

pulls down the files from the remote git repository

will send the locally modifed file to the remote git repository

• <tab> to expand sections OR to expand a file magit-section-toggle
• hammer magit-visit-thing ?
• s on an untagged file, to stage it. magit-stage
• u on a stagge4d file to unstage it. magit-unstage
• ? show available commands. magit-dispatch q to quit this command display
• c commit magit-commit
• c commit magit-commit-create (c is entered twice )
• b branch magit-branch
• b b again which is magit-checkout ( b is entered twice )
• s spin off a branch magit-branch-spinoff
• l log magit-log
• l log magit-log-current (l is entered twice)
• q quit this command (magit-log-bury-buffer)
• w magit-am
• w magit-am-apply-patches (w is entered twice)
• C-c C-c to close the edited commit.
• SPC show a magit diff magit-diff-show-or-scroll-up
• 0 show magit diff default magit-diff-default-context
• 1 show section level 1
• 2 show section level 2
• 3 show section level 3
• 4 show section level 4
• : magit-git-command
• < beginning of buffer
• > end of buffer

So a typical, basic magit workflow is: M-x magit

• s -
• s |- or all changes with S
• s -
• c c

Make your editing changes, then C-c C-c actually I think it's C-c c Find out which one.

• $ bring up the details of the error message that just appeared.
• P push your commit o repository i.e. github

M-x magit-status (you can set C-x g to map to M-x magit-status by using: (global-set-key (kbd "C-x g") 'magit-status) in your .emacs-d/init file

Refres (g/G) global-magit-file-mode (C-c M-g) magit-dispatch (C-x M-g)

First a good idea to confirm that C-x g is not being used by anything useful C-h k C-x g See help magit status section above.

? will display the magit commands availale. (must be in the magit-status buffer)

M-n/p, j to move around the git status window (next/previous) M-1 or -2 or -3 or -4 , TAB, S-<tab> for visibility

D C-c C-t (or M-x magit-diff-trace-definition) ?

Once in the diff buffer (D) see toggles such as -U for context lines and -t for hunk refinements which can show you the actual changes made to files between git commits.

git diff –word-diff (is the equivalent git cli command.

In a diff buffer, you can get the function history list as well… That is a list of historic changes to the function you are currently looking at say in python, or in .php or whatever program is being edited in magit mode.

L can toggle dates from absolute dates or days or hours ago.

shows who and when people committed people.

$ will show you what is happening with your git commands, at any time you want.

• to show dates when lines or sections were added or changed or deleted from a git file.

c -e allow empty commit -a stage all modified and deleted files –all

• v show diff of changes to be committed
• M-n or M-p can browse through past commit messages. (once in the commit buffer) i.e. have hit c

You can also C-c C-a to commit ammend (see docs for all the options of C-c C-a to commit ammend.)

b brings up the branch popup. Can create a new branch, or open a branch, can check it out or not in the same command.

V VV (magit-revert-and-commit) Vv (magit-revert-no-commit)

Read the docs on this. What follows is just to make you aware that this feature exists, and is fairly useful:

Get your mouse onto a recent commit (pick one) and hit: x (and type Head) to revert to that version. ? x (and bring up the log to see what version you want to revert to.)

z z (magit-stash-both) Stashes index and working tree, untracked files included.

Once a change is stashed, you can hit a on the stash (under git status buffer) at a latter time, to then incorporate the change into the branch at that time.

r i (magit-rebase-interactive) Rebase allows you to resolve conflicts and rewrite history. ** very useful

magit does this very well.

Look at the log, choose a commit where you want to start the rebase. hit r i For instance c76309r then you will see a list of commands. Read them and use C-c C-c to execute what you want with the rebase. - any errors will pop up for you to resolve, or skip and continue forward.

C-c C-k to kill buffer out of this if you do not want to make any changes.

B B (magit-bisect-start) B s (magit-bisect-run) B b (magit-bisect-bad) B g (magit-bisect-good) B r (magit-bisect-reset)

This is good if you have a bug and want to know when the bug came into being.

Works good if you have been following proper git etticat, hygene and standards, with proper messages left on commits, etc.

Read up on this.