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
http://www.slideshare.net/GoAtlassian/superpowered-ci-with-git-sarah-goffdupont
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
/