Thread by @QuinnyPig

In today's thread we're going to learn how to work with git. I'm an expert in git because ten years ago I watched a @chacon talk, realized there's a LOT of complexity to it, gave up, and focused instead on shitposting. This is very much the spirit of git.

Before git we used alternate forms of version control: svn, cvs, perforce if you're @jpaulreed, "Copy of Copy of pythonscript_ ver1c3333 (Repaired)v2_AA-zz - Final Draftver5_FINAL (Autosaved) AA_v2-ZZ use this one_AA-zz_AAoldver-zz_AA-zz Feb24.rb," etc.

In Subversion, finding out who changed a given line of the file was done via either `svn bless` or `svn blame`, which both did the same thing. In git it's just `git blame` because in this era we're a lot more honest with ourselves.

What is git? It's a distributed version control system, which means it's basically hypeless blockchain.

Git was written by Linux author Linus Torvalds, who's a brilliant engineer who talks so condescendingly to people that it's basically "the subtext of Google engineers' 2010 conference talks."

Git was fully decentralized--everything was peer to peer. No one repository was "central;" all copies had a full history.
The industry saw this, freaked the hell out, demanded a centralized option, and then @GitHub was built and acquired for $7 billion or so.

`git init` creates a "hidden" .git/ directory. If you cd into it, you'll see a lot of strange files and folders. They're arcane, but important.

It's best to back these up, so run `git init`.

You can configure git with the --config flag. "local," "user," and "system" are the three places that it can store things--namely for a specific repo, your user account, or /etc/gitconfig.

The latter is a best practice to confuse the living hell out of your peers.

Other competitors include mercurial (hg), CVS (dead), RCS (wow I'm old), a bunch of proprietary options nobody uses, or "simply writing your shit properly the first time so there's only one version."

Every git commit is a snapshot of the current state of files that git is managing.

You can use 'git pull' as a code deployment system to production, but it's often faster to stand atop a mountain with a metal rake during a thunderstorm and curse god.

I know I joked upthread, but you can indeed have a git repository within another git repository. This is accomplished via either git submodules or git subtrees.

Which is best? Neither. Absolutely never use these things. Most of git is written in C; these are written in pain.

Have you screwed up in git and are afraid you've lost data? `git reflog` is your friend, but it's the second thing you do.

The first thing is recursively copy the directory elsewhere as a backup because when you find yourself in a hole, stop digging.

Did a thing used to work and now doesn't? When did it break and why?

`git bisect` is your friend. (So is @gitbisect.)

It does a binary search through history to isolate the commit that broke everything.

"What's git rebase?"

It integrates multiple branches. It has a few uses, but be aware that it rewrites history like it's a Texas textbook.

These days learning git isn't a multi-day endeavor. Both @github and @gitlab have excellent documentation, but for my money / learning style?

`gem install githug; githug`

That's not a misspelling. You may thank me later.

Do you have to work with a whole bunch of git repos because your company interpreted "microservices" as an invitation to try for the high score?

myrepos is great for this. (myrepos.branchable.com)

Have you accidentally committed credentials (like @awscloud keys) to your repo and then pushed? There are ways to fix this; git filter-branch is finicky, `bfg` is Java. Then you get to force push and spend the week hiding from your colleagues' retribution.

Alternately use this to your benefit. Is there an @awscloud service you can't figure out how to configure? Scope an IAM role to the service in question and commit creds to a public repo.

Soon, people will configure it to mine bitcoin. Turn that off, then use what they built.

I have been informed that unlike the contents of that Texas textbook, git itself does evolve. TIL; thanks for the tip!

https://twitter.com/leo60228/status/1364766914820665345

Many common "github-isms" aren't actually part of git itself--including forks, pull requests, issues, public vs. private repos, or support that is in any way supportive / friendly.

You can also use commit hooks--scripts that fire off at different part of the git lifecycle.

They live in .git/hooks so they're outside of the working tree and not part of the upstream repo; this is a design decision focused on increasing workplace collaboration by force.

The cloud providers all offer git hosting: Microsoft owns @github, @awscloud runs CodeCommit which has no customers, and @Google offered Google Code, killed it in 2016, and now offers GCP Cloud Source Repositories because it hopes we have the collective memory of a goldfish.

JGit from the @EclipseFdn can use @awscloud S3 buckets as repository backends.

Not kidding: years ago I had to use this to copy data (open source code) *into* a company's environment due to a hilariously overzealous infosec posture.

you: 'git push origin main'

git: whines about upstream branches, doesn't offer to do it for you

you: git config --global push.default current

you from now on:

Need to integrate with a version control system that isn't git because either you or your company are engaging in some "the earth is flat" / "IBM has a real cloud" level denialism? Git still has you covered.

I will now field questions. I've already learned some things from the comments so far!

Git confuses *everyone*. Let's learn together!

I’m near-certain that @ksylor built this during a conference in Zurich we were both speaking at—or am I misremembering the timing?

https://twitter.com/mnewkirk/status/1364779497237618688

That’s all of us. The best practice is to grant access to ‘*’ and then lie like a rug about it in public.

https://twitter.com/donmacaskill/status/1364789199593820167

There are lots of great ways to use git to collaborate.

The git maintainers build git by emailing their patches to a mailing list.