Red Green Repeat Adventures of a Spec Driven Junkie

Wrapping Your Head Around git

tl;dr: If you want to learn git better, understand why Linus made it. Everything fell together for me once I did.

Linus explaining git

When I got back into development after a hiatus, software development changed. Notably, version control. This new thing called git was on the scene and it was different than what I used (or barely used) before.

Version control is essential to software development. Tracking work as you progress essential to own development. When you’re working with a team of other developers, combining work together multiplies the team’s productivity.

Knowing git is essential to not hosing your own work but the team’s work.

I had a hard time wrapping my head around git. That is, until SK gave me this video:

Linus explaining git

For me, understanding that git:

  • is a tool Linus made git for his own needs
  • Linus’ main need is merging changes on the Linux kernel development
  • Linux kernel development happens in a distributed manner at scale

When I think about that, there are decisions Linus made that make git work well for him. In other aspects, not so well for others.

One of those things the concept of “distributed”. Every git repository is it’s own “source” - and which one is “authoritative” is only determined by the users, not by the system.

Example: your local copy of work from github.com can be the “authoritative” version OR the version from github.com - which may / may not have changes from others. It’s up to you which source to “pull” from or push to.

Because Linus designed git using the distributed model, centralization is up-to the user.

Want to develop centrally? Sure - have everyone agree what’s “central”.

Want to develop in a distributed manner? No worries - the system will be able to figure out the common intersection with ease.

In a way, knowing where your tools came from help you use your tools better.