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
git popularized 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
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
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!!