Git has been a powerful tool for software development and version control since the mid ’00s, gaining widespread popularity since then. Originally built by none other than Linus Torvalds for handling Linux kernel development, it’s branched out for use with all kinds of other projects. That being said, it is not the easiest thing to learn how to use, with tons of options, abstract ideas, and non-linear workflows to keep track of. So if you’re new to the system or don’t need all of its vast swath of features, you might want to try out an alternative like Gitless.
Thanks to the fact that the original Git is open source, it’s free to modify and use as any user sees fit, and there are plenty of options available. This one aims to simplify many of the features found in the original Git, implementing a tracking system which somewhat automates commits. It also includes a simplified branching system, making it easier to switch between branches and keep better track of all that’s happening in a project. The command line interface is simplified as well, and the entire system is backwards-compatible with Git which means that if you find yourself needing some of the more advanced tools it’s possible to switch between them with relative ease.
For those of us keeping track of our own software projects, who don’t necessarily need the full feature set that the original Git has to offer, this could be a powerful tool that decreases the steep learning curve that Git is known for. It’s definitely a system work diving into, though, regardless of whichever implementation you choose. It’s an effective tool for everything from complex, professional projects to small hobby projects on the Arduino.
If only Ann and Nancy had been born a little later, maybe we would have had “Gitless”! :-)
https://youtu.be/BnI9MdpaMjA
Although Gitless does simplify the commands and options, it doesn’t change the fact that git itself is difficult. If you don’t fully understand the concepts behind git, then no matter how simple your tool you’ll still be unable to use it correctly. Just look at the Gitless docs for “gl branch” and you’ll see that Gitless is also not immune to the complexity of git. The only solution is to switch to Mercurial or SVN, but those are terrible so you might as well just learn git and enjoy its extremely powerful yet confusing commands and options.
If Mercurial and SVN are terrible, Git is even worse… Fight generalization with more generalization.
It’s not the complexity, but rather than git is a hot mess of leaky abstractions, state and implementation details that keep bubbling up to the user:
Simple stuff like rolling back an accidental commit, or removing a file included in a commit, is state dependent and requires directly interacting with the implementation of the change graph. Eg: I need to remove a file, wtf is a reflog?
Delete, comment “deleted x.h, not needed any more”, commit?
I find that most things difficult with git are because I wanted to do something one way, instead of just focusing on the results.
With the exception of changing a submodule, holy fuck what a mess.
I would agree, but organizational use means imposing an (often completely incompatible) structure on top of any storage system, and git’s necessarily rigid structure just ends up being a total mess that happens to support differential changes.
What we need are intermediary abstractions that automatically take care of certain use cases and can be templated. Instead we get hundreds of projects like this, that only fit very specific use cases and we’re back where we started.
To be successful such an abstraction would also need to take care of large binary storage, as much as everyone hates to talk about it.
Can you explain why SVN is terrible? A genuine question. I’ve used it for years, only grudgingly switching to Git because other team members wanted to.
I didn’t understand then and still do not understand why people want to use it over something like Subversion. It is unnecessarily complicated to me. I find myself having to spend more time managing the versioning tool with Git than I ever did with SVN.
Having the full repo local to my machine is nice, I suppose, but for small or medium sized shops it’s really not a must have feature.
What am I missing or not understanding?
Agreed, I’m also a massive fan of SVN and find git overcomplicated and unnecessary.
It strikes me that these DVCS are less used for the D (distributed) part, and more because the implemented merge technology is much superior. I used SVN for years, but found if there were more than a few developers working in the same area, then merge conflicts happened often. Git (and mercurial, etc), seemed to have less of that.
Just my perception.
All too often we don’t have a choice.
Y’all ain’t used a version control like PVCS. That software is a PIA!
Git is not that complicated. 98% of what normal devs use can be learned in a day. The 2% that’s more complicated will be used by the technical lead who’s managing the repo and produces a company’s documentation and policies for using git, and will be the one fixing stuff when other devs misuse it.
The problem with Git isn’t so much its functionality but the obscure, messy interface and jargon where almost nothing is what its name suggests, especially command names.
So Gitless is an attempt at a simplified UI on the Git client, with the same back end, right? There are also GUI/IDE clients which have tried to provide different kinds of defaults and abstractions while using the existing Git back end. You might have trouble communicating with people using standard git, and you might have to relinquish using the standard web UI, and you might wind up having to reintroduce all those details in ways that are really no simpler… but if you really think there’s a better way to think about this, you should be able to take those as proof that it’s possible and try something out.
I actually liked the Eclipse interface to SVN, in large part because it encouraged associating development and pull requests with specific work items.
I also liked the automation we had built into our system where every commit got regression-tested in isolation before being a merge candidate, and every merge got tested again and it and other new merged were automatically backed out if that failed so conflicts could be reconciled before the change was accepted. Real change control, not just blame control.
Bingo, can’t help but notice ppl with bad verbal communication skills create this kinda crap.. so it same problem, diff medium.
My preferred solution is to stick with a GUI interface to Git. Tortoisegit works alright for simple projects, and it keeps me from having to memorize the commands I’ll inevitably forget after leaving a project alone for a week anyway.
I predict ther will be a ChatGit soon, where we can just tell it what it is we want done. Computer adapts to human instead of otherwise.
This has already happened(-ish). There are several operations on github which require you to chat with their Virtual Assistant. e.g. https://stackoverflow.com/questions/38831301/how-to-un-fork-the-github-repository/66470086#66470086
ChatGit will just merge whatever it feels like. I can see this going very wrong very quickly.
I agree that GIT is an increasingly complex and difficult tool to use and less user-friendly. An easier alternative is welcome.
SVN, Git, CVS, TFS, Mercurial (…) one can´t say there aren´t alternatives !
To me the problem with GIT is that it allows you to do a lot, even things that doesn’t make sense in most cases and there are little to no guardrails for beginners (or advanced users that make a mistake). It’s like learning to drive a car, you can drive off a cliff, hit gas paddle instead of brakes, drive through a marketplace at 100 etc. You just have to learn a few good workflows with git and stick to them, expand as and when you learn more about the tool and as needed. It’s not difficult but you have to learn best practice and that can be hard at first, especially if you want to find it in a video tutorial which often focuses on bad workflows.
This. Combined with expert users promoting these options a lot. Rebase is extremely powerful for example, and no basic user should ever touch it. As there are many gotchas with it.
For sure, absolutely!
However in a professional environment (e.g. $$job), I expect anybody not an intern to know the tools of their trade and be able to work (and get help from) more senior engineers. The work environment should suffer because of (willingness to learn) lack of skill.
Its not like we ask a carpenter to use a hammer and handsaw because a nailgun and electric saw are to difficult to use.
A carpenter should be able to use an electric saw without having to know the details of how an induction motor works, and it should have some basic safety features built in.
Software developers are not version control experts (yes, some are…but that’s not the job description). It’s OK for some things to be somewhat complicated when they’re expected to be handled by a domain expert. But the every day tasks that most developers need to perform (check out files, modify those files, check those files back in) should be simple and safe, and their effects on the repository easy to understand. Git utterly fails in that regard.
Huh? No regular user should ever do merge. Rebase only.
What, you don’t like your commit graph looking like a slime mold growing up the screen?
I have no desire to ever rebaase or do anything more complicated than branch and merge with git. I’m a software developer, not a git engineer. The less time I have to spend thinking about git, the more time I have to focus on writing good code.
Thank you, precisely!
The incredible fact that the most upvoted StackOverflow questions are dominated by basic Git use cases tells it all.
In the context of tech evolution Git is analogous to an invasive species, or some global pandemic, or cancer.
Is gitless actually still alive?
I just gave it a try and immediately ran into some python exception.
When researching if this is already in the issue list… i realized this Project did not release anything in the last years nor had commits
https://github.com/gitless-vcs/gitless/graphs/code-frequency
Title of https://github.com/gitless-vcs/gitless/issues/248 is “Is this project abandoned?”
Isn’t this the same as only using git add, push, commit and pull?
Git might be complicated, but I have been using it for years with just these basic commands. If I need something else less trivial, a quick google-bing-baidu search usually gives the answer.
The statement “People who are bred, selected, and compensated to find complicated solutions do not have an incentive to implement simplified ones.” might be really true, perhaps.
For mac users, `gitup` is an amazing gui that really does simplify life.
Got me out of many tricky situations (and saved days of RTFM)
This is worth a read — it’s over ten years old now, so some of it is obsolete, but a depressing amount is still completely valid: https://stevebennett.me/2012/02/24/10-things-i-hate-about-git/
My solution to get around the aggressively obtuse git UI is to use Mercurial as a git client. With the hg-git plugin (http://hg-git.github.io/) it Just Works with git repositories, allowing the use of the vastly cleaner and more consistent Mercurial UI. Being able to use things like ad-hoc branching and hg glog to show the real structure of the data makes life so much simpler. I’ve been using it with github for years now and there is no going back.
lol; “Git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.”
But in seriousness, if you are interested in an easy-to-use DVCS and are sporting, check out FossilSCM.
https://www2.fossil-scm.org/home/doc/trunk/www/index.wiki
The executable is a single binary, the repository is a single file. Aside from VCS, it also provides a web interface, bug tracking, wiki, discussion forum, etc.
It’s a less well-known, but actively developed and maintained by the SQLite guys (who use it for sqlite, big surprise).
I think most problems with git come from bad documentation and bad tutorials. Most ( from their site and others ) start to talk about how things are implemented, instead of presenting some clear instructions for people that just need to use the thing.
Maybe the explanations about the pointers and states are important to some people, but tutorials explaing just the “good practices” and how to use them would go a long way to help .
I agree with you but also have an interesting contradiction. The man pages for git includes tutorials that are remarkably good. They basically do exactly what you imply they should do. They give you the basics of how to use it then give suggestions on what to read next with options for more technical information or more immediately usable info.
I think it’s extremely likely most people that found git hard to learn haven’t read the man page gittutorial since:
a) I’m not sure why anyone would think to look at the man pages unless they are specifically using git from the cli,
b) you don’t normally expect the man pages to include a tutorial and,
c) if you were using Windows I have no clue how you would even find those tutorials.
I honestly can’t tell the difference between the trolls, sarcasm, and legitimate misunderstanding in these comments. It was entertaining though.
Git solves a problem that almost no development teams have. Now yours may be geographically distributed with an unreliable Internet connection, but that’s not the majority. The only thing we gained with the move to git was some speed in a few areas at the expense of lots of additional unnecessary complexity.
imo, people would be better served by a git tutorial.
i agree with criticisms that git is opaque to newcomers. but personally, once i saw a half dozen idioms, i was able to use it to replace my previous dependence on rcs. i was really uncomfortable knowing there was a deep unknown there, waiting to mess me up. but that fear was unhelpful: i have literally never messed anything up with git. and git’s undiscovered dark corners are actually about how i would intuitively imagine. now that i know how to use it, i would struggle to imagine a better set of commands and capabilities.
the place all this falls apart is non-programmers. a lot of people are technical enough to have git forced upon them, but not technical enough not to make the same mistakes repeatedly. and i think the reasons git is forced upon them are pretty valid, but they’re in an awful situation and i don’t know what to offer them. “you are not geeky enough, you do not deserve collaborative change tracking”? to me, any system i use, i will want to know if i am checking in .DS_Store or temporary files, but if you aren’t opinionated about which changes you’re sharing then it’s gonna be hard to benefit from any revision software?
fwiw, git is the ur blockchain app, i don’t know why no one ever says that
Just use a Git gui client ffs! It’s so simple that way rather than learning new commands. Git btw is already is simple enuf given enuf usage.
Yeah! Skool iz 4 losers anyway.
For real though. A GUI makes the everyday git tasks so much clearer. And for more complex things you can still always jump into a command shell. I hate those tutorials that try to teach git, buy just saying to stage and commit all changes. Instead of using a GUI and clearly and easily seeing what files and lines you actually want to commit.
Hi,
after seeing that there are so many Git GUIs, which would you recommend?
… for Linux?
Git submodules is finally fixed after 10 years!
I’m a big fan of the tutorials by Bart Busschots and Allison Sheridan. They cover git in their Programming by Stealth series starting at episode 101. https://pbs.bartificer.net/
I really don’t understand the people that say that git is incredibly complex to use… I mean yeah, maybe it’s not super easy. But it’s usually used to work with code. And at least for me the complexity of that code is magnitudes higher than git. Also just use a GUI, and the everyday tasks become much clearer.