5 ms·
Git Exercises
- mcadenhe 6y agoExcited 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/ https://pgexercises.com/
- antoniuschan99 6y agoThanks for this :). A few more: https://jskatas.org https://jskatas.org https://www.flexboxfroggy.com https://www.flexboxfroggy.com https://www.cssgridgarden.com https://www.cssgridgarden.com
- justusthane 6y agohttps://vim-adventures.com/ https://vim-adventures.com/ https://www.vimgolf.com/ https://www.vimgolf.com/
- bmn__ 6y agohttps://flukeout.github.io/ https://flukeout.github.io/ https://deadlockempire.github.io/ https://deadlockempire.github.io/ https://fightcodegame.com/ https://fightcodegame.com/ https://play.elevatorsaga.com/ https://play.elevatorsaga.com/
- CrunchyTaco 6y agoThis 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.
- harsilspatel 6y agoHere's another great resource that was posted not too long ago https://learngitbranching.js.org/ https://learngitbranching.js.org/
- notafraudster 6y agoResponding 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.
- auxym 6y ago1. If the large objects are not referenced by any commit anymore, they should automatically get garbage collected eventually, but you can force this process with git gc: https://git-scm.com/docs/git-gc https://git-scm.com/docs/git-gc 2. Never seen that one. There's probably an arcane filter-branch command that could detect the duplicates and squash them, but personally I'd just leave it alone. How often do you look at many-years old history anyways.
- notafraudster 6y ago
- thamer 6y agoThat 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.
- mcstafford 6y ago> git start master I've been using git for years, and can't find documentation for start. https://gitexercises.fracz.com/exercise/master https://gitexercises.fracz.com/exercise/master https://git-scm.com/docs https://git-scm.com/docs
- yissp 6y agoThe configure.sh script you run at the start creates a few aliases (start, verify, exercises). See https://raw.githubusercontent.com/fracz/git-exercises/master/configure.sh https://raw.githubusercontent.com/fracz/git-exercises/master...
- dengsauve 6y agoThank you for posting this, when I cloned the repo initially from the site, configure.sh was not included.
- kubanczyk 6y agoYup, the initial `git clone` is checking out detached head 71c5f2d08f23d30c6fc11ac71d65f683b326c844. It looks like the remote bare repo has a botched HEAD. Workaround: cd exercises git checkout master ./configure.sh git start
- toyg 6y ago> It looks like the remote bare repo has a botched HEAD. So the guy teaching us git has a messed-up git repo...? (╯°□°)╯︵ ┻━┻
- cgriswald 6y agoFrom the site: > And the git start? > That is the first alias configured by the script described above. It initializes the first exercise that is on master branch. Read the instructions and solve it!
- JoshMcguigan 6y agoAny tips on fix-old-typo? I'm familiar with interactive rebase, but for some reason I'm not able to get something the `git verify` script likes.
- deleted 6y ago[deleted]
- karolist 6y agoHere's how I did it, but I think there should be a more optimal solution. Inspect history, see that mistake was made 1 commit ago git log Interactive rebase to edit last 2 commits git rebase -i HEAD~2 This will open rebase editor, change first line to below edit e794bf2 Add Hello world pick 77c37d2 Further work on Hello world Fix typo in file.txt stage modified file.txt and amend to commit git add file.txt git commit --amend In the editor fix commit message (again?) This causes merge conflict in file.txt, should be avoidable? git rebase --continue Edit file.txt to remove conflict markers, make it as below Hello world Hello world is an excellent program. Again, stage file.txt and continue, just exit the editor, no changes needed on the last commit. git add file.txt git rebase --continue You can inspect with git log, but that's it git verify
- cmehdy 6y agoThanks for the resource! I've noticed that if I run a clone `git clone https://gitexercises.fracz.com/git/exercises.git https://gitexercises.fracz.com/git/exercises.git` it gets cloned in "DETACHED HEAD" mode and I need to checkout master, i.e. `git clone https://gitexercises.fracz.com/git/exercises.git https://gitexercises.fracz.com/git/exercises.git -b master`. Any idea why that is? (It ultimately wasn't a problem once I switched to master, but without doing so there would be no configure.sh script either and I'm asking in case someone else runs into the same issue).
- miqkt 6y agoIt looks like `.git/refs/remotes/origin/HEAD` doesn't exist, which might explain why a fresh clone results in a detached HEAD (i.e. Git should default to being on the branch referenced by this entry). As for how you can end up in such a state on the remote, I'd actually be interested to know too.
- DonCopal 6y agoIt's a part of the exercise.
- remram 6y agoIs it, though? If the instructions in your "How to start?" section don't work, that feels more like a bug. I went through all the exercises and didn't find a point where this was relevant. Currently, the initial HEAD actually contains the solution for a future exercise. It was also created by a different user than the rest of the exercises. Maybe the detached HEAD should contain a README with instructions like "You are in detached HEAD mode, reach the master branch to continue"
- jimkleiber 6y agoI think you should call it Gitness.
- strstr 6y agoThese were fun. I would recommend filter-branch over log/interactive rebase for find-swearwords.
- mvansch 6y agoIs there a way to restart a challenge when you've made a mistake on(e.g. an extra commit)? `git start <challenge_name>` appears to keep the same state of the git branches associated with the challenge. I'm also noticing when trying to rollback to a previous commit with `git reset HEAD --hard <commit_id>` that I'm getting `fatal: Cannot do hard reset with paths.`
- mvansch 6y agoNevermind, `git start` does reset the state I just wasn't understanding the question correctly.