Red Green Repeat Adventures of a Spec Driven Junkie

git: Always Fork

When working on a project with git, always fork the repository.

Why? When I understood Linus designed git as a distributed system, use git in a distributed manner and one should always fork the repository.

  • you have your own copy
  • all of your branches are yours
  • you shooting yourself in your foot only affects your stuff
  • you work your way (warts and all)
  • once you understand forks, “centralized git repository” will be trivial

Your Own Copy

Having a fork of the main repository means you have independence of what is happening with the main repository.

Of course, this adds overhead for your fork to sync with the main repository.

Maintain Sync

Add upstream remote

The upstream remote is a reference to the main repository you want to maintain sync with:

$ git remote add upstream <main repository git URL>

Updating with upstream

$ git fetch upstream
$ git checkout <branch to sync>
$ git pull upstream <branch to sync>

Example:

$ git fetch upstream
$ git checkout master
$ git pull upstream master
$ git push origin

This ensures your current master branch is in sync with the upstream master branch and your fork, origin is in sync as well!

Update all

another shortcut that JK taught me:

$ git remote update

This will update all remotes and branches.

Who’s Branch Is It Anyways??

Whenever I work on a centralized repository, the branch list always devolves into a mess of:

  • feature_x
  • temp
  • temp_master
  • develop-20211108
  • mydev

It’s just a headache to even go through and figure out which branch are removable. Branches are easy to make - it’s part of git’s design!

With your own forked repository, these are the branches you can have:

Basically, anything you want! If you don’t want master? Just delete it, rename it, whatever you want.

IT’S YOUR REPOSITORY!

Cleaning up Inherited Branches

If the main repository isn’t well maintained, your fork will inherit those branches and well, you have to clean them up. The easiest way:

git remote prune origin

Only Shooting Yourself in Your Repository

git is a powerful tool and everyone’s comfort level in using it is different.

Forked repository contains your actions to your repositories, branches, pushes, and most importantly: errors.

If you accidentally do a git push -f (which should be part of your workflow!) to a shared branch on the main repository, well, anyone working off that branch won’t have a good day (unless their git knowledge is highly advanced.)

So, having your own forked repository will save yourself if you ever typed in the wrong thing or do a git push -f or anything else to shoot yourself in the foot with git.

git is a powerful tool - it will do whatever you command. That’s what makes it great and scary.

Work Your Way

Just like having a fork to contain your errors, you have the freedom to work however you want.

  • If you want branches with random names, why not?
  • If you want a single branch on the whole repository, why not?
  • If you want to create hundreds of branches, why not?
  • If you want to have lots of commits, why not?

You gain freedom with your branches. You don’t need to conform to the rules of the main repository because well, it’s your repository.

Forked Repository » Centralized Repository

Ultimately, once you know how to work with a forked repository, a centralized repository will be trivial to work with.

You might not like the rules of the centralized repository, but you can always fork.