From DevSummit
Jump to: navigation, search

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

'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 - 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, 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 - tutorials


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