Git
branching - defined
git follows changes, difference in the code, so merge back almost always works, changes get pulled back in easily
power shift (versus subversion) is you can create a separate project without permission and later pulling in changes back to master will work
with subversion, had to fork and you could almost never go back
fork is a split, branch is still within same space, fork is separate
fork is controversial, ideological split, we don't intend to come back
with git, you can fork, and then pull things back fairly easily
this process has destroyed the central power of core committers, the power has become more decentralized
pull request versus patch (subversion) - patch would be applied at that particular point, or patch will no longer apply, this made it difficult to apply
with git - a rebase will walk back to the common point and then re-run the series of changes in order, less likely to have merge conflict
almost always rebase with git rather than merge, to be sure that there are no conflicts
example: master runs in production, each developer has fork with changes, then a pull request pulls in the changes
typically a branch for each feature or functionality
every bug or feature/ticket will have it's own branch
so you don't have a situation like you did with subversion that you couldn't deploy something because you have something else in progress
your branch should pull from master on a regular basis
when on the branch run 'git rebase master'
when you push back, you first need to pull changes then rebase, then push your change
when managing your branch, you want to merge in from master frequently 'git merge master'
'git fetch' does a pull but not a merge
usual process, create repo on git hub, which creates url github.com/youruser/myapp.github
'git clone url' - creates local empty repo on your machine
create files, which at this point are untracked, so use 'git add'
'git commit' - takes the added files and records current state locally
'git add -p' adds just a piece of a files
general methodology is to make commits as small and specific as possible
'git push' has implicit origin
'git pull' - pull current branch from origin back down
'git pull --rebase' - typically don't need to do this, unless this there is a problem
other remotes can be added
heroku.com - owned by Salesforce, platform as a service, multilanguage hosting
you can easily scale # of servers on horuku based on need (1 day every three months), so just that day, 1 dyno up to 1,000s for that one day
slider for server capacity
for campaigns, ideal solution
'git branch branchname' only a local branch
then need to push
'git chekcout branchname' - switches branches
git flow is a model for branches and merging - command which encapsulates 5 steps, good for dev linkes
blog post - git flow rebase,
github.com structure - example
master - never is released
first things for every bug fix, create a branch, work on this branch, then create pull request. then it is approved and merged from master into the feature branch and that is released into production
then feature is added into master, if a bug is found on feature that is released, you go back to last branch or master
for typical projects, run test, commit to master, then push to origin - for small fixes
for large feature set, branch which is then feature
resources
gitimpersion.org - tutorials
GUI -
git for windows
gitg - linux
gitx - osx
prettiest tools released by github, they hired the developers that were already developing apps and hired designers to make them better
git used for laws - german parliament
other european governments using
writing tool - commits changes every few minutes
mysql databases - depends on the dump, it may bunch a lot of rows into one line, so since git is line by line, if any one line has changed, then it the entire new line is a change or force to have a new line
overall, biggest benefit is decentralized power, branching became easy
svn to git - which allows you to use git commands to interact with git, allows one individual to try gitg
clay sharky - ted talk on git