A beginner's guide to Git version control

https://developers.redhat.com/articles/2023/08/02/beginners-guide-git-version-control

by freedude • 3 years ago

277 272 3 years ago

developers.redhat.com

gpspake• 3 years ago

I think this is a good guide. Git tends to be an emotional topic for a lot of people - myself included - and the hill I dramatically die on time and time again is that I think, tragically, this is about where developers stop learning git. I think operations like rebase, cherrypick, and squash are just as important as some of the ones you first encounter. Especially when you're working with other people. I use them every day and I see some of the spaghetti experienced developers pile on the graph because they only know merge. I guess my point is "don't sleep on rebasing" :)

jkubicek8• 3 years ago

Git is one of those tools that exposes so much of the underlying infrastructure that people just can't help diving in and making their own lives so much more difficult.

After using git for well over a decade, I'm completely convinced that if you find yourself frequently rebasing/cherry-picking/reflogging you're using git wrong.

hughesjj3• 3 years ago

.... Why not rebase before merging into main?

nerdponx7• 3 years ago

I've been using Git for the same length of time, but I have not reached this conclusion. That's the problem with teaching someone how to use a very powerful flexible tool that accommodates a variety of workflows and styles: different people use it differently.

RandallBrown• 3 years ago

I use rebase multiple times per day. Mostly for putting my changes on top of the latest development branch, but also for squashing commits.

I'm curious why you don't like it?

Espressosaurus2• 3 years ago

I agree that if you're having to use the reflog frequently, you're using git wrong (not least of which because the reflog is not designed for readability and understanding the context where it came from).

But for the rest? If you're working in a repo with more than 5 people, rebase, cherry-pick, and squash are necessary to keep your sanity. Merge nodes are awful once you get beyond more than maybe 3 developers.

no_wizard• 3 years ago

