Ask HN: Git alternatives that aren't so complicated?

As another commenter said, Git is so pervasive that learning something else would put you at a big disadvantage.

That doesn't excuse Git having an unintuitive UI that makes it very difficult to learn. It has that in common Vim, Emacs, the command line itself... and programming in general. What they also have in common is that once you get used to them they're wonderful tools.

If you don't practice using branches, resetting, rebasing, etc., you're not going to get good with them. Create a dummy repo and practice. There's no "easy button."

I was terrified of Git when I started using it. All the time, I would call in senior colleagues to resolve Git issues that went over my head.

Nowadays, I use Git for coding as well as writing, vector graphics, datasets, and anything else that isn't stored in binary. The time it took to get here was well worth it.

> That doesn't excuse Git having an unintuitive UI that makes it very difficult to learn. It has that in common Vim, Emacs, the command line itself... and programming in general. What they also have in common is that once you get used to them they're wonderful tools

I can't agree with that. Emacs, UNIX CLI etc are indeed powerful tools with a steep learning curve but they are wonderful once learned.

Git? Not so much. Git is not any better than mercurial (to OP: I recommend mercurial) but git is extremely user hostile to an extreme I can't think of any other popular tool ever.

Over the decades I've probably used every well-known source control system (and a handful less famous ones) and git is the only one where if I need to do anything out of the ordinary I will always backup the whole tree first because it's 50/50 odds git will go into some inexplicable and unrecoverable state and the code is lost. I've never had that happen with any other source control tool. Kinda defeats the point of source control.

I do agree with everyone saying git is a plague we must face so do learn it. I suggest doing so at work where they pay you to do unfun things, that's why they call it a job.

For personal/pleasure project I want to enjoy quality tools that are well designed, pleasant to use and don't fight against me - so I use mercurial.

Git is so pervasive in software development that I think you will be at a disadvantage if you give up on it.

This is the sort of situation where I would recommend taking a step back, finding a good book that covers the topic, and read it cover to cover. At least for me, taking time outs like this to learn something in an academic manner has paid big dividends over the years.

> Git is so pervasive in software development that I think you will be at a disadvantage if you give up on it.

I would call BS on this. Yes, git is pervarsive, but if you learn alternative tool (mercurial, perforce, even svn), you will find that learning git (at least for being productive on team that uses git) is straightforward.

Also, haven't seen a company that actually tried during interviews ti figure out if you know how to use git or not.

I agree with this first paragraph. But disagree with the second. Depends on what kind of learning style you have but I don't think a book is the best format for learning git (or most programming concepts for that matter). You probably already understand most concepts of git already anyway, but the devil is in the details and it sounds like that's where you're getting stuck. If you're a book person for technical things, though, then go for it.

I'd suggest that anytime you go into a situation where you're not sure if you'll mess something up, just make a full copy of your project on your local file system. Then try stuff out on the copy. Then you can try branching and such without the fear of messing anything up. Once you get it, you can repeat the process over and over to make sure you know it. You have to be able to fail without fear of wasting days of your time.

I have to agree with this. It's an essential skill. There are great courses on LinkedIn and Coursera for free (even if you don't get the respective subscriptions).

Try Mercurial: https://www.mercurial-scm.org/ Much saner behavior than git, IMO. Last I heard, it is being actively maintained and Facebook still uses it for their source control.

Something else that might help out is one of the GUI git clients like SourceTree, GitKraken, etc. to help you visualize the state of your git repository.

Mercurial definitely is easier and prevents a lot of dangerous behaviour, but it's also unfortunately not quite supported enough to do much CI (unless you also want to maintain your own Jenkins setup) and isn't supported by some IDEs (looking at you, Xcode). The 2018 StackOverflow survey[0] regarding Version Control also shows how Mercurial fares, even against zip files (!!).

It shouldn't prevent anyone from learning it or using it, but it's important to keep those things in mind when considering any kind of work with existing companies (or on the flip-side, any recruitment of staff when creating a company).

[0] https://insights.stackoverflow.com/survey/2018/#work-_-versi...

I would highly recommend learning git to a deep level as it confers a huge force-amplifying power for both day-to-day development as well as the long-term maintainability of a well-constructed commit history.

The CLI is definitely obtuse, but the underlying data model is quite simple and elegant. Once you grok the primitives you can learn the idiosyncrasies of the CLI at your own pace, secure with knowing that you always have reflog and cherry-pick as a safety net. My recommendation is to use a client like Sourcetree to visualize branches/commits as you learn new operations.

Having come up in the CVS, and then Subversion eras, I acutely remember in 5 years of using Subversion that I never truly understood the underlying data model (a branch is a tag is a directory!?) as well as I understood git after 3 months. It's a very very good data model.

Mercurial is arguably equivalent with a better CLI. I won't argue the comparison here, but given the mindshare git has it seems like you'd be losing a lot by constraining yourself to a different version control system. I promise git is extremely usable once the primitives click in your brain, and likely to outlive most of your other dev tools like editors, languages, other toolchains, etc.

