Pro Git

True. it can track new files, stage files, and mark merge-conflicted files as resolved.

it may also be able to do more things.

SHA1 hash. 40 length. Hex; i.e. 0-9 + a-f

1. Modified (changed in your working directory)
2. Staged (in the index, ready for commit)
3. Committed (saved in the repository / HEAD history)

it is a file called index.

• --system | all users: /etc/gitconfig
• --global | current user; all repos: ~/.gitconfig or ~/.config/git/config
• --local= | .git/config per repo control

No. local trumps global which trumps system. This is also the case for configuration files more generally.

git config --list

git config <key> ; where key can be something such as user.name or user.email, core.editor, etc.

1. tracked: things previously staged; newly staged files.

   • can be modified, unmodified or staged
2. untracked: everything else. the stuff git doesn't know about.

trick question; git add automatically adds directories recursively.

it begins tracking the file and stages it for committing. it is multi-purpose and can do even more. think of it as "add precisely this content to the next commit"

files ending with .o OR .a and files ending with .~.

#

end the directory name with /

note, unless you add the prefix slash, it will ignore that named directory at all levels! the prefix slash means 'not recursively'

• *.a
• !lib.a
• /TODO
• build/
• doc/*.txt
• doc/**/*.pdf

no, it can have one in each subdirectory if required.

it compares what is in your working directory with what is in your staging area.

git diff --staged

they're synonyms!

shows the diff between last commit and what is staged

adds a git diff to the commit popup so you can see exactly what you are committing.

git commit -a -m "<message>"

this will only commit the files that were already being tracked. no new files.

you must remove the file from the tracked files (staging area) and then commit.

