Git is not hard. It's very simple. But people learn it the wrong way. You have to learn it from the DAG up. If you cannot grasp how the DAG works you'll forever be reading and writing articles like this one which do not help you to learn.
This is a horrible article. You should not bookmark it or use it. If you're not a programmer, you shouldn't use git. If you are a programmer, do yourself a favour and spend a day going through something like this: https://wyag.thb.lt/
It will make you better at git and better at programming. Git is a powerful tool and you need to learn how to use it. Imagine if people read articles like this one instead of learning how to drive.
Don't gatekeep. Git isn't just for programmers.. it's for people that are learning.. people using it in non programming capacities and tons more. Telling people to "git gud" is not helpful. Not everyone knows, or indeed cares to know what a Directed Acyclic Graph is, and sites like this help people's anxiety who are just learning, or who have already screwed up and just want a solution.
You can use Git for versioning all kinds of assets...3D models, fonts, textures, music. I know someone who stored his book on Github and took pull requests from editors.
Yes but those are hacks, no one should immediately reach for git as a tool to version EVERYTHING just because you can. If you treat git as a convenient hammer for your screw, don't be surprised when the screw breaks at an inopportune time
Are you imagining every use of git is either (1) a Computer Scientist writing Code, or (2) a hack? You can't imagine anything in the spectrum in between? LaTeX papers by academics in various fields, scientific coders (MATLAB etc.), people writing stuff in Markdown, students who are still learning even CS, etc. are all doing the wrong thing by using git?
First of all I read it as using git in those ways are hacks (in the computer sense), not that the people using git in those ways are hacks (in the bad at your job sense)
Secondly I think his point is (and I kind of agree) that while you certainly can use git to version you documents, 3D-models, and InDesign layouts, it's not necessarily the best tool for the job. Sure if you're already well versed in git go ahead and use it and if you're collaborating with people using git you're probably going to have to learn it, but at least realize that using git for not-code is probably not the best tool for the job especially if you're at the same time trying to learn git from zero.
> First of all I read it as using git in those ways are hacks (in the computer sense), not that the people using git in those ways are hacks (in the bad at your job sense)
Yes that's why I said "every use of git [...] (2) is a hack".
> Secondly I think his point is (and I kind of agree) that while you certainly can use git to version you documents, 3D-models, and InDesign layouts, it's not necessarily the best tool for the job. Sure if you're already well versed in git go ahead and use it and if you're collaborating with people using git you're probably going to have to learn it, but at least realize that using git for not-code is probably not the best tool for the job especially if you're at the same time trying to learn git from zero.
a) they can grow quite large and the diffs do not compress well so downloading the entire history is quite expensive. SVN supports only downloading part of the tree and history which is useful
b) SVN supports file locking which can help prevent conflicts between editing the same file which is important because of the next point:
c) These files generally do not have diff and merge tools so branching is generally not useful and so are most of git's advantages over SVN.
That said, I am now generally using git for such files because a) I use git for code anyway and b) gitlab (especially which CI is still useful).
Depends on the job. If you're making a game in Unreal, perhaps take a look at Perforce and Perforce integration that Unreal offers. Doing post work on a movie, consider something like Alien Brain. Doing some collaborative writing with a bunch of non-technical co-authors, then the tools that come with Google docs might be the best fit for you.
And if you're going to claim they should be using online-only tools, please explain why it's wrong for them to instead choose the tools that work locally...
so the people who maintain our site content using markdown and hugo, commit/push git, and trigger a CI build and deploy automatically MUST be developers?
answer: they are not, but they can handle basic git just fine. we aren’t some special class of super human: git is a tool, and you absolutely don’t need to know what a DAG is to use it
I agree that the DAG and Git storage model are at least not particularly complicated. The problem is that the Git user interface (the CLI, plus various concepts that are used in other interfaces as well, like refspecs, that are not fundamental to Git) is not very simple, and the correspondence between the DAG and mutations you may wish to perform, and Git commands, is often fairly obtuse and opaque.
I care about the internals of git about as much as I care about the internals of my filesystem.
It's probably helpful to know some basics, but do I need to know intimate details of my filesystem to use cp, mv, shell redirection? No. For most basic actions it Just Works™.
The problems in git are purely user-interface based. Other distributed systems have proven you can make a dcvs with a reasonably friendly UI.
That's because a file system is something you already understand, even if you've never actually used an old fashioned paper filing system. The software is providing you with something you understand.
Git is not providing you with something you understand. It is providing you with a DAG and you neither understand what that is or why you need it. The DAG is not the "internals of git". This is the big mistake. It is git. Everything about git is about building that DAG.
Git isn't hard but it's usually taught like absolute shit. From the get go you're told to use 4 commands, 2 of which are usually not explained and when they are it's often hand wavey. From there on its usually people pontificating about high level philosophy while failing to give concrete working examples. At least that was my experience.
I'm decent at got now for the work I do so I'm cool with it. It really is an awesome tool. But for some reason its just collectively taught like shit.
It's just one of those tools that is very foreign to new users, but once you know how to use it, you can't remember not knowing how to use it because it's so easy... this is like a lot of programming, actually.
I think you are right about the DAG. Once I understood what the high-level data structure of git is, many branch related commands immediately made sense and it was suddenly very easy to use. Many of my colleagues haven't taken the time to learn that and continuously struggle with basic commands.
Honestly the DAG isn't the whole story. The distributed nature also adds a twist that makes things entirely difficult, and the obtuseness of the commands is yet another layer of difficulty. People have every right to expect git commit to commit their changes to the remote repo. And it very well could, but it just doesn't happen to. Similarly you can't tell me with a straight face that notion of having to 'git add' a file you just deleted in order to be able to commit that change is somehow intuitive. I could go on and on but the point is knowing the DAG is hardly the end of the story.
I agree it's not the end of the story, but without that knowledge, learning git is almost impossible. Even with DAG knowledge, some commands are hard to remember.
Graph = graph, a structure composed of a set of objects (nodes or vertices) with links between them (edges).
Directed = the edges have an orientation / a direction.
Acyclic = there's no cycle, you can't come back to a node (in a directed graph you have to follow edge direction).
In Git, the commit objects are nodes, the "parent" link(s) is a directed edge, and because commit objects are immutable you can't create a commit which refers to one of its "descendants" and thus the graph is acyclic.
Unfortunately this article, like almost all others, is still wrong because it looks like commits get mutated when you rebase and the old commits disappear.
It is very important to understand that commits (in fact, all blobs) are immutable in git. You can only make new things. You can't modify old things. Git doesn't delete anything for a while either.
Directed acyclic graph. Basically each git commit points to zero or more parent commits (usually one, zero for root commits, more than one for merge commits) and that forms a DAG.
This is a horrible article. You should not bookmark it or use it. If you're not a programmer, you shouldn't use git. If you are a programmer, do yourself a favour and spend a day going through something like this: https://wyag.thb.lt/
It will make you better at git and better at programming. Git is a powerful tool and you need to learn how to use it. Imagine if people read articles like this one instead of learning how to drive.