Git lightning talk - Revision history

M at 15:58, 6 November 2017

2017-11-06T15:58:08Z

← Older revision		Revision as of 15:58, 6 November 2017
Line 1:		Line 1:
	~~git lightning talk~~

	CENTRALIZED vs DISTRIBUTED VERSION CONTROL		CENTRALIZED vs DISTRIBUTED VERSION CONTROL
Line 9:		Line 8:
	sometimes someone else may have reserved the code so you can't even check it out		sometimes someone else may have reserved the code so you can't even check it out

	~~then~~ git ~~introduced me to~~ distributed version control		git popularized distributed version control
	the difference is this:		the difference is this:
	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.
Line 62:		Line 61:
	second, alice's changes, added back on top of bob's, may very well need a merge effort		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~~		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
	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
Line 72:		Line 70:
	and feel confident that she had the time to do the merge properly, on her own machine, without impacting others		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		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 stash her changes - that basically stuffs them all out of the way in a git stash

M at 14:32, 6 November 2017

2017-11-06T14:32:09Z

← Older revision		Revision as of 14:32, 6 November 2017
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

M: 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..."

2017-11-04T16:36:24Z

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..."

New page

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