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).

It discards working-tree changes to <file> by replacing it with the version from the index (staging area). If the file is not staged, that effectively means “restore from =HEAD=​”.

Perils:

• It can permanently lose local edits in your working directory (not just “unstage”).
• It does not create a commit or safety net.

Safer / modern equivalents:

• git restore <file> (restore working tree from index)
• git restore --source=HEAD <file> (force restore from last commit)

git reset HEAD <file> and git checkout -- <file>

(For the “unstage” use-case) git reset replaces:

git reset HEAD <file>

Because git reset <file> defaults to HEAD, so:

git reset <file>

is the shorter equivalent.

Note: git checkout -- <file> is a different operation (discard working-tree changes) and is now commonly written as:

git restore <file>

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

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.

• same scope (i.e. same fork): #<num>
• another fork: username #<num>
• different repo: username/repo#<num>

Github create a 'trackback' event

A little icon with their progress appears beside the headings.

git pull <URL> patch-1

here patch-1 is the branch.

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.