and some different ways of thinking about Version control. • I prefer questions at the end, but please don’t let that stop you if you really want to raise your hand.
the code develops. • Easier to trash changes to a known point than to manually edit back to it. • Small, frequent changes that can be rolled up into more atomic commits. http://www.flickr.com/photos/mariachily/3382813383/
50 chars) in the present imperative tense. • “change” not “changes” • A blank line: • Body, wrapped to less than 80 chars, that provides more information about the commit. • Describe what applying the change will do, not what was done to create the change.
happen. Small commits that affect minimum subsets are easier to manage. • Git is not a substitute for project management. If many changes are happening to the same place in the same file, there will be conflicts. • Branches are cheap. Tags are cheap. Don’t be tempted to clean history too often. • Multiple repositories as backups are a good idea.
a local branch that is not shared with anybody else. • You are on a branch that is synced with a private repository that only you use. • You roll up your list of small individual commits on your working branch into a larger atomic commit that you then push. • rebase is your friend. Seriously.
the upstream changes. • Use `git remote update` to fetch changes if the repository has multiple remotes. • Merge or rebase onto a temporary branch if you aren’t sure if the changes will apply cleanly.
git: add, push, commit, pull, fetch, checkout, status, are usually enough to get started • Git objects are immutable, changes are not irrevocable. Errors can be corrected. • Well named branches and a set of conventions are a great help. • Make people care, and they will care. Everyone wants to do a good job.
branch. They are cheap. • Use some sort of naming convention so that you don’t get confused about them. • You can create a description for a branch • git branch --edit-description • If you want to park a branch - Create an annotated tag with a description.
• Create a separate branch for a demo that uses the main code. • Use rebase liberally when only one branch is being used for development, but be sure to make it clear which the non-development branch is. • Use `cherry-pick` if changes are made in both branches.
start with. Start using automation when you become comfortable with them. • Use a GUI if you have to. • If you want to do something complex, look it up and try to do it. Repetition builds knowledge. • Learn the Git object model, and everything becomes a lot clearer.
abizern
bkuhlmann
teamlab
kazumain
1wedge_one
linew_official
ogurotakayuki
har1101
nagainaganawa
hironytic
hanyudaeiiti
honnibal
urmot
mojombo
jlugia
pauljervisheath
aleyda
davidbonilla
kneath
colly
iamctodd
bryan
eileencodes
addyosmani