Let's be pragmatic about this.

- For single person projects, committing directly to "master" / main branch alone is fine. Releases can be tagged.

- Multiple branches are recommended if you need a complex workflow. But they aren't mandatory for using Git.

If Git works for you the way you use it, go ahead with it.

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

Mercurial: https://www.mercurial-scm.org/

There are other tools, as well. Search for SCM (software configuration management). Research and try them out.

If a tool isn't helping, look for an alternative. Git is such a tool that does some things well. But it isn't for everybody and everything.

I became my company's go-to person when it came to other developers (or devlops) struggling with Git. In getting people more comfortable, I found there were two very dominant difficulties/wins for the situation you describe:

* Are you using gitk viewer?. Specifically "gitk --all". Open it, leave it open, and refresh it after running any Git command to see what you did. Stick with gitk too, don't be tempted to reach for a viewer in your favourite toolkit/webapp implementation just yet. A long time ago, too many GUI were either focused on single branch, or did not render the whole branching/merging adequately. I'm sure that's changed, but gitk is part of git, and experience with it will mean you're in a position to evaluate alternatives later.

* Erase all knowledge of "git pull" from your brain. Basically a "fetch+merge" in one step, it's like leaving a parked car in gear, but with more mess when you get it wrong. Replace it with "git fetch", followed by inspecting in gitk, and deciding if a "git merge" is what you want.

With both of these I found developers were often more developed in their understanding than they thought they were; they just needed a 'leg up'. With these their confidence and understanding improved dramatically.

> it's like leaving a parked car in gear

What, you want my car to roll off?

Wooah. Thank you for writing this. I know it's simple but these were really helpful tips for someone in the same position as the OP

Have you tried to use some git gui: https://git-scm.com/downloads/guis/

No one is making you to stick to "one true way of command line". For me it is a lot easier to grasp branching when I have good gui. I don't really need a gui anymore but for starting out I definitely recommend one.

Just another POV being pretty good with Git, not bringing anything new compared to other answers but adding weight:

You're absolutely right that Git is terrible in terms of UX, and there's zero shame in messing stuff up like you did, it's standard. I think it's because Git contributors are such good Git users that they're blind to how bad it is for newcomers/intermediate users, and also they're not particularly interested in UX. But it's all free and open-source, let's be thankful it even exists.

> Is there anything you would suggest to someone like me?

No. I'm afraid that despite its bad UX it's the best out there (subjective, I don't even actually know other VCS very well). In addition, Git is so prevalent that not knowing it will be massive problem for you, career-wise or in your interaction with the open-source communities

Honestly, it hurts me to tell you that but I think your best option is to suck it up and learn it. Use GUIs (git tower, sourcetree, gitkraken...) if that helps

The key is to understand the underlying data structure is a directed acyclic graph, to install a tool that lets you visualize that graph, and to practice commands and predict results until you can prove your mental model matches reality. If you can make it through this video and do the same command line exercises, you will have a pretty firm understanding. https://youtu.be/1Iijw4xR6lk

I would say you're already using git correctly. What you're doing is called "trunk-based development" (TBD). I recommend doing a little bit of research on it since it's what you seem to want to do anyway. Fully embracing TBD will be WAY easier than learning and using git-flow (https://georgestocker.com/2020/03/04/please-stop-recommendin...).

It has a domain, so its legit :)

https://trunkbaseddevelopment.com/

If the git CLI is difficult, there are some good GUI git clients like Sourcetree and Git Tower that I would recommend. I still use Sourcetree pretty regularly if I'm working on a larger project and want to get a better picture of everything.

However, as others have said, I would recommend giving git a fourth try. It really is the standard tool in source control.

Somewhat related idea: I feel similarly about vim/emacs. Most senior developers in my company work in vim/emacs, and while I can definitely use either, I am MUCH more productive in something like VSCode. Will this hurt me in the long run? Is it worth the temporary reduction in productivity to make vim my primary editor?

This interactive tutorial should be very useful: https://learngitbranching.js.org/

I agree. It wasn't until I went through this visualization that I actually 'got' git. I liken it to trying to navigate a filesystem without first understanding the metaphor of a hierarchical folder structure. Without understanding the fs in almost spatial terms (up and down the tree, adjacent directories, etc), the output of ls and friends would be nonsensical.

Likewise with git. Until you understand that you are crafting, navigating and reconciling immutable nodes in a structured history of directory contents, no amount of git man pages will help you.

There used to be something called subversion ...

Git has massive usability problems and a culture of overly complex workflows.

However if you stick to trunk based development (aka just work in master and only branch out if you really have to) and use some of the many support tools (github, visual code), then you should be alright.

The only reason I've been able to use Git in the first place is because of visual tools in IntelliJ.

