18. derivations
• branch for a spike
• branches for concurrent design
• push/pull changes directly from teammate
• stashing changes temporarily
• reset to prior commit (in case of FUBAR)
19. some cool tools for
your Git utility belt
• git reset
• git cherry-pick
• git stash
• git bisect
• git add -p
• git reflog
• git svn
20. get Git info
• http://ProGit.org (the site for THE book)
• http://gitready.com
• http://gitcasts.com
• http://whygitisbetterthanx.com/
• http://delicious.com/stevenharman/git
21. fork these slides from
http://github.com/stevenharman/git-workflows
steven harman
twitter: stevenharman
http://stevenharman.net
Notas do Editor
\n
git is awesome - if you’re using it, you know. if not, don’t be scared, give it a try.\n
don’t be scared, it’s not as bad as it looks.\n
\n
let’s assume there already exists a Git repository somewhere in the cloud. like maybe... The GitHub.\n
start by cloning a copy of that remote repository (conventionally known as “origin”) to our local machine.\n
we need to work a sweet new feature. step 1) create a local branch to work in. step 2) hackity-hack-hack. step 3) commit the changes. [repeat steps 2 & 3 as necessary]\n
a teammate, or maybe even another you, has pushed some new changes.\n
[still continuing steps 2 & 3 from earlier]\n
get any new changes that are on the remote, but not local.\n
merge the changes from the remote “master” branch into our local “master” branch. because there are no divergent changes on our local master, this is a “fast-forward merge” along the master’s graph.\n
now we need to merge our feature into “master” so we can release it. \n\noption 1) merge feature in. [keeps all info, but we end up with a noisy history graph that’s hard to follow]\n
OR [go back to just after we merged in the fetched changes]\n
option 2) rebase our “feature” branch on top of “master”.\n\nthis “rewinds” our branch back to where it started, then “fast-forwards” along “master”, and finally re-applies each of our change sets. afterward, our local commits have a new SHA1 hash, meaning they are different objects than before rebase, however, the original committer info & meta-data are preserved.\n
now we can merge our changes into “master.” because we already have all of the changes that exist in “master,” this results in a “fast-forward” merge onto “master”.\n
finally we share our sweet, sweet bacon with the rest of the world by pushing our local changes to the remote (origin).\n
now everyone can enjoy the bacony-goodness!\n
\n
add -p to interactively stage hunks of a file change.\n
