CFObjective Notes: GIT: Choosing workflows that make sense - Tim Cunningham

May 18, 2013

GIT: Choosing workflows that make sense - Tim Cunningham

Git is not a hammer, it's a hardware store
know which tool you need to use.

Everything stored in Git is an "object"

Forking
different than a clone
when you fork it, you're taking the code to do your own thing
not planning to integrate it back into the original place you copied it from

Rebase
different from a merge
takes changes in your current branch that are NOT in the remote branch...
grabs all the changes from others
applies all of them
puts YOUR changes at the END

Cherry Picking
takes a commit and sticks it somewhere else
For those RARE cases when you have to change code in the Master branch, then roll it into the Staging branch later
if you're doing this a LOT, rethink your work flow.

How Git Communicates
http/https
Easy to set up in Linux
Harder in IIS
SSH -- most common setup
-- secure
-- simple in Linux, harder in IIS

or you can just outsource all of that to GitHub

Centralize workflow
simplest
if you're new to Git do this one first
you'll have a Master branch, you pull from Master, do your work, and commit it
This is basically how Google uses Git.

(these work flows are all just by convention, everyone agreeing to work this way. it's not a "feature" you turn on/off in Git)

Feature / Branch Flow
Master = production
create a "feature branch" off of master, do all my work here. if i have a team, EVERYone working on the feature is in that same branch
not a "per developer" thing, it's a "per feature" thing.
deem someone "branch master"
-- creates the branch, tells the team were it is so they know where to write code

The GitHub Flow
will find this one more often than not, if you do a Google search on Git workflows
master branch (permanent)
development branch (permanent)
create feature branches off of development
when features are done, they're merged into Dev
Then take Dev, make a NEW branch for a Release
do your UAT and hot fixes on Release
after testing/fixes are done, merge Release back into Dev and Master

(You don't NEED to fork a project to do a pull request)

Custom workflow
build any work flow that makes sense for your project,
but make sure you understand the principles of Git.

Nothing is Unrecoverable on GitHub
if you overwrote something, it's still there somewhere
it's -extremely- hard to delete something entirely, so it can never be recovered