git rm does this and also deletes the file from the working directory (so it's not "unstaged" later)

if you modified the file or added it to the staging area.

it's a safety feature to prevent removal of files that aren't in a snapshot.

git rm --cached <file>

reverse chronological order – most recent commits first.

shows only last 2 commits with diff (or patch) details

--stat prints a list of modified files below each entry. how many such files, and how many lines were changed.

--pretty has options: oneline, short, full, fuller, format: _, etc.

shows last 2 commits.

git log --since=2.weeks

also, --until is useful too.

dates can be "2008-01-15" or even relative: "2 years 1 day 3 minutes ago"

git log -S<needle> (the “pickaxe”) shows commits where the number of occurrences of <needle> changes (added/removed).

(Note: git log -s just suppresses diff output.)

at the very end, separated by -- to segregate from the other options: git log -- path/to/file

--no-merges

Use git commit --amend.

• To fix the message only: git commit --amend -m "new message" (or run without -m to edit in your editor)
• To add a forgotten file: git add <file> then git commit --amend --no-edit

Amending rewrites the last commit: it creates a new commit with a new hash (the old commit becomes unreachable unless referenced). Avoid amending if the commit has already been pushed/shared (or you’ll need a force push).

git remote add <shortname> <url>

it just downloads the data from whichever remote is the argument, and places it in the .git folder. no merging occurs.

It resets the file in the index to match HEAD (unstages it) while leaving the working directory version unchanged.

git remote -v

OR for more info on a single remote: git remote show origin

git tag

with optional -l that respects globs -l ""

lightweight: pointer to a specific commit

annotated: full objects. checksummed; contain metadata: tagger name, email, date, message.

git push <remote> <tagname>

or for lots: git push <remote> --tags

delete: git tag -d <tagname> (which does so locally) followed by git push <remote> --delete <tagname>

git tag -a <tagname> -m ""

git tag -a <tagname> <commit_hash>

git show <tagname>

when other people have based work on your commits.

do not rebase those.

git rebase master server

"replay the commits onto master from server branch"

rebase: git checkout experiment git rebase master "go to experiment branch, apply patches to master"

merge: git checkout master git merge experiment "merge changes into current branch"

takes all the changes committed on one branch and replays them on another branch

it's telling you information about what we have cached from the last fetch. we are better off running git fetch --all; git branch -vv

shows what tracking branches have been set-up.

lists out local branches with more information; what each branch is tracking and if the local branch is ahead, behind or both.

short for the upstream url. hence @{upstream} is another short-form.

git merge @{u} merges the current branches' upstream into the current branch.

git checkout --track origin/serverfix which itself is shorthand for git checkout -b serverfix origin/serverfix

no, only unmodifiable pointers.

you need to run git merge origin/<branch> which pulls in the changes into your current branch. to make a new branch, use git checkout -b serverfix origin/serverfix

git push -u <remote> <branch>

This pushes the local branch to the given remote and sets its upstream, so that later you can just run git push on that branch.

Creating a branch does not automatically push it; you must push it at least once as above.

git fetch <remote>

git ls-remote <remote>

OR

git remote show <remote>

git branch -m <old> <new> (rename branch locally)

git push -u origin <new> (push new branch name + set upstream)

git push origin --delete <old> (delete old branch from the remote)

Perils: if others are using the old branch name (locally or tracking origin/<old>), renaming/deleting it will break their setup until they rename or re-point their branches.

shows you which branches have not been merged into master. You can give the final argument to see info on a branch you don't have checked out.

shows you which branches are already merged into the branch you're on.

--no-merged shows the branches that have work that you have not merged in.

naked is a simple listing.

 git branch
  iss53
,* master
  testing

note that * tells you what is currently checked out! (i.e. where the HEAD points)

-v also shows the last commit on each branch:

$ git branch -v
  iss53 93b412c Fix javascript issue
,* master 7a98805 Merge branch 'iss53'
  testing 782fd34 Add scott to the author list in the readme

edit the files and choose the correct code.

git add and git commit (staging the file marks it as resolved). you could also use git mergetool

simple three-way merge. uses the two snapshots pointed to by the branch tips and the common ancestor of the two.

git checkout main

git merge hotfix

note if you can fast-forward then you should delete the hotfix branch after merging: git branch -d hotfix

When the merge has no divergent work to merge together it just moves the branch pointer forward

git checkout -b <new_branch_name>

alternatively you can now use git switch with --create / -c for a new branch.

note git switch - changes to the last branch.

No, the pointers are just simple text files with the 40 character SHA1-hash checksums of the commit it points to.

41 bytes cost (+ newline)

git log <branch_name> shows logs for an arbitrary branch git log --all shows for all branches but by default, it's whatever HEAD is pointing to.

git checkout <branch_name>

git branch <branch_name>

git log --oneline --decorate

Modern note: --decorate is now on by default in most Git versions

Keeps a special pointer called HEAD that is a pointer to the local branch

• 0 for the initial commit (no parents)
• 1 for regular commits
• multiple (2?) for merge commits

stores a commit object with a pointer to the snapshot. also contains metadata + pointer/s to directly previous commits.

when the file is staged.

implies a version of the file has been stored. (called blobs)

Write "Fix bug", not "Fixes bug" or "Fixed bug".

The convention matches with commit messages generated by commands like git merge and git revert.

Yes: you can combine short flags, so:

git commit -am "msg"

is the same as:

git commit -a -m "msg"

But no, this is not true for all flags. Only single-letter short options can be grouped like this, and only when they don’t require their own attached value.

Examples:

• OK: -am (equivalent to -a -m; -m takes its message as the next argument)
• NOT like this: you generally can’t combine long options (e.g. --amend) or assume every short flag combination is valid.

The three-dots range A...B is the symmetric difference between the two branches.

git log --no-merges issue54...origin/master

shows commits that are reachable from either issue54 or origin/master, but not from both — i.e. commits that are unique to one side or the other.

(You can add --left-right to see which side each commit comes from.)

-u is short for --set-upstream.

In:

git push -u origin featureB:featureBee

• origin is the remote.

• featureB:featureBee uses the <src>:<dst> syntax:

  • featureB is the local branch.
  • featureBee is the remote branch name on origin.

The -u / --set-upstream flag makes the local branch featureB track origin/featureBee, so later you can just run git push or git pull with no extra arguments.

It takes all the changes introduced by branch featureB (since the merge-base with your current branch) and applies them to your working tree/index as one combined change, without creating a merge commit and without recording the branch history.

After running it:

• the changes are staged (like a big “combined” diff)
• you still need to run git commit to create the single squashed commit
• it does not mark featureB as “merged” in Git history (a later normal merge may try to reapply commits).

"_a_​pplies a series of patches from a _m_​ailbox"

reads on mbox file, but can also accept a .patch file.

shows last commit with fuller formatting.

git log <branch> --not master

-p

On your feature branch, to see what this branch has introduced since it forked from master:

git diff master...

This uses the three-dots syntax:

• In general, git diff A...B means: diff between merge-base(A, B) and B (changes on B since the common ancestor).
• So git diff master... (or git diff master...HEAD) shows commits that are on your current branch but not on master, ignoring changes that only master has.

(You can also write git diff master...branch if you want to compare explicitly to branch.)

git merge-base contrib master

it is like a rebase, but for a single commit.

git cherry-pick <commit_hash>

(cherry picks that commit into current branch)

Gives a human-readable string to describe a commit.

gives a short log of all the changes since the last release of v1.0.1

git clone <remote> <optional_path>

a Git repository with no working directory.

git clone --bare <source>

git init --bare <directory>.git

the .git part is convention for bare repositories.

Generates a public and (corresponding) private key.

-o saves the private key in a format more resistant to brute-force attacks. (use this option if setting a password)

pros:

• lots of control
• run everything from within your own firewall
• some organisations might not allow code on another server

cons:

• time to set-up
• maintainence efforts

local, http, secure shell (ssh), git.

gh issue list --state open

gh issue view <num>

No, it is a Git host. A place where some functionalities become simpler.

by email address

Forks and pull requests are not core Git features; they are hosting-platform features (e.g., GitHub/GitLab/Bitbucket).

In Git itself, you only have repositories and remotes; a “fork” is just another repo you can add as a remote, and a “pull request” is a workflow built on Git commits/branches plus platform review + merge tooling.

True. Because you can keep pushing to the topic branch even after the pull request is opened.

Commit to the topic branch and push. The pull request gets updated automatically.

Github create a 'trackback' event

A little icon with their progress appears beside the headings.

plumbing.

gives a list of all the branches and tags and other references in the repo.

It shows contributors the rendered version of the file when they start opening a pull request.

What kind of entities have this functionality in Github?

1. Hooks and Services
2. API

5,000 vs. 60.

There is never a "best way", but other languages like Go, .NET, Objective-C and Ruby do have more idomatic frameworks for the API.

git rm -r --cached (unstages everything)

git gc --prune=now (deletes blobs)

for each line in a file, it shows the last commit that modified it: who made the change, when, and which commit it was.

e.g. git blame path/to/file.py

It shows the contents of file as it was in commit (or any commit-ish), without changing your working tree or HEAD.

e.g. git show HEAD~2:src/main.py prints how src/main.py looked two commits ago.

What is the other requirement?

They are the same.

Note though, that git log --pretty=oneline does not abbreviate the commits.

Where rev-parse is a plumbing command, and topic1 is a branch (pointer)

Nope – it only records the current users actions.

"Reference log" – a log of where the HEAD and branch references have been (for the last few months)

-g

What about HEAD^n?

traverses the parent of HEAD, 3 times. i.e. grand-grand parent of HEAD (equivalent to HEAD~~~

useful for isolating commit ranges?

Asks Git to resolve a range of commits that are reachable from one commit but not from another.

lists all commits reachable from experiment but not reachable from master

useful to see what you are about to push to a remote.

(origin/master is the remote; recall the double-dot syntax)

git log origin=master..

synonyms to --not, hence

git log refA..refB

git log ^refA refB

git log refB --not refA

specifies all the commits that are reachable by either of the two references, but not by both.

gives angle brackets pointing at the reference the commit belongs to:

$ git log --left-right master...experiment
< F
< E
> D
> C

most useful with triple-dot syntax

git add -i

takes the dirty state of the working directory (modified tracked files and staged changes), and saves them on a stack of unfinished changes that you can re-apply later.

git stash list

git stash

or

git stash push

git stash apply

It does not. It only applies the stash.

git stash drop <stash_name>

or

git stash pop

removes files that are not tracked.

--dry-run ( or -n, which you can later swap for -f )

Nope, but you can make it do so with -x

git grep – allows searching across branches! (and perhaps even through history)

--count

--line-numbers (-n)

-p (--show-function)

1. change commit message

   • git commit --amend

2. change commit contents

   • make modifications
   • stage changes
   • git commit --amend

Note: this is for when you make tiny changes that do not warrant a new commit message

git rebase -i HEAD~3

note: HEAD~3 will be the commit that is the parent of commit head - 2

perils: rewrites last 3 commits

with the interactive rebasing tool.

git rebase -i <branch>

• changing multiple commit messages
• reordering commits
• squashing commits
• splitting commits
• deleting commits

filter-branch

git filter-branch --tree-filter 'rm -f passwords.txt' HEAD

the parent of HEAD

1. git reset --soft HEAD~
2. git reset [--mixed] HEAD~
3. git reset --hard HEAD~

undid the last commit (changes branch HEAD points to)

and unstaged everything (updates index with snapshot of HEAD~1)

1. moves branch that HEAD points to
2. updates index with contents of new snapshot that HEAD points to.
3. makes working directory look like index

1. moving branch that HEAD points to is skipped (files are not commits!)
2. make index look like HEAD. practically this unstages the file.

git reset --soft HEAD~2

git commit

git merge --abort

reverts the repository back to the last committed state

git merge -Xignore-space-change <branch>

or instead use the flag -Xignore-all-space

"all-space" ignores whitespace completely when comparing lines, "space-change" treats sequences of one or more whitespace characters as equivalent

$ git ls-files -u
100755 ac51efdc3df4f4fd328d1a02ad05331d8e2c9111 1 hello.rb
100755 36c06c8752c78d2aff89571132f3bf7841a7b5c3 2 hello.rb
100755 e85207e04dfdd5eb0a1e9febbc67fd837c44a1cd 3 hello.rb

shows the conflicting files with

1. common ancestor
2. yours
3. theirs

--ourss shows what the merge introduced.

--theirs shows us how the merge differed on their side

--base shows how the file was changed on both sides.

What are the options available to conflict?

triple-dot syntax:

git log --oneline --left-right HEAD...MERGE_HEAD

git log --merge

usefully, you probably do want to add --oneline and --left-right

what is currently in a conflicted state.

Note: this can be helpful to see what needs to be resolved.

1. move the branch that HEAD points to
2. make index look like HEAD
3. make the working directory look like the index.

makes a new commit which undoes all the changes from an existing one.

allow us to choose which files to use in merge conflicts.

-s; can take recursive (default) or ours as options. potentially others are available too.

"re-use recorderd resolution"

restricts the lines of the <file> in question

tries to track down where (else) (in the codebase) the lines in the current file originated from

helps us find the commit that is broken with a binary search

start with git bisect start, then follow it up with git bisect bad.

this will tell it we are in a broken state.

then git bisect good <commit> where <commit> is the commit that is working.

repeat this good, bad cycle until git finds the offending commit.

run git bisect reset when done. this resets HEAD.

Can we do it from the git clone command directly?

git submodule update --init,

but for good measure you should really also add the --recursive flag, in case those submodules have submodules too:

i.e. git submodule update --init --recursive

git diff --submodule

goes into all the submodules and basically runs git fetch followed by git merge

git push --recurse-submodules=check

Note: --recurse-submodules=on-demand will try to do the git push for you in all submodules.

How can we use it to create a unified diff?

add the recurse-submodules flag to git checkout

This (after git version > 2.13) takes care of placing the submodules in the right state for the branch we're on.

What is wrong with simply doing rm -f <subfolder>; git submodule add ...subfolder.git?

Rebases the current branch onto c1, starting from commits after c2.

In other words: take all commits reachable from HEAD but not from c2, and replay them onto c1.

This is useful for moving a branch to a new base while excluding certain commits.

creates a local file that contains the entire repo. you must add all the refs desired. it can later be unpacked with git clone repo.bundle repo as usual!