Git lightning talk

git lightning talk

   CENTRALIZED vs DISTRIBUTED VERSION CONTROL

   older version control systems are centralized
   there is one authority that is a gatekeeper of the code
   you hvae to check code out from this gatekeeper
       you'll need a connection to the server,
       you'll need permission,
       and you may even be able to check teh code out reserved so no one else can change it

   before i used git, this was ALWAYS how i accessed code
   and i didn't realize how extremely restrictive it is
   until git introduced me to distributed version control
   it's pretty revolutionary

   the difference is this:
   the developer is empowered to get and manage the code independent of everyone and everything else
   once you get a copy of the repository, it lives locally on your box.
   you can do every version control task imaginable - create branches, add files, delete files, anything
   and no one can tell you it's not allowed
   you can even disconnect your laptop and work on a remote island
   it doesn't matter, you can still do everything you need to do
   you're working in your own bubble, completely under your control

   so git is totally distributed
   which gives you fantastic freedom as a developer
   all that convenience pushes the challenge of merging out to the final step
   our original goal remains: that is, to have a central repository

   so how do you best manage a central repo with distributed version control?

   here's how the merging process works:

       bob         central         alice
                   1111
                   2222
       1111   /             \      1111
       2222                        2222
       ----                        ----
       bbbb                        aaaa
              \
                   bbbb            WHAT SHOULD ALICE DO?

   the most important goal is that all team members have the same commit history
   git uses hashes of the code for commit identifiers, so it can allow diverging history
   but it is NOT what you want
   to avoid it, git provids the rebase option
   here's the result of alice doing a [git pull -rebase]:

       bob         central         alice
                   1111
                   2222
       1111   /             \      1111
       2222                        2222
       ----
       bbbb
              \
                   bbbb     >      bbbb
                                   ----
                                   aaaa

   bob's code has been pulled in, and MERGED IN BEFORE alice's change
   this is how you keep your history intact
   two merge issues to take note of:
       first, bob's commit will not need merging, because it was always applied to 222
           this is called a fast-forward merge, they are the absolute best kind, because they just work, always
       second, alice's changes, added back on top of bob's, may very well need a merge effort

   let's think about what's happening
   basically bob checked in first, leaving alice the responsibility of merging - this is sensible
   and the merge that alice must do happens in her own bubble
       she can take her time getting it right, without impacting other development
       if more development happens while she is merging, she can repeat the process
       until she feels good about the merge
       then she can do a git pull --rebase one more time to ensure nothing new has arrived
       and quickly do a git push
       and feel confident that she had the time to do the merge properly, on her own machine, without impacting others

   so if you are with me so far, and in agreement that this is looking like a pretty good pattern...
   git provides two ways for alice to manage her changes
       she can stash her changes - that basically stuffs them all out of the way in a git stash
       she can then easily pull bob's changes with a standard git pull, it will be a fast forward merge
       then she can pop her stash back out on top of bob's changes, initiating the merge

       the other option she has is to commit her code, she can do this as many times as she likes
       then she will do a git pull --rebase, and that will initiate the merge

       same effect, slightly different path

   so to wrap up, i'd just like to talk quickly about automating your commit cycle
   so you can focus on development and let teh tools do everything they can to make your job easier

   here's the pattern i'm proposing:
       git clone
       # work
       git commit -a -m "my changes"
       # work
       git stash
       git pull --rebase
       # merge as needed
       git stash pop
       # merge as needed
       git pull --rebase && git push

   you can automate this, and that was the reason i wanted to give a quick talk
   i wrote a node.js module that automates this pattern
   and extends it to allow you to automatically include a semantic version into your commit
   as the rebasing happens, it will ensure that the version of your commit will follow from any previous commits
   it works great for me, and I can give you more info if you're interested
   see my npm module, it's called rad-scripts, if you want to see more

   thanks!!