This document outlines a basic Git branch workflow for collaborating on features. It shows developers branching off of master to work on features, merging in changes from origin/master, rebasing branches, and merging branches back into master before pushing to the remote repository. Additional Git tools like reset, cherry-pick, stash, bisect, add -p, reflog are recommended for more advanced workflows. Information resources on Git are also provided.
1 of 21
More Related Content
Git workflow
1. a handful of Git
敬看姻一鍖o敬s for the
agilist
steven harman
twitter: stevenharman
http://stevenharman.net
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 re鍖og
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-敬看姻一鍖o敬s
steven harman
twitter: stevenharman
http://stevenharman.net
Editor's Notes
\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