Git Exercises

Excited to give this a try and see if it will help me expand my day-to-day git-fu.

I like interactive learning resources like this. A similar one was posted to hn a while back for postgres and going through it taught me a lot. https://pgexercises.com/

This was great. The exercises towards the end definitely taught me some new tricks. `git reflog` and `git bisect` weren't part of my git lexicon, but they absolutely will be now.

Responding in hopes some Git non-novices are here and can give some quick advice.

I have a fairly large Git repo with 5 years of commits from numerous team members including a bunch of non-technical people who had never used Git before.

There were two major issues:

1. We started off storing binary files -- mostly images, but also a ton of raw data files that got versioned every day or two -- in this repro and it spiralled out of control size-wise. I ended up using "BFG" to nuke the binary files and I think that worked, but it still feels like the repo is way too large in terms of file size. Is it possible that orphaned old versions of files are floating around somewhere in .git/? What are the best practices here?

2. The branching strategy was badly wrong. We used two branches: production and dev. New commits are made to dev, dev is merged into production periodically via GitHub PRs. Dev is NOT deleted and we did not use a squash strategy on merges. Somehow this resulted in the repo having 2, 3, 4, or 5 copies of the same commit immediately in a row. I think that somehow a branch got merged into itself? I don't know how that would be possible, but I can tell you the symptom is that there's a period of time several years ago where every commit appears in quintuplicate, and this slowly decreases until every commit is just doubled, and then at some point we're back to a correct commit history. What's the likely cause here and what's the likely solution?

We would like to fix both these things while preserving history (obviously the problem could be immediately "solved" with rm -rf .git && git init, but we'd like to avoid that at least partially so that no one who worked on the project has their historical commit record broken and so we can still use blame to know who most recently touched some of the older stuff)

My own git-fu is not great, so, thanks for posting these exercises.

You should use git-lfs for these files. Probably some wizardry with `filter-branch` and adding these files to lfs could debloat your repo once you do a fresh clone from that.

That was very well done, I really enjoyed it.

I liked that a few of the exercises had multiple solutions; it's often the case in real-world use that various approaches can work. The exercises themselves do cover many common situations such as having to edit a commit that's not the HEAD, or porting changes from a branch to another, or finding the source of a bug.

I had only ever used git-bisect once but had the same impression then as I did now with these exercises: that it was super powerful for this particular situation.