Skip to content

Instantly share code, notes, and snippets.

@jaybobo

jaybobo/.gitconfig

Last active August 29, 2015 14:12
Show Gist options
  • Save jaybobo/e2fb529d48e54c30d233 to your computer and use it in GitHub Desktop.
Save jaybobo/e2fb529d48e54c30d233 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
.gitconfig
[core]
excludesfile = /home/rstovall/.gitignore
[alias]
st = status
ci = commit
co = checkout
br = branch
[user]
name = Snuggs
email = rashaun.stovall@clash-media.com
[color]
interactive = auto
[color]
ui = auto
[color "branch"]
current = yellow reverse
local = yellow
remote = green
[color "diff"]
meta = yellow bold
frag = magenta bold
old = red bold
new = green bold
[color "status"]
added = yellow
changed = green
untracked = cyan
[color]
ui = true
[color "diff"]
whitespace = red reverse
[core]
whitespace=fix,-indent-with-non-tab,trailing-space,cr-at-eol
Raw
git notes
NOTES =======================================================================================================================
Hey guys, I won't overbear you with a ton of stuff on GIT. First we will go over a workflow. keep in mind this is JUST A CONVENTION.
- WE USE INTEGRATOR WORKFLOW (We WERE using centralized workflow)
- CREATE "TOPIC BRANCH" for EVERY feature. * A topic branch that has been merged elsewhere should not be rebased (including production).
- "habitually" (regularly for no real reason) merging an integration branch (production) into your topics
and by extension, merging anything upstream (remote) into anything downstream (local)on a regular basis is frowned upon.
- topic should contain a single (well-separated) change.
- SHOULD USE THE ONE COMMIT ONE FEATURE IDIOM (Linus T)
- easier to merge individually. can easily be removed. easier code reviews.
- rebase onto master before making team branch public
- have integrator merge (FAST-FORWARD) head of master (production) to head of team branch.
* Just because you make one feature be one commit on the public facing side does not mean that commit really was 15 squashed commits which involved 2 developers locally.
* local history DOES NOT have to be the same as public facing history. public history should be clean.
- Eric brought up a great point…what if your team requires some NEW work in production. This can easily be accomplished by rebasing your work onto the current state of production.
- This is preferred over merging since rebasing will put you at the current state of production instead of merging production into our branch then our branch into production
- also, MERGE CONFLICTS are MUCH more simpler to resolve with rebase than traditional merge.
because rebase takes your commits INDIVIDUALLY and applies them one by one ON TOP OF the head of the target branch as apposed to recursively merging history (big mess you can see it in gitk)
****************
- LINUS goes over this in GREAT detail in this article… MUST READ!
http://lwn.net/Articles/328438/
****************
Once we have clean histories and are "ready to go to production" we need to have a convention methodology of getting the merges in. There are GREAT strategies in the following articles. (especially this one http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html)
http://lwn.net/Articles/328438/
http://unethicalblogger.com/node/276
http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html
http://blog.woobling.org/2009/05/git-rebase-considered-awesome.html
Git Book - pg. 224 (Upstream Consumer
** IN MORE DETAIL **
- The state of the index becomes the tree of the next commit
Why rebase over merge (INCLUDING GIT PULL REBASE) -
When looking through history, it is just never interesting to know when the guy working on the feature stopped to sync up. It might be useful for the guy while he's doing it, but that's what reflog is for. It's just adding noise for everyone else.
- Eric said "But I am waiting for someone else's changes" - Rebase your work to the head of production and keep working on it.
As your git knowledge increases you find yourself looking a lot more at history than with any other vcs I've used. If you have a ton of small merge commits, it's easy to loose focus of the bigger picture that's happening in your history.
When looking through history, it is just never interesting to know when the guy working on the feature stopped to sync up. It might be useful for the guy while he's doing it, but that's what reflog is for. It's just adding noise for everyone else.
=============================================================================================================================
[ ] - optional
| - or
< > - variable
WORKFLOW
-------------------
-> git pull . remotes/<repo>/<branch> # pull stable branch into current branch (or new branch) ** Pull always merges into current branch! **
-> git log -p <branch>..remotes/<repo>/<branch> # to see what has changed since branch was pulled last
# * or git diff (with no flags)
-> git checkout -b <feature-name-branch> # create and checkout new branch at tip of HEAD of current branch (possibly at SHA commit point)
****************************************************************************************
-> ** DO A SMALL BIT OF WORK and commit ** (rinse, repeat)
****************************************************************************************
-> git rebase # can do forward (and backward) porting.
[-i] # for interactive rebase console
[--continue]
[--abort]
[HEAD~n] # (where n = number of commits that consist of the new feature) Squash commits into a single commit
[--onto <branch_to_put_new_work_on> <another_branch_merge_base> <branch_with_new_work>] # C:>git rebase --onto master work-branch^ feature
<branch_to_put_new_work_on> # "forward porting" branch history onto branch
* Could cause merge conflict if changes made to same file if so, fix merge conflict and run >git rebase --continue
* CONFLICT (content): Merge conflict in file.txt
-> git reset --hard ORIG_HEAD # ORIG_HEAD is the starting point of the rebase
-> git rebase --abort # if the abort needs to be disregarded
* This can be dangerous in some cases
--never throw away a commit if that commit may itself have been merged into
another branch, as doing so may confuse further merges.
-> git checkout <production_branch> # switch to production
-> git merge <feature-name-branch> # (optional) Do a fastforward to move production to the tip of the head
-> (optional) delete <feature-name-branch>
MISCELLANEOUS COMMANDS
--------------------------------
*** SEE A LOG OF ALL COMMITS IN HISTORY (Will take a while determining the project)
git fsck --unreachable | grep commit | cut -d\ -f3 | xargs git log --merges --no-walk --grep=WIP
*** SEE A LOG OF ALL COMMITS IN HISTORY USING GITK (Will take a while determining the project)
gitk --all $( git fsck --no-reflog | awk '/dangling commit/ {print $3}' )
gitk [--all | <branch_name>] [--since] [--until] [<path_name>] [<file_name>]
git mergetool # work through conflicted files
git remote show <repo> # show all remote branches and whether or not they are new or tracked
MERGE TYPES
--------------------------------
Resolve (trivial), Recursive (default strategy), Octopus (3 or more),
Ours Forces merge to occur using local changes while keeping names of merged commits * Produces commit *
Subtree Performs merge but merged files exist in a subtree of the HEAD* Produces commit *
HEADS
--------------------
HEAD, MERGE_HEAD, FETCH_HEAD, ORIG_HEAD
FLAGS
------------------------------
<repo>^ # each carat(^) | tilde (~) means a different parent (from merge)
--graph # show graph representation
--color # color coded output
--pretty=oneline # formats into a single line
<blob>..<blob> # comparison
CREATE
------------------------------
-> git clone <repo> # this is similar to "checkout (but downloads the repo....I think)
-> git symbolic-ref HEAD refs/heads/<new_branch> # allows the creation of an empty new branch before initial commit
-> git branch <branch_name> <SHA1> # creates branch at that commit point (most recent commit used when not provided!)
#####################################################
## Create a local branch that is checked out and at the head of the remote branch
-> git fetch origin <remote_branch_name>:<local_branch_name>
#####################################################
-> git checkout
[-m] <branch> # will checkout <branch> while also merging changes from current branch into checked out branch.
[-b] # create new branch
[--ours | --theirs] # creates new branch using local or remote code (only during merge conflicts)
<new_branch_name>
[<branch | file | SHA hash (or part of hash)>] # create starting point of branch from this blob
-> git commit [-am "Message"] # commits all AND message
-> git merge-base <branch_1 | SHA hash> <branch_2 | SHA hash> # creates a unified base commit point branches can fall back to.
READ
---------------------------------------------
-> git branch -v (or git show-branch for all actions) # shows us the position of each branch's HEAD
-> [--merged] # shows all of the branches that have been merged into the current working branch
-> [--contains <SHA_1>] # shows branch which contains sha hash
-> git show-branch [<branch_1>,…<brach_n>] # above --- is all branches. each branch is associated with a single column of output (star=current branch)
[--more=n] # how many commits to retrieve
[-g] # shows graph
[-gN] # shows graph N commits back
-> git hash-object <file_name> # get the hash of a file
-> git whatchanged # shows which blobs changed
-> git show # shows diffs
[sha:<file_name | folder>] show what changed in a specific file]
-> git ls-files
[-s] # shows file in all stages (during merge conflicts)`. (i.e. 0=non-conflicting, 1=merge-base, 2=ours, 3=theirs)
[-u] # show unmerged files only
-> git ls-tree <sha> # only for tree shas
[-s] # shows file in all stages (during merge conflicts)`. (i.e. 0=non-conflicting, 1=merge-base, 2=ours, 3=theirs)
[-u] # show unmerged files only
-> git blame <filename> # shows which commit/author each line of a file belongs to
-> git log # cares about the files and history
[--graph] '--pretty=format:%H %d %s %n' --all
[--author | --committer]="gitster@pobox.com"] # only show logs from specific author or committer
[--merge] # shows only commits related to files that produced a conflict
[--no-merges] # show logs without merges
[--left-right] # displays < if commit was from "left side" (ours) or > if commit was from "right side" (theirs)
[--since="1 day ago"] [--until="1 hour ago"] [--before="1 week ago"] [--after="2009-01-26"] [-S'some string to search'] [--graph] [directory/] [--date=relative]
[--pretty=format:"hash:%h, when:%ar, message:%s"] # -> git log --help for format placeholders
* by putting a + (plus sign) after % of a placeholder, a line-feed is inserted immediately before the expansion if placeholder is non-empty string
[%H # full hash]
[%h # short hash (5 characters)]
[%d] # ref names
[%P] # parent hashes
[%p] # abbreviated parent hash
[%s # message]
[%ar # since time]
[--name-only] # shows only names of changed files
[--date=relative] = "1 day ago"
[-n] # n is a number for the last n commits listed
[-p] # shows diff, commit message, and the patch associated with each commits
[<filename_1 | branch_1 | SHA_1>] # will need to use hash if repo is ahead of local
[<filename_2 | branch_2 | SHA_2>]
or [<branch_1 | SHA_1>]..[<branch_2 | SHA_2>] # leave one side off depending on current branch
-> git diff # diff between working directory (last commit) and index (files changed not committed)
<filename_1 | branch_1 | SHA_1> # diff working directory and commit
[<filename_2 | branch_2 | SHA_2>] # diff both commits (sans working directory)
[--cc | --c] # shows combined diff and will show diff between current status when only one blob is given.
[--cached | --staged] # diff staged changes and current index
[--stat] # shows stat in pretty one line format.
[-S"some string"] # searches diff for some string
[<directory>[/file]] # narrow diff down to a specified directory [must.
:1:<directory>[/file] :2:<directory>[/file] # see what changed between merge files (i.e. 1=merge-base, 2=ours, 3=theirs)
-> git reflog # a very special "branch" that records each position of HEAD in the last 30 days (by default).
expire --all #all references (use --all as LAST FLAG PASSED)
[--expire=<time> --expire-unreachable=<time>] # shows log after expire time (saves your ass)
[show HEAD@{now} -n] # show history of HEAD where n = number of commits to go back.
-> delete ref@{specifier} # (i.e. master@{two.weeks.ago} "where master used to point to one week ago"
# HEAD@{2} means "where HEAD used to be two moves ago"
-> git show-ref # shows ref heads (i.e. refs/heads/<local_branches>
-> git cat-file
[blob] # actually show contents within a blob commit
[-p] # pretty
[-t] # tree
[-s] # size
<sha>
# cat-file will take blobs & trees
-> git fsck --lost-found # commits that are abandoned but not garbage collected
UPDATE
----------------------------------------------
-> git commit -am "message"
-> git commit [--amend] # redo previous commit, including changes made
-> git stage <file1>, <file2>, ... # stages files for next commit
-> git git mergetool -y # to save a few keystrokes if you're merging a lot of files at once.
-> git merge <repo>/<branch> (<repo> <branch> WILL NOT WORK!)
[-s] # (resolve | recursive ) explicitly specify merge strategy.
-> git checkout [--theirs | --ours] <filename | Hash> # when conflicts arise do this to choose which commit to keep
-> git rebase # can do forward (and backward) porting. current branch should be the working branch (implicit)
[-i] # for interactive rebase console
[--preserve-merges] # preserve merge structure and not recursively rebase commits into single line.
[--ignore-whitespace]
[--continue]
[--abort]
[HEAD~n] # (where n = number of commits that consist of the new feature) Squash commits into a single commit
[--onto <branch_to_put_new_work_on> <another_branch_merge_base> <branch_with_new_work>] # C:>git rebase --onto master work-branch^ feature
<branch_to_put_new_work_on> # "forward porting" branch history onto branch
<branch> # base branch to apply changes to (git performs a git-checkout first then applies current branch onto checked out branch)
[<working_branch>] # rebase the base branch onto working branch (http://progit.org/book/ch3-6.html)
-> git fetch <repo> #
-> git push <repo> [<up_to_this_sha | branch>:]<remote_branch>
-> git cherry-pick <file | SHA hash (or part of hash)> # used for pulling patches one at a time without it's entire parent tree (if head has fast forwarded or rewound past working branch)
-> git reset [--soft] <HEAD file | SHA hash (or part of hash)> brings commit back to state with staged changes
-> [--hard] <HEAD file | SHA hash (or part of hash)> #revert to commit ( --hard * DESTRUCTIVE! *)
-> [--mixed] HEAD <file> # to unstage (Remove file from repository but keep it in working directory)
-> [--merge] ORIG_HEAD # undo merges
-> git stash save <optional-name>
-> git stash [list] # because you can't switch branches with pending changes
-> git stash show [<stash>] # view stash (defaults to first stash)
-> git stash <branchname> [<stash>] # stashes branch into branch name
-> git stash apply # runs the most resent stash (or stash@{1} for specific stash)
-> git stash drop [<stash>] #drops stash (defaults to first stash)
-> git stash clear # clears out entire stash
DELETE
----------------------------------------------
-> git revert <SHA hash (or part of hash)>
-> git rm <file> # deletes file
[--cached] # to unstage (Remove file from staged files but keep it in working directory)
-> git gc # Garbage Collection ******* REALLY DELETES EVERYTHING!!! (Empties Trash) ******************
-> git clear # clean out untracked files
CLEANUP
----------------------------------------------
$git repack -fad
$rm -rf .git/refs/original/
$git prune
$git gc --prune=now
$git gc --aggressive --prune=now
$git reflog expire --expire=now --all # remove reflogs
Raw
gitnotes
NOTES =======================================================================================================================
Hey guys, I won't overbear you with a ton of stuff on GIT. First we will go over a workflow. keep in mind this is JUST A CONVENTION.
- WE USE INTEGRATOR WORKFLOW (We WERE using centralized workflow)
- CREATE "TOPIC BRANCH" for EVERY feature. * A topic branch that has been merged elsewhere should not be rebased (including production).
- "habitually" (regularly for no real reason) merging an integration branch (production) into your topics
and by extension, merging anything upstream (remote) into anything downstream (local)on a regular basis is frowned upon.
- topic should contain a single (well-separated) change.
- SHOULD USE THE ONE COMMIT ONE FEATURE IDIOM (Linus T)
- easier to merge individually. can easily be removed. easier code reviews.
- rebase onto master before making team branch public
- have integrator merge (FAST-FORWARD) head of master (production) to head of team branch.
* Just because you make one feature be one commit on the public facing side does not mean that commit really was 15 squashed commits which involved 2 developers locally.
* local history DOES NOT have to be the same as public facing history. public history should be clean.
- Eric brought up a great point…what if your team requires some NEW work in production. This can easily be accomplished by rebasing your work onto the current state of production.
- This is preferred over merging since rebasing will put you at the current state of production instead of merging production into our branch then our branch into production
- also, MERGE CONFLICTS are MUCH more simpler to resolve with rebase than traditional merge.
because rebase takes your commits INDIVIDUALLY and applies them one by one ON TOP OF the head of the target branch as apposed to recursively merging history (big mess you can see it in gitk)
****************
- LINUS goes over this in GREAT detail in this article… MUST READ!
http://lwn.net/Articles/328438/
****************
Once we have clean histories and are "ready to go to production" we need to have a convention methodology of getting the merges in. There are GREAT strategies in the following articles. (especially this one http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html)
http://lwn.net/Articles/328438/
http://unethicalblogger.com/node/276
http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html
http://blog.woobling.org/2009/05/git-rebase-considered-awesome.html
Git Book - pg. 224 (Upstream Consumer
** IN MORE DETAIL **
- The state of the index becomes the tree of the next commit
Why rebase over merge (INCLUDING GIT PULL REBASE) -
When looking through history, it is just never interesting to know when the guy working on the feature stopped to sync up. It might be useful for the guy while he's doing it, but that's what reflog is for. It's just adding noise for everyone else.
- Eric said "But I am waiting for someone else's changes" - Rebase your work to the head of production and keep working on it.
As your git knowledge increases you find yourself looking a lot more at history than with any other vcs I've used. If you have a ton of small merge commits, it's easy to loose focus of the bigger picture that's happening in your history.
When looking through history, it is just never interesting to know when the guy working on the feature stopped to sync up. It might be useful for the guy while he's doing it, but that's what reflog is for. It's just adding noise for everyone else.
=============================================================================================================================
[ ] - optional
| - or
< > - variable
WORKFLOW
-------------------
-> git pull . remotes/<repo>/<branch> # pull stable branch into current branch (or new branch) ** Pull always merges into current branch! **
-> git log -p <branch>..remotes/<repo>/<branch> # to see what has changed since branch was pulled last
# * or git diff (with no flags)
-> git checkout -b <feature-name-branch> # create and checkout new branch at tip of HEAD of current branch (possibly at SHA commit point)
****************************************************************************************
-> ** DO A SMALL BIT OF WORK and commit ** (rinse, repeat)
****************************************************************************************
-> git rebase # can do forward (and backward) porting.
[-i] # for interactive rebase console
[--continue]
[--abort]
[HEAD~n] # (where n = number of commits that consist of the new feature) Squash commits into a single commit
[--onto <branch_to_put_new_work_on> <another_branch_merge_base> <branch_with_new_work>] # C:>git rebase --onto master work-branch^ feature
<branch_to_put_new_work_on> # "forward porting" branch history onto branch
* Could cause merge conflict if changes made to same file if so, fix merge conflict and run >git rebase --continue
* CONFLICT (content): Merge conflict in file.txt
-> git reset --hard ORIG_HEAD # ORIG_HEAD is the starting point of the rebase
-> git rebase --abort # if the abort needs to be disregarded
* This can be dangerous in some cases
--never throw away a commit if that commit may itself have been merged into
another branch, as doing so may confuse further merges.
-> git checkout <production_branch> # switch to production
-> git merge <feature-name-branch> # (optional) Do a fastforward to move production to the tip of the head
-> (optional) delete <feature-name-branch>
MISCELLANEOUS COMMANDS
--------------------------------
*** SEE A LOG OF ALL COMMITS IN HISTORY (Will take a while determining the project)
git fsck --unreachable | grep commit | cut -d\ -f3 | xargs git log --merges --no-walk --grep=WIP
*** SEE A LOG OF ALL COMMITS IN HISTORY USING GITK (Will take a while determining the project)
gitk --all $( git fsck --no-reflog | awk '/dangling commit/ {print $3}' )
gitk [--all | <branch_name>] [--since] [--until] [<path_name>] [<file_name>]
git mergetool # work through conflicted files
git remote show <repo> # show all remote branches and whether or not they are new or tracked
MERGE TYPES
--------------------------------
Resolve (trivial), Recursive (default strategy), Octopus (3 or more),
Ours Forces merge to occur using local changes while keeping names of merged commits * Produces commit *
Subtree Performs merge but merged files exist in a subtree of the HEAD* Produces commit *
HEADS
--------------------
HEAD, MERGE_HEAD, FETCH_HEAD, ORIG_HEAD
FLAGS
------------------------------
<repo>^ # each carat(^) | tilde (~) means a different parent (from merge)
--graph # show graph representation
--color # color coded output
--pretty=oneline # formats into a single line
<blob>..<blob> # comparison
CREATE
------------------------------
-> git clone <repo> # this is similar to "checkout (but downloads the repo....I think)
-> git symbolic-ref HEAD refs/heads/<new_branch> # allows the creation of an empty new branch before initial commit
-> git branch <branch_name> <SHA1> # creates branch at that commit point (most recent commit used when not provided!)
#####################################################
## Create a local branch that is checked out and at the head of the remote branch
-> git fetch origin <remote_branch_name>:<local_branch_name>
#####################################################
-> git checkout
[-m] <branch> # will checkout <branch> while also merging changes from current branch into checked out branch.
[-b] # create new branch
[--ours | --theirs] # creates new branch using local or remote code (only during merge conflicts)
<new_branch_name>
[<branch | file | SHA hash (or part of hash)>] # create starting point of branch from this blob
-> git commit [-am "Message"] # commits all AND message
-> git merge-base <branch_1 | SHA hash> <branch_2 | SHA hash> # creates a unified base commit point branches can fall back to.
READ
---------------------------------------------
-> git branch -v (or git show-branch for all actions) # shows us the position of each branch's HEAD
-> [--merged] # shows all of the branches that have been merged into the current working branch
-> [--contains <SHA_1>] # shows branch which contains sha hash
-> git show-branch [<branch_1>,…<brach_n>] # above --- is all branches. each branch is associated with a single column of output (star=current branch)
[--more=n] # how many commits to retrieve
[-g] # shows graph
[-gN] # shows graph N commits back
-> git hash-object <file_name> # get the hash of a file
-> git whatchanged # shows which blobs changed
-> git show # shows diffs
[sha:<file_name | folder>] show what changed in a specific file]
-> git ls-files
[-s] # shows file in all stages (during merge conflicts)`. (i.e. 0=non-conflicting, 1=merge-base, 2=ours, 3=theirs)
[-u] # show unmerged files only
-> git ls-tree <sha> # only for tree shas
[-s] # shows file in all stages (during merge conflicts)`. (i.e. 0=non-conflicting, 1=merge-base, 2=ours, 3=theirs)
[-u] # show unmerged files only
-> git blame <filename> # shows which commit/author each line of a file belongs to
-> git log # cares about the files and history
[--graph] '--pretty=format:%H %d %s %n' --all
[--author | --committer]="gitster@pobox.com"] # only show logs from specific author or committer
[--merge] # shows only commits related to files that produced a conflict
[--no-merges] # show logs without merges
[--left-right] # displays < if commit was from "left side" (ours) or > if commit was from "right side" (theirs)
[--since="1 day ago"] [--until="1 hour ago"] [--before="1 week ago"] [--after="2009-01-26"] [-S'some string to search'] [--graph] [directory/] [--date=relative]
[--pretty=format:"hash:%h, when:%ar, message:%s"] # -> git log --help for format placeholders
* by putting a + (plus sign) after % of a placeholder, a line-feed is inserted immediately before the expansion if placeholder is non-empty string
[%H # full hash]
[%h # short hash (5 characters)]
[%d] # ref names
[%P] # parent hashes
[%p] # abbreviated parent hash
[%s # message]
[%ar # since time]
[--name-only] # shows only names of changed files
[--date=relative] = "1 day ago"
[-n] # n is a number for the last n commits listed
[-p] # shows diff, commit message, and the patch associated with each commits
[<filename_1 | branch_1 | SHA_1>] # will need to use hash if repo is ahead of local
[<filename_2 | branch_2 | SHA_2>]
or [<branch_1 | SHA_1>]..[<branch_2 | SHA_2>] # leave one side off depending on current branch
-> git diff # diff between working directory (last commit) and index (files changed not committed)
<filename_1 | branch_1 | SHA_1> # diff working directory and commit
[<filename_2 | branch_2 | SHA_2>] # diff both commits (sans working directory)
[--cc | --c] # shows combined diff and will show diff between current status when only one blob is given.
[--cached | --staged] # diff staged changes and current index
[--stat] # shows stat in pretty one line format.
[-S"some string"] # searches diff for some string
[<directory>[/file]] # narrow diff down to a specified directory [must.
:1:<directory>[/file] :2:<directory>[/file] # see what changed between merge files (i.e. 1=merge-base, 2=ours, 3=theirs)
-> git reflog # a very special "branch" that records each position of HEAD in the last 30 days (by default).
expire --all #all references (use --all as LAST FLAG PASSED)
[--expire=<time> --expire-unreachable=<time>] # shows log after expire time (saves your ass)
[show HEAD@{now} -n] # show history of HEAD where n = number of commits to go back.
-> delete ref@{specifier} # (i.e. master@{two.weeks.ago} "where master used to point to one week ago"
# HEAD@{2} means "where HEAD used to be two moves ago"
-> git show-ref # shows ref heads (i.e. refs/heads/<local_branches>
-> git cat-file
[blob] # actually show contents within a blob commit
[-p] # pretty
[-t] # tree
[-s] # size
<sha>
# cat-file will take blobs & trees
-> git fsck --lost-found # commits that are abandoned but not garbage collected
UPDATE
----------------------------------------------
-> git commit -am "message"
-> git commit [--amend] # redo previous commit, including changes made
-> git stage <file1>, <file2>, ... # stages files for next commit
-> git git mergetool -y # to save a few keystrokes if you're merging a lot of files at once.
-> git merge <repo>/<branch> (<repo> <branch> WILL NOT WORK!)
[-s] # (resolve | recursive ) explicitly specify merge strategy.
-> git checkout [--theirs | --ours] <filename | Hash> # when conflicts arise do this to choose which commit to keep
-> git rebase # can do forward (and backward) porting. current branch should be the working branch (implicit)
[-i] # for interactive rebase console
[--preserve-merges] # preserve merge structure and not recursively rebase commits into single line.
[--ignore-whitespace]
[--continue]
[--abort]
[HEAD~n] # (where n = number of commits that consist of the new feature) Squash commits into a single commit
[--onto <branch_to_put_new_work_on> <another_branch_merge_base> <branch_with_new_work>] # C:>git rebase --onto master work-branch^ feature
<branch_to_put_new_work_on> # "forward porting" branch history onto branch
<branch> # base branch to apply changes to (git performs a git-checkout first then applies current branch onto checked out branch)
[<working_branch>] # rebase the base branch onto working branch (http://progit.org/book/ch3-6.html)
-> git fetch <repo> #
-> git push <repo> [<up_to_this_sha | branch>:]<remote_branch>
-> git cherry-pick <file | SHA hash (or part of hash)> # used for pulling patches one at a time without it's entire parent tree (if head has fast forwarded or rewound past working branch)
-> git reset [--soft] <HEAD file | SHA hash (or part of hash)> brings commit back to state with staged changes
-> [--hard] <HEAD file | SHA hash (or part of hash)> #revert to commit ( --hard * DESTRUCTIVE! *)
-> [--mixed] HEAD <file> # to unstage (Remove file from repository but keep it in working directory)
-> [--merge] ORIG_HEAD # undo merges
-> git stash save <optional-name>
-> git stash [list] # because you can't switch branches with pending changes
-> git stash show [<stash>] # view stash (defaults to first stash)
-> git stash <branchname> [<stash>] # stashes branch into branch name
-> git stash apply # runs the most resent stash (or stash@{1} for specific stash)
-> git stash drop [<stash>] #drops stash (defaults to first stash)
-> git stash clear # clears out entire stash
DELETE
----------------------------------------------
-> git revert <SHA hash (or part of hash)>
-> git rm <file> # deletes file
[--cached] # to unstage (Remove file from staged files but keep it in working directory)
-> git gc # Garbage Collection ******* REALLY DELETES EVERYTHING!!! (Empties Trash) ******************
-> git clear # clean out untracked files
CLEANUP
----------------------------------------------
$git repack -fad
$rm -rf .git/refs/original/
$git prune
$git gc --prune=now
$git gc --aggressive --prune=now
$git reflog expire --expire=now --all # remove reflogs
Raw
microsoft_presentation.sh
How many people use (Git & SubVersioN) today?
http://www.readwriteweb.com/hack/2011/06/github-has-passed-sourceforge.php
My Slide (Innovative-Studios.com, @snuggsi, github.com/snuggs)
# GIT history (10 minutes)
# kernel.org/pub/software/scm/git/docs
# Developed to maintain the Linux Kernel
# Transition from SVN / Murcurial
# distributed source control
# svn:external
# git-svn
# Git Differences
# nothing is ever (really) deleted
# each commit is a snapshot of every project
# only 1 .git database of text files (no .svn everywhere)
# Directed Acyclic Graph
# Key Value Storage (content addressable)
- tree, commit, parent, author, message
# How to use
# You want to maintain stable branches (seperation of concerns)
- bug fixes, patches/features, & tags
- (Evolution) Features (Explain why), Learning
# Fully Distributed Source Control Management System
# HEAD (relative e.g. HEAD~4)
# refs/heads/
# refs/tracking
# revs (Commits)
# Commit is a noun - Revisions, parent(s), content (tree != directory blobs != files).
# Installing GIT on windows (5 Minutes)
# Cygwin
# Setting up SSH Keys
# Git Extensions - http://code.google.com/p/gitextensions/
# or Visual Studio integration (extension manager) (Can see status)
# Global Configuration (Globe) (5 Minutes)
$ git config --global user.name 'Snuggs'
$ git config --global user.email 'snuggs@github.com'
# ~/.gitconf - https://gist.github.com/gists/605704 (.gitconfig)
# Working Project (30 Minutes)
--------------------------------------------
# git commands (???? Minutes)
$ git --help
$ git init
# .git directory
# gitk
# working directory (clean / dirty / staged)
* "Working" means there can be fetched deltas that do not affect repository "non-working"
- Make changes, Add changes (staged), staged changes (committed)
- Backing out (reset [hard/soft])
- Sha1 Hash (Checksum)
- Git Blame
# Branching and Merging (15 Minutes)
#Branching
# (HEADS) - HEAD, MERGE_HEAD, FETCH_HEAD, ORIG_HEAD
# fast-forward vs. normal merge, (octopus)
# When things go wrong
$ git blame <sha>
# Push and Pull (10 Minutes)
$ git remote -v
$ git remote add origin git://path.to/repository.git
$ permissions control (most will be read only)
# Github (5 Minutes)
# pushing
# browser editing
# pulling
#viral https://github.com/MrMEEE/bumblebee/commit/a047be85247755cdbe0acce6f1dafc8beb84f2ac
# Rebasing (20 Minutes)
# Linus Torvalds Email 5 Minutes
# Diagram flow
# Feature branches (Palm Tree)
$ git rebase <branch_name>
# Interactive rebase
$ git rebase -i HEAD~<n>
**** IF YOU NEED HELP I'M HERE ****
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment