Git lightning talk: Difference between revisions

From Bitpost wiki
(Created page with "git lightning talk CENTRALIZED vs DISTRIBUTED VERSION CONTROL older version control systems are centralized there is one authority that is a gatekeeper of the co...")
 
No edit summary
Line 5: Line 5:
     older version control systems are centralized
     older version control systems are centralized
     there is one authority that is a gatekeeper of the code
     there is one authority that is a gatekeeper of the code
     you hvae to check code out from this gatekeeper
     you have to check code out from this gatekeeper
         you'll need a connection to the server,
         you'll need a connection to the server
         you'll need permission,
         sometimes someone else may have reserved the code so you can't even check it out
        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


    then git introduced me to distributed version control
     the difference is this:
     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.
     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
     you can do every version control task imaginable - create branches, add files, delete files, anything
Line 23: Line 17:
     it doesn't matter, you can still do everything you need to do
     it doesn't matter, you can still do everything you need to do
     you're working in your own bubble, completely under your control
     you're working in your own bubble, completely under your control
    the developer is empowered to get and manage the code independent of everyone and everything else


    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
     our original goal remains: that is, to have a central repository
    a distributed version control system pushes the challenge of merging out to the final step
    and that's where you want to make sure follow best practice


     so how do you best manage a central repo with distributed version control?
     so how do you best manage a central repo with distributed version control?
Line 46: Line 40:
     git uses hashes of the code for commit identifiers, so it can allow diverging history
     git uses hashes of the code for commit identifiers, so it can allow diverging history
     but it is NOT what you want
     but it is NOT what you want
     to avoid it, git provids the rebase option
     to avoid it, git provides the rebase option
     here's the result of alice doing a [git pull -rebase]:
     here's the result of alice doing a [git pull -rebase]:


Line 70: Line 64:
     let's think about what's happening
     let's think about what's happening
     basically bob checked in first, leaving alice the responsibility of merging - this is sensible
     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
     the merge that alice must do happens in her own bubble
         she can take her time getting it right, without impacting other development
         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
         if more development happens while she is merging, she can repeat the process

Revision as of 14:32, 6 November 2017

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 have to check code out from this gatekeeper
       you'll need a connection to the server
       sometimes someone else may have reserved the code so you can't even check it out
   then git introduced me to distributed version control
   the difference is this:
   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
   the developer is empowered to get and manage the code independent of everyone and everything else
   our original goal remains: that is, to have a central repository
   a distributed version control system pushes the challenge of merging out to the final step
   and that's where you want to make sure follow best practice
   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 provides 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
   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!!