Git

https://gist.github.com/blackfalcon/8428401

https://github.com/PCSailor/

Command Description Notes
Start New Repository:
 git init  verify in correct folder
 git commit -m “first commit message”
 git remote add origin [Github website for your Repository]
 git push -u origin master
 END  Initial new repository started
git branch what branch am I in? mt
git pull origin master merges existing master server repo with local repo branch = master
Tutorials
Git basics – a general workflow

Get these in a table:
push an existing repository from the command line
git remote add origin https://github.com/PCSailor/Phi.git
git push -u origin master

Memorize: git add / git commit / git push
Git Workflow Commands
Workflow on new Repositories:
1. ls
2. cd D: (any drive)(Use ls, cd, and Tab commands alternatively to work down into folder of interest.
3. mkir [create a folder name of your choice]
4. cd (previously created folder name)
5. touch [create files of your choice, i.e. index.html, script.js, styles.css, readme.txt, etc]
6. git init (creates hidden directory)
7. git status (double check init success with files in Red)
8. git add . (adds modified/new files https://github.com/PCSailor/Phi_Weekend01_Starter_Completeo index, preparing for inclusion in next git commit)
8a. git add ‘some-file-name-+-extension’ to add only file
7. git status (double check init success with files in Green)
9. git commit -m “initial commit text” (enter whatever comment text you like)
10. git remote add origin www (insert Github web-address for specific repository)
11. git push -u origin master (only need -u for 1st push, -f for force, :q to quit VM)
Successful message =
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 251 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/PCSailor/PA_PreWork_01.git
* [new branch] master -> master
Branch master set up to track remote branch master from origin.
12. Now git add , git commit, git push is ready to be used?

Memorize: git add / git commit / git push

Paths:
/d/_Professional/Software_Developing/Github/Github_Clones/**

Git Commands:
touch (creates a file)
mkdir (creates a folder)
cd .. (goes up one folder)
git add -A (stages All)
git add . (stages new and modified, without deleted)
git add -u (stages modified and deleted, without new)
rm -rf (Removes Folder and all contents)
rm (Removes File [Enter multiple files separated by space])
git log (Shows activity log)
git pull origin master (Pulls Remote changes in GitHub repository
git diff HEAD (Inspect what is different from last commit) (This didn’t work)
git diff (try adding path and/or file)
git diff –staged (see the changes just staged)
git reset (removes staged files)
git checkout — (Files are changed back to last commit)
git branch (Create a branch to edit independent of the Master)
git checkout (switch branches)
atom . (opens in Atom)

VIM:
:q ! (Quit [exit VIM])
i then Esc then message then :wq (or qw?) to use the text editor and commit this way

Github Login:
git config –global user.email “you@example.com”
git config –global user.name “Your Name”

https://try.github.io (Excellent Tutorial)


To join as collaborator:
git clone webAddress
cd (into cloned folder)
–> edit code
git add .
git commit -m “commit text”
git push

when a change online has been made
your existing changes, git commit or delete changes
git pull // allows you to get most recent version of some code on your computer

git checkout `some name’
git branch
git pull
git checkout . // deletes any changes to files

In terminal
ls -a Shows hidden folders
git remote -v shows what Github repo you’re in
… rm origin ((origin replaces the www address)
add -a adds all files/folders

To Log in within Terminal:
git config –global user.name “Philip Curtis”
same as
git config –g
git config –global user.mail “Phil@PhilCurtis.io”

placed all app.gets/posts from app.js into folder

rm-rf node_modules/
To remove a file (Note: is the node_modules/ folder name

Change the URL for a remote GIT repository git remote set-url origin git://new-url-here
Displays the current remote Git repo git remote -v
displays the current branch git checkout
git checkout -b
git add .
git commit -m “sum-message-here”
git push
Add all files in all folders git add –all


Enabling GitHub Pages to publish your site from master or gh-pages
To select master or gh-pages as your publishing source, you must have the branch present in your repository. If you don’t have a master or gh-pages branch, you can create them and then return to source settings to change your publishing source. On GitHub, navigate to your GitHub Pages site’s repository. Repository settings buttonUnder your repository name, click Settings. select-gh-pages-or-master-as-sourceUse the Select source drop-down menu to select master or gh-pages as your GitHub Pages publishing source. click-save-next-to-source-selectionClick Save.

Publishing your GitHub Pages site from a /docs folder on your master branch
To publish your site’s source files from a /docs folder on your master branch, you must have a master branch and your repository must: have a /docs folder in the root of the repository not follow the repository naming scheme .github.io or .github.io GitHub Pages will read everything to publish your site, including the CNAME file, from the /docs folder. For example, when you edit your custom domain through the GitHub Pages settings, the custom domain will write to /docs/CNAME. Tip: If you remove the /docs folder from the master branch after it’s enabled, your site won’t build and you’ll get a page build error message for a missing /docs folder. On GitHub, navigate to your GitHub Pages site’s repository. Create a folder in the root of your repository on the master branch called /docs. Repository settings buttonUnder your repository name, click Settings. select-master-branch-docs-folder-as-sourceUse the Select source drop-down menu to select master branch /docs folder as your GitHub Pages publishing source. Tip: The master branch /docs folder source setting will not appear as an option if the /docs folder doesn’t exist on the master branch. click-save-next-to-master-branch-docs-folder-source-selectionClick Save. Added Publish info to ReadMe file
https://help.github.com/articles/configuring-a-publishing-source-for-github-pages/
https://github.com/blog/2289-publishing-with-github-pages-now-as-easy-as-1-2-3



1/7/2017 A Visual Git Reference
http://marklodato.github.io/visualgitguide/
indexen.
html 1/14
A Visual Git Reference
If the images do not work, you can try the NonSVG
version of this page.
This page gives brief, visual reference for the most common commands in git. Once you know a bit about how git works, this site
may solidify your understanding. If you’re interested in how this site was created, see my GitHub repository.
Also recommended: Visualizing Git Concepts with D3
Contents
1. Basic Usage
2. Conventions
3. Commands in Detail
a. Diff
b. Commit
c. Checkout
d. Committing with a Detached HEAD
e. Reset
f. Merge
g. Cherry Pick
h. Rebase
4. Technical Notes
Basic Usage
The four commands above copy files between the working directory, the stage (also called the index), and the history (in the form of
commits).
git add files copies files (at their current state) to the stage.
git commit saves a snapshot of the stage as a commit.
git reset ‐‐ files unstages files; that is, it copies files from the latest commit to the stage. Use this command to “undo” a git
add files. You can also git reset to unstage everything.
git checkout ‐‐ files copies files from the stage to the working directory. Use this to throw away local changes.
You can use git reset ‐p, git checkout ‐p, or git add ‐p instead of (or in addition to) specifying particular files to interactively
choose which hunks copy.
It is also possible to jump over the stage and check out files directly from the history or commit files without staging first.
1/7/2017 A Visual Git Reference
http://marklodato.github.io/visualgitguide/
indexen.
html 2/14
git commit ‐a is equivalent to running git add on all filenames that existed in the latest commit, and then running git commit.
git commit files creates a new commit containing the contents of the latest commit, plus a snapshot of files taken from the
working directory. Additionally, files are copied to the stage.
git checkout HEAD ‐‐ files copies files from the latest commit to both the stage and the working directory.
Conventions
In the rest of this document, we will use graphs of the following form.
Commits are shown in green as 5character
IDs, and they point to their parents. Branches are shown in orange, and they point to
particular commits. The current branch is identified by the special reference HEAD, which is “attached” to that branch. In this image,
the five latest commits are shown, with ed489 being the most recent. master (the current branch) points to this commit, while maint
(another branch) points to an ancestor of master’s commit.
Commands in Detail
1/7/2017 A Visual Git Reference
http://marklodato.github.io/visualgitguide/
indexen.
html 3/14
Diff
There are various ways to look at differences between commits. Below are some common examples. Any of these commands can
optionally take extra filename arguments that limit the differences to the named files.
Commit
When you commit, git creates a new commit object using the files from the stage and sets the parent to the current commit. It then
points the current branch to this new commit. In the image below, the current branch is master. Before the command was run, master
pointed to ed489. Afterward, a new commit, f0cec, was created, with parent ed489, and then master was moved to the new commit.
1/7/2017 A Visual Git Reference
http://marklodato.github.io/visualgitguide/
indexen.
html 4/14
This same process happens even when the current branch is an ancestor of another. Below, a commit occurs on branch maint, which
was an ancestor of master, resulting in 1800b. Afterward, maint is no longer an ancestor of master. To join the two histories, a merge
(or rebase) will be necessary.
Sometimes a mistake is made in a commit, but this is easy to correct with git commit ‐‐amend. When you use this command, git
creates a new commit with the same parent as the current commit. (The old commit will be discarded if nothing else references it.)
1/7/2017 A Visual Git Reference
http://marklodato.github.io/visualgitguide/
indexen.
html 5/14
A fourth case is committing with a detached HEAD, as explained later.
Checkout
The checkout command is used to copy files from the history (or stage) to the working directory, and to optionally switch branches.
When a filename (and/or ‐p) is given, git copies those files from the given commit to the stage and the working directory. For
example, git checkout HEAD~ foo.c copies the file foo.c from the commit called HEAD~ (the parent of the current commit) to the
working directory, and also stages it. (If no commit name is given, files are copied from the stage.) Note that the current branch is not
changed.
1/7/2017 A Visual Git Reference
http://marklodato.github.io/visualgitguide/
indexen.
html 6/14
When a filename is not given but the reference is a (local) branch, HEAD is moved to that branch (that is, we “switch to” that
branch), and then the stage and working directory are set to match the contents of that commit. Any file that exists in the new commit
(a47c3 below) is copied; any file that exists in the old commit (ed489) but not in the new one is deleted; and any file that exists in
neither is ignored.
When a filename is not given and the reference is not a (local) branch — say, it is a tag, a remote branch, a SHA1
ID, or something
like master~3 — we get an anonymous branch, called a detached HEAD. This is useful for jumping around the history. Say you want
to compile version 1.6.6.1 of git. You can git checkout v1.6.6.1 (which is a tag, not a branch), compile, install, and then switch
1/7/2017 A Visual Git Reference
http://marklodato.github.io/visualgitguide/
indexen.
html 7/14
back to another branch, say git checkout master. However, committing works slightly differently with a detached HEAD; this is
covered below.
Committing with a Detached HEAD
When HEAD is detached, commits work like normal, except no named branch gets updated. (You can think of this as an anonymous
branch.)
1/7/2017 A Visual Git Reference
http://marklodato.github.io/visualgitguide/
indexen.
html 8/14
Once you check out something else, say master, the commit is (presumably) no longer referenced by anything else, and gets lost.
Note that after the command, there is nothing referencing 2eecb.
If, on the other hand, you want to save this state, you can create a new named branch using git checkout ‐b name.
Reset
1/7/2017 A Visual Git Reference
http://marklodato.github.io/visualgitguide/
indexen.
html 9/14
The reset command moves the current branch to another position, and optionally updates the stage and the working directory. It also
is used to copy files from the history to the stage without touching the working directory.
If a commit is given with no filenames, the current branch is moved to that commit, and then the stage is updated to match this
commit. If ‐‐hard is given, the working directory is also updated. If ‐‐soft is given, neither is updated.
If a commit is not given, it defaults to HEAD. In this case, the branch is not moved, but the stage (and optionally the working
directory, if ‐‐hard is given) are reset to the contents of the last commit.
1/7/2017 A Visual Git Reference
http://marklodato.github.io/visualgitguide/
indexen.
html 10/14
If a filename (and/or ‐p) is given, then the command works similarly to checkout with a filename, except only the stage (and not the
working directory) is updated. (You may also specify the commit from which to take files, rather than HEAD.)
Merge
A merge creates a new commit that incorporates changes from other commits. Before merging, the stage must match the current
commit. The trivial case is if the other commit is an ancestor of the current commit, in which case nothing is done. The next most
simple is if the current commit is an ancestor of the other commit. This results in a fastforward
merge. The reference is simply
moved, and then the new commit is checked out.
1/7/2017 A Visual Git Reference
http://marklodato.github.io/visualgitguide/
indexen.
html 11/14
Otherwise, a “real” merge must occur. You can choose other strategies, but the default is to perform a “recursive” merge, which
basically takes the current commit (ed489 below), the other commit (33104), and their common ancestor (b325c), and performs a
threeway
merge. The result is saved to the working directory and the stage, and then a commit occurs, with an extra parent (33104)
for the new commit.
Cherry Pick
1/7/2017 A Visual Git Reference
http://marklodato.github.io/visualgitguide/
indexen.
html 12/14
The cherrypick
command “copies” a commit, creating a new commit on the current branch with the same message and patch as
another commit.
Rebase
A rebase is an alternative to a merge for combining multiple branches. Whereas a merge creates a single commit with two parents,
leaving a nonlinear
history, a rebase replays the commits from the current branch onto another, leaving a linear history. In essence,
this is an automated way of performing several cherrypicks
in a row.
1/7/2017 A Visual Git Reference
http://marklodato.github.io/visualgitguide/
indexen.
html 13/14
The above command takes all the commits that exist in topic but not in master (namely 169a6 and 2c33a), replays them onto master,
and then moves the branch head to the new tip. Note that the old commits will be garbage collected if they are no longer referenced.
To limit how far back to go, use the ‐‐onto option. The following command replays onto master the most recent commits on the
current branch since 169a6 (exclusive), namely 2c33a.
There is also git rebase ‐‐interactive, which allows one to do more complicated things than simply replaying commits, namely
dropping, reordering, modifying, and squashing commits. There is no obvious picture to draw for this; see gitrebase(
1) for more
1/7/2017 A Visual Git Reference
http://marklodato.github.io/visualgitguide/
indexen.
html 14/14
details.
Technical Notes
The contents of files are not actually stored in the index (.git/index) or in commit objects. Rather, each file is stored in the object
database (.git/objects) as a blob, identified by its SHA1
hash. The index file lists the filenames along with the identifier of the
associated blob, as well as some other data. For commits, there is an additional data type, a tree, also identified by its hash. Trees
correspond to directories in the working directory, and contain a list of trees and blobs corresponding to each filename within that
directory. Each commit stores the identifier of its toplevel
tree, which in turn contains all of the blobs and other trees associated with
that commit.
If you make a commit using a detached HEAD, the last commit really is referenced by something: the reflog for HEAD. However,
this will expire after a while, so the commit will eventually be garbage collected, similar to commits discarded with git commit ‐‐
amend or git rebase.
Copyright © 2010, Mark Lodato. Japanese translation © 2010, Kazu Yamamoto. Korean translation © 2011, Sean Lee. Russian
translation © 2012, Alex Sychev. French translation © 2012, Michel Lefranc. Chinese translation © 2012, wych. Spanish translation
© 2012, Lucas Videla. Italian translation © 2012, Daniel Londero. German translation © 2013, Martin Funk. Slovak translation ©
2013, Ľudovít Lučenič. Portuguese translation © 2014, Gustavo de Oliveira Traditional Chinese translation © 2015, Peter Dave Hello
This work is licensed under a Creative Commons AttributionNoncommercialShare
Alike 3.0 United States License.
Want to translate into another language?