But although it supports branching, the UI is indecipherable to me, and I used console for that.

Try Mercurial https://www.mercurial-scm.org

Commands make sense there!

Git honestly feels like a low level library that no human should use. It's a very performant 'framework' that better tools could be built on. Using it directly is like getting used to assembler.

The git monoculture is rather sad and I don't know if something else will come up to free tech from Git.

I hope that a Semantic VCS will come next, but I worry it will be implemented on top of Git too!

And I would recommend the TortoiseHg GUI client when you need to see or do something visually. I find I use the GUI and the command line about 50/50.

https://tortoisehg.bitbucket.io/

Git being the low level layer was the idea initially. People tried to create user friendly layers on top. I believe they were called "porcelain" in contrast to "plumbing". That never became popular for the command line.

I'd try go understand how git works better than you do. I have been using git for 10+ years. Maybe my first couple years, I would get git in a confusing state, but that never ever happens any more.

If you stick with the basics (Level 1), never commit to master:

$ git add

$ git commit

$ git checkout -b

$ git pull origin master -r

Then trust your webtool to handle merges (github/gitlab), then its really hard to mess things up.

level 2 would be understanding how to handle merge or rebase conflicts.

Level 3 would be understanding how to use the `git reflog` cmd.

Git is immensely popular, so using an alternative probably isn't worthwhile in the end.

Having said that, a couple of alternatives that are more modern and less complicated (by design that is, not necesseralily implementation):

- http://darcs.net

- https://pijul.org

Pijul's theory of patches is very appealing, conceptually. IIRC both Pijul and Darcs are implemented in Rust by the same author.

I always recommend this article to new developers:

Learn git concepts, not commands

https://dev.to/unseenwizzard/learn-git-concepts-not-commands...

> Making changes

> Branching

> Merging

> Rebasing

> Resolving conflicts

> Updating the Dev Environment with remote changes

> Cherry-picking

> Rewriting history

> Reading history

May be if you can give some examples of screw up you had, we can understand the exact problem and provide some help. My advice would be to understand how git works under the hood, after that you will be easily able to visualize git commands in you head and execute them with confidence.

Here's the screwup I experienced, as I understand it:

I started a new branch and developed on it.

I realized that my installs were no longer updating when I did a git pull, because I was no longer committing to master.

So I did a git checkout on the installs, and all was good.

Then, I wanted to merge the branch into master, so I did.

Then I did a "git push".

This is where things got screwed up, I think, because I did not know that, apparently, git does not push the whole tree in this case, only the currently selected branch. (wtf?)

After this, I looked at my local code, and some of my recent changes were gone, because it had either reverted to ... some older fucking version.

And that's when I posted this thread.

I've worked on 10+ person teams over the past 5 years, on 10+ year old codebases with hundreds of thousands of lines. About 8-10 total years of software engineering experience in general. The best flow I've found, and the one my team uses now is:

1. Make a branch from master called `yourName/featureName` 2. Work on the feature for a day or two max 3. Merge it right to master

CI/CD runs all the tests, builds it, deploys it to stage. All the other engineers and product people can see exactly what master looks like at any given time. On our newer projects we skip the stage step entirely and just deploy straight to prod. Yes, no stage, right to prod. These are sites that get millions of hits a day.

This makes it so:

1. Engineers stop making big scary PRs REAL QUICK. Engineers always feature flag everything, de-risking changes drastically. There's something about the psychology of knowing your code is going straight to stage or prod that instantly causes people to make smaller changes. It's great.

2. I'm the best person at git on the team (probably because I set up all the CI/CD stuff), and I feel like I pretty much know nothing. I've watched like, half of an advance git tutorial on Frontend Masters and I'm light years ahead of my 2nd most knowledge coworker. I've realized 99% of people only have a surface knowledge of git, so the simpler you can make things for everyone the better. Everyone understands how to branch from master and merge it back in. And if they don't (which is OK! Engineers I've trained with < 1 year experience sometimes struggle) I can teach them within an hour.

I've been on teams with release branches. Nobody in my experience ever really gets it right, I might have been unlucky though. Usually it ends up a a merge conflict mess merging to master and a show stopping bug when it's deployed.

I recommend watching a couple of videos on git on a Sunday afternoon to make yourself feel a bit more confident, but honestly don't sweat it too much. The KISS rule (Keep It Simple Stupid) really shines with version control on git here.

That works but:

- pushes code into a master before it is ready

- makes next to impossible to work on several tasks at a time: current state of incomplete tasks is spread all over in the master. Even working on a single multi-day task with multiple commits, it's harder to see the task changes and any slight feature refactoring during prototyping or development now involves master.

An easy modification to this flow is:

1. Make a branch from master called `yourName/featureName`

2. While feature is not ready:

2.1. Work on the feature for a day or two max

2.2. Pull master, rebase your branch from master

3. Merge it right to master when your branch is ready

88 comments