Once you're done with the tutorial bit, the https://learngitbranching.js.org/?NODEMO version is good to try out commands and see what the tree looks like after each command.
The problem is that source control is optimally a visual activity: the source control tree is a diagram, and the operations one does to it are diagrammatic.
Text-command-first approaches lead to inferior and hard to understand APIs which are, at best, papered over with a GUI. Managing the source of the project should be a series of trivial visual operations.
Bothers me a lot that you're getting downvoted. Bunch of elitists who insist that cmdline is only way to get things done (everyone has to study cmdline options because who could possibly have multiple 4k screens for some visual options dialog?), probably using GDB in 2025 and having massive Stockholm syndrome about it, ...
I'm one of those folks who will tell people to give the official CLI frontend of git a chance and to try and stick to it. I can assure you it is not out of elitism, but experience. I've tried the many third party GUI frontends, and always got myself into bigger trouble down the line in the end, nor did they bring any of the revelatory boosts in insight they claimed they would. And of course, they're all a little different from one another, so migrating between them is an additional chore.
Then of course it's possible I didn't give the many GUI frontends enough of a chance. Such is life, it's a resource limited game. Principally, I justify my position with the argument that the many GUIs will try to translate git into something visual by adding their own designs, and this can prove additionally misleading and difficult, if git wasn't rough enough already.
The only GUI bits I use for git are editor integrations such as the official one in VS Code, and only when I know it's adequate. Which you can only know if you know what's going on in the background.
GUI is absolutely easier for merge conflicts. I use the one that comes on jetbrain ides which is awesome.
This isn't even opinion. It's fact. Anyone who has experience regularly(keyword) using both CLI and GUI for merge conflicts will side with me on this by an overwhelming majority such that I might as well call this fact.
The community seems to disagree so far. I'll take a look at how it works tomorrow though. For me most of the misery around merge conflict resolution stems from how git fundamentally works, so I'm not sure how much it can possibly improve on it.
The only people who disagree are people who don't have regular experience from both sides.
Graphical diffs that automatically handle merge conflicts visually with clicks to insert, undo and the ability for custom modification are MUCH MUCH more convenient with a GUI. Highly recommend the jetbrains conflict resolver gui.
I can assure you ANYONE who regularly has experience with both the CLI and that GUI(jetbrains) will hands down say the GUI is superior for merge conflicts. It is NOT intrinsic to the nature of merge conflicts. Any disagreement in this area stems from lack of experience or knowledge.
If anyone has experience with both and they have a contrary opinion, feel free to tell me. I doubt such a person exists though.
I find ediff from Emacs to be superior to the JetBrains conflict resolution view. And I've had to deal with some gnarly (and large) merges at $JOB.
I dunno, something about its keyboard-driven design (and in general being Emacs-based) makes it clearer in usage than the JetBrains offering. Although this is probably what one is used to.
Of course, the really important thing is that people set merge.conflictStyle = zdiff3. Maybe a bit opinionated, but it really makes proper merging a lot easier.
Ediff is still a GUI (yes, even if you're running emacs -nw).
I also thing Ediff has some very annoying behaviors - the fact that it doesn't use intuitive names for the two buffers (especially because of Git's annoying nomenclature when rebasing vs merging), and the fact that there's no shortcut for inserting both the A and the B changes into the destination, which is a common operation.
I haven't really used the JetBrains merge UI, so I don't know if it's better or worse, but I don't think it's very hard to improve over ediff.
I've seen another gui waaay back before git was popular. Perforce actually handled merge conflicts with a GUI just as good. I think it's still just as good, though almost no one uses it.
> Graphical diffs that automatically handle merge conflicts visually with clicks to insert, undo and the ability for custom modification are MUCH MUCH more convenient with a GUI
Not saying you are wrong, I used to only use VSC Gui for merge conflicts. Then at some point learned to edit myself and just use the CLI. After many many years I tried lazygit (TUI) for merge conflicts while still being in the terminal and I don’t think I can go back to do it manually anymore.
I honestly don't mean to insult you but when you say things like this in a discussion where others obviously disagree with you, it makes you seem like either an overly enthusiastic beginner that hasn't learnt about tradeoffs yet, or a very stupid fanatic. You might be neither, but that is how it comes across.
>Anyone who has experience regularly(keyword) using both CLI and GUI for merge conflicts will side with me on this
I and many others simply disagree with you. I have used those tools. They work okay in simple cases but break down in more complex ones. That is my opinion.
You seem like a stupid idiot too. I don’t mean to insult you either, honest this is just how you come across to me as well.
I would say very very few people would disagree with me. I would even argue that your experience is in fact limited. You probably worked with a trashy gui and likely didn’t use it too much.
I regularly use jetbrains to merge the most massive conflicts. There is no use case that is too complex for it to handle. The fact that you even said these guis can’t handle complex use cases indicates an extreme lack of experience in this area.
I am sure you indeed do successfully use JetBrains to merge "the most massive conflicts". Good on you. I'm glad it works for you.
The mere fact you've even typed out the words "Anyone who has experience regularly(keyword) using both CLI and GUI for merge conflicts will side with me on this" makes you look like a child. This is how children speak.
>You probably worked with a trashy gui and likely didn’t use it too much.
You don't seem to be able to encounter someone that disagrees with you without immediately assuming they must be doing something wrong, lack experience, or be stupid.
Again, how hard is it to accept that people have different preferences? You are like those people on forums in the 2000s that argued that anyone that liked Ruby/Python was an idiot and obviously Python/Ruby was the far superior language. Anyone that disagreed obviously had never used Python/Ruby properly, and was obviously just a fanatic. I thought we moved past that stupid shit years ago.
> You don't seem to be able to encounter someone that disagrees with you without immediately assuming they must be doing something wrong, lack experience, or be stupid.
Yes. Not stupid though. More lack of experience. That’s my opinion about it and in my opinion the gui is better and that is a fact.
What I don’t understand is why my opinion about something as a fact no matter how extreme leads to you openly calling me a stupid fanatic and calling me a child?
I said you come off as stupider earlier but not to be insulting but I also said it to sort of illustrate what happens when you call someone stupid and then say the words I don’t mean to be insulting as if that negates what is in actuality an insult. It doesn’t and now you’ve openly called me a child. This ends here. Good day.
This is basically my workflow too. I use git from the command line until I need to resolve a merge conflict, then I hop into vscode to resolve the conflicting file.
I don't consider myself a very core or talented developer, but I do feel quite strongly that git from the cmd line is much easier than a GUI, but overall ridiculously hard regardless. The abstractions and visualizations in graphical interfaces is either too dense & complicated, or more likely hides what's actually happening; there's no way to reduce the inherient complexity.
My take: don't play the game. learn your basic required workflow from the command line and use the decent documentation to look up everything else.
NB. I did explicitly say a GUI on top of a cli app is a broken approach. Your intuition comes from this -- that the git API is cli-first.
Source control should be designed graphically first, with a cli to automate. I routinely use tree-view and column view in macos finder to think-through fs organisation -- doing this as a sequence of cli commands would be masochistic.
Notice how all the best vcs tutorials are just providing basic visuals which would be better as the interface.
The thing that CLI have over GUI is programmability, which for programmers is a valuable property. As for me, any repeatable task, I automate away with various degree of effort and quality. If I find myself needing a particular set of commands and flag, I create an alias, a function, or a shell script for that, like `flac2mp3.sh` instead of hunting down through the shell history.
For most vcs tutorial, they don't often use why the history of changes is important, instead focusing on a set of usual commands. Why, not how. Once you have that philosophy down, the tool usage become much more efficient.
I thought I would be just fine with the CLI but I was amazed by magit. A GUI can work well if it leans into the strengths of GUIs - discoverability of features and showing state. Magit does all of these exceptionally well. It helps that git's CLI is quite poorly designed with a lot of unintuitively named commands. How do you undo a commit? How to unstage a file? What's a stash? What's the difference between log and reflog?
With magit I've been able to do things I wouldn't bother before, like reverting small parts of hunks from past commits, doing partial staging of files (not including all changes), and dealing with stashes effectively.
I work in a lot of repos at once. I do a lot of global search-and-replacing and random debugging. With SourceTree, I can easily see all the changes I've made across all repos in one glance.
I can then drill down to each file with the visual diff and see whether the changes are something I want to check in, or just debugging. If it's debugging code, I can click "Discard Changes" to drop all changes I've made to that file. Or I can selectively discard a hunk or discard lines.
When I show these features to command line purists, they always concede that this can't easily be done with the command line. So I don't see what's to gain if I'm losing those features, which I rely on constantly.
I've been working in SourceTree for a decade, so I know all the quirks by now, which I pass on to any new devs who want to use it.
Which is kind of the point. If a GUI editor does this stuff for you, that seems like a win over incrementally learning these little command line tricks that save you a bunch of time.
That’s fine for some and I have no problems with it but my mind doesn’t work that way and instead it asked “how is possible the UI is doing this”. All of that lead to learning what hunks are and manually editing them to learn.
How does this scan a bunch of repos at once and let me see all the changes at a glance, and then drill down to individual files to either discard the changes (revert back to their committed state) or check them in?
All git add -p does is that last part from what I can tell. I'd still have to cd into each repo and run git status one by one (I've made changes to up to 10 repos before for one tweak), and then do a git add -p to the changes I do want, and a git stash to the changes I don't and then delete the stash.
If "cd" and "git status" in a bash for loop is too advanced, you might need a GUI. Though I'd also argue that you've got too many separate git repos if you're finding yourself needing to do that often. It all depends on where you are on the journey to Monorepoland.
We're too small to implement a monorepo, because no one has time to build the tools we'd need to do it right. I still don't see what I gain by cd-ing into all those directories and running git status and looking at a bunch of text results, when I can just glance at the SourceTree repo window and see all the repos I've touched.
You're not offering any benefit that I'd get from using the command line over my current process, except, apparently, being able to express your superiority over GUI users.
I semi-agree - the real win is in unstaging changes you didn't mean to stage! Much easier in a GUI, because I don't have to remember the non-symmetric CLI command.
There's a really good argument to use plaintext - it lends itself to very efficient use through searching, matching and replacing, whether interactively or in bulk. The lack of structure and semantics in a pure plaintext representation is often a curse, but sometimes a blessing.
At the same time, I'll go further than you, GP and GGP - I'd say that insisting on coding in plaintext, specifically on always directly reading and editing the same plaintext, single-source-of-truth representation of a program, is fundamentally limiting our ability to manage complexity, and makes people waste a lot of time on faux-problems like "lots of small vs. few big functions", or "exceptions vs. result types", etc.
FWIW, plaintext is still okay for most coding use cases - it's trying to fit everything into the same source code and somehow keep it readable that's an impossibility.
It bothers me a lot that you're complaining about downvotes when the comment you are replying to isn't even greyed out let alone flagged dead.
It bothers me a lot that you can't discuss something like this without turning it into personal attacks. People can't just have different preferences than you. No it has to be "elitists" with "stockholm syndrome". This kind of rhetoric is unbecoming of this forum and destroys amicable discussion.
Have you considered that maybe people use the command line because it is better for them, and they recommend it to others because in their view, you'll need it eventually so why not learn now?
You can visualise a git history with a gui tool while still learning the command line interface btw. They aren't mutually exclusive. Do you just use scratch too? Or are you one of those elitists using textual programming languages? Must be stockholm syndrome...
I learned the git CLI first, and still prefer it, but I've found VSCode's source control plugin very helpful for teaching newbies. I tell them to avoid the synch button and just manually git fetch/pull, but adding a commit is easier for a newbie to do visually.
I also found LazyGit recently and think that's a good middleground for doing things from the CLI.
If someone doesn’t use the CLI, they are a newbie? I’ve never needed to learn or use the CLI, the GitHub tools built into JetBrains IDEs and VS Code have always worked fine for me, and I’ve been a professional developer for nearly 30 years.
I think the idea is that the people you'd teach version control to are typically the newbies. You can also just be new to git specifically or the git workflow on any given project.
I love this book. It's what helped me move from an intermediate Git user to an advanced one, and I've subsequently trained a bunch of people at different organizations by going through it.
However, Pro Git is not an ideal resource for newbies unless they are highly motivated or receiving generous training. A simple graphical representation of your own repo goes a long way towards establishing a mental model of what Git is doing internally — which is in my view the chief insight of mjburgess's post at the top of this thread.
You’re probably right about that. I used a certain interactive online course when I was a beginner, but they’ve added “AI assistance for guided coding help”, so I hesitate to recommend it.
FWIW, the Git website links to some videos and external tutorials, which might be of use: https://git-scm.com/doc
Does not still fix the root cause that Git is super-bad as an industrial tool - actions that should be trivial push-button activities become incomprehensible command line character soup.
The fact there is a book on the subject speaks volumes about how bad it is.
If the existence of a book speaks volumes
about how bad something is or is not, I have some bad news for you about what's inside libraries. What beloved subject doesn't have a plethora of books written about it?
Exactly. VCS is part of an industrial process. It's not supposed to be implemented with a thin wrapper to a database whose node structure you need to rummage through.
The software analogue would be that in order to use the platform default List and Dictionary data structures you would need to manually manage the links between the data nodes.
Or to use text editor you would occasionally tweak the rope datastructure or equivalent. Etc.
VCS should be trivial push-button activity (and _is_ except with Git). There is no added value making a thing far less usable than could be. This is not git’s fault - it is what it is. But it is incomprehensible industry selected it as it’s de facto vcs.
All of them. A command line should not be the default option.
Again, this is not to bash Git. It's a bash on the industry for selecting tool that requires engineers to spend time and effort on non-value adding part of their work rather than offering a solution so simple you would most of the time not even think about it.
I use this whenever I need to look up anything outside of our workflow, but don't believe internalizing the myriad of git details has a very high pay-off. There's probably higher value knowledge in your role that you should prioritize.
The payoff comes when you develop a mental model of Git's data structure design, which is stuff like "a branch is a named pointer to a commit" and "the central data structure is a content-addressable store" — and most germane to this thread, "the source control tree is a diagram, and the operations one does to it are diagrammatic". (Thanks mjburgess!)
Learning Git's infinity CLI options won't teach you that.
Which you can read easily in a week or two without much effort for something that is currently de facto for software development. The Emacs Manual has ~700 pages.
Relied on gitk heavily when first started using git. People used to SVN and such will find git unfamiliar and scary.
Once I understood it as a series of revisions where even branches have little meaning, I never used gitk again…
The command line is actually very good if one gets in the habit of using something like “git log -oneline —reverse —no-merges origin/main..HEAD” to see where they are.
The following command provides a visualization which is good enough to start from:
git log --oneline --graph
The more practical problem is that Github, which provides a useful graphic UI to complement the local command line for any project hosted there, is brain dead[1] about showing the source control tree as a tree and doesn't expose anything like `--graph`.
If you get tired of typing `git log --oneline --graph`, you can add a `git slog` alias[2] for it by adding the following in `~/.gitconfig`:
[alias]
slog = log --oneline --graph
[1] Gitlab is superior in this aspect, as it actually exposes a graph mode, via "[repo] > Code > Repository Graph".
`git log --graph` is just a really really bad GUI. Why not use a good GUI instead?
Although in fairness it's quite hard to find a good Git GUI because there are so many bad ones. The only good ones I've found all have some kind of flaw:
* GitX - the clearest design IMO, but it's one of those "gazillion forks" bits of software like TomatoUSB, and Mac only. Plus it has some annoying bugs.
* Git Extensions - I didn't even realise this was a Git GUI until relatively recently because it its terrible name. It's pretty decent, but Windows only.
* VSCode 'Git Graph' extension - my current favourite - it integrates into VSCode too which is much better than a standalone app, especially when using Remote SSH. However it is abandonware and although the source is available, the license doesn't let you republish it so it's not "open source" and nobody can take it over.
Disappointingly even these don't let you do things that a GUI obviously should let you do, like copy & pasting commits, dragging and dropping to rebase.
Like instead of `git rebase -i` and tedious text edits, why can't I just ctrl-select some commits, ctrl-C and ctrl-V?
But, they're still miles better than `git log --graph`.
It may serve a different purpose, but I personally use https://zolk3ri.name/cgit/ggrp/about/ for displaying commits, because it categorizes commits based on prefixes such as "feat:", "fix:" and so forth, and supports scopes too (e.g. "feat(foo)"), and a lot of my projects have commits with such prefixes.
`git log --graph` without `--oneline` is pretty hard to follow — that's not what I use, and it's not what I suggested.
With `--oneline`, it's not perfect but it's good enough to be useful — and by working within the constraints of the CLI, I didn't have to tell people to install software to get my point across.
And I already spoke approvingly of Gitlab's GUI for graph representation! I don't disapprove of GUIs; I use them all the time (particularly Github's). One you grok the data structures that underlie Git, you wind up seeing front ends as interchangeable.
Compare the graphs that people draw to explain git branching. They are usually very beautiful. Then you see the graph even these GUIs make, and they are still pretty bad. I think the visual graphs could be improved quite a lot.
No, I mean why can't you select commits in the graph and copy/paste them. I wasn't talking about copy/pasting the lines of text in the `git rebase -i` file.
I basically never used Git command line unless fixing some problems other people created.
It is just insanity when people claim "only proper way is to use command line" - well yeah it is much faster if you work on your branch and just need to make quick series of commits. But as soon as you have to deal with collaboration with other people and organize project, coordinate features etc. I find GUI invaluable and Git Extensions of course.
That's really it. Could I use the CLI? Sure. Do I? Nope. Using a tool like Git Extensions makes it so much easier to visualize what's going on. I have enough on my mind, I don't need to make the branch/merge/commit process harder than it is.
There are hundreds of them (everyone has an opinion about which is best). And most of them go out of their way to hide the nonsense that they have to jump through to get git to behave as the GUI expects it. Some of the visual git GUI tools do show you the gobbley-gook that they emit to the git CLI and it's shocking, like watching how the sausage is made.
Really, really good examples and walkthroughs with easy to understand, animated console sessions that show real-world-ish use cases including conflict resolution and why JJ's model makes it easier.
Really good read and easy to digest because of the animated session replays.
My main takeaway is that the missing pieces right now are IDE support for a world filled with detached heads and a foolproof upstream integration pattern on `push` (requires a bit of manual work to designate the target branch).
I am 100% going to link to the original post and these replies next time there’s a jj thread and people express bewilderment about needing anything else because “git is so simple”.
I don't really understand struggles with git. I learned ~10 commands 15 years ago which have worked fine for me. I don't think I deeply understand git internals but it does what I need so not compelled to dig deeper.
I actually think git is a bad example of "just memorise these commands" - unless you are working with projects with a small number of users / branches - or you're fine to just delete and reclone if things get really hairy. I think a lot of my struggles with git came down to not grokking what it was actually DOING at first. Examples:
- not understanding branch pointers / staging / committing corrently. E.g. [add file] [modify file again] [commit] - what just happened? (IMO these things could have been named better). Also reset vs revert vs restore - easier to use these if you've internalised branch pointers etc
- git pull fails because it says it would overwrite a file you've never heard of - how is that file on your local? Is it ok to delete it?
- times when you (or your colleagues) need to rewrite history (rebase / squashing etc) - require a pretty good mental model of what is going on to both diagnose issues and to fix them
The thing is, for me, I have never really struggled with anything. I work on a large project and use rebase, force push, amend and cherry-pick sometimes. I am fully confident that I can get myself out of any bind that myself or others have created just using my ~10 commands and without deep understanding of git internals.
I agree with rebase on shared branches however, that requires coordination and understanding of everyone using the branch. Sometimes, long running shared branches are needed but it generally something to try to avoid.
A curated sequence of logical commits assembled into an idealized history is often much easier to review than the real history. However, to rewrite history well enough for that you need....
* a solid understanding of interactive rebasing, including `fixup` and `reword`.
* `git add -p` for adding partial sections of files
* `git commit --amend` for patching the last commit
* `git commit --fixup [COMMIT_ID]` for attaching patches to commits further back in history.
* `git stash` for pausing progress while you fix up an old commit.
* `git rebase -i --autosquash [COMMIT_ID]~` to apply the fixups
* topic branches that never get too big or drift too far from the mainline, because rebasing often becomes infeasible when repo snapshots are too far apart.
* A low enough error rate that you don't screw everything up when rewriting history (which is a reasonable critique and argument for why you shouldn't attempt this in the first place).
I can usually manage this, and efficiently enough that it's worthwhile — and my colleagues appreciate that my PRs are easy to follow. But as a reviewer, I don't insist on other people putting in the same investment.
It depends a lot on what you are doing. If making incremental changes to a production system, just try to use trunk based development style (except use pull requests - let's not be insane) along with targeted commits.
If you need to do exploratory work and need to share that with someone else, yeah, you will have lots of noise in these commits. Yes, maybe some of those commits wont even build depending on how long your build takes. One approach is to do a "clean room" style re-write with better quality commits (ideal) or likely some rebasing and cherry-picking might be needed - both of which are better than merging all of the noise to the repo.
Taken to the extreme, one could consider every character typed to be what "really happened" but of course no one wants that.
I've worked in more than one place where a 'clean history' was deemed so valuable that someone and re-applied all the deltas after the fact to create some kind of alternative timeline where everything landed just so, and we all had to eat the resulting force pushes to main
Every explanation of git I have seen starts by explaining that git is cool because branches are just pointers and then talks about the index/staging area. If you don't understand that then you aren't going to be writing code worth committing anyway, are you? A software developer that doesn't understand reference semantics?
> Every explanation of git I have seen starts by explaining that git is cool because branches are just pointers and then talks about the index/staging area.
Which is precisely _not_ a "just memorise these commands" approach to git right?
Also re: your general snark - try a bit more empathy? I'm sure you are an experienced dev but we are talking about people LEARNING git, they don't have the same points of reference as you do today.
I learnt git too. I was new to it too. It used whatever the information is that is on the official git website and had no problems. And that was back when its interface had quite a few rough edges that have been sanded down
Today there is "git switch" which people say is good for beginners. I have too much git checkout muscle memory.
This is like saying "I've lived in a house for 15 years and I've never had a problem. I don't understand how people could have a problem living in a house." The thing is, living in a house isn't a very specific experience. The difficulty of the problems you might face varies a lot by many factors.
If I run into a problem I would research it, what is so bad about that? Even if I studied git source code in detail 15 years ago I would have forgotten it by now.
Do you know how to build a working computer from individual transistors or understand the physics behind it (I happen to know these things personally)? If not, better crack open your modern physics text and study particle in a box, along with the requisite differential equations, calculous and linear algebra just in case you might run into a problem one day.
It's hard not to get stuck at some point if you don't have some understanding of the internals.
If I was a beginner, I'll try to get some proficiency early on rather than having to learn the hard way when you're on the middle of a project. It's a good investment.
I've also found that learning crafting nice commits made me a better programmer. It seemed difficult at first but now it's second nature (and I assume that in most teams, one is expected to submit small and self-contained commits anyway).
Never gotten stuck in the more than 15 years (cvs etc before it) of using it; never needed a gui and hardly needed to look up anything (but we can do what's the issue with that?); work(ed) on massive projects. It's just not that hard.
That is my main point, I have never gotten stuck despite not deeply understanding the internals. Instead I built a solid mental model just from the behavior of the commands.
This is a point that is not made enough. Git can be overly complicated if you want it to be. But 99% of your work is add, committing, branching and resetting. If you can do that you can probably never need much more.
I will say though that I get really nervous reverting sometimes, making sure I’m using the right command to reset etc can be confusing.
This. Maybe even more than 99% of the time you are fine. It's okay to struggle a day with a rare problem every now and then. Just don't be scared of it. There are enough resources out there to research them when you need them.
Where I still get nervous is when I force push my branch after a rebase, even if I know I am the only one working on it. But this is also one of these examples. If I remember correctly, there are other options to sync your remote after you did a rebase, but force push is just the easiest. So I rather take 5 seconds to make sure I typed exactly what I wanted and that everything is fine and that just works.
Edit: I was just brainstorming a bit about it and thought that probably some of the unknown magic git features were just implemented by a motivated dev that just wanted to explore what's possible. But on the other hand, there are most likely some very very obscure configurations and edge cases in the wild where people actually need those features. But most people will likely never need them, so I myself won't bother understanding "everything"
Agree. It only makes sense to be scared of it if direct pushes to master are allowed - that would be crazy. This + avoid long running branches and there isn't much to fear.
I agree that it won't cause collaboration issues. Perhaps the fear arises because force pushing destroys your backup, so to speak?
I freed myself from the fear of losing data after a rebase when I learned to restore from a commit in `git reflog`. So long as your work made it into an actual commit at some point, everything is recoverable from the local repo's history[1].
[1] Ignoring giganto repos that actually trigger garbage collection.
I was an English major and generally do not have the gift that makes programming come naturally. What skills I have, including passing Git proficiency, are the result of brute force learning, plus years of mistakes.
So I naturally assumed I could teach a team of non-engineers enough Git to enable them to interact with and contribute to text-only repositories as their job required.
I was quite wrong. Git flummoxes some people, and even the best visual tutorials (the ones that helped me immensely), leave some more confused than when they started.
YMMV but explaining simple Git concepts over and over in the face of incomprehension made me a bit of a dick too.
The idiocy that is "staging" is the primary problem with Git. 99% of people do not need "staging" and yet Git inflicts it on everybody.
"Staging" (and "stash") makes Git modal, and that's a pain in the ass.
Having taught people both Mercurial and Git, I can tell you that teaching Git is simply a losing battle. Fortunately, jj operates just like Mercurial but can coexist in the Github ecosystem.
What is wrong with staging? I don't even consider staging until it is time to commit, at which point it is a little area to gather the exact changes you need.
I'm actually surprised how many Software Engineers/Developers don't know how to use Git... I was once showing a Staff SWE on how to setup VScode + Python. I see kinda why when you're programming in vim + C(++) your whole career. But when I told him to push his changes to a temp branch or give me a git diff so I can try his changes myself, he had zero clue what I was talking about. His local `main` was over 2 months old. We had to prune and pull to get it back to match remote.
A funner part of the story, I was showing him how to setup VScode because programming using VScode...through RDP. That's right, he was programming remotely on the remote machine using RDP with VScode on the remote screen.
I've known quite a few software engineers who just don't bother to learn anything about the tooling they use to create and deploy code. For younger, new developers, I can understand it when everything is presented as an app with minimal customization, but for mid-levels and senior engineers I am baffled by the lack of curiosity.
Sometimes just a couple of simple howto sessions can be incredibly useful, especially for teams just starting on a new project. I've given tutorials on Git basics, command line basics, workflow basics, and AWS terminology. Each time I've had engineers say it was like learning computing for the first time, because apparently newer engineers just don't get taught this stuff.
This is partly why I enjoy improving the developer "experience" (DevEx) alongside my normal DevOps duties.
So on the other side of this, I’ve also seen senior+ folk working on projects alone, with no collaboration at all, but still use a GitHub-esque PR/git-flow process. Almost feels like a professionalism-espousing self-flagellation.
Create a PR, self-approve the PR, then merge it to a develop branch. Then merge the develop branch into main. Then in main make a release branch, and tag it.
I sometimes do something similar, as it gives a chance for the CI to run more comprehensive tests on other platforms that's hooked up to the PR flow, and "reviewing" your own code can be pretty helpful.
I can see doing this, stepping away from the change for a bit, come back and read the PR from a fresh perspective and see if you can make sense of the change and if there are any errors.
Yes. Because writing code is so easy a bot can do it these days. sets the everything else that goes into writing code that wants to be captured, so following process is about how much you love future you, who has to come in three/five/ten/twenty years from now and figure out wtf you were thinking when you wrote this. Did I mean to use > instead of >= or was I just careless?
That's such a relatable story - and I feel like it highlights something I've been thinking about a lot while working on these visual and gamified Git tools.
There's this whole class of capable engineers (some at senior/staff levels!) who just never had to build good Git habits or learn how to think about the different options that Git's command set provides, because their workflow didn't demand it.
Curious - do you think that's mostly a tooling/culture thing, or more of a learning gap, where they just never had a reason to dive deeper?
Part of why I'm making these tools is to explore if a more visual approach might make some of those concepts stick better. But curious what you've seen actually work in practice for helping people improve their Git skills.
As you highlight with the "VSCode over RDP" story later on the post, it doesn't stop on Git. Some people just don't care about learning their tools. RTFM? Hell no. There is no care for the "craft". Once they learn the very basic for their current need, they're done with it.
We can also observe this behavior during coding, once "it works", they just push all changes and move forward to the next thing. No second thoughts if it could be simpler/there were unnecessary changes, no double check if there is missing cases, etc. "Someone will spot my wrongings during review".
From the outside, it feels like "low effort" all around. But to be honest, I can't really blame who does this. For some, it is just a 9-5 job anyway and they prefer not think about these stuff outside that 9-5 space. Deep diving into their tools might look like "wasted time" on their view.
This is simply what happens when you pay people with very little knowledge large amounts of money to do something that requires expertise. I'm not sure why we're pussyfooting around that.
It would be like not knowing about loops or how to print text to the screen or how to do I/O. People seem to think you can be clueless and somehow still deserve a programmer's salary. The entitlement baffles me (and I've experienced a lot of it from people throughout my career).
A staff SWE who can't send you a patch is simply unworthy of their title, the way I'm unworthy of the title "pilot" or "doctor" or "attorney".
I wouldn't trust the world's leading neurosurgeon to perform surgery on my ankle. Nor would I want my patent attorney to represent me on a murder charge. I'm also not trusting the pilot for the Marine One helicopter to fly me anywhere on a Boeing 737 Max. "SWE" is simply too broad a term to encompass all of the deep knowledge someone should have at some point in their career. That us, unless we want to talk about licensing software developers with certifications, which is a whole other can of worms.
Maybe because they didn't use Git in their career or their role doesn't require to be hands-on.
In my company, we use mercurial so I can imagine that some SWEs aren't fluent in Git because they've used different tools. But apart from that, Git isn't rocket science. It takes a bit of practice like anything else but anybody should be able to know the basics in a few days, and become proficient after a few months of regular practice.
I don't think that regular usage of the Git CLI is sufficient to develop an insight into Git's internal data design for most people, which is really necessary for to become proficient enough to troubleshoot. You wind up thrashing a lot and then just giving up.
It's not quite what you're asking for, but Jujutsu+Git is still a much better dev experience than Git alone and is completely compatible with those sites.
I use Jujutsu for 100% of my version control at my day job, where all of our repos are in Bitbucket and all my coworkers are using Git. AFAIK most of my coworkers don't even know I'm doing anything different, other than those who I've "evangelized" so far :)
...I think my PRs have gotten noticeably cleaner and easier to review, though!
Lipstick on a pig, I'm sorry to say. Especially jujutsu which is literally just a wrapper for git.
These tools have better CLI for sure, and some nice added features too. VCS-integrated collaboration tools in fossil is nice. But my point was more along the lines of "why don't we have a radically different architecture that is better matched to the problem domain?"
We have database-backed storage backends for Jujutsu at Google. There's no Git involved there. So I think it's wrong to say that it's a wrapper for Git.
Even when using the Git backend, it's only commits and lower-level objects that are stored in the Git repo, and even some parts of the commits are stored outside Git (e g. the change ID). The operation log (which powers the undo feature) is also not stored in Git.
Git is the radically different architecture. Before it we had RCS, CVS, SVN, and a host of others that were simply striving to improve on the RCS model... a model that was simply unable to scale to large distributed projects with many collaborators.
Torvalds dreamed up Git in a weekend, and it's radically different from the patch-tree stuff that came before it. It's not taken over the world for no reason.
I lived through all that, I know. Torvalds didn't dream up git btw, it was a bad, but performant copy of monotone's DVCS UI/UX.
We can do better though. Patch theory shows that we shouldn't even need to care about commit history, for example. If we could just get off the tree-of-diffs model.
Version control that is simpler to reason about, and doesn't have such complex layers of tooling underneath is quite possible. It is network effects that keep us on git.
Git is extremely easy to reason about and requires the use of a very small number of commands. It would not have become the dominant VCS if that weren't true because nobody would have switched to it.
It became the dominant version control system because (1) Linux and (2) GitHub. There were better version control systems even at the time (and better ones still now).
I learned Git from an O'Reilly book and I loved that it started with the internals first.
The git CLI has some rough edges, but once you have concepts of work tree, index, commits and diffs down, it is extremely powerful. magit in Emacs is also incredible.
Ah yes, the hallmark of great software is having to learn how it's implemented to be able to use it.
None of the concepts behind git are difficult to grasp, the problem is interface and leaky abstractions all over.
Any person that mentions reflogs is actually saying I don't understand any of the points above.
> Ah yes, the hallmark of great software is having to learn how it's implemented to be able to use it.
Because learning how a software model a particular problem domain is a great step towards efficient use? You can hope it's magic, but that's a recipe for failure if you're a heavy user. Every professional learns the ins and outs of the tools he uses often.
> The problems with Git are many, though. Most of all, its infamously terrible command line interface results in a terrible user experience. In my experience, very few working developers have a good mental model for Git. Instead, they have a handful of commands they have learned over the years: enough to get by, and little more. The common rejoinder is that developers ought to learn how Git works internally — that everything will make more sense that way.
This is nonsense. Git’s internals are interesting on an implementation level, but frankly add up to an incoherent mess in terms of a user mental model. This is a classic mistake for software developers, and one I have fallen prey to myself any number of times. I do not blame the Git developers for it, exactly. No one should have to understand the internals of the system to use it well, though; that is a simple failure of software design. Moreover, even those internals do not particularly cohere. The index, the number of things labeled “-ish” in the glossary, the way that a “detached HEAD” interacts with branches, the distinction between tags and branches, the important distinctions between commits, refs, and objects… It is not that any one of those things is bad in isolation, but as a set they do not amount to a mental model I can describe charitably. Put in programming language terms: One of the reasons the “surface syntax” of Git is so hard is that its semantics are a bit confused, and that inevitably shows up in the interface to users.
I truly don't get it. All these supposed software engineers who can't seem to grasp the basics of the tools of the trade. It's like watching carpenters argue about a hammer every few weeks for ten plus years.
There's no excuse. Either learn git, or stop using it. If you can do neither, stop complaining, because plenty of people use it just fine.
And no, you really don't have to understand the internals to use git, but you DO need a mental model of what's happening: what a commit is, what a ref is, what a branch is, what merging/rebasing does, etc. These don't involve knowing the internals, but they do involve maybe reading the manual and actually THINKING about what is happening.
Too many developers confuse not wanting to think about something with that thing being difficult. I learned git one summer during a college internship 15 years ago, and I've been fine ever since. I am really, truly, not that smart, and if I can do it, so can you.
Everyone needs to just quit their bitching and actually learn something for once.
This quote from "PHP: a fractal of bad design" [0] seems applicable here:
> Do not tell me that it’s the developer’s responsibility to memorize a thousand strange exceptions and surprising behaviors. Yes, this is necessary in any system, because computers suck. That doesn’t mean there’s no upper limit for how much zaniness is acceptable in a system. PHP is nothing but exceptions, and it is not okay when wrestling the language takes more effort than actually writing your program. My tools should not create net positive work for me to do.
Yes totally agree. Curious if you think visual or gamified tools might have been useful to get an initial grasp on the types of concepts you mentioned? And if so where they might fit in?
There are so many abstract concepts that could easily be taught with a string of 2-3 Minigames that don't have to be harder than the average balloon pop game or a portal2 puzzle.
A while ago I played a little game that taught you vim commands and let you traverse an RPG style landscape doing it.
Putting content in the right order and hitting the right abstraction level.
Keeping the reader/user in the zone between being bored and overwhelmed while you teaching them, without knowing something about them (only data as feedback if they are using a tool that you built,rather than them raising eyebrows or nodding in a classroom).
I think it's hard but also fun. For the EV stuff that I look at there are a few problems compounding this:
I’ve seen so much content on the Internet dedicated to how hard Git is to understand the moment you get beyond basic functionality. Is Git the problem or is meant to be used only after months of training and practice? Seems silly to have any software take so long to learn and comprehend.
Training won't help: you need to be fighting wild git beasts almost daily, otherwise it all evaporates. Any modern dev work takes up 500% of your brain already. You pull, push, commit and stash all the time and it becomes second nature.
Then, suddenly: your stash pop has failed! Something has been left somewhere! You need to git add something! Output of git diff is empty! Why is it empty, did stash not apply at all? (you run git stash pop second time, and feel terror) It recomends you to run git restore --staged! Was restore not kinda reset that wipes your local changes? Stash was your safe space, the only git thing you felt sure about. You feel abandoned.
Next time, build script breaks only for you! No idea why! Turns out a day later the script cannot deal with worktrees you set up last year when you tried to "learn git"
Some time later lead emails about "scrubbing prod creds", "force pushing HEAD". You run attached commands with fear and awe.
Next month, you end up with a detached head! It sounds painful! Half stuff does not work!
Gradually you are being conditioned that git equals pain. Sure, other tools have it worse (hi ffmpeg!), but they don't spring it on you in a middle of a big change you are trying to keep in your head, only to be forced to take a sabbatical and learn seven circles of reset because a wild tag merge conflict has appeared, or your lead wants you to use rerere to rebase your branch after splitting one commit into three.
Hey, so, these are not problems unique to git, for what it's worth. And if people don't want to deal with problems, then maybe software development isn't for them, because this is like a plumber complaining about joining pipes. (And don't bother belaboring this analogy, because I will not respond.)
No, it's like plumber complaining about filling tax return forms. In the middle of joining pipes. (And I will bother belaboring your analogy. For the benefit of others reading it.)
As you say, it is not unique to git. Bug trackers, system updates etc. also can "disrupt flow" and take a lot of attention away from the main work. But git is unique in the insidious way that it springs such hard problems on unsuspecting developers that are busy *actually working*
Git is there for tracking changes. If you don't care about that, then there's nothing to be done. If you do care about it and it's important for your job, you learn the tool and use it. And git is a good tool.
Git is a good tool for tracking changes if your primary job is tracking changes. It is terrible tool if you care about tracking changes because you need your work done. There is no encapsulation and the cognitive load and amount of moving parts you need to keep track of mentally is hugely distracting.
It's just the realities of participating in a distributed system. There's no 'current state' or 'now'.
You could make the mental model easier to understand by centralising the state and switch to pessimistic locking instead of optimistic. But then you'd have to live with the downsides of those, like git's predecessors.
There's definitely a local "current state". Its just that there's no inherent concept of a central repository or source of truth.
In practice most people use it as if it does - the remote is "preferred". Which isn't such a bad thing if you know how to use branches and resolve conflicts properly.
Best practice is to create a new branch for each feature, then create a PR into the proper branch.
Early on in development it can be very chaotic as so much code is changing so quickly. No revision system is going make up for a lack of communication and division of responsibilities.
If you use something frequently you should know it in-depth. It applies to tools (git, VSCode), frameworks (Spring, Django, whatever), infra (kubernetes, docker). otherwise you're missing out.
Hard agree. I love this mindset! If you put a tool in your toolbag you should know how to use it.
Git is definitely abstract and hard to get the hang of but totally worth it - pays dividends in terms of the options it puts at your disposal. And the stimulating nature of learning how it works so that you can think for yourself to figure out a solution, instead of just memorizing 3 commands and running to AI for help when you get a little stuck.
Version control is one of our main tools for interacting with other developers. Having a rich understanding of your version control software often helps to find solutions and workarounds for problems which would otherwise result in needless conflict.
I would just add `git rebase -i` to the mix. Very useful to clean up a work branch before submitting it for others. Sometimes you just need a bunch of "wip" commits, e.g. testing CI scripts, deploying a optimization on the side for further testing, etc. and rebase is a must if you care about the commit log.
You forgot to include an explanation of what rebase does, which is important for knowing when to actually use it, instead of just specific goals you might have.
sure but is it enough to avoid using it though? I don't like to get screwed in business, but I don't avoid the screwdriver in my toolbox when I need one.
This was my approach for my first few years of git. I always tried to approach git via its commands, and I horribly failed - until I finally took a little bit of effort to understand how git actually works under the hood, which really made it click for me.
For anyone who has ever spent a modicum of time (e.g. while getting a CS degree) trying to understand datastructures, it's probably really straight-forward to "get git". The datastructure underneath is really quite simple. A branch is a pointer to a commit, a commit is a pointer to a tree, a tree is a list of pointers to other trees and files. That's already pretty much all there is to it.
Once the datastructure of git is understood, the commands start to "make sense" on their own - at least most of them. They still have tons of obscure options that one doesn't realistically need in a daily work flow, but the general idea what the commands do (and how to recover from screwups) was, at least for me, pretty simple after understanding the datastructure.
haha this is a bit of a sad take in my opinion, because of the value that I feel that comes with understanding how a tool like Git works behind the scenes, but seems to be several folks here who feel the same way you do
I feel the same way. All of git's weirdness seems totally reasonable once you understand it on its own terms. It doesn't even take a ton of understanding to get that that point either.
It's not a sad take. There are many roles in tech and I'd encourage those trying to make things to focus on that. You can get extremely far with 4 git commands. Even in a production team environment, you may only need to ever add in the merge workflow.
I agree with you. My typical workflow is: update master branch in Visual Studio, create a new branch off of the master, work on it, when ready use GitGUI to commit and push, then do a merge request in GitLab (we use GitLab). When approved, I push the branch to master. From time to time I need to update my branch, either because I make some code changes, or because my branch a few commits behind the master.
Would I like to know more about the underlying ideas of Git. Yes. But the time it would take me to do that is time I can spend on other things, like the stuff I am actually paid to do. If I become a git guru, I might get a pat on the back, but more likely no one would care. If I deliver more stuff, people who use my stuff actually appreciate it.
The reason it's sad to me is because there is so much more to explore, to be stimulated by, to be able to apply in a way that makes you think out of the box.
Maybe a lot of people don't care about that, and I guess everybody has their threshold, where as long as they know the minimum required to do their job they can stay in that comfort zone typing the same commands over and over.
The only winning move is to learn your tools and develop a mental model of what they're doing. You know, like everything else a programmer needs to know.
It's brilliant for it's original purpose of managing diffs in an open source project.
For industrial projects that are not organized like an open source project it's a massive, massive footgun and it saddens me it remains some sort of badge of honour to memorize it's incomprehensible UI.
It saddens me even more it's the goto vcs system even for industrial projects.
What would you suggest instead of git, if a hypothetical organization came and asked you which vcs to use other than git? Assume git interoperability is not necessary, to obviate the “we must be compatible with what our dependencies/upstreams use” argument.
My company uses Perforce, and while it's not perfect, it's more intuitive and has a comprehensive graphical user interface. Most importantly, once I learn how to do something with Perforce, I never forget it. That's not the case for me with git.
Single executable you just download and put in your path. Sane, well-documented interface (CLI, API and web). Full repo in a single SQLite file. Highly intelligent and efficient diff-based storage and compression (including network transfers). Rock-solid code. Easy exports to git/github.
I think it's kind of a tragedy the dev world got so stuck on git.
Maybe just my present frustration, but I spent the day revising the Aider AI editor's code because it barely even works without git. It relies on git just to list the files in a directory, and so turns off most of it's cool features if there's no repo in it.
I fixed it (PR coming) with some simple non-git directory traversal functions, which enables the cool features again.
But makes me wish the dev world knew git alternatives exist.
Heh. I care about results from my colleagues and collaborators, not their tool preferences. If your topic branches and commit messages make sense, that's what matters — because those are our touch points of collaboration.
Not to be annoying, but maybe one of the most useful things git does for me outside of the usual SCM stuff, is git-bisect. Its saved me many hours of debugging.
If you ever run into a case where something is broken (that you can measure, like a test or broken build) but it’s not obvious what change caused the fault, first go to a commit where you know the fault is present.
$ git bisect start
$ git bisect bad
Then go to a commit where you know the fault is NOT present. Go back far if you can! This can be in another branch as long as your start and end spots are connected somehow.
$ git checkout abc123
$ git bisect good
And after that bisect command, your HEAD will get moved to the mid point between the good and bad commits. Check if the fault is still there, and run either "git bisect good" or "git bisect bad" depending on if it’s resolved or not.
It will keep jumping you to the mid point between the nearest bad commit and good commit till you end up at 1 precise commit that caused your fault.
This works extremely well for configuration changes specifically, where maybe it doesn’t break in CI, but on your local dev machine it does. You can also use this for non-text files like images to find out when 1 part of an image was changed for example.
—
Also if you just want to make normal SCM stuff easier,
Thanks for sharing your workflow - nice and simple! And sounds like you've got a rhythm down with those core commands, which I know is the case for many Git users.
One of the things I'm trying to explore with these visual and gamified tools is how to help newer Git folks or even users who mostly live in that commit/push/pull flow get a clearer mental model of what's actually happening under the hood.
Git has a really wide breadth of functionality that is kind of interesting on its own merit, but also useful for a plethora of different tasks. For better or worse even Git experts can always find ways to expand their knowledge :)
I'm sorry, but it's been ten years and you haven't learned how to handle other git situation? And then you're dependent on Google? Is there a reason why you haven't sat down to learn some more?
Does anyone use Fossil source control? I've always been interested by it, but it just seems to stay under the radar. I'm curious if there's a functional reason for that, or if github just got to be good enough.
Been using it for years and absolutely love and highly recommend it.
Single executable you just download and put in your path. Sane, well-documented interface. Full repo in a single SQLite file. Highly intelligent and efficient diff-based storage and compression (including network transfers). Rock-solid code.
I think it's kind of a tragedy the dev world got so stuck on git. Maybe not too late!
Fossil is the SQLite one right? I would love to try alternatives SCM tools, but you run into the fact that associated tooling is so concentrated on git and its processes.
I was using bitbucket and mercurial for a while! If fossil had something similar (which off the top of my head, I think they do? Something wiki-like for the SQLite project) I would be willing to mess around with it on a small team or something.
I wonder if the author of this considered using luanti (formerly minetest) as the engine, would have maybe saved some work? https://content.luanti.org/
But perhaps they'd a good reason to go the route they did. Very interesting concept, anyway.
Hey there! Never heard of Luanti, but the reasons I chose to make this in Pygame using this particular open-source voxel engine implementation are outlined in the post :D
I’ve been programming by professionally for about ~5years and using git for version control that entire time.
When I deliberately spent time to learn the foundations of it, it blew my mind how incredibly sophisticated it is and how intuitive it becomes once you understand the core ideas behind it
Highly encourage reading through the official documentation and Julia Evans blog posts on git.
Kinda! But really only in the sense that they're both "games" related to Git.
Devlands can do so much more (it's can simulate, run, and visualize any command or scenario that can happen in Git within the context of any local repo) and in a much more intuitive way.
I find that the command "git add -p", which allows you to add individual sections of files rather than whole files before committing, helps with this issue.
It's quite natural to wind up with a bunch of work that really needs to be in multiple commits. I don't think this ever changes for most of us.
That’s basically what I do, I just end up doing it in large spurts. I typically use the cli for most things but I like the GitHub app for picking out changes for a particular commit.
Git is not good, but I'm yet to see anything that's a clear improvement without sacrificing on the core capabilities. Do you have any recommendations that you like?
Modern Mercurial with evolution is extremely pleasant, and the more I use it the more I abhor git whenever I have to go back to it. That plus Heptapod (fork of GitLab with Mercurial support) — it’s very nice indeed. I count myself lucky to mainly contribute to a project where we use all of this.
It’s a shame there’s still nothing quite like GitHub for Mercurial (anymore), where anyone can just sign up and create repositories. Heptapod has a public instance for FOSS, but it requires approval to create projects. There’s also a separate hosted instance for basically anything, but it’s commercial and costs money. One can also self-host, but GitLab is not exactly lightweight, and other solutions aren’t as integrated with evolution features.
why? I had to stop using it because no one else would, and the various centralized services dropped support for it. but it handled branching and merging much better, was easier to pick up, and was less likely to trash your local checkout.
maybe if someone rewrote it in rust it would be sexy again? rurcurial?
OK, it's not a Mercurial clone, but it did take some features from it, and using it will feel more like Mercurial than git. And you can use it on git repositories, so you can have your cake and eat it too.
I think the loss of the google and bitbucket repositories was the main problem - i know that took the heart out of me for doing foss development. i can deal with git (shit, i can deal with rcs), but i don't like it.
https://learngitbranching.js.org/ is very good for learning how Git branching works.
Once you're done with the tutorial bit, the https://learngitbranching.js.org/?NODEMO version is good to try out commands and see what the tree looks like after each command.
The problem is that source control is optimally a visual activity: the source control tree is a diagram, and the operations one does to it are diagrammatic.
Text-command-first approaches lead to inferior and hard to understand APIs which are, at best, papered over with a GUI. Managing the source of the project should be a series of trivial visual operations.
Amen. The ever-present insistence that the command line is the only way to use git is the modern version of "ed is the standard text editor"[1]
https://www.gnu.org/fun/jokes/ed-msg.html
Bothers me a lot that you're getting downvoted. Bunch of elitists who insist that cmdline is only way to get things done (everyone has to study cmdline options because who could possibly have multiple 4k screens for some visual options dialog?), probably using GDB in 2025 and having massive Stockholm syndrome about it, ...
I'm one of those folks who will tell people to give the official CLI frontend of git a chance and to try and stick to it. I can assure you it is not out of elitism, but experience. I've tried the many third party GUI frontends, and always got myself into bigger trouble down the line in the end, nor did they bring any of the revelatory boosts in insight they claimed they would. And of course, they're all a little different from one another, so migrating between them is an additional chore.
Then of course it's possible I didn't give the many GUI frontends enough of a chance. Such is life, it's a resource limited game. Principally, I justify my position with the argument that the many GUIs will try to translate git into something visual by adding their own designs, and this can prove additionally misleading and difficult, if git wasn't rough enough already.
The only GUI bits I use for git are editor integrations such as the official one in VS Code, and only when I know it's adequate. Which you can only know if you know what's going on in the background.
GUI is absolutely easier for merge conflicts. I use the one that comes on jetbrain ides which is awesome.
This isn't even opinion. It's fact. Anyone who has experience regularly(keyword) using both CLI and GUI for merge conflicts will side with me on this by an overwhelming majority such that I might as well call this fact.
But solving merge conflicts is fundamentally an editing task, not source control.
Yeah this is true. It’s similar enough such that most gui version control interfaces include an interface to deal with this.
Your editor should be able to handle this (via git mergetool).
The community seems to disagree so far. I'll take a look at how it works tomorrow though. For me most of the misery around merge conflict resolution stems from how git fundamentally works, so I'm not sure how much it can possibly improve on it.
The only people who disagree are people who don't have regular experience from both sides.
Graphical diffs that automatically handle merge conflicts visually with clicks to insert, undo and the ability for custom modification are MUCH MUCH more convenient with a GUI. Highly recommend the jetbrains conflict resolver gui.
I can assure you ANYONE who regularly has experience with both the CLI and that GUI(jetbrains) will hands down say the GUI is superior for merge conflicts. It is NOT intrinsic to the nature of merge conflicts. Any disagreement in this area stems from lack of experience or knowledge.
If anyone has experience with both and they have a contrary opinion, feel free to tell me. I doubt such a person exists though.
I find ediff from Emacs to be superior to the JetBrains conflict resolution view. And I've had to deal with some gnarly (and large) merges at $JOB.
I dunno, something about its keyboard-driven design (and in general being Emacs-based) makes it clearer in usage than the JetBrains offering. Although this is probably what one is used to.
Of course, the really important thing is that people set merge.conflictStyle = zdiff3. Maybe a bit opinionated, but it really makes proper merging a lot easier.
Ediff is still a GUI (yes, even if you're running emacs -nw).
I also thing Ediff has some very annoying behaviors - the fact that it doesn't use intuitive names for the two buffers (especially because of Git's annoying nomenclature when rebasing vs merging), and the fact that there's no shortcut for inserting both the A and the B changes into the destination, which is a common operation.
I haven't really used the JetBrains merge UI, so I don't know if it's better or worse, but I don't think it's very hard to improve over ediff.
if I understand correctly ediff isn't cli, it is a gui built into emacs, only implemented unsing characters?
I can second this—the JetBrains merge conflicts ui is the best I’ve ever seen.
For some reason there are a lot of subpar uis though. E.g. not showing three versions, only showing THEIRS and not the remote branch name, etc.
I've seen another gui waaay back before git was popular. Perforce actually handled merge conflicts with a GUI just as good. I think it's still just as good, though almost no one uses it.
I still use it. Even have it set up with Jujutsu. Only complaint is that you have to explicitly exit the app after each use.
It's still free, too.
> Graphical diffs that automatically handle merge conflicts visually with clicks to insert, undo and the ability for custom modification are MUCH MUCH more convenient with a GUI
Not saying you are wrong, I used to only use VSC Gui for merge conflicts. Then at some point learned to edit myself and just use the CLI. After many many years I tried lazygit (TUI) for merge conflicts while still being in the terminal and I don’t think I can go back to do it manually anymore.
My point is, is this TUI considered graphical?
Same concept. The TUI is attempting to imitate what GUI does with pixels as primitives but with terminal character primitives.
>This isn't even opinion. It's fact.
I honestly don't mean to insult you but when you say things like this in a discussion where others obviously disagree with you, it makes you seem like either an overly enthusiastic beginner that hasn't learnt about tradeoffs yet, or a very stupid fanatic. You might be neither, but that is how it comes across.
>Anyone who has experience regularly(keyword) using both CLI and GUI for merge conflicts will side with me on this
I and many others simply disagree with you. I have used those tools. They work okay in simple cases but break down in more complex ones. That is my opinion.
You seem like a stupid idiot too. I don’t mean to insult you either, honest this is just how you come across to me as well.
I would say very very few people would disagree with me. I would even argue that your experience is in fact limited. You probably worked with a trashy gui and likely didn’t use it too much.
I regularly use jetbrains to merge the most massive conflicts. There is no use case that is too complex for it to handle. The fact that you even said these guis can’t handle complex use cases indicates an extreme lack of experience in this area.
I am sure you indeed do successfully use JetBrains to merge "the most massive conflicts". Good on you. I'm glad it works for you.
The mere fact you've even typed out the words "Anyone who has experience regularly(keyword) using both CLI and GUI for merge conflicts will side with me on this" makes you look like a child. This is how children speak.
>You probably worked with a trashy gui and likely didn’t use it too much.
You don't seem to be able to encounter someone that disagrees with you without immediately assuming they must be doing something wrong, lack experience, or be stupid.
Again, how hard is it to accept that people have different preferences? You are like those people on forums in the 2000s that argued that anyone that liked Ruby/Python was an idiot and obviously Python/Ruby was the far superior language. Anyone that disagreed obviously had never used Python/Ruby properly, and was obviously just a fanatic. I thought we moved past that stupid shit years ago.
> You don't seem to be able to encounter someone that disagrees with you without immediately assuming they must be doing something wrong, lack experience, or be stupid.
Yes. Not stupid though. More lack of experience. That’s my opinion about it and in my opinion the gui is better and that is a fact.
What I don’t understand is why my opinion about something as a fact no matter how extreme leads to you openly calling me a stupid fanatic and calling me a child?
I said you come off as stupider earlier but not to be insulting but I also said it to sort of illustrate what happens when you call someone stupid and then say the words I don’t mean to be insulting as if that negates what is in actuality an insult. It doesn’t and now you’ve openly called me a child. This ends here. Good day.
Your opinion is not fact.
Prove it’s an opinion with your own anecdotal experience.
I would say that my opinion is shared by the overwhelming majority in such an overwhelming way that it’s indistinguishable from fact.
Anecdata don't make facts
It’s better than nothing. If he has something better than nothing he’d present it. I doubt he does though.
This is basically my workflow too. I use git from the command line until I need to resolve a merge conflict, then I hop into vscode to resolve the conflicting file.
I don't consider myself a very core or talented developer, but I do feel quite strongly that git from the cmd line is much easier than a GUI, but overall ridiculously hard regardless. The abstractions and visualizations in graphical interfaces is either too dense & complicated, or more likely hides what's actually happening; there's no way to reduce the inherient complexity.
My take: don't play the game. learn your basic required workflow from the command line and use the decent documentation to look up everything else.
NB. I did explicitly say a GUI on top of a cli app is a broken approach. Your intuition comes from this -- that the git API is cli-first.
Source control should be designed graphically first, with a cli to automate. I routinely use tree-view and column view in macos finder to think-through fs organisation -- doing this as a sequence of cli commands would be masochistic.
Notice how all the best vcs tutorials are just providing basic visuals which would be better as the interface.
The thing that CLI have over GUI is programmability, which for programmers is a valuable property. As for me, any repeatable task, I automate away with various degree of effort and quality. If I find myself needing a particular set of commands and flag, I create an alias, a function, or a shell script for that, like `flac2mp3.sh` instead of hunting down through the shell history.
For most vcs tutorial, they don't often use why the history of changes is important, instead focusing on a set of usual commands. Why, not how. Once you have that philosophy down, the tool usage become much more efficient.
I've been using magit for almost a decade now and it directly contradicts what you're saying simply by existing and being as awesome as it is
I thought I would be just fine with the CLI but I was amazed by magit. A GUI can work well if it leans into the strengths of GUIs - discoverability of features and showing state. Magit does all of these exceptionally well. It helps that git's CLI is quite poorly designed with a lot of unintuitively named commands. How do you undo a commit? How to unstage a file? What's a stash? What's the difference between log and reflog?
With magit I've been able to do things I wouldn't bother before, like reverting small parts of hunks from past commits, doing partial staging of files (not including all changes), and dealing with stashes effectively.
I work in a lot of repos at once. I do a lot of global search-and-replacing and random debugging. With SourceTree, I can easily see all the changes I've made across all repos in one glance.
I can then drill down to each file with the visual diff and see whether the changes are something I want to check in, or just debugging. If it's debugging code, I can click "Discard Changes" to drop all changes I've made to that file. Or I can selectively discard a hunk or discard lines.
When I show these features to command line purists, they always concede that this can't easily be done with the command line. So I don't see what's to gain if I'm losing those features, which I rely on constantly.
I've been working in SourceTree for a decade, so I know all the quirks by now, which I pass on to any new devs who want to use it.
> can't easily be done with the command line.
Learning the -p was the biggest gain I’ve had after years of using git via cmdline only.
Which is kind of the point. If a GUI editor does this stuff for you, that seems like a win over incrementally learning these little command line tricks that save you a bunch of time.
That’s fine for some and I have no problems with it but my mind doesn’t work that way and instead it asked “how is possible the UI is doing this”. All of that lead to learning what hunks are and manually editing them to learn.
You can do it with stash too!
How does this scan a bunch of repos at once and let me see all the changes at a glance, and then drill down to individual files to either discard the changes (revert back to their committed state) or check them in?
All git add -p does is that last part from what I can tell. I'd still have to cd into each repo and run git status one by one (I've made changes to up to 10 repos before for one tweak), and then do a git add -p to the changes I do want, and a git stash to the changes I don't and then delete the stash.
If "cd" and "git status" in a bash for loop is too advanced, you might need a GUI. Though I'd also argue that you've got too many separate git repos if you're finding yourself needing to do that often. It all depends on where you are on the journey to Monorepoland.
We're too small to implement a monorepo, because no one has time to build the tools we'd need to do it right. I still don't see what I gain by cd-ing into all those directories and running git status and looking at a bunch of text results, when I can just glance at the SourceTree repo window and see all the repos I've touched.
I'm just saying it might be a skill issue rather than a tool issue.
You're not offering any benefit that I'd get from using the command line over my current process, except, apparently, being able to express your superiority over GUI users.
I would argue that "git add -p" is the one thing which is unambiguously better with a GUI.
Scrolling through changes and staging lines is just much nicer with a mouse.
I semi-agree - the real win is in unstaging changes you didn't mean to stage! Much easier in a GUI, because I don't have to remember the non-symmetric CLI command.
There's a really good argument to use plaintext - it lends itself to very efficient use through searching, matching and replacing, whether interactively or in bulk. The lack of structure and semantics in a pure plaintext representation is often a curse, but sometimes a blessing.
At the same time, I'll go further than you, GP and GGP - I'd say that insisting on coding in plaintext, specifically on always directly reading and editing the same plaintext, single-source-of-truth representation of a program, is fundamentally limiting our ability to manage complexity, and makes people waste a lot of time on faux-problems like "lots of small vs. few big functions", or "exceptions vs. result types", etc.
FWIW, plaintext is still okay for most coding use cases - it's trying to fit everything into the same source code and somehow keep it readable that's an impossibility.
GUI's are bad for expressing tasks beyond some level of complexity.
It bothers me a lot that you're complaining about downvotes when the comment you are replying to isn't even greyed out let alone flagged dead.
It bothers me a lot that you can't discuss something like this without turning it into personal attacks. People can't just have different preferences than you. No it has to be "elitists" with "stockholm syndrome". This kind of rhetoric is unbecoming of this forum and destroys amicable discussion.
Have you considered that maybe people use the command line because it is better for them, and they recommend it to others because in their view, you'll need it eventually so why not learn now?
You can visualise a git history with a gui tool while still learning the command line interface btw. They aren't mutually exclusive. Do you just use scratch too? Or are you one of those elitists using textual programming languages? Must be stockholm syndrome...
I learned the git CLI first, and still prefer it, but I've found VSCode's source control plugin very helpful for teaching newbies. I tell them to avoid the synch button and just manually git fetch/pull, but adding a commit is easier for a newbie to do visually.
I also found LazyGit recently and think that's a good middleground for doing things from the CLI.
Emacs' magit is great too.
If someone doesn’t use the CLI, they are a newbie? I’ve never needed to learn or use the CLI, the GitHub tools built into JetBrains IDEs and VS Code have always worked fine for me, and I’ve been a professional developer for nearly 30 years.
I think the idea is that the people you'd teach version control to are typically the newbies. You can also just be new to git specifically or the git workflow on any given project.
No, they said that for a git newbie, a gui will be easier.
Chacon & Straub’s Pro Git, available for free online [1], is an excellent resource and has a lot of visual diagrams.
[1] https://git-scm.com/book/en/v2
I love this book. It's what helped me move from an intermediate Git user to an advanced one, and I've subsequently trained a bunch of people at different organizations by going through it.
However, Pro Git is not an ideal resource for newbies unless they are highly motivated or receiving generous training. A simple graphical representation of your own repo goes a long way towards establishing a mental model of what Git is doing internally — which is in my view the chief insight of mjburgess's post at the top of this thread.
You’re probably right about that. I used a certain interactive online course when I was a beginner, but they’ve added “AI assistance for guided coding help”, so I hesitate to recommend it.
FWIW, the Git website links to some videos and external tutorials, which might be of use: https://git-scm.com/doc
Does not still fix the root cause that Git is super-bad as an industrial tool - actions that should be trivial push-button activities become incomprehensible command line character soup.
The fact there is a book on the subject speaks volumes about how bad it is.
If the existence of a book speaks volumes about how bad something is or is not, I have some bad news for you about what's inside libraries. What beloved subject doesn't have a plethora of books written about it?
Exactly. VCS is part of an industrial process. It's not supposed to be implemented with a thin wrapper to a database whose node structure you need to rummage through.
The software analogue would be that in order to use the platform default List and Dictionary data structures you would need to manually manage the links between the data nodes.
Or to use text editor you would occasionally tweak the rope datastructure or equivalent. Etc.
Like what?
VCS should be trivial push-button activity (and _is_ except with Git). There is no added value making a thing far less usable than could be. This is not git’s fault - it is what it is. But it is incomprehensible industry selected it as it’s de facto vcs.
Give an example of an "action that should be a trivial push-button activity" that requires "incomprehensible command line character soup".
All of them. A command line should not be the default option.
Again, this is not to bash Git. It's a bash on the industry for selecting tool that requires engineers to spend time and effort on non-value adding part of their work rather than offering a solution so simple you would most of the time not even think about it.
I use this whenever I need to look up anything outside of our workflow, but don't believe internalizing the myriad of git details has a very high pay-off. There's probably higher value knowledge in your role that you should prioritize.
The payoff comes when you develop a mental model of Git's data structure design, which is stuff like "a branch is a named pointer to a commit" and "the central data structure is a content-addressable store" — and most germane to this thread, "the source control tree is a diagram, and the operations one does to it are diagrammatic". (Thanks mjburgess!)
Learning Git's infinity CLI options won't teach you that.
500 pages (excuse me, 501) to document a source control tool.
Something went very wrong here early on. But, lacking a time machine and a handgun, it's clearly unfixable.
The first 6-7 chapters should teach you more than most Git users know (myself included, suppose I might be due a re-read!).
Which you can read easily in a week or two without much effort for something that is currently de facto for software development. The Emacs Manual has ~700 pages.
This seems wildly optimistic.
Also agree.
Relied on gitk heavily when first started using git. People used to SVN and such will find git unfamiliar and scary.
Once I understood it as a series of revisions where even branches have little meaning, I never used gitk again…
The command line is actually very good if one gets in the habit of using something like “git log -oneline —reverse —no-merges origin/main..HEAD” to see where they are.
Mine is basically: git log --oneline --graph --all master~1..
A combination of "--all" and "branchname.." shows all descendant commits, and "--graph" shows their relationships visually.
The following command provides a visualization which is good enough to start from:
The more practical problem is that Github, which provides a useful graphic UI to complement the local command line for any project hosted there, is brain dead[1] about showing the source control tree as a tree and doesn't expose anything like `--graph`.If you get tired of typing `git log --oneline --graph`, you can add a `git slog` alias[2] for it by adding the following in `~/.gitconfig`:
[1] Gitlab is superior in this aspect, as it actually exposes a graph mode, via "[repo] > Code > Repository Graph".[2] Or if you want to get fancy: https://github.com/rectang/dotfiles/blob/064b22c42846f8a3f18...
`git log --graph` is just a really really bad GUI. Why not use a good GUI instead?
Although in fairness it's quite hard to find a good Git GUI because there are so many bad ones. The only good ones I've found all have some kind of flaw:
* GitX - the clearest design IMO, but it's one of those "gazillion forks" bits of software like TomatoUSB, and Mac only. Plus it has some annoying bugs.
* Git Extensions - I didn't even realise this was a Git GUI until relatively recently because it its terrible name. It's pretty decent, but Windows only.
* VSCode 'Git Graph' extension - my current favourite - it integrates into VSCode too which is much better than a standalone app, especially when using Remote SSH. However it is abandonware and although the source is available, the license doesn't let you republish it so it's not "open source" and nobody can take it over.
Disappointingly even these don't let you do things that a GUI obviously should let you do, like copy & pasting commits, dragging and dropping to rebase.
Like instead of `git rebase -i` and tedious text edits, why can't I just ctrl-select some commits, ctrl-C and ctrl-V?
But, they're still miles better than `git log --graph`.
It may serve a different purpose, but I personally use https://zolk3ri.name/cgit/ggrp/about/ for displaying commits, because it categorizes commits based on prefixes such as "feat:", "fix:" and so forth, and supports scopes too (e.g. "feat(foo)"), and a lot of my projects have commits with such prefixes.
`git log --graph` without `--oneline` is pretty hard to follow — that's not what I use, and it's not what I suggested.
With `--oneline`, it's not perfect but it's good enough to be useful — and by working within the constraints of the CLI, I didn't have to tell people to install software to get my point across.
And I already spoke approvingly of Gitlab's GUI for graph representation! I don't disapprove of GUIs; I use them all the time (particularly Github's). One you grok the data structures that underlie Git, you wind up seeing front ends as interchangeable.
I meant any variation of `git log --graph`.
Compare the graphs that people draw to explain git branching. They are usually very beautiful. Then you see the graph even these GUIs make, and they are still pretty bad. I think the visual graphs could be improved quite a lot.
> Like instead of `git rebase -i` and tedious text edits, why can't I just ctrl-select some commits, ctrl-C and ctrl-V?
git obeys $EDITOR, so you can get that like this with whatever text editor you want:
No, I mean why can't you select commits in the graph and copy/paste them. I wasn't talking about copy/pasting the lines of text in the `git rebase -i` file.
I use Git Extensions since 2012 or something?
I basically never used Git command line unless fixing some problems other people created.
It is just insanity when people claim "only proper way is to use command line" - well yeah it is much faster if you work on your branch and just need to make quick series of commits. But as soon as you have to deal with collaboration with other people and organize project, coordinate features etc. I find GUI invaluable and Git Extensions of course.
> Like instead of `git rebase -i` and tedious text edits, why can't I just ctrl-select some commits, ctrl-C and ctrl-V?
You can do this with lazygit.
That's really it. Could I use the CLI? Sure. Do I? Nope. Using a tool like Git Extensions makes it so much easier to visualize what's going on. I have enough on my mind, I don't need to make the branch/merge/commit process harder than it is.
I'm shocked nobody has a made a visual GUI to abstract git's weird API. There's sourceTree and whatnot, but it's so bad. So, so bad.
Try Fork, it's still obviously git, but it's the easiest I've found so far: https://git-fork.com/
TortoiseGit?
There are hundreds of them (everyone has an opinion about which is best). And most of them go out of their way to hide the nonsense that they have to jump through to get git to behave as the GUI expects it. Some of the visual git GUI tools do show you the gobbley-gook that they emit to the git CLI and it's shocking, like watching how the sausage is made.
This is why I've always liked gitk for anything non-trivial.
You may also consider using the Jujutsu VCS[0] as effectively a nicer and saner git frontend.
I’ve written an intro to it a couple weeks back[1] - I’ve been using it since, and so far haven’t had the need to switch back to git at any point.
[0]: https://jj-vcs.github.io/jj/latest/
[1]: https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs...
This one is probably the best intro I've read: https://v5.chriskrycho.com/essays/jj-init/
Really, really good examples and walkthroughs with easy to understand, animated console sessions that show real-world-ish use cases including conflict resolution and why JJ's model makes it easier.
Really good read and easy to digest because of the animated session replays.
My main takeaway is that the missing pieces right now are IDE support for a world filled with detached heads and a foolproof upstream integration pattern on `push` (requires a bit of manual work to designate the target branch).
I am 100% going to link to the original post and these replies next time there’s a jj thread and people express bewilderment about needing anything else because “git is so simple”.
I don't really understand struggles with git. I learned ~10 commands 15 years ago which have worked fine for me. I don't think I deeply understand git internals but it does what I need so not compelled to dig deeper.
I actually think git is a bad example of "just memorise these commands" - unless you are working with projects with a small number of users / branches - or you're fine to just delete and reclone if things get really hairy. I think a lot of my struggles with git came down to not grokking what it was actually DOING at first. Examples:
- not understanding branch pointers / staging / committing corrently. E.g. [add file] [modify file again] [commit] - what just happened? (IMO these things could have been named better). Also reset vs revert vs restore - easier to use these if you've internalised branch pointers etc
- git pull fails because it says it would overwrite a file you've never heard of - how is that file on your local? Is it ok to delete it?
- times when you (or your colleagues) need to rewrite history (rebase / squashing etc) - require a pretty good mental model of what is going on to both diagnose issues and to fix them
The thing is, for me, I have never really struggled with anything. I work on a large project and use rebase, force push, amend and cherry-pick sometimes. I am fully confident that I can get myself out of any bind that myself or others have created just using my ~10 commands and without deep understanding of git internals.
I agree with rebase on shared branches however, that requires coordination and understanding of everyone using the branch. Sometimes, long running shared branches are needed but it generally something to try to avoid.
If you work at a place that doesn't care about a curated history, which I always have, it becomes much simpler.
It’s more accurate too. Linear rebased histories aren’t representative of what occurred.
I think much of the confusion comes from git log which is a lie. People want git log to be an accurate representation of what occurred.
A curated sequence of logical commits assembled into an idealized history is often much easier to review than the real history. However, to rewrite history well enough for that you need....
* a solid understanding of interactive rebasing, including `fixup` and `reword`.
* `git add -p` for adding partial sections of files
* `git commit --amend` for patching the last commit
* `git commit --fixup [COMMIT_ID]` for attaching patches to commits further back in history.
* `git stash` for pausing progress while you fix up an old commit.
* `git rebase -i --autosquash [COMMIT_ID]~` to apply the fixups
* topic branches that never get too big or drift too far from the mainline, because rebasing often becomes infeasible when repo snapshots are too far apart.
* A low enough error rate that you don't screw everything up when rewriting history (which is a reasonable critique and argument for why you shouldn't attempt this in the first place).
I can usually manage this, and efficiently enough that it's worthwhile — and my colleagues appreciate that my PRs are easy to follow. But as a reviewer, I don't insist on other people putting in the same investment.
It depends a lot on what you are doing. If making incremental changes to a production system, just try to use trunk based development style (except use pull requests - let's not be insane) along with targeted commits.
If you need to do exploratory work and need to share that with someone else, yeah, you will have lots of noise in these commits. Yes, maybe some of those commits wont even build depending on how long your build takes. One approach is to do a "clean room" style re-write with better quality commits (ideal) or likely some rebasing and cherry-picking might be needed - both of which are better than merging all of the noise to the repo.
Taken to the extreme, one could consider every character typed to be what "really happened" but of course no one wants that.
I've worked in more than one place where a 'clean history' was deemed so valuable that someone and re-applied all the deltas after the fact to create some kind of alternative timeline where everything landed just so, and we all had to eat the resulting force pushes to main
clean history and forced pushes to main are orthogonal. why were dirty commits making it to main the first place?
Single squashed commits with a linear history.
This scales for monorepos with thousands of engineers, too.
Every explanation of git I have seen starts by explaining that git is cool because branches are just pointers and then talks about the index/staging area. If you don't understand that then you aren't going to be writing code worth committing anyway, are you? A software developer that doesn't understand reference semantics?
> Every explanation of git I have seen starts by explaining that git is cool because branches are just pointers and then talks about the index/staging area.
Which is precisely _not_ a "just memorise these commands" approach to git right?
Also re: your general snark - try a bit more empathy? I'm sure you are an experienced dev but we are talking about people LEARNING git, they don't have the same points of reference as you do today.
I learnt git too. I was new to it too. It used whatever the information is that is on the official git website and had no problems. And that was back when its interface had quite a few rough edges that have been sanded down
Today there is "git switch" which people say is good for beginners. I have too much git checkout muscle memory.
[dead]
This is like saying "I've lived in a house for 15 years and I've never had a problem. I don't understand how people could have a problem living in a house." The thing is, living in a house isn't a very specific experience. The difficulty of the problems you might face varies a lot by many factors.
If I run into a problem I would research it, what is so bad about that? Even if I studied git source code in detail 15 years ago I would have forgotten it by now.
Do you know how to build a working computer from individual transistors or understand the physics behind it (I happen to know these things personally)? If not, better crack open your modern physics text and study particle in a box, along with the requisite differential equations, calculous and linear algebra just in case you might run into a problem one day.
It's hard not to get stuck at some point if you don't have some understanding of the internals.
If I was a beginner, I'll try to get some proficiency early on rather than having to learn the hard way when you're on the middle of a project. It's a good investment.
I've also found that learning crafting nice commits made me a better programmer. It seemed difficult at first but now it's second nature (and I assume that in most teams, one is expected to submit small and self-contained commits anyway).
Never gotten stuck in the more than 15 years (cvs etc before it) of using it; never needed a gui and hardly needed to look up anything (but we can do what's the issue with that?); work(ed) on massive projects. It's just not that hard.
That is my main point, I have never gotten stuck despite not deeply understanding the internals. Instead I built a solid mental model just from the behavior of the commands.
This is a point that is not made enough. Git can be overly complicated if you want it to be. But 99% of your work is add, committing, branching and resetting. If you can do that you can probably never need much more.
I will say though that I get really nervous reverting sometimes, making sure I’m using the right command to reset etc can be confusing.
This. Maybe even more than 99% of the time you are fine. It's okay to struggle a day with a rare problem every now and then. Just don't be scared of it. There are enough resources out there to research them when you need them.
Where I still get nervous is when I force push my branch after a rebase, even if I know I am the only one working on it. But this is also one of these examples. If I remember correctly, there are other options to sync your remote after you did a rebase, but force push is just the easiest. So I rather take 5 seconds to make sure I typed exactly what I wanted and that everything is fine and that just works.
Edit: I was just brainstorming a bit about it and thought that probably some of the unknown magic git features were just implemented by a motivated dev that just wanted to explore what's possible. But on the other hand, there are most likely some very very obscure configurations and edge cases in the wild where people actually need those features. But most people will likely never need them, so I myself won't bother understanding "everything"
Agree. It only makes sense to be scared of it if direct pushes to master are allowed - that would be crazy. This + avoid long running branches and there isn't much to fear.
[flagged]
>Where I still get nervous is when I force push my branch after a rebase, even if I know I am the only one working on it.
It sounds like you recognise that this is an irrational fear but in case you don't: this is an irrational fear.
I agree that it won't cause collaboration issues. Perhaps the fear arises because force pushing destroys your backup, so to speak?
I freed myself from the fear of losing data after a rebase when I learned to restore from a commit in `git reflog`. So long as your work made it into an actual commit at some point, everything is recoverable from the local repo's history[1].
[1] Ignoring giganto repos that actually trigger garbage collection.
you could do git checkout -b backup-of-branch-foo and push that, before force pushing branch-foo, for the paranoid
Git init is all I need. The rest is just from gui
I was an English major and generally do not have the gift that makes programming come naturally. What skills I have, including passing Git proficiency, are the result of brute force learning, plus years of mistakes.
So I naturally assumed I could teach a team of non-engineers enough Git to enable them to interact with and contribute to text-only repositories as their job required.
I was quite wrong. Git flummoxes some people, and even the best visual tutorials (the ones that helped me immensely), leave some more confused than when they started.
YMMV but explaining simple Git concepts over and over in the face of incomprehension made me a bit of a dick too.
Teach jj (jujutsu) instead.
The idiocy that is "staging" is the primary problem with Git. 99% of people do not need "staging" and yet Git inflicts it on everybody.
"Staging" (and "stash") makes Git modal, and that's a pain in the ass.
Having taught people both Mercurial and Git, I can tell you that teaching Git is simply a losing battle. Fortunately, jj operates just like Mercurial but can coexist in the Github ecosystem.
What is wrong with staging? I don't even consider staging until it is time to commit, at which point it is a little area to gather the exact changes you need.
[flagged]
I'm actually surprised how many Software Engineers/Developers don't know how to use Git... I was once showing a Staff SWE on how to setup VScode + Python. I see kinda why when you're programming in vim + C(++) your whole career. But when I told him to push his changes to a temp branch or give me a git diff so I can try his changes myself, he had zero clue what I was talking about. His local `main` was over 2 months old. We had to prune and pull to get it back to match remote.
A funner part of the story, I was showing him how to setup VScode because programming using VScode...through RDP. That's right, he was programming remotely on the remote machine using RDP with VScode on the remote screen.
I've known quite a few software engineers who just don't bother to learn anything about the tooling they use to create and deploy code. For younger, new developers, I can understand it when everything is presented as an app with minimal customization, but for mid-levels and senior engineers I am baffled by the lack of curiosity.
Sometimes just a couple of simple howto sessions can be incredibly useful, especially for teams just starting on a new project. I've given tutorials on Git basics, command line basics, workflow basics, and AWS terminology. Each time I've had engineers say it was like learning computing for the first time, because apparently newer engineers just don't get taught this stuff.
This is partly why I enjoy improving the developer "experience" (DevEx) alongside my normal DevOps duties.
So on the other side of this, I’ve also seen senior+ folk working on projects alone, with no collaboration at all, but still use a GitHub-esque PR/git-flow process. Almost feels like a professionalism-espousing self-flagellation.
Create a PR, self-approve the PR, then merge it to a develop branch. Then merge the develop branch into main. Then in main make a release branch, and tag it.
I sometimes do something similar, as it gives a chance for the CI to run more comprehensive tests on other platforms that's hooked up to the PR flow, and "reviewing" your own code can be pretty helpful.
You could easily have your CI keyed on tags or commits, reviewing my own code is very helpful but also so wasteful of time.
Depends how much CD you have.
I can see doing this, stepping away from the change for a bit, come back and read the PR from a fresh perspective and see if you can make sense of the change and if there are any errors.
Also, the “paper trail” of PRs is nice to have.
I don't use pull requests because it seems higher ROI to just put that effort into crafting a good merge commit message.
Aside from that, you've more or less described my workflow for solo projects.
It's a mindset thing for some people I think, they have a "flow" and just continue using it. I sort of see it, but it's a time sink.
Personally if I'm working by myself absolutely not, commit straight to main or a feature branch, life is way too short.
I'm guilty of this. I open PRs on my personal projects and then merge them in myself. Not for every commit of course, but for the big changes.
I just like to see the diffs on the github UI. <shrug>
Yes. Because writing code is so easy a bot can do it these days. sets the everything else that goes into writing code that wants to be captured, so following process is about how much you love future you, who has to come in three/five/ten/twenty years from now and figure out wtf you were thinking when you wrote this. Did I mean to use > instead of >= or was I just careless?
That's such a relatable story - and I feel like it highlights something I've been thinking about a lot while working on these visual and gamified Git tools.
There's this whole class of capable engineers (some at senior/staff levels!) who just never had to build good Git habits or learn how to think about the different options that Git's command set provides, because their workflow didn't demand it.
Curious - do you think that's mostly a tooling/culture thing, or more of a learning gap, where they just never had a reason to dive deeper?
Part of why I'm making these tools is to explore if a more visual approach might make some of those concepts stick better. But curious what you've seen actually work in practice for helping people improve their Git skills.
As you highlight with the "VSCode over RDP" story later on the post, it doesn't stop on Git. Some people just don't care about learning their tools. RTFM? Hell no. There is no care for the "craft". Once they learn the very basic for their current need, they're done with it. We can also observe this behavior during coding, once "it works", they just push all changes and move forward to the next thing. No second thoughts if it could be simpler/there were unnecessary changes, no double check if there is missing cases, etc. "Someone will spot my wrongings during review".
From the outside, it feels like "low effort" all around. But to be honest, I can't really blame who does this. For some, it is just a 9-5 job anyway and they prefer not think about these stuff outside that 9-5 space. Deep diving into their tools might look like "wasted time" on their view.
A friend refered me to this great post a few days ago that touches on this subject: https://josvisser.substack.com/p/you-cant-teach-caring
[flagged]
This is simply what happens when you pay people with very little knowledge large amounts of money to do something that requires expertise. I'm not sure why we're pussyfooting around that.
It would be like not knowing about loops or how to print text to the screen or how to do I/O. People seem to think you can be clueless and somehow still deserve a programmer's salary. The entitlement baffles me (and I've experienced a lot of it from people throughout my career).
A staff SWE who can't send you a patch is simply unworthy of their title, the way I'm unworthy of the title "pilot" or "doctor" or "attorney".
I wouldn't trust the world's leading neurosurgeon to perform surgery on my ankle. Nor would I want my patent attorney to represent me on a murder charge. I'm also not trusting the pilot for the Marine One helicopter to fly me anywhere on a Boeing 737 Max. "SWE" is simply too broad a term to encompass all of the deep knowledge someone should have at some point in their career. That us, unless we want to talk about licensing software developers with certifications, which is a whole other can of worms.
Maybe because they didn't use Git in their career or their role doesn't require to be hands-on.
In my company, we use mercurial so I can imagine that some SWEs aren't fluent in Git because they've used different tools. But apart from that, Git isn't rocket science. It takes a bit of practice like anything else but anybody should be able to know the basics in a few days, and become proficient after a few months of regular practice.
I don't think that regular usage of the Git CLI is sufficient to develop an insight into Git's internal data design for most people, which is really necessary for to become proficient enough to troubleshoot. You wind up thrashing a lot and then just giving up.
I've always used IntelliJ/PyCharm/Rubymine for my Git needs.
That handles 98% of what I need to do. For the remainder I sometimes stumble pretty badly, but figure things out.
I’m still waiting for “I struggled with git, so I invented the next paradigm of DVCS so no one ever has to struggle with git anymore.”
Fossil, Mercurial, Jujutsu. All have better CLIs and consistent behavior.
If only IDEs and sites like GitHub and GitLab were agnostic about the DVCS.
It's not quite what you're asking for, but Jujutsu+Git is still a much better dev experience than Git alone and is completely compatible with those sites.
I use Jujutsu for 100% of my version control at my day job, where all of our repos are in Bitbucket and all my coworkers are using Git. AFAIK most of my coworkers don't even know I'm doing anything different, other than those who I've "evangelized" so far :)
...I think my PRs have gotten noticeably cleaner and easier to review, though!
Lipstick on a pig, I'm sorry to say. Especially jujutsu which is literally just a wrapper for git.
These tools have better CLI for sure, and some nice added features too. VCS-integrated collaboration tools in fossil is nice. But my point was more along the lines of "why don't we have a radically different architecture that is better matched to the problem domain?"
We have database-backed storage backends for Jujutsu at Google. There's no Git involved there. So I think it's wrong to say that it's a wrapper for Git.
Even when using the Git backend, it's only commits and lower-level objects that are stored in the Git repo, and even some parts of the commits are stored outside Git (e g. the change ID). The operation log (which powers the undo feature) is also not stored in Git.
Ok that's pretty awesome. But by git backed I meant the data structure. Darcs & pijul shows that we can do better than a commit tree.
Git is the radically different architecture. Before it we had RCS, CVS, SVN, and a host of others that were simply striving to improve on the RCS model... a model that was simply unable to scale to large distributed projects with many collaborators.
Torvalds dreamed up Git in a weekend, and it's radically different from the patch-tree stuff that came before it. It's not taken over the world for no reason.
I lived through all that, I know. Torvalds didn't dream up git btw, it was a bad, but performant copy of monotone's DVCS UI/UX.
We can do better though. Patch theory shows that we shouldn't even need to care about commit history, for example. If we could just get off the tree-of-diffs model.
I seriously considered fossil when I was looking for a git replacement that handles large files better. IIRC fossil has the exact same issue.
How about "I struggled with git, so I read the very easily digestible and entirely free Pro Git book"
Version control that is simpler to reason about, and doesn't have such complex layers of tooling underneath is quite possible. It is network effects that keep us on git.
Git is extremely easy to reason about and requires the use of a very small number of commands. It would not have become the dominant VCS if that weren't true because nobody would have switched to it.
It became the dominant version control system because (1) Linux and (2) GitHub. There were better version control systems even at the time (and better ones still now).
I learned Git from an O'Reilly book and I loved that it started with the internals first.
The git CLI has some rough edges, but once you have concepts of work tree, index, commits and diffs down, it is extremely powerful. magit in Emacs is also incredible.
Ah yes, the hallmark of great software is having to learn how it's implemented to be able to use it.
None of the concepts behind git are difficult to grasp, the problem is interface and leaky abstractions all over. Any person that mentions reflogs is actually saying I don't understand any of the points above.
> Ah yes, the hallmark of great software is having to learn how it's implemented to be able to use it.
Because learning how a software model a particular problem domain is a great step towards efficient use? You can hope it's magic, but that's a recipe for failure if you're a heavy user. Every professional learns the ins and outs of the tools he uses often.
https://v5.chriskrycho.com/essays/jj-init/
> The problems with Git are many, though. Most of all, its infamously terrible command line interface results in a terrible user experience. In my experience, very few working developers have a good mental model for Git. Instead, they have a handful of commands they have learned over the years: enough to get by, and little more. The common rejoinder is that developers ought to learn how Git works internally — that everything will make more sense that way.
This is nonsense. Git’s internals are interesting on an implementation level, but frankly add up to an incoherent mess in terms of a user mental model. This is a classic mistake for software developers, and one I have fallen prey to myself any number of times. I do not blame the Git developers for it, exactly. No one should have to understand the internals of the system to use it well, though; that is a simple failure of software design. Moreover, even those internals do not particularly cohere. The index, the number of things labeled “-ish” in the glossary, the way that a “detached HEAD” interacts with branches, the distinction between tags and branches, the important distinctions between commits, refs, and objects… It is not that any one of those things is bad in isolation, but as a set they do not amount to a mental model I can describe charitably. Put in programming language terms: One of the reasons the “surface syntax” of Git is so hard is that its semantics are a bit confused, and that inevitably shows up in the interface to users.
I truly don't get it. All these supposed software engineers who can't seem to grasp the basics of the tools of the trade. It's like watching carpenters argue about a hammer every few weeks for ten plus years.
There's no excuse. Either learn git, or stop using it. If you can do neither, stop complaining, because plenty of people use it just fine.
And no, you really don't have to understand the internals to use git, but you DO need a mental model of what's happening: what a commit is, what a ref is, what a branch is, what merging/rebasing does, etc. These don't involve knowing the internals, but they do involve maybe reading the manual and actually THINKING about what is happening.
Too many developers confuse not wanting to think about something with that thing being difficult. I learned git one summer during a college internship 15 years ago, and I've been fine ever since. I am really, truly, not that smart, and if I can do it, so can you.
Everyone needs to just quit their bitching and actually learn something for once.
[flagged]
What are you doing programming if you can't handle interfaces and leaky abstractions? that's basically the job!
This quote from "PHP: a fractal of bad design" [0] seems applicable here:
> Do not tell me that it’s the developer’s responsibility to memorize a thousand strange exceptions and surprising behaviors. Yes, this is necessary in any system, because computers suck. That doesn’t mean there’s no upper limit for how much zaniness is acceptable in a system. PHP is nothing but exceptions, and it is not okay when wrestling the language takes more effort than actually writing your program. My tools should not create net positive work for me to do.
[0] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
Yes totally agree. Curious if you think visual or gamified tools might have been useful to get an initial grasp on the types of concepts you mentioned? And if so where they might fit in?
https://learngitbranching.js.org/
is my go-to recommendation
[flagged]
Oooh! I am literally talking to game devs today for ways to visualise knowledge about
+ Lithium batteries
+ Battery management systems
+ Embedded coding
+ CAN-Bus communication
+ Inverters & DC DC converters
I made my own electric cars and am now sharing everything I learnt in a series of mini games & flashcard trainers. Duolingo for learning energy tech:
https://foxev.io/academy/
There are so many abstract concepts that could easily be taught with a string of 2-3 Minigames that don't have to be harder than the average balloon pop game or a portal2 puzzle.
A while ago I played a little game that taught you vim commands and let you traverse an RPG style landscape doing it.
Was it https://vim-adventures.com ?
Yes!!
isvteaching people really that hard? the older i get and the more i see attempts at teaching i wonder why just teaching simply is hard
Putting content in the right order and hitting the right abstraction level.
Keeping the reader/user in the zone between being bored and overwhelmed while you teaching them, without knowing something about them (only data as feedback if they are using a tool that you built,rather than them raising eyebrows or nodding in a classroom).
I think it's hard but also fun. For the EV stuff that I look at there are a few problems compounding this:
+ Overwhelming buzzwords and complexity
+ Wrong intuition for HV systems
+ Unclear where to start
+ Capital requirements are high
+ Dangerous tech
[flagged]
do adults not get bored or overwhelmed?
I’ve seen so much content on the Internet dedicated to how hard Git is to understand the moment you get beyond basic functionality. Is Git the problem or is meant to be used only after months of training and practice? Seems silly to have any software take so long to learn and comprehend.
Training won't help: you need to be fighting wild git beasts almost daily, otherwise it all evaporates. Any modern dev work takes up 500% of your brain already. You pull, push, commit and stash all the time and it becomes second nature.
Then, suddenly: your stash pop has failed! Something has been left somewhere! You need to git add something! Output of git diff is empty! Why is it empty, did stash not apply at all? (you run git stash pop second time, and feel terror) It recomends you to run git restore --staged! Was restore not kinda reset that wipes your local changes? Stash was your safe space, the only git thing you felt sure about. You feel abandoned.
Next time, build script breaks only for you! No idea why! Turns out a day later the script cannot deal with worktrees you set up last year when you tried to "learn git"
Some time later lead emails about "scrubbing prod creds", "force pushing HEAD". You run attached commands with fear and awe.
Next month, you end up with a detached head! It sounds painful! Half stuff does not work!
Gradually you are being conditioned that git equals pain. Sure, other tools have it worse (hi ffmpeg!), but they don't spring it on you in a middle of a big change you are trying to keep in your head, only to be forced to take a sabbatical and learn seven circles of reset because a wild tag merge conflict has appeared, or your lead wants you to use rerere to rebase your branch after splitting one commit into three.
Hey, so, these are not problems unique to git, for what it's worth. And if people don't want to deal with problems, then maybe software development isn't for them, because this is like a plumber complaining about joining pipes. (And don't bother belaboring this analogy, because I will not respond.)
No, it's like plumber complaining about filling tax return forms. In the middle of joining pipes. (And I will bother belaboring your analogy. For the benefit of others reading it.)
As you say, it is not unique to git. Bug trackers, system updates etc. also can "disrupt flow" and take a lot of attention away from the main work. But git is unique in the insidious way that it springs such hard problems on unsuspecting developers that are busy *actually working*
Git is there for tracking changes. If you don't care about that, then there's nothing to be done. If you do care about it and it's important for your job, you learn the tool and use it. And git is a good tool.
Git is a good tool for tracking changes if your primary job is tracking changes. It is terrible tool if you care about tracking changes because you need your work done. There is no encapsulation and the cognitive load and amount of moving parts you need to keep track of mentally is hugely distracting.
It's just the realities of participating in a distributed system. There's no 'current state' or 'now'.
You could make the mental model easier to understand by centralising the state and switch to pessimistic locking instead of optimistic. But then you'd have to live with the downsides of those, like git's predecessors.
There's definitely a local "current state". Its just that there's no inherent concept of a central repository or source of truth.
In practice most people use it as if it does - the remote is "preferred". Which isn't such a bad thing if you know how to use branches and resolve conflicts properly.
Best practice is to create a new branch for each feature, then create a PR into the proper branch.
Early on in development it can be very chaotic as so much code is changing so quickly. No revision system is going make up for a lack of communication and division of responsibilities.
[flagged]
The only winning move is not to play. Stick to a few git commands (3-4) and there won't be a whole Alice in Wonderland journey down the rabbit hole.
I use the following commands frequently
* pull
* push
* checkout / switch
* commit (ofcourse)
* merge
But I will end up needing
* log / log --stat
* stash
* diff
* show / show --stat
* blame
* revert
* cherry-pick
* reset
* git grep (can be replaced with rg / grep -rn)
I can't imagine not having these commands now.
If you use something frequently you should know it in-depth. It applies to tools (git, VSCode), frameworks (Spring, Django, whatever), infra (kubernetes, docker). otherwise you're missing out.
Hard agree. I love this mindset! If you put a tool in your toolbag you should know how to use it.
Git is definitely abstract and hard to get the hang of but totally worth it - pays dividends in terms of the options it puts at your disposal. And the stimulating nature of learning how it works so that you can think for yourself to figure out a solution, instead of just memorizing 3 commands and running to AI for help when you get a little stuck.
Version control is one of our main tools for interacting with other developers. Having a rich understanding of your version control software often helps to find solutions and workarounds for problems which would otherwise result in needless conflict.
I would just add `git rebase -i` to the mix. Very useful to clean up a work branch before submitting it for others. Sometimes you just need a bunch of "wip" commits, e.g. testing CI scripts, deploying a optimization on the side for further testing, etc. and rebase is a must if you care about the commit log.
You forgot to include an explanation of what rebase does, which is important for knowing when to actually use it, instead of just specific goals you might have.
> If you use something frequently you should know it in-depth.
I prefer to remain oblivious to many things. Two views of the Mississippi and all that.
Git works reliably and achieves my humble expectations. Thanks git.
But in reality I use about the same set of commands. The exception being ‘cherry-pick’ which I avoid solely on disliking the name.
what would you call it instead? or does the word cherry have some weird association in your mind?
No, it’s just weird and out of context. Just plain “pick” maybe.
maybe
cherry picking has a negative connotation in its most common usage.
sure but is it enough to avoid using it though? I don't like to get screwed in business, but I don't avoid the screwdriver in my toolbox when I need one.
[flagged]
Core:
- pull
- push
- commit/checkout
- merge
Quality of life:
- stash
- diff
Asking for trouble:
- revert
- cherry-pick
Your definition matches my mine of a tight subset of git.
git reset --hard HEAD~1
lol not sure why this got downvoted unless it's because ~1 is redundant and you can either do HEAD^ or HEAD~ and save one keystroke
> Stick to a few git commands
This was my approach for my first few years of git. I always tried to approach git via its commands, and I horribly failed - until I finally took a little bit of effort to understand how git actually works under the hood, which really made it click for me.
For anyone who has ever spent a modicum of time (e.g. while getting a CS degree) trying to understand datastructures, it's probably really straight-forward to "get git". The datastructure underneath is really quite simple. A branch is a pointer to a commit, a commit is a pointer to a tree, a tree is a list of pointers to other trees and files. That's already pretty much all there is to it.
Once the datastructure of git is understood, the commands start to "make sense" on their own - at least most of them. They still have tons of obscure options that one doesn't realistically need in a daily work flow, but the general idea what the commands do (and how to recover from screwups) was, at least for me, pretty simple after understanding the datastructure.
haha this is a bit of a sad take in my opinion, because of the value that I feel that comes with understanding how a tool like Git works behind the scenes, but seems to be several folks here who feel the same way you do
I feel the same way. All of git's weirdness seems totally reasonable once you understand it on its own terms. It doesn't even take a ton of understanding to get that that point either.
It's not a sad take. There are many roles in tech and I'd encourage those trying to make things to focus on that. You can get extremely far with 4 git commands. Even in a production team environment, you may only need to ever add in the merge workflow.
I agree with you. My typical workflow is: update master branch in Visual Studio, create a new branch off of the master, work on it, when ready use GitGUI to commit and push, then do a merge request in GitLab (we use GitLab). When approved, I push the branch to master. From time to time I need to update my branch, either because I make some code changes, or because my branch a few commits behind the master.
Would I like to know more about the underlying ideas of Git. Yes. But the time it would take me to do that is time I can spend on other things, like the stuff I am actually paid to do. If I become a git guru, I might get a pat on the back, but more likely no one would care. If I deliver more stuff, people who use my stuff actually appreciate it.
The reason it's sad to me is because there is so much more to explore, to be stimulated by, to be able to apply in a way that makes you think out of the box.
Maybe a lot of people don't care about that, and I guess everybody has their threshold, where as long as they know the minimum required to do their job they can stay in that comfort zone typing the same commands over and over.
[flagged]
The only winning move is to learn your tools and develop a mental model of what they're doing. You know, like everything else a programmer needs to know.
Git is bad. Super bad.
It's brilliant for it's original purpose of managing diffs in an open source project.
For industrial projects that are not organized like an open source project it's a massive, massive footgun and it saddens me it remains some sort of badge of honour to memorize it's incomprehensible UI.
It saddens me even more it's the goto vcs system even for industrial projects.
What are the differences between open source and industrial projects that make Git suitable for the former but not the latter?
What would you suggest instead of git, if a hypothetical organization came and asked you which vcs to use other than git? Assume git interoperability is not necessary, to obviate the “we must be compatible with what our dependencies/upstreams use” argument.
My company uses Perforce, and while it's not perfect, it's more intuitive and has a comprehensive graphical user interface. Most importantly, once I learn how to do something with Perforce, I never forget it. That's not the case for me with git.
The merge tool works pretty well.
Also, my company has large repositories.
This. There are other options.
Subversion is still an excellent choice.
I use like 5 commands on a day to day basis. If you think that's incomprehensible then maybe this isn't the right career.
I'm actually shocked to see this many comments on this site with this opinion. Maybe that's a sign that there's just a lot of charlatans here.
[flagged]
Neat game. You might want to check out this other git teaching game - https://learngitbranching.js.org/
Thanks! Yeah I've seen that before. Nice that it's online and nice little puzzles but pretty limited in what it can do by comparison.
Sort of repeating a nested comment, but - I've been using fossil ( https://fossil-scm.org/home/doc/trunk/www/index.wiki ) for years and absolutely love it.
Single executable you just download and put in your path. Sane, well-documented interface (CLI, API and web). Full repo in a single SQLite file. Highly intelligent and efficient diff-based storage and compression (including network transfers). Rock-solid code. Easy exports to git/github.
I think it's kind of a tragedy the dev world got so stuck on git.
[flagged]
Maybe just my present frustration, but I spent the day revising the Aider AI editor's code because it barely even works without git. It relies on git just to list the files in a directory, and so turns off most of it's cool features if there's no repo in it.
I fixed it (PR coming) with some simple non-git directory traversal functions, which enables the cool features again.
But makes me wish the dev world knew git alternatives exist.
I used to struggle with git until I started to use a GUI, now it just works but I get far less hacker cred therefor, which is regrettable.
Heh. I care about results from my colleagues and collaborators, not their tool preferences. If your topic branches and commit messages make sense, that's what matters — because those are our touch points of collaboration.
Which GUI?
Not OP, but I've been using SourceTree for over a decade. I've tried loads, but the only one that I have semi-moved to recently is Fork.
I upskilled significant in git playing the https://learngitbranching.js.org/ game.
so much this. It should be second nature too navigate got history and commits as this tutorial teaches you.
how i've used git every day in the last 10 years:
git add -A, git commit -m, git push
If there's an error because there are changes on the remote, type:
git pull, fix conflicts in case there are any, repeat previous commands
In all other cases, google/grok for the solution, doesnt happen often.
Not to be annoying, but maybe one of the most useful things git does for me outside of the usual SCM stuff, is git-bisect. Its saved me many hours of debugging.
If you ever run into a case where something is broken (that you can measure, like a test or broken build) but it’s not obvious what change caused the fault, first go to a commit where you know the fault is present.
Then go to a commit where you know the fault is NOT present. Go back far if you can! This can be in another branch as long as your start and end spots are connected somehow. And after that bisect command, your HEAD will get moved to the mid point between the good and bad commits. Check if the fault is still there, and run either "git bisect good" or "git bisect bad" depending on if it’s resolved or not.It will keep jumping you to the mid point between the nearest bad commit and good commit till you end up at 1 precise commit that caused your fault.
This works extremely well for configuration changes specifically, where maybe it doesn’t break in CI, but on your local dev machine it does. You can also use this for non-text files like images to find out when 1 part of an image was changed for example.
—
Also if you just want to make normal SCM stuff easier,
For a combo add-everything+commitThanks for explaining this so clearly! I'm going to try this next time :)
Thanks for sharing your workflow - nice and simple! And sounds like you've got a rhythm down with those core commands, which I know is the case for many Git users.
One of the things I'm trying to explore with these visual and gamified tools is how to help newer Git folks or even users who mostly live in that commit/push/pull flow get a clearer mental model of what's actually happening under the hood.
Git has a really wide breadth of functionality that is kind of interesting on its own merit, but also useful for a plethora of different tasks. For better or worse even Git experts can always find ways to expand their knowledge :)
I'm sorry, but it's been ten years and you haven't learned how to handle other git situation? And then you're dependent on Google? Is there a reason why you haven't sat down to learn some more?
Haha yes I am extremely curious to hear the answers to these questions as well to understand the utter stagnation here.
Does anyone use Fossil source control? I've always been interested by it, but it just seems to stay under the radar. I'm curious if there's a functional reason for that, or if github just got to be good enough.
Been using it for years and absolutely love and highly recommend it.
Single executable you just download and put in your path. Sane, well-documented interface. Full repo in a single SQLite file. Highly intelligent and efficient diff-based storage and compression (including network transfers). Rock-solid code.
I think it's kind of a tragedy the dev world got so stuck on git. Maybe not too late!
Fossil is the SQLite one right? I would love to try alternatives SCM tools, but you run into the fact that associated tooling is so concentrated on git and its processes.
I was using bitbucket and mercurial for a while! If fossil had something similar (which off the top of my head, I think they do? Something wiki-like for the SQLite project) I would be willing to mess around with it on a small team or something.
I wonder if the author of this considered using luanti (formerly minetest) as the engine, would have maybe saved some work? https://content.luanti.org/
But perhaps they'd a good reason to go the route they did. Very interesting concept, anyway.
Hey there! Never heard of Luanti, but the reasons I chose to make this in Pygame using this particular open-source voxel engine implementation are outlined in the post :D
I’ve been programming by professionally for about ~5years and using git for version control that entire time.
When I deliberately spent time to learn the foundations of it, it blew my mind how incredibly sophisticated it is and how intuitive it becomes once you understand the core ideas behind it
Highly encourage reading through the official documentation and Julia Evans blog posts on git.
Kinda reminds me of https://ohmygit.org/
Kinda! But really only in the sense that they're both "games" related to Git.
Devlands can do so much more (it's can simulate, run, and visualize any command or scenario that can happen in Git within the context of any local repo) and in a much more intuitive way.
The main thing I struggle with in git is the habit of “make a change, make a commit”.
I will often do multiple commits but they will be all at once as I go through and make a commit and include any relevant changes in the commit.
I find that the command "git add -p", which allows you to add individual sections of files rather than whole files before committing, helps with this issue.
It's quite natural to wind up with a bunch of work that really needs to be in multiple commits. I don't think this ever changes for most of us.
That’s basically what I do, I just end up doing it in large spurts. I typically use the cli for most things but I like the GitHub app for picking out changes for a particular commit.
I recognize that URL! Git-sim is so cool!
Oh how I love a good game UX for DevOps.
everybody does...instead of playing games lets put the worshiping to one side and start using alternatives
Git is not good, but I'm yet to see anything that's a clear improvement without sacrificing on the core capabilities. Do you have any recommendations that you like?
A lot of people love jujutsu/jj.
I'll be a late adopter, go ahead without me :)
You first. :)
What alternatives do you recommend?
jujutsu: https://jj-vcs.github.io/jj/latest/
mercurial was arguably better - but switching to it is probably a bit silly now
Modern Mercurial with evolution is extremely pleasant, and the more I use it the more I abhor git whenever I have to go back to it. That plus Heptapod (fork of GitLab with Mercurial support) — it’s very nice indeed. I count myself lucky to mainly contribute to a project where we use all of this.
It’s a shame there’s still nothing quite like GitHub for Mercurial (anymore), where anyone can just sign up and create repositories. Heptapod has a public instance for FOSS, but it requires approval to create projects. There’s also a separate hosted instance for basically anything, but it’s commercial and costs money. One can also self-host, but GitLab is not exactly lightweight, and other solutions aren’t as integrated with evolution features.
I haven't tried it in a while, but mercurial supports reading and writing to git repos: https://wiki.mercurial-scm.org/HgGit and its page says that https://wiki.mercurial-scm.org/GitExtension is bundled, but doesn't handle all of git's features
why? I had to stop using it because no one else would, and the various centralized services dropped support for it. but it handled branching and merging much better, was easier to pick up, and was less likely to trash your local checkout.
maybe if someone rewrote it in rust it would be sexy again? rurcurial?
> maybe if someone rewrote it in rust it would be sexy again?
They have and it's called jujutsu :-)
https://github.com/jj-vcs/jj
OK, it's not a Mercurial clone, but it did take some features from it, and using it will feel more like Mercurial than git. And you can use it on git repositories, so you can have your cake and eat it too.
I think the loss of the google and bitbucket repositories was the main problem - i know that took the heart out of me for doing foss development. i can deal with git (shit, i can deal with rcs), but i don't like it.
You jest, but… https://mercurial-scm.org/help/topics/rust#rhg
ark: https://ark-vcs.com/
Gitbutler is great.
[dead]
it is already pretty good and far better than svn, mercurial
The problem is I can't forget everything I know about git and approach it with fresh eyes to see if this is good or bad.
git is paradise, I now have to use svn, fuck that shit
I'd much rather use SVN than git. I only grudgingly tolerate git because of network effects, otherwise I'd still happily be using SVN.
[flagged]