rebase and cherry picking are both cornerstones of trunk based development workflows, and those have proven to be extremely successful in my experience, vs other methods (like Git Flow, the GitHub overly simplistic branch per feature and merge approach, which feels like trunk based but isn't etc.)

rebase makes roll backs extremely easy if you need to roll back specific commits because of bugs and makes releases easier via cherry picking (so you don't slow down trunk merges just to do a release) and allow for fine grained continuous deployment that is harder to achieve than without it.

It is my experience however, that either everyone needs to rebase or you end up with issues eventually when only some developers are and other ones aren't.

I don't care as much for squashing myself as a general case, as you lose fine grained per commit rollback strategies though

lcnPylGDnU4H9OF• 3 years ago

I'm completely convinced that if you find yourself frequently [cherry-picking] you're using git wrong.

A previous employer had a multi-tenant application that was deployed as a client-specific application which loaded the "core" as a dependency. They didn't really know how to do versioning and most version changes were just arbitrary "I feel like we should call it 1.8 now".

At one point I ended up maintaining a client-specific branch of the core dependency on version 1.10 (branch was 1.10-$CLIENT) while the "main" branch was 2.3 or something. For context, it went 1.10 to 2.0 because general cognitive dissonance.

This meant any change that needed to be made in the application core for this particular client also needed to be cherry-picked in some direction, usually by making the change on the client branch and cherry-picking it back as necessary. In some cases another client -- naturally, they would be on a separate branch like 2.3-$CLIENT -- also wanted that change so it needed to be cherry-picked again to that branch.

The result was a minimum of two PRs, one a cherry-pick of the others' commits (one commit unless I felt like spending my time in self-loathing), that I would make for every change. Not knocking cherry-pick at all; it's wonderfully useful when used correctly. That's just the result of non-technical decision-makers making decisions about technical tools.

On the plus side, I learned a ton about git in that job.

jsunderland3232• 3 years ago

If you’re doing collaborative trunk based development then you’re only cherry-picking. So far Dave Farley is the only person I’ve ever heard advocate for this but it does have its place in the universe. Cherry picking is not destructive to history fwiw.

There’s absolutely nothing wrong with rebasing/squashing/amending/resetting heads on personal feature branches. In fact, it’s a pretty good practice if you make messy history and can make PRs less of an eyesore. I think the confusion comes up about when destructive history operations are appropriate because the git cli client does not have a concept of protected (shared) branches vs feature branches.

As long as you keep history destructive operations away from shared branches, you’re good.

User23• 3 years ago

I can’t imagine using VC for exploratory programming without rebase or something equivalent. I don’t want to bother writing a meaningful commit message for a change I’m probably going to throw away. I also don’t want to push a history like “WIP, WIP, works now, broke again, WIP” and that’s what it looks like at a first pass when I’m moving quickly.

Instead I squash away the garbage and push out a reasonable looking chain of commits with nice descriptions.

jayd16• 3 years ago

How do you pull a critical fix across branches w/o the occasional cherry pick? What do you do instead?

p1necone2• 3 years ago

As long as you never ever cherry-pick from one branch to another when the source branch is intended to eventually be actually merged (directly or indirectly) into the destination branch I think it has its use cases.

If you break this rule you could be in for dealing with some atrocious merge conflicts though, so I try not to do it unless the branch I'm cherry picking from is a definite actual dead end (e.g. the change was an urgent hotfix against an old release branch and your workflow doesn't involve merging those back into main/master).

u801e2• 3 years ago

I'm completely convinced that if you find yourself frequently rebasing/cherry-picking/reflogging you're using git wrong.

A lot of people want to use git as a checkpoint/backup system, and commits and associated changes reflect that. The rebasing/cherry-picking/reflogging is one way to update the set of commits on the branch in order to make a set of meaningful commits for the feature branch they're working on.

zwieback• 3 years ago

If you use those commands in your local repo to keep the central shared repo clean then yeah, rebase and friends are great.

StevenXC2• 3 years ago

I've been working a bit the past week on a guide for a workshop I'll be running in a few months to get research mathematicians productive using just GitHub's UI. [0] So the purpose is not identical by any means. But I'm curious whether it's appropriate that this RedHat guide seems to go straight into "what commands do I run" rather than answering/illustrating "how does Git model the history of a software project's files".

[0] http://jmm2024.clontz.org/

nerdponx7• 3 years ago

The #1 mistake in trying to teach people Git is jumping right to commands without developing a mental model first. It leads to nothing but confusion down the line, and reliance on copy/paste of snippets and scripts to get anything done. Effective usage of Git depends heavily on having a basic understanding of how it works, moreso than a lot of other tools.

IshKebab7• 3 years ago

Definitely a mistake, though you can explain Git's data model in about 2 minutes.

I would say a bigger mistake is starting with the command line. A good GUI is absolutely instrumental to understanding Git, and it lets you avoid Git's terrible CLI for as long as possible.

williamdclt2• 3 years ago

Mental models are famously quasi-impossible to transfer. Almost nobody really groks new concepts with theoretical explanations, practical experience is needed almost immediately

abdullahkhalids• 3 years ago

You should almost certainly talk about the way the history is stored. Both because it is essential to understand how git works, but also, if you drop in some of the mathematics that git uses, the mathematicians will enjoy it more.

gdprrrr• 3 years ago

Definitely mention "directed acyclic graph"

StevenXC2• 3 years ago

I prefer "partial order" but I'm closer to a set theorist than I am a combinatorist lol.

chiefalchemist3• 3 years ago

This guide would benefit from some visuals. That is, what is happening, and why. Else, for beginners, just listing commands is too abstract. It would also help to elaborate a bit on why, or at least walk though a merge conflict, 'cause ultimately, that's what beginners need to be aware of. That is, Dev A made changes a file and Dev B also made changes to that file. Boom! But this is why we use Git.

nerdponx7• 3 years ago

The Git book, Pro Git, does a decent job of this. Also https://learngitbranching.js.org/

chiefalchemist3• 3 years ago

I believe that on GitHub there are also visual examples.

For me, ultimately, Git is best understood when there are visuals. The command line is cool, but if there's a tool that begs for a UI it's Git.

Yeah, I know there are Git UI tools, so many the article should have suggested some of those as well?

jehb• 3 years ago

Fun fact, when I worked at Red Hat for many years on the Opensource.com project, we created a collection of dozens of great articles on the ins and outs of git, written by open source community members. You can still find most of those articles here:

https://opensource.com/tags/git

Unfortunately, the team who ran site got caught up in Red Hat's layoffs earlier this year and the site has been sitting in limbo ever since, so I don't know what will happen to it long term.

pabs3• 3 years ago

ArchiveTeam saved the entire site to archive.org using ArchiveBot, except for the downloads, since those were loginwalled. If you are able to contact whoever still has access, it would be great to be able to save the downloads too. It looks like the team or someone from it are planning on continuing the site though?

https://wiki.archiveteam.org/?title=ArchiveBot https://archive.fart.website/archivebot/viewer/domain/openso... https://opensource.com/article/23/6/new-developments-opensou...

micw• 3 years ago

A short explaination what remotes are and how to configure it would be helpfull. Otherwise, the "git push" command would fail and the tutorial gives no hint, why.

criddell• 3 years ago

This image helped me a lot:

https://nitter.net/pic/orig/media%2FFjJ62xKXkAYfFjt.jpg

nelsonfigueroa• 3 years ago

Wow this is great. Wish I came across something like this back when I was learning git.

boneitis2• 3 years ago

As someone who's having a very difficult time coming to grips with git, would really appreciate another source for this. It does not load for me, in the eight ways I have tried to load it (two devices each on a different IP, on two browsers, with that %2F left encoded and attempted with it unencoded.)

6581• 3 years ago

https://twitter.com/bibryam/status/1601499207977693184

https://twitter.com/bibryam/status/1609979930351132683

Given_47• 3 years ago

For posterity here’s [1] a list of Nitter instances. The flagship one (Nitter.net) always gets overloaded

[1] https://github.com/zedeus/nitter/wiki/Instances

tempest_• 3 years ago

Honestly the picture shown in that thread are fine and most people I have met grok those commands really quick.

The issue is git's interface is terrible and very powerful. Which means when something goes awry and they land outside those 5 or 6 commands they often have no idea how to fix it. Which invariably leads to a copy paste of their changes and a delete and re-clone.

Honestly I really like mercurial. I found its interface better but in this day and age all the tooling is built around git so ...

boneitis2• 3 years ago

..when something goes awry and they land outside those 5 or 6 commands..

Yes, this. I have no problem adding, rm-ing, branching, making and accepting PRs, etc. These are what the overwhelming majority of git for dummies tutorials cover. (I've even paid for a very well-known and well-reviewed course and completed it.) And, these photos upthread are fantastic for that initial git-101 progression.

Then, I eventually landed my first tech-sector job and still haven't picked up much more since. My solution to every ounce of apprehension is deleting and re-cloning out of paralysis and fear.

I find great difficulty in being able to glean a repository's "environment" in a sense analogous to gleaning the environment of an initially compromised machine (the foothold) when you've popped a fresh shell on a boot2root box. (I thank the digital gods for IppSec and his hands-on videos that teach you how to clear up the fog of war around you!)

raincole• 3 years ago

The issue is git's interface is terrible and very powerful.

Git is basically that a programming language. The time you need to "master" git is comparable to "master" a programming language.

I'm being writing code for more than half of my lifetime so far, and every time I need to use an unusual git command I feel like a script kiddo who copies and pastes from SO.

rapnie• 3 years ago

The other day Jujutsu featured on HN, with git as a possible back-end. Describing itself as "both simple and powerful" with a combination of practices adopted from multiple tools:

Jujutsu is a Git-compatible DVCS. It combines features from Git (data model, speed), Mercurial (anonymous branching, simple CLI free from "the index", revsets, powerful history-rewriting), and Pijul/Darcs (first-class conflicts), with features not found in most of them (working-copy-as-a-commit, undo functionality, automatic rebase, safe replication via rsync, Dropbox, or distributed file system).

https://news.ycombinator.com/item?id=36952796

messe• 3 years ago

It's missing:

    git diff > ../i-messed-up.patch
    cd .. && rm -rf $REPO
    git clone $REMOTE
    cd $REPO && git apply ../i-messed-up.patch

cakemuncher• 3 years ago

Why apply i-messed-up on main/master? Am I missing a meme here? What's the point of this?

u801e2• 3 years ago

Though, if you know enough to edit diffs by hand, you could use git apply --cached to stage parts of the diff in a way to make a sensible set of commits instead of a single commit for a large change.

PlunderBunny6• 3 years ago

I'm probably showing my ignorance of what is possible/required, but I'd like to see a GUI front-end for Git that looked like the background of this image, where each commit was a lozenge that I could just drag from one column to the other. Maybe individual files could be circles inside the lozenges. Just drag-and-drop, and the front-end figures out all the underlying Git commands to use.

paulddraper8• 3 years ago

Wow that is great!

gorgoiler4• 3 years ago

I don’t recommend git pull to anyone. The magical ways that .git/config sets up tracked vs untracked branches are too opaque for me.

It’s always been much easier to understand (and explain) what’s going on when you separate fetch from rebase/merge*, and I feel like all these “just re clone and start again” memes are all because people’s branch tracking broke and they wanted magical “git push # no further args” to work properly again.

Once you know how to “git push remote myref:theirref” you become much less dependent on magic. Knowing about / having to know about how it works internally is the fun / tedium of git.

*Just kidding about doing git merge, btw. Linear history for life!

nvy4• 3 years ago

Yep. I've been using git for years and still don't really understand the difference between fetch, checkout, and pull.

The official docs are dogshit so I just don't have time to figure out the minutiae.

skinner9272• 3 years ago

git pull with fast-forward (--ff-only) is the only sane way to use git pull (if one must use git pull).

The most powerful one most people don’t use is reset. Soft and hard resets are my bread and butter. I don’t even bother with interactive rebases for squashing. I do a soft reset against origin/<branch> and create a new commit.

da39a3ee3• 3 years ago

Yes I agree. Have you ever seen the "command line instructions" GitHub prints at the bottom of pull requests to checkout the PR code?! I don't think you'd approve of them. I'm pretty expert at git having used it every day for the last 15 years or whatever and I have no idea how to do anything after following GitHub's instructions!

To do it sanely you need to add the contributors remote, and fetch, and checkout, as usual. Would be happy to be educated here if I'm missing something.

Nezteb• 3 years ago

Original source along with some of their other git content: (Nitter search sometimes returns no results, so just refresh if that happens)

- https://nitter.net/search?f=tweets&q=from:@NikkiSiapno+git&f...

- https://nitter.net/search?f=tweets&q=from:@ChrisStaud+git&f-...

For folks who enjoy visual guides, here are a few more I'm aware of:

- http://marklodato.github.io/visual-git-guide/index-en.html

- https://mukulrathi.com/git-beginner-cheatsheet/

forrestthewoods9• 3 years ago

My dream is that someday we’ll all use a VCS that is so simple the internet doesn’t have literally tens of thousands of blog posts pretending it’s simple. Someday…

Espressosaurus2• 3 years ago

We had our chance and decided that worse is better, so here we are.

IshKebab7• 3 years ago

Mercurial was simpler but it was also written in slooooow Python so overall it wasn't really better.

mardifoufs• 3 years ago

I'm curious, if you are referring to mercurial, how is it better?

I've never used it so I'm wondering what I'm "missing out" on!

IshKebab7• 3 years ago

I think it's because it is simple, but Git's terrible CLI makes it hard to learn. Once you've learnt it you can ignore all of the terrible interface and just think about the actual operations you want to do which are generally very simple.

I could explain Git's data model and what the operations do to my wife. I don't think I could actually teach her how to use the git command line though.

Pxtl4• 3 years ago

The core is simple. Misfeatures like the stage and the stash and submodules are not part of the simple core. The workflow where we have no good way to hide history besides destroying it is simple but also stupid, particularly when destroying history also destroys your ability to collaborate or even merge your own code cleanly.

PlunderBunny6• 3 years ago

Yeah. Maybe I'm making excuses, but tools should be easy to use and get out of the way - they're not what we're being paid for. People say 'knowing how to use your tools properly is part of your craft', but I feel Git is more like someone asked for a cabinet and instead we gave them a hammer, some nails, and some timber and said 'but this is so much better than just giving you a cabinet!'

sixstringtheory5• 3 years ago

I see it more like someone asked for a cabinet and hired you, the carpenter, to plane, route, chamfer, mitre, join, hammer, nail, screw and glue the wood into place.

You absolutely need to know the right tools and techniques, of which there are many. For instance, nails and screws are not interchangeable, and they're made with a variety of metals and coatings for specific applications.

Just about anyone can hammer a nail into a piece of wood. It is quite difficult to put together a high quality finished piece of woodwork. Same is true for software.

memefrog7• 3 years ago

People blog about things they learn about. Lots of people use git so they blog about it.

Nobody is pretending it is simple. It is simple.

forrestthewoods9• 3 years ago

It is simple.

No, it isn’t.

smokel• 3 years ago

How can it be that we are still using plain text files for editing code?

Wouldn't the grass be greener if a variable were stored as a unique key, making refactoring trivial? Wouldn't the birds sing louder if formatting were just a view on the underlying data? And wouldn't the sun shine really brightly if diffs were to operate directly on the abstract syntax tree?

I fear that this has to do with the great problem of interoperability, and of people not always wanting to work together. What would be a constructive way to coordinate ourselves out of this silliness?

zakary• 3 years ago

Those do sound like good ideas. Why don’t you try making a proof of concept? I’d definitely give it a go

PlunderBunny6• 3 years ago

Not to mention that comments could point to bits of code without being in the code. We could show them to the user like tooltips (or like the sweet sweet balloon help from macOS Classic - how I miss it so much!)

suralind2• 3 years ago

You may be interested in difftastic for doing diffs based on the AST. One problem with this approach is that when you have a lot of changes (tens of lines, maybe hundreds), it gets slow.

The tool is great thou, and is my default diffing tool.

eviks3• 3 years ago

Great potential tool especially when it adds structured data output for easier integration with other tools

erik_seaberg2• 3 years ago

We need a way to not break the AST when we extend the language.

OkayPhysicist• 3 years ago

We're in a very, very strong local maxima with plain text source code. In order for a rich-data source language to work you'd need to implement, competitively with what we have for text, the language itself (which is already a hard sell, look at how difficult it is for even phenomenal languages to gain a foothold) including built-in macro and codegen systems, a compiler, at least one fully-featured editor, complete with linting and code suggestion and search and an input mechanism competitive with just typing out text, possibly more than one to support the wide range of opinions about editors ranging from IDEs to Vim, source control integrated with means for sharing and collaborating on said code, and every other convenience you get for free from choosing plain text.

Basically, you need to sit down and build the greatest programming language ever conceived, complete with a world class ecosystem, and then convince people that this is truly a revolution software development, and you probably won't make a dime off it because proprietary programming languages are evil.

Good luck?

jdougan• 3 years ago

Look up "Intentional Programming", but watch out for patents.

PaulDavisThe1st7• 3 years ago

It's not about "not always wanting to work together".

It's about "i want to be able to pick the tools i use", which in turn means "the underlying data we operate on needs to use a format/storage mechanism that any reasonable candidate for a tool can use"

And the answer to that quandry is: plain text files.

reductum• 3 years ago

Here's an effort that explores a non textual format for code and tooling:

https://dion.systems/gallery.html

jasoneckert• 3 years ago

Not a bad guide, but the Linux/Windows differentiation is a bit deceiving.

For example, 'git config --global user.name "username"' and 'git config --global user.email "useremail"' are required for Git users on any system before a commit is made, but since it follows the 'Git Configuration: Windows' title, it reads as if it's a Windows-specific configuration.

Additionally, $HOME/.gitconfig is also used by Linux (and UNIX and macOS) systems to store this configuration.

noiv• 3 years ago

I like the guide, but that simply scrolling the page adds entries to the browser's history makes me cry.

noddingham• 3 years ago

Agreed that is awful

suralind2• 3 years ago

The scrolling is indeed terrible.

everybodyknows• 3 years ago

Expected better from Redhat -- looks like incompetence.

loubbrad• 3 years ago

Leaving this here (not self promo):

https://www.youtube.com/watch?v=hZS96dwKvt0

By far the best non-beginner git tutorial I've ever found.

LargeTomato• 3 years ago

Honestly Redhat puts out some really solid documentation and blog posts. It's a shame what they're doing with rhel.

karmakaze• 3 years ago

OT: scrolling creates browser history entries that have to be skipped back, back, etc to go back--new ways to break user expectations.

725686• 3 years ago

I always recommend getting started with git with "Git For Ages 4 And Up" by Michael G. Shwern:

https://www.youtube.com/watch?v=1ffBJ4sVUb4&t=10s

spiritplumber• 3 years ago

Stupid question: how do I move stuff from "master" to, IDK, "main" or similar, while preserving history?

yCombLinks• 3 years ago

Cherry pick if you want an entire commit

mlsu3• 3 years ago

Git is one of those things that people (including myself) have frequently derided for being "unintuitive", "full of footguns", etc.

But after looking at other source control options, I find it to be an absolute joy to use -- even for very complex tasks. The VC problem itself is where the complexity lies. Any tool that deals with collaborative working on document will present the same issues that Git does. Maybe worse.

Be thankful that you can use any tool you want to create plain-text diffs; that git performs operations quickly; that resets, undo's, etc are possible; that the precise history (both of the actual state and the steps taken to get there) is entirely legible; that each command performs a single, well-defined, and well documented atomic operation; that the tool is extensible, command-line script-able, usable locally, free; that it keeps the size of a repository small; that it is scalable across any number of contributors working simultaneously.

Some, all, or none of these may be true with other tools.

Anyone ever had to do a diff of a Microsoft Visio document by hand? Anyone had to manually type in the name of a document and its revision by hand into a web form? Anyone ever spent an afternoon working on a document, only to realize that someone else already made the changes you made but forgot to update the filaname which caused their changes not to be visible to you? Programmers are spoiled with the best tools in version control. People in other domains are doing this, without even knowing that they are doing this. They are making commits, merging, rebasing, etc.. without even having a word to describe it.

paulddraper8• 3 years ago

Yes and no.

Git beautifully matches the problem of collaboration at a fundamental level.

The abstractions, the data structures... if not flawless then at least very, very good. (And that is enough to overcome any number of other issues.)

The complaints are the inconsistency of the interface. E.g. `git branch`

mlsu3• 3 years ago

Yes, But I would say that is a minor issue; I appreciate that there actually is lots of documentation for the precise and unchanging behavior of `git branch`!

Instead of:

"Oh, email this to doc management. Depends on who you get. If you get Nancy, she will double check that your rev C filename matches with your rev D filename in the changes section. Matteo does it differently though, sometimes you do need to include redlines for minor AND major changes, even if the major version gets rev'd. Oh, that doc doesn't have any minor changes at all. I don't really know why, but you better not include minor changes because that will be flagged for sure, only on this document though, for every other one you should have C->D in the footer. Oh that one, the template never got updated so you actually have to type it in manually. Yeah, no idea why it does that.

It would be great if you got the change review back by Wednesday because regulatory has a preliminary product summative scheduled Monday. There's a confluence page for which doc manager should be CC'd for each document to get the review back in time."

masklinn11• 3 years ago

The abstractions, […] The complaints are the inconsistency of the interface. E.g. `git branch`

Surely “git branch” is “the abstractions”?

sverhagen• 3 years ago

Up to 2011 I used Subversion. Then I worked for a year for a company that used CVS. So, by comparison, my time with Subversion looks trouble-free, as you can imagine. I've worked in Git ever since, but every time Git makes my feet hurt, I think back with fond memories to Subversion and TortoiseSVN, probably unwarranted so.

TylerE• 3 years ago

Don’t even have to go that far back. Mercurial is/was a way better ux over a very similar feature set.

CivBase• 3 years ago

I started with Git and now work with Subversion. SVN is definitely simpler but I find myself regularly getting frustrated with its relative lack of features and the wait times inherant to centralized version control systems.

If I could go back to Git I would in a heartbeat.

ozim• 3 years ago

I have exactly opposite experience with Subversion and Tortoise Git from pre 2011.

For me it was annoying and janky any conflicts were blocking me for ages. With git it’s a breeze and I would never ever want to go back.

e12e2• 3 years ago

It's not quite fair to compare Distributed VCS to strictly centralized IMNHO (even if a lot of people are using git as a centralized VCS with GitHub in the middle).

Still, it is interesting to compare workflows and common gotchas.

thiht• 3 years ago

Subversion was atrocious. Not having a proper staging area was a nightmare to work with.

howinteresting5• 3 years ago

Simple question: why is there no git undo command shipped in box? There is absolutely no technical barrier to shipping such a command.

paulddraper8• 3 years ago

Like, git revert? Or git reset?

jsunderland3232• 3 years ago

Do you mean literally deleting your last commit? That would break a lot of the guarantees gained from the append only graph that git exploits for nearly everything it does. I think undo is too ambiguous in the context of vcs that it would be risky to introduce as a part of the cli api. What would you expect undo to do?

lloeki• 3 years ago

why is there no git undo command shipped in box? There is absolutely no technical barrier to shipping such a command.

To undo something you gotta know what thing-that-you-did to undo in the first place.

This is often achieved using the command design pattern, but git does not record commands, nor has such a concept. It only has state.

Let's imagine it does record commands, what should a purported magical "undo" right after each one of these commands?

    - git branch topic
    - git branch -f topic cafebead
    - git checkout topic
    - git checkout cafebead
    - git checkout -- file
    - git commit # detached
    - git commit # on branch
    - git commit --amend
    - git reset HEAD^
    - git reset --hard HEAD^
    - git add foo
    - git rm foo
    - git rm --cached bar
    - git merge a b c # merge succeeds
    - git merge a b c # merge fails
    - git merge a b c # merge fails, resolve conflicts, add, continue
    - git merge --abort
    - git cherry-pick
    - git cherry-pick --abort
    - git rebase main
    - git rebase --onto main cafebead^ topic
    - git rebase -i # pick, reword, drop commits, one fails
    - git rebase -i # pick, reword, drop commits, one fails, fix, add, continue
    - git rebase --abort
    - git stash
    - git fetch
    - git pull

You could come up with answers to that, but then, they would make sense only with one use case of what you intended to do with each command. To cater for that you'd start to need "git undo --this-way" or "--that-way". Any command that cannot be undone would break undo. Any external tool would need to operate using only commands, or it would break undo. Any external too or script extending git by chaining commands would need to implement new commands with undo for it not to break undo (otherwise "git undo" would only undo the last one). Also, consider that there may be files untracked in the tree and tracked in other branches, become tracked midway through a merge or rebase and whatnot. It becomes stupendously complex stupendously fast.

If "git undo" were made for beginner users to make it more approachable, then it would fail as soon as the user faced a non-undoable situation and not understand why ("this undo is stupid!"). If "git undo" were made for advanced users to make it more convenient, then it would fail as soon as the user used advanced tools or scripts breaking undo.

What git chose to do is to be the simplest possible tool: it's a DAG made out of commits that can be labeled, and its commands operate on the DAG and labels (with a staging area so that commit creation is transactional). Commits are not removed until they're GC'd and "undoing" is moving back labels to be pointing to commits as they were before, so not having "git undo" is not even dangerous.

To make "git undo" robust, git would need to hide and/or change its core design + API + UI, which would make it not-git. I'd argue that part of the success of git is these "internals" (which are its actual interface) made it spectacularly easy to script, extend, compose, write alternative implementations of...

The only way to implement "git undo" is to embrace the database-like design (stage manipulation with git add and git rm are preparing a transaction that gets committed with git commit) and explicitly start (git start / git begin, records current work tree + refs + index state) and end (git end, a.k.a discard recorded state) or rollback (git undo / git rollback, restore recorded state).

    BEGIN TRANSACTION             git begin
    INSERT INTO ...               echo >> foo && git add foo && git commit
    UPDATE ... WHERE              git cherry-pick bar
    DELETE ... (SELECT ...)       git rm baz && git commit
    COMMIT // or ROLLBACK         git end # or git rollback

Now you gave me some ideas... hold my beer...

williamdclt2• 3 years ago

There is absolutely a ton of technical barrier to shipping this. I don't know that much about internals, and I can imagine quite a few off the top of my head.

For example: a number of operations are not reversible in the current git model because they're not tracked. We'd need git to start tracking uncommitted changes so that it can restore them on `undo`. That's a fundamental change to how git works and I doubt that the idea would be entertained

8ig8• 3 years ago

Have you spent much time using Fossil?

https://fossil-scm.org/home/doc/trunk/www/index.wiki

nvy4• 3 years ago

But after looking at other source control options, I find it to be an absolute joy to use

Git is objectively pretty janky, though, so it seems to me this statement is an indictment of Subversion and CVS rather than some statement about the virtues of git.

I think it's much like the case with Wireguard. It's not that wireguard is some super amazing thing to deserve such adulation; it just sucks (a lot) less than what came before it.

mlsu3• 3 years ago

Nope, I'm not even talking about subversion or CVS (although, I certainly prefer git to those, and it's a fun discussion).

I am talking about patched-together workflows developed at regulatory agencies, law offices and the like; collaborative editing of... non-code "information".

People who are doing "version control" but don't know that they are doing version control. They are editing documents in parallel. They are changing documents and recording the changes with a paper trail and diffs. They are working on separate parts of the same document in parallel, and managing the conflicts that appear in those documents when they are rev'd. They are sending their changes to someone else to have them reviewed before they are rev'd. Version control.

Their workflows and their tools are positively prehistoric compared to what is being discussed here.

lelanthran4• 3 years ago

But after looking at other source control options,

...

Anyone ever had to do a diff of a Microsoft Visio document by hand? Anyone had to manually type in the name of a document and its revision by hand into a web form? Anyone ever spent an afternoon working on a document, only to realize that someone else already made the changes you made but forgot to update the filaname which caused their changes not to be visible to you? Programmers are spoiled with the best tools in version control. People in other domains are doing this, without even knowing that they are doing this. They are making commits, merging, rebasing, etc.. without even having a word to describe it.

I don't see what that last paragraph has to do with git being any good. You're looking at the difficulty of collaboration without revision control, and saying "this shows how good this particular revision control system is".

If you think git is good because of that last paragraph, then it's no better than CVS.

robertlagrant3• 3 years ago

That isn't the point there. It's that we should be thankfuly for text-based tools in general, compared to most other professions' experience of digital collaboration.

e12e2• 3 years ago

But after looking at other source control options, I find it to be an absolute joy to use -- even for very complex tasks. The VC problem itself is where the complexity lies.

I think mercurial is a lot better and more intuitive.

So does the recent "jj" appear to be: https://github.com/martinvonz/jj

I think maybe both fossil and bitkeeper are more intuitive too.

Did you try any of those?

lucideer3• 3 years ago

But after looking at other source control options

Genuinely curious: what other VCS are you referencing here?

Personally, I have not used many, but of the total of three that I have used, Git is the hardest.

I've used SVN and I will start by saying that Git is objectively better. But that "better" is a balance between ease-of-use and features/power. SVN is much much nicer to use than Git in certain (admittedly narrow) contexts. To be more specific, the SVN (cli) user interface is a lot nicer to use than Git's. Merge conflict resolution is improved in Git, and decentralisation is pretty useful - the ability to setup a local repo and persist changes to disk immediately with no remote is essential in modern version control. These things make Git better but it is not easier to use.

Then of course there's Mercurial: somehow delivers on all the things Git has over SVN while still being almost as easy to use as SVN. No competition here.

senda• 3 years ago

git is just a dag once you get that you're golden

seba_dos116• 3 years ago

Teaching git by showing commands is like teaching how to write letters by showing LibreOffice Writer's toolbars. It only makes sense when you're moving from another similar DVCS that you already understand and know what you're operating on by using it.

Tommstein• 3 years ago

I am reminded of this thread I came across when Bram Moolenaar died the other day: https://groups.google.com/g/vim_dev/c/ivkq22t3LQM . Choice quotes:

It will be good if someone can suggest the git commands for that.
I tried creating diffs from the tagged commits, but those are a bit messy too. I'll not try to fix more, unless someone can tell me the git commands that will make something better.

Consider that even the creator of Vim, a text editor so esoteric that the running joke is that no one even knows how to exit it at first, was repeatedly asking for help with Git commands. Let that sink in.

PlunderBunny6• 3 years ago

My version of this is: "Tell me which button to smash to make this problem go away."

eviks3• 3 years ago

Beginners should use a good GUI client that would obviate the need to remember a whole bunch of commands in the guide while also being more expressive

Pxtl4• 3 years ago

Unrelated to content of article but the fact that scrolling the article pushes sections onto the history stack (instead of replacing the top of the stack) is exceptionally rude. I should not have to hit back 10 times just because I skimmed through the subject headings.

PaulDavisThe1st7• 3 years ago

Someone might appreciate the write-up I did after using git for a couple of years:

https://ardour.org/files/gitintro.pdf

If I say so myself, I think it's better than TFA from redhat.

whartung2• 3 years ago

This was a nice document. But could you expand what happens after step 4 of your last workflow if you get a conflict with the rebase? You say:

    > and then tell git to continue attempting to apply your changes.

Sorry, I just don’t know what that means. Redo step 4? Does rebase fail on the first conflict? It seems that when you get a rebase conflict your in the middle of a process but dumped to the command line. It’s not clear how you move forward (I guess repeat step 4) but more importantly how do you go back to the start before you did step 4?

PaulDavisThe1st7• 3 years ago

so, you run

   git rebase master

and get a conflict report. You fire up your preferred editor/IDE/whatever on the files that have conflicts, and you fix the conflicts, either by picking one of the versions (they will be marked sections delimited by <<<< and >>>>) or by manually merging the versions into a single new version. You save those files back to disk.

Then you run

    git add ... list of files with conflicts that are now fixed ...

and then you run

    git rebase continue

You may have to repeat this process multiple times before the rebase can complete.

arkj• 3 years ago

> When using the git commit command, we recommend always including two arguments: -an and -m.

This advice will mislead beginners for whom the article is written.

5424582• 3 years ago

On the topic of Git, I vaguely remember somebody mentioning that Google was looking at wrapping Git with something else to simplify it. Anybody remember what that project is?

resonious• 3 years ago

There's "jj", which started as a Google employee's hobby project but they put him full time on it. Not sure how much G plans to push this, but they are endorsing it at least.

https://github.com/martinvonz/jj

I've been using it myself lately and it's pretty cool. Takes some getting used to, but actually pretty easy to recover from screw ups, unlike git.

5424582• 3 years ago

Thank you!

hmble• 3 years ago

Thank you for sharing this. It inspired me to not worry about whether content already exists or not, we can surely write once again in our way again.

Earlier than this post, my thought was that "What value can I add by writing about git? Theres already tons of articles for that."

Seeing this post from Redhat, motivated me to write whatever I feel like writing, even if it has been written before.

Thank You

ciberado2• 3 years ago

I have contradictory feelings regarding git. For more than ten years, I was using it daily without really understanding the internals... and I was often confused and frustrated. After investing some time learning how the Directed Acyclic Graph works, suddenly everything made much more sense.

And, yes: it is good to learn the underlying fundamentals of the technology we are using. But, on the other hand, it denotes a rather poor abstraction from the UX point of view, imho.

Now, when I deliver git training, I start by explaining the DAG and how there is no magic, only git. By the way, the notes and exercises of the course are in my GitHub account[1], feel free to check it out if you think it can be useful.

[1] https://github.com/ciberado/git-workshop (https://ciberado.github.io/git-workshop/)

not_your_vase2• 3 years ago

Unfortunately knowing DAG's inside out will not save anyone who decides to open man git and related pages. Git is not magic. It's just the dictionary example of what you get when software developers start coding without adult supervision. Lots of cool stuff, but usability and user-friendliness is not one them.

ciberado2• 3 years ago

I only partially agree. Git is a complex project, developed to help with the management of the Linux kernel source code. Because of that, the original audience was technically very advanced and maybe didn't need any higher layer of abstraction, nor a proper product development roadmap.

The problem appeared when people like I started basing our workflow on it ^_^. There are a few good books[1] and tutorials[2] out there, but I totally agree that the official documentation is only useful as a technical reference.

[1] Mastering Git, https://www.packtpub.com/product/mastering-git/9781783553754 [2] Atlassian Git tutorials, https://www.atlassian.com/git/tutorials

dogleash• 3 years ago

It's just the dictionary example of what you get when software developers start coding without adult supervision.

git was originally explicitly a VCS core for anyone to build on. Remember the "plumbing vs porcelain" days? I do.

And after 18 years what have the "adults" done in the meantime? Come at them sideways for having the gall to release an unrefined tool that got popular?

h1fra• 3 years ago

In my 10 years of using Git I think I have used mostly these commands: "git pull --rebase", "git add -p", "git commit -m" and "git push"

Everything else can be googled/learned when needed. I think I just wish the default flags were more sane and command's name would be less "internal".

paradite• 3 years ago

I use a lot of git aliases, and I check git status all the time.

  $ history 1000 | cut -c 8- | sort | uniq -c | sort -nr | head -10
  238 gs
  73 gd
  68 gcz
  67 ga .
  56 npm run test
  53 gp
  29 code .
  25 open .
  24 git pull
  20 ls

sireat• 3 years ago

Coming from subversion it seemed silly that staging and committing is separated in git. Why not have a command to combine the both?

Most git clients handle this automatically since for most "normal" flows there is no need to separate the two.

An explanation on the need for separate staging would be nice to include the in the philosophy of git.

A beginner's guide to Git version control

Related Stories