mkdir project
cd project
git init .
echo "hello" > hello.txt
git diff
git add .
git status
git commit -m "said hello"
git status
git log
echo "friend" >> hello.txt
git diff
git add .
git status
git commit -m "said friend"
git status
git log
command | description |
---|---|
git clone |
copy a remote repo to your local disk |
git add |
stage your local changes |
git commit |
save your local changes with comments |
git fetch |
get the changes from a remote, but don't apply them yet |
git pull |
sync and merge with the remote repo |
git push |
send all your local changes to and merge with the remote repo |
git checkout -b foo |
create a local branch named "foo" |
git status |
run this all the time! |
git diff |
show the changes since the last commit |
Git's fundamental data model is a linked list.
A commit contains a set of changes, to be applied all at once, possibly to many different files
to commit means to save a set of changes to the log
Each commit contains a pointer to its parent commit(s), recursively
A commit also represents a checkpoint of all the files at a given point in history
Because a commit contains a diff and a pointer to history, a commit represents both a minimal set of changes to some files in the repo, and a maximal set of the contents of all files in the repo.
"Git was written by very smart aliens." -Alex
Git has an elegant data model, but a clunky command-line interface.
Here are some examples of how some of git's commands are counterintuitive and inconsistent.
Don't bother to memorize these (yet)!
git checkout .
git checkout some_branch_name
switches to branch some_branch_name
git add
git commit
saves your staged changes locallygit push origin foo
foo
git push origin :foo
deletes remote branch named foo
git reset
git branch foo
foo
but doesn't switch to it
git checkout -b foo
creates and switches to a local branch named foo
A branch is a pointer to a commit.
When you start work on a story, create a named branch for it
git checkout -b search-by-username
While working on it, continuously merge or rebase from master
When ready for feedback, create a Pull Request based on the branch
When complete (or earlier if possible), merge to master
If you always use pull requests, then code on
master
is guaranteed to have been reviewed.
[TODO: screenshots]
master
, not from your own work-in-progress branchfoo@bar@baz.com
); is that intentional?"An old open source trick to reach consensus in an online discussion: use the +1/+0/-0/-1 scale.
+1 : "I’m willing to try and convince you we should do this."
+0 : "I don't feel strongly about it, but I'm okay with this."
-0 : "I'd rather we didn't do this, but if others want it, I won't object."
-1 : "I strongly disagree and am willing to argue my case."
https://www.apache.org/foundation/voting.html#expressing-votes-1-0-1-and-fractions
1/16