6. History I hate CVS! I like BitKeeper,
but it’s not open.
Linus Torvalds
7. History I hate CVS! I like BitKeeper,
but it’s not open.
Linus Torvalds
8. History I hate CVS! I like BitKeeper,
but it’s not open.
Wait a minute! I made Linux dammit!
I should just make my own code repository!
...give me 2.5 months
Linus Torvalds
9. History I hate CVS! I like BitKeeper,
but it’s not open.
Wait a minute! I made Linux dammit!
I should just make my own code repository!
...give me 2.5 months
Ok! All done!
Linus Torvalds
10. History I hate CVS! I like BitKeeper,
but it’s not open.
Wait a minute! I made Linux dammit!
I should just make my own code repository!
...give me 2.5 months
Ok! All done!
Linus Torvalds
11. History I hate CVS! I like BitKeeper,
but it’s not open.
Wait a minute! I made Linux dammit!
I should just make my own code repository!
...give me 2.5 months
Ok! All done!
GIT was made to be: Linus Torvalds
fast, distributed, non-linear,
use existing protocols,
and good at merging.
12. Branching
• Branches are cheap!
• Always work in a branch, which is your own little
world.
• Change didn’t work? Just kill the branch!
• They are the key to non-linear development.
• You can’t change branches if your workspace isn’t
“clean”
• Always “checkout”!
• Switch Branch: git checkout <branch>
13. Committing
• In Subversion there is just commit, but in GIT, you commit and push.
• GIT is distributed, so you commit locally and then only push to
another server when needed.
• “status” allows you to see current changes or files not in the repo.
• git status
• Files must be added to the repo, and if changed, the commit.
• git add <filename or path> or add everything to the
commit with git commit -a
• Set a commit message with -m: git commit -m “Crazy awesome
14. Pushing
• GIT is distributed! ...but we don’t use it that way. We use a single
“origin” that we all push and pull from.
• Remember that you commit locally and use “git push” to add your new
changes to the origin.
• git push origin/<branch>
• Remember:
• When pushing a shared branch, you must be up-to-date first.
• You can never push to master!
15. Merging
• You use “git merge” to bring a different hash’s
changes in to your current branch.
• git merge <hash>
• You can also use the branch name as a
shortcut to it’s latest hash.
• After merging, git will output data about the
changes merged in.
16. Diff
• Diff is a way to
compare two code
changes (or hashes)
• git diff
<hash1> <hash2>
• If you only give the
diff command one
hash, it will assume
you are diff’ing the
currently checked
18. Config
• Your global config lives at: ~/.gitconfig (*nix)
• Aliases give you the power of chaining git commands together in one
command.
• You can also your name & email for commits globally...
• ...as well as set color schemes and your diff tool of choice.
19. Other Tricks
• git reset [--hard] <hash>
• Resets your current workspace to a given hash.
• git log -<max>
• Allows you to see the current branch’s history.
• git stash
• Allows you to set aside your current changes
temporarily.
• git stash pop brings your changes back to your
current workspace.
The development of Git began on April 3, 2005. The project was announced on April 6, and became self-hosting as of April 7. The first merge of multiple branches was done on April 18. Torvalds achieved his performance goals; on April 29, the nascent Git was benchmarked recording patches to the Linux kernel tree at the rate of 6.7 per second. On June 16, the kernel 2.6.12 release was managed by Git.\n\nFast: Binaries are all fast C apps.\nDistributed: There isn&#x2019;t just one origin, but any GIT client can also serve code.\nNon-Linear: Allow for rapid branching and merging.\nProtocols: Uses FTP, HTTP, or SSH\nMerging: A change is merged more than it&#x2019;s written! Merging branches must be quick and easy.\n
The development of Git began on April 3, 2005. The project was announced on April 6, and became self-hosting as of April 7. The first merge of multiple branches was done on April 18. Torvalds achieved his performance goals; on April 29, the nascent Git was benchmarked recording patches to the Linux kernel tree at the rate of 6.7 per second. On June 16, the kernel 2.6.12 release was managed by Git.\n\nFast: Binaries are all fast C apps.\nDistributed: There isn&#x2019;t just one origin, but any GIT client can also serve code.\nNon-Linear: Allow for rapid branching and merging.\nProtocols: Uses FTP, HTTP, or SSH\nMerging: A change is merged more than it&#x2019;s written! Merging branches must be quick and easy.\n
The development of Git began on April 3, 2005. The project was announced on April 6, and became self-hosting as of April 7. The first merge of multiple branches was done on April 18. Torvalds achieved his performance goals; on April 29, the nascent Git was benchmarked recording patches to the Linux kernel tree at the rate of 6.7 per second. On June 16, the kernel 2.6.12 release was managed by Git.\n\nFast: Binaries are all fast C apps.\nDistributed: There isn&#x2019;t just one origin, but any GIT client can also serve code.\nNon-Linear: Allow for rapid branching and merging.\nProtocols: Uses FTP, HTTP, or SSH\nMerging: A change is merged more than it&#x2019;s written! Merging branches must be quick and easy.\n
The development of Git began on April 3, 2005. The project was announced on April 6, and became self-hosting as of April 7. The first merge of multiple branches was done on April 18. Torvalds achieved his performance goals; on April 29, the nascent Git was benchmarked recording patches to the Linux kernel tree at the rate of 6.7 per second. On June 16, the kernel 2.6.12 release was managed by Git.\n\nFast: Binaries are all fast C apps.\nDistributed: There isn&#x2019;t just one origin, but any GIT client can also serve code.\nNon-Linear: Allow for rapid branching and merging.\nProtocols: Uses FTP, HTTP, or SSH\nMerging: A change is merged more than it&#x2019;s written! Merging branches must be quick and easy.\n
The development of Git began on April 3, 2005. The project was announced on April 6, and became self-hosting as of April 7. The first merge of multiple branches was done on April 18. Torvalds achieved his performance goals; on April 29, the nascent Git was benchmarked recording patches to the Linux kernel tree at the rate of 6.7 per second. On June 16, the kernel 2.6.12 release was managed by Git.\n\nFast: Binaries are all fast C apps.\nDistributed: There isn&#x2019;t just one origin, but any GIT client can also serve code.\nNon-Linear: Allow for rapid branching and merging.\nProtocols: Uses FTP, HTTP, or SSH\nMerging: A change is merged more than it&#x2019;s written! Merging branches must be quick and easy.\n
The development of Git began on April 3, 2005. The project was announced on April 6, and became self-hosting as of April 7. The first merge of multiple branches was done on April 18. Torvalds achieved his performance goals; on April 29, the nascent Git was benchmarked recording patches to the Linux kernel tree at the rate of 6.7 per second. On June 16, the kernel 2.6.12 release was managed by Git.\n\nFast: Binaries are all fast C apps.\nDistributed: There isn&#x2019;t just one origin, but any GIT client can also serve code.\nNon-Linear: Allow for rapid branching and merging.\nProtocols: Uses FTP, HTTP, or SSH\nMerging: A change is merged more than it&#x2019;s written! Merging branches must be quick and easy.\n
The development of Git began on April 3, 2005. The project was announced on April 6, and became self-hosting as of April 7. The first merge of multiple branches was done on April 18. Torvalds achieved his performance goals; on April 29, the nascent Git was benchmarked recording patches to the Linux kernel tree at the rate of 6.7 per second. On June 16, the kernel 2.6.12 release was managed by Git.\n\nFast: Binaries are all fast C apps.\nDistributed: There isn&#x2019;t just one origin, but any GIT client can also serve code.\nNon-Linear: Allow for rapid branching and merging.\nProtocols: Uses FTP, HTTP, or SSH\nMerging: A change is merged more than it&#x2019;s written! Merging branches must be quick and easy.\n
\n
\n
\n
\n
\n
1. cd ~/wa-sandbox\n2. Create branch\n3. Add files\n4. Commit files\n5. Back to master\n6. Make new branch\n7. Add/modify files\n8. Diff\n9. Commit\n10. Back to master\n11. Peer Review! Check diff from master and branch 1.\n12. Switch to branch and make a change.\n13. Commit.\n14. Back to master.\n15. Make CAB branch\n16. Merge in both branches\n17. Push\n
