I've never really tried it myself, but a friend of mine found this quite helpful: https://learngitbranching.js.org/

That game is really good indeed; I wish it had existed when I first started using git. I definitely recommend it. If you're having trouble with git, it might be that your workflow is weird/unorthodox? What are some situations where you think you've messed up? Like what were you trying to do (and how did you eventually do it)?

And there's plenty of other resources: • https://ohmygit.org/ • https://gitimmersion.com/ • https://gitready.com/ • https://githowto.com/ And if you want a really extensive source, there's always the book: https://git-scm.com/book/en/v2 (which I myself will probably never read).

I highly recommend https://git-scm.com/book/en/v2 — it can be used as either a tutorial or a reference!!!

The git-scm book above is what made me finally "get" git, and got me to a point where I could help undo coworker blunders like force pushing something bad to main 🙂

I don't understand how you can push something bad. If you have a feature branch and create a PR which has to pass tests, then how can you push anything bad to master? Because then you'd be force-pushing to the feature branch before the merging. So the master branch would be untouched until you merge. But you don't merge blindly, do you? Pushing something bad can only happen when you're alone on a project. But then it doesn't actually matter.

If you have a feature branch.

This was back 13ish years ago, before PRs/code reviews/CI/CD were standard, and our team (still new to git coming from SVN) could still push directly to master whenever

So then there is a question: Why are there multiple developers who push into the same branch but don't use feature branches?

I remember working at a start-up where the CTO guy was pushing and breaking the code sometimes. And not actually breaking accidentally, but renaming folders, moving files all over the place and so on... You can do this... but then how can you work with it? It's sometimes useful to restructure the project. But well... you have to communicate. So if you blindly push your non-working code this is also lack of communication.

You're preaching to the choir. :)

I'm providing alternative points that can be used to derive the same conclusion, yes 😄

> It's sometimes useful to restructure the project. But well... you have to communicate. This point isn't even about git at all. This is about how you work. Recently there was a presentation with John Romero and he said that during the years they wrote Doom they didn't have git and source control at all. They were communicating by owning piece of code and by talking instead.

> Why are there multiple developers who push into the same branch but don't use feature branches? You've been lucky if you've never worked in an environment where everyone just works directly in the master branch. In my experience this is sadly common, also common to work in master and have 0 tests.

I too find git really confusing, I can fumble through for my day to day basic usage. But anything that deviates from that and I have to get lucky to not make a mess

I recently started https://shop.jcoglan.com/building-git/, which recreates git in Ruby. But I'm writing it in Clojure instead, while also trying to translate into a functional design instead of the OOP style supported by Ruby. Hoping to turn it into a useful library for Clojurists to interact with git repos, with the cli interface being just an example client. 🤞 Probably more than you are asking for, but thought I would bring it up, since a part of my motivation began in the same place. (I'm also very interested in how all the tracking, diffing, merging, etc. actually works.)

Unfortunately I haven't actually made much progress on the book yet, because 🐰🕳️🕳️🕳️ . 😄 The very first "commit" of the book is written with the assumption the project at that step is a single file in a flat project. But even bare Clojure projects already have source and output folders, a cache and other hidden files from tooling. So out on my own, with a plan to read gitignore files, led me to building a parser for POSIX pattern matching, that can then be easily modified for git-specific rules.

So far Magit has let me guess my way through Git and do many things I otherwise would've never done with Git, but I'm clueless the moment I'm stuck with the Git CLI

Why is your own pattern parser better than POSIX pattern parser?

Not sure what you mean? Does Clojure come with built in parser for POSIX pattern matching?

Ah, for a moment I thought that your own implementation of git would be an interface to git -- a wrapper. But what you're doing is a reimplementation which may end up to be non-compatible with git's files as you don't want to use POSIX tools but you decided to reimplement them (the matcher).

> So far Magit has let me guess my way through Git and do many things I otherwise would've never done with Git, but I'm clueless the moment I'm stuck with the Git CLI I think this is actually a big part of my problem! I too use magit and it let me be lazy about learning git for so long

Yeah, everything written in Clojure. But it needs to stay compatible.

So I have to know what rules are being used for parsing and replicate them.

Waiting for the presentation when you'll finish it then 😄 Maybe it will solve branch problems too

Oh, for sure. And instead of an interactive rebase, it will just read your mind. 😉

AI, LISP is intended to do AI, yes.

Gheez! I'm teaching myself how to do parsing, just so I can get past page 30 of a 700 page book. And now you want AI for it too?

@U03099N7XU2 I often find myself teaching git to m'colleagues. For homework, I make them work through: • John Wigley's Git from the Bottom Up: https://jwiegley.github.io/git-from-the-bottom-up/ , and • Ry's Git tutorial: https://johnmathews.is/rys-git-tutorial.html Additional material: • The Version Control section of the lovely "Missing Semester" course: https://missing.csail.mit.edu/2020/version-control/ The key is no copy-pasting anything... type out all the commands / git operations in the terminal. Invariably, people who don't do the typing-out continue to flounder after my workshop. The ones who put in the work develop the sense and confidence that further helps them "see" their version control in their mind's eye, and discover more git for pretty much any situation they may want to solve (bisect, automated bisect, octopus merges, filter-branch rewrites etc).

I think git-scm is too vast and improperly structured for the purpose of teaching git. It works very well as a reference book.

I git rebase -i quite a lot when working in a solo branch. Sometimes I mess up the rebase, but I'm able to recover everything with git reflog https://git-scm.com/docs/git-reflog . It's basically a transaction log for git, and it gives you the sha-1 from before the action has taken place, this allows to recover from almost everything

Usually the metaphor that works for me with git is that git is like a pearl collar. A branch is a line that makes the collar A commit is a pearl If you start a new branch, you will tie a new line into a specific pearl (the last commit before the branch was created) New commits on this new branch are "pearls" on this new "line" If you merge the branch back on the master/main branch, and there are no commits on that master branch, it's a "fast forward" merge - basically, both "lines" become one If, on the other hand, there are new commits on that master branch, you generate a "merge commit" - basically, a new "pearl" that ties both strings together A "rebase" is the destruction of the line and all pearls, and replace them with new pearls And, that's basically it :)