
Ask HN: Git alternatives that aren't so complicated? - forgotmypw17
For the last three years, I&#x27;ve been developing my project strictly on master.<p>And the reason for this is that every time I try branching, within hours or days, something is screwed up, and I don&#x27;t know how to fix it, and I end up having to reset and redo a bunch of code, if I didn&#x27;t back it up.<p>This just happened again, even though someone else was holding my hand through the process.<p>At this point, I think I have tried at least 3 times, my minimum for trying something new, and I&#x27;m ready to give up on git and try something new, even if it costs me days of learning a new system.<p>Is there anything you would suggest to someone like me?
======
robertakarobin
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.

~~~
jjav
> 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.

~~~
robertakarobin
Personally, I don't ever really find myself needing to back up a tree, or find
myself encountering something unexpected (outside of the code itself). In my
experience Git is extremely reliable... but only if you enter its weird
commands with no typos whatsoever. Hence: this enormous dotfile I maintain
that is half Git shortcuts:
[https://github.com/RobertAKARobin/dotfiles/blob/master/.bash...](https://github.com/RobertAKARobin/dotfiles/blob/master/.bash_profile_helpers#L108)

It makes me think of an old car that only the owner can drive, because it'll
break down for anyone who hasn't memorized all its quirks (e.g. my own bumper-
sticker-covered, manual-transmission 1996 Toyota Corolla, fondly named
Sharon).

Again, though, I have the same relationship with virtually all frameworks,
tools, and languages (looking at you, Bash).

------
njhaveri
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.

~~~
mic47
> 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.

~~~
majewsky
Disagree. I learned Git after working with SVN for years. Knowing SVN put me
at no advantage whatsoever. If anything, I had to actively get SVN habits out
of my brain to make the most out of Git (e.g. SVN trains you to avoid branches
because their merging is a hot mess, but in Git, branches are everywhere).

~~~
mic47
But you were able to be productive on those projects with git, even if you
didn't use it optimally, or to full extend, right?

~~~
majewsky
Sure, but that's moving the goalposts so much that you're invalidating your
entire premise.

------
ThrowawayR2
Try Mercurial: [https://www.mercurial-scm.org/](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.

~~~
cmehdy
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...](https://insights.stackoverflow.com/survey/2018/#work-_-version-
control)

------
factorialboy
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.

------
dasil003
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.

------
Nicksil
Fossil: [https://fossil-scm.org/home/doc/trunk/www/index.wiki](https://fossil-
scm.org/home/doc/trunk/www/index.wiki)

Mercurial: [https://www.mercurial-scm.org/](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.

------
zbuf
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.

~~~
clarry
> it's like leaving a parked car in gear

What, you want my car to roll off?

~~~
tomjen3
If you leave a manual car in gear and forget it when you start it, it will
jump forward about a foot or two and then the engine will stall.

I always put mine in neutral, then pull the handbrake (unless dead of winter),
that way it can be turned on with no issues.

I suspect that is what gp meant, but it may not work the same way on
automatics.

~~~
clarry
Leave it in gear, that keeps it from rolling off if handbrake fails.

Always depress the clutch when you start. Even if you're in neutral,
depressing the clutch reduces the load on the starter motor because it doesn't
have to get all the mass of the transmission spinning. (This can also make the
difference between starting or not if you're in cold or the battery is
otherwise not doing great)

There are times when it's best not to use the handbrake at all.. (let me tell
you how I found out: mine is currently seized and I need to get towed, sigh)

------
ozim
Have you tried to use some git gui: [https://git-
scm.com/downloads/guis/](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.

------
williamdclt
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

------
auslegung
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...](https://georgestocker.com/2020/03/04/please-stop-recommending-
git-flow/)).

~~~
qznc
It has a domain, so its legit :)

[https://trunkbaseddevelopment.com/](https://trunkbaseddevelopment.com/)

------
voodootrucker
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](https://youtu.be/1Iijw4xR6lk)

------
__palo_alto__
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?

------
g_b
This interactive tutorial should be very useful:
[https://learngitbranching.js.org/](https://learngitbranching.js.org/)

~~~
throw_away
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.

------
chvid
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.

~~~
forgotmypw17
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.

~~~
platz
Use gitk for visualization

------
fierarul
Try Mercurial [https://www.mercurial-scm.org](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!

~~~
anotherevan
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/](https://tortoisehg.bitbucket.io/)

------
itake
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.

------
eterps
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](http://darcs.net)

\- [https://pijul.org](https://pijul.org)

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

~~~
nieve
Is Pijul still corrupting repositories? Not many months ago the answer on here
from devs was that despite the confident assertions about its advantages it's
not actually ready for production and it was your problem if it lost code. I
was very interested in Pijul until that popped up, but as I said at the time
the first duty of an SCM is not losing your code. I really hope this changes
in the not too distant future since I'm fond of Darcs.

~~~
9214
This is an interesting and important thing you pointed out, thanks for
sharing. Unfortunately I cannot answer your question since I'm on the edge of
trying Pijul myself, and only briefly read about the patch-based model that it
uses.

------
ggregoire
I always recommend this article to new developers:

Learn git concepts, not commands

[https://dev.to/unseenwizzard/learn-git-concepts-not-
commands...](https://dev.to/unseenwizzard/learn-git-concepts-not-
commands-4gjc)

> Making changes

> Branching

> Merging

> Rebasing

> Resolving conflicts

> Updating the Dev Environment with remote changes

> Cherry-picking

> Rewriting history

> Reading history

------
valid_username
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.

~~~
forgotmypw17
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.

~~~
tomjen3
Git pull is just git fetch+merge

If you are confused at all use them in two steps, that also gives you more
options such as (what I think you need in this case) merge remote master into
your local branch (git merge origin/master).

Also I don't think you actually lost any code, if you do a checkout of the
branch you did your work on, I think it should still be there based on your
description.

Also git only pushes the current branch because it is designed to be used more
decentralized than it often is: git does not assume you are ready (or want to)
share all your branches right now.

------
jameshush
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.

~~~
garrybelka
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

------
thiht
It sounds like you never learned Git and are somehow expecting to be able to
use it. You can't. Just take 2 hours to learn the basics of Git. You can do
almost everything with a basic understanding of the graph and a few commands.

------
SanderSantema
At least trying three times seems like a very good thing to me. Although you
might want to try a fourth time, Git really isn't that hard I think but rather
quite opaque and easier when understood.

What made me understand is this picture:
[https://miro.medium.com/max/962/0*psCSE-
BxW3zn4Ya1.png](https://miro.medium.com/max/962/0*psCSE-BxW3zn4Ya1.png) and
the gittutorial manpage which is also available online: [https://git-
scm.com/docs/gittutorial](https://git-scm.com/docs/gittutorial)

------
maxmalysh
I recommend trying one more time with a simple branching model, e.g. Github
Flow:

\-
[https://guides.github.com/introduction/flow/](https://guides.github.com/introduction/flow/)

\- [https://guides.github.com/activities/hello-
world/](https://guides.github.com/activities/hello-world/)

\- [https://try.github.io](https://try.github.io)

Everything else (Mercurial, Subversion) is out of date.

------
garrybelka
Some options:

\- Read a book or tutorials about reimplementing git. That will make clear its
data model and how it works.

\- Use libgit2 to extract some data from a git repository. As a side effect,
you will become a git expert.

\- Think what would you like as your source control flow. Use libgit2 or its
binding in your favorite language to implement it.

\- Adapt git flow or a similar predefined control flow.

\- Try Fossil SCM (by the author of SQLite). Not recommended - you will need
git in your career.

~~~
auslegung
I don't think recommending git flow is correct here.
[https://georgestocker.com/2020/03/04/please-stop-
recommendin...](https://georgestocker.com/2020/03/04/please-stop-recommending-
git-flow/).

~~~
garrybelka
I do not use git flow. Only mentioned it here as a lesser evil than getting
rid of git at all. Any reasonable predefined flow will do.

Besides, in my experience, a review system such as Gerrit or GitHub has a huge
impact on whatever flow is convenient to use.

------
bob1029
I think a lot of the pain in git boils down to code structure and how merge
conflicts conflate any bad decisions made there. If your codebase is well-
structured, I.e. each logical unit of business functionality is in an
independent source file or method, then disparate work branches should not
create much trouble, even if they are wildly out of sync relative to current
master. Git will transparently create merge commits if you do not explicitly
rebase (and there are no conflicts).

Many times you have to explicitly sit down and spend a few days/weeks
determining if you need higher-order abstractions which enable granularity in
the code. For instance, we've developed abstractions such as
View/Workflow/Context/Step which contain logical groupings/subsets of business
logic and which are easily reasoned with in isolation (i.e. allowing many
concurrent work branches). These were explicitly developed so that the
software engineering process could function effectively.

Another potential pain point would be trying to do too much work on 1 branch
or letting it become perpetual. Ideally, your work branches are a daily/weekly
lifecycle before being merged back down to master. You should probably not try
to maintain more than 1 permanent master branch unless you can confidently
justify reasons for having another.

One good thing to practice would be to rebase any outstanding work branches
against master after merging any work. (git checkout master && git pull && git
checkout <work branch> && git rebase master). The more frequently you do this,
the less likely you will wind up with a nasty merge conflict situation. This
also allows you to re-test your work in terms of what would actually happen
after a merge to master prior to making the merge. This makes it possible to
develop effective check build safeguards in products like GitHub Actions.

------
rags2riches
Learn git properly instead. It can be done. Sit down and start reading all the
`git help` pages. As you read, clone a repo and try things out until you
understand them. Experiment, read, experiment some more. Set a goal, like "I
will make a branch, commit some changes, then merge them back". Try to predict
what will happen before you run a command. Try to get back to where you were
before. Try to achieve something in more than one way. Write an explanation
for what just happened, then verify by repetition and more experiments that
your explanation holds up. Find somebody to ask when you really can't figure
out what is going on. But don't just get a solution in the form of strange
commands, keep at it until you can reproduce the problem and the solution
yourself.

Git isn't magical. Everything you will need to learn it is already at your
fingertips.

------
callahad
If you decide to give Git one more shot, you might enjoy John Wiegley's _Git
from the Bottom Up_ ([https://jwiegley.github.io/git-from-the-bottom-
up/](https://jwiegley.github.io/git-from-the-bottom-up/)). It didn't teach me
how to _use_ Git, but it did teach me how Git _works,_ and _that_ was key to
solidifying my own knowledge.

As others have mentioned, the version control space has been effectively
monopolized by Git. Mercurial offers roughly the same data model with a better
interface, but you're still fighting an uphill battle with limited tooling
support, etc. Fossil is notable for being the SCM used to develop SQLite, but
again, it's relatively unknown outside of that space.

------
the-peter
I agree that git is a nightmare with a user-hostile interface. Keep backups
outside of git and just bite the bullet and learn it. There is no middle-
ground, you are either floundering in a storm or master of git but it's
everywhere so you have to get through the learning curve. If you are using the
command line I recommend 'easygit' (eg)
([https://people.gnome.org/~newren/eg/](https://people.gnome.org/~newren/eg/))
or 'gitless' (gl) as far saner interfaces that don't hide git from you but
make the interface simpler and more consistent.

------
leokennis
I just want to sympathize with you. I’m part of a large-ish team, and some of
our most senior developers are still just using the most basic of GIT
functionality (basically, creating a branch and merging it back to master)
because if you go more advanced it’s so easy to fuck up.

For me, GIT fluency is not related to your technical skills. If you’re bad at
GIT it says nothing about the quality of your work.

Basically you need to understand the concept of GIT (not easy but not
impossible either) and then also learn to map that concept onto the
terminology used (rebase, blame, stash etc...it’s a lot).

------
david_draco
Maybe look at [https://gitless.com/](https://gitless.com/) . It provides a
simpler interface and workflow, but you can go back to full git anytime.

------
uniqueid
It's honestly hilarious how obsessed this industry is with Git. It verges on a
fetish. Like writing code is an evil you need to endure so you can experience
the high of using version control.

~~~
m4r35n357
Before Git, branching and merging was a nightmare. People are using git to do
much more complicated things than in the days of CVS/SVN.

~~~
uniqueid
True enough. It's not the ubiquity of git that is laughable, nor developers
using vcs. It's _this_ sort of thing:
[https://news.ycombinator.com/item?id=7894288](https://news.ycombinator.com/item?id=7894288)

------
el_dev_hell
I was in your exact shoes. Like multiple others have said, Git is everywhere
and you could be hurting your career by avoiding it.

I bought a physical book (Pro Git, which is also open source: [https://git-
scm.com/book/en/v2](https://git-scm.com/book/en/v2)) and read it cover-to-
cover. I found chapter 3 (branching) to be the best ROI from the reading.

If you start working professionally with Git everyday, it does eventually
"click" and make sense in my experience.

------
juancn
Git is not really that complex, it is conceptually really simple. Most of the
issues at the beginning have to do with an incorrect mental model of how it
works.

It's almost impossible to lose something you committed in git by screwing up
(due to reflogs).

I would recommend studying "Git from the bottom up" which for me was the way
to finally grasp it: [http://jwiegley.github.io/git-from-the-bottom-
up/](http://jwiegley.github.io/git-from-the-bottom-up/)

------
clarry
> something is screwed up, and I don't know how to fix it, and I end up having
> to reset and redo a bunch of code, if I didn't back it up.

You need to figure out what is screwed up (and how it came to be so) and how
to fix it. You shouldn't ever need to reset and rewrite code.

Why did the person who did the hand-holding not tell you what you did wrong
and how to fix it? But either way, if you can't get help from them and can't
figure it out yourself, it's ok to ask the internet for help.

------
Hamuko
[https://github.com/k88hudson/git-flight-
rules](https://github.com/k88hudson/git-flight-rules)

Leaving this here for reference.

------
roywiggins
Mercurial is supposed to be more ergonomic to use, but it's not less powerful
than Git, so you can probably get yourself into a screwed up situation with
Mercurial, too.

------
daniel-levin
I'm going to answer the question, rather than tell OP they should just use
git.

It might be worthwhile to check out Perforce [1]. Downsides: proprietary,
expensive. Upside: you can version all sorts of content at a high level, not
just software. I know of a large embedded shop that swears by Perforce.

[1] [https://www.perforce.com/solutions/version-
control](https://www.perforce.com/solutions/version-control)

~~~
zbuf
I did consider that in my reply. But then the poster is really getting to
grips with branching, and so I didn't feel the tool was the weakness here.

However, it's worth considering if subversion is actually what you need (I
haven't used Perforce but I have heard its underlying structure is
conceptually similar?) I saw sysadmins struggling with Git when all they
needed was to enforce good use of a single branch, and central repository and
some history. They felt they should be using Git, and in doing so threw away a
tool that was already a good match to their workflow.

------
thaumaturgy
Git can be as simple or as complicated as you make it. A lot of people make it
more complicated than it needs to be, usually because they're trying to follow
patterns that don't need to be applied to the project they're working on.

I was able to get a small team who were uncomfortable with git and had weekly
tangled messes in their repositories to start using it problem-free pretty
quickly. It was just a matter of using a simpler branching system and clearing
up a few misconceptions.

So my suggestion would be to write up a post, here or on a blog or something,
describing exactly what went wrong, and ask for help. But git right now is the
de facto tool for software version control pretty much everywhere; I think
you'll be hurting yourself by avoiding it.

Two books that might help:

Pro Git, [https://git-scm.com/book/en/v2](https://git-scm.com/book/en/v2),
available for free download.

Git For Teams: [https://www.oreilly.com/library/view/git-for-
teams/978149191...](https://www.oreilly.com/library/view/git-for-
teams/9781491911204/)

Other reading:

Patterns for managing source code branches:
[https://martinfowler.com/articles/branching-
patterns.html](https://martinfowler.com/articles/branching-patterns.html)

Oh shit, git! [https://ohshitgit.com/](https://ohshitgit.com/)

The guts of git:
[https://lwn.net/Articles/131657/](https://lwn.net/Articles/131657/) (some
common errors are caused by misunderstanding how git works behind the scenes)

Merging vs. Rebasing: [https://www.atlassian.com/git/tutorials/merging-vs-
rebasing](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)

A simple git branching model:
[https://gist.github.com/jbenet/ee6c9ac48068889b0912](https://gist.github.com/jbenet/ee6c9ac48068889b0912)
(2013, still relevant)

And better client software might help too:

Fork (Mac and Windows): [https://fork.dev/](https://fork.dev/)

GitKraken (Mac, Windows, Linux):
[https://www.gitkraken.com/](https://www.gitkraken.com/)

------
ufo
If I ever came across a magic lamp, one of my 3 wishes would be to replace all
references to "git checkout" on the internet by "git switch" or "git restore",
as appropriate.

Wish #2 would probably be to go back in time and get rid of the staging area.

------
ufo
One thing that can help is using a GUI tool to view the commit history. My
favorite is gitg.

For cleaning up mistakes it might be helpful to look at `git rebase -i`. It
lets you delete or reorder commits, as well as move a branch to a different
starting point.

------
majkinetor
SVN is infinitelly easier, and more understandable by juniors. Its also well
known and supported by huge number of tools and virtually any OS - even GitHub
supports git via svn clients.

It is central only, has sequential revision numbers, you don't need to pull
others code if you work on some stuff that is unrelated to them, it can grab
any part of repository (a folder or file), supports metadata on anything (key
value store), can contain subrepositories (like git submodules) etc.

I always use it when I work with non technical people. That was mostly on
larger static sites where SVN makes collaboration part easy.

On Windows, you can install Visual SVN Server in a matter of seconds (most of
features are free) and it has nice Web UI, AD integration, PowerShell
management and other nice stuff... TortoiseSVN has idential interface as that
of git and also allows you to have private server by just creating a local
folder.

------
wayneftw
Just use the git commands in VS Code and you can't go wrong.

Before VS Code when I was on Windows, I used TortoiseGit.

Seriously, I haven't had to use the Git CLI to do anything other than `git
init` for like over a decade that I've been using Git.

------
jimbob45
TortoiseGit can make your life much easier if you haven’t yet found it.

~~~
olvy0
I'll second that, TortoiseGit has been a lifesaver, especially its git log
display, which is very details and lots of actions can be done directly using
it by right clicking on commits.

I'm a visual person, with a horrible short term memory, and I never got along
with the git command line, or with any other command line tool. When I need
something slightly more complicated I google it.

------
chmaynard
I'd suggest that you block out some time to really learn how Git works. There
are many resources available but the Git Pro book is arguably the best.
Tutorials are very useful, too.

------
olvy0
I hear you. I was exactly the same. I still am, in a way, ironically I'm
considered the local "git guru" at work, and I regularly save people when
they're stuck.

My main pain point is that all the tutorials etc seem obsessed with the
command line.

Being a visual person myself, with a horrible short-term memory, I've never
been comfortable with the command line tools, I've always preferred GUIs.

The problem is that all tutorials mix up two different things: git's concepts,
which is fine, with the command line syntax, which for me, personally, was
confusing and inconsistent, especially if you don't know it yet. With the
command line I feel like I'm groping blindly in the dark (reinforced by the
dark background, I guess). From my point of view, all git tutorials, and
almost all git answers in SO, are written by a bunch of borderline autistic
and slightly sadistic people (so, programmers...), who seem hell bent on
shaming me for being a visual person and not remembering arcane command line
invocations. :-) I admit that for a very long time I felt ashamed of myself,
like I was not "man enough" for not remembering and mastering the command
line. But this implicit shaming has to stop. There's nothing wrong in having
lousy short term memory, and being a visual person. I'm still able to ship
software, solve many bugs, and run a team.

I've tried different GUI tools, but Tortoise Git was what I use day to day,
it's great, I keep its log view open all day and refresh it before, during and
after each git action that I do, to make sure everything is fine.

If you're like me, I suggest you install it and try doing some tutorials using
only it, dropping to the command line only as a last resort. This may help you
even as a temporary crutch if you really want to actually learn / memorize the
command line syntax. Looking at the visual advance of history, I understood
the relationship between remote and local branches, merging, rebasing, I could
see that rebasing leaves the original commits and what it does exactly, etc.
Like I said in another comment here, many actions could also be done directly
from this view.

My "secret weapon" when I'm helping my team grapple with git problems is
opening Tortoise Git log view, pointing at the graph there and saying "ok, we
are here, but we want this to be here and that to be here and all these blue
lines to go away, so how would YOU do that?" and thus lead them to the answer.

It's not perfect and it has bugs, but for me, personally, it was the thing
that made like git just a bit better.

------
atirip
If you are using Mac, Use
[Gitbox]([http://gitboxapp.com/](http://gitboxapp.com/)), it is a godsend.

------
Lordarminius
> At this point, I think I have tried at least 3 times...

I hate to be the one to break it to you, but you haven't fiddled with git
enough times.

------
stakkur
As someone who's used some form of version control for a long time (PVCS,
SourceSafe, and several things during and after), I'd say these are the salad
days, man. It's easier than it's ever been to do version control. And to me,
Git's one of the 'easiest' I've ever used.

------
daleholborow
Gitflow plus a copy of smartgit will go a long way

------
modzu
use github/gitlab (you mentioned not having backups? git _is_ your backup).
there really is no substitute to git, but there are supporting tools that can
make life easier: a good ide like intellij, github desktop, to name a couple.
dedicate some time to learning it well (hopefully there are some good learning
resources posted in the thread) and once you get over the hump it will start
to pay dividends

------
IshKebab
Have you tried using a GUI? It makes things _much_ more obvious. Trying to
learn Git from the command line is like trying to learn image editing using
ImageMagick, or CAD with OpenSCAD. CLIs are great in their place but sometimes
it is easier to grasp something with pictures.

Once you have figured out what is going on you can go back to the CLI.

I don't think you will find anything "simpler" than Git, because apart from
the terrible terrible CLI, it doesn't really add any complexity on top of the
fundamental complexity of this style of version control.

------
iliaznk
Git is not complicated. Version control is. If you sit and think hard enough
about what you'd want a VCS to do, you'll come up with about the same set of
features, I believe. And then think about how you'd implement those in an
abstract CLI tool. So, as I said, it's the process that's complicated and that
complexity can't be hidden behind just one simple button (or one CLI command).

I couldn't wrap my head around git for a while when I started. Some time later
I decided to write a procedure for our branching flow at work. I wanted it to
cover all the common cases like: checking out a branch, squashing and
rebasing, undoing things, amending commits, etc. All of which I knew was
possible with Git, but I didn't feel comfortable with most of those operations
and had to go to Google almost every time. So in order to put that all down in
simple steps with some short explanatory comments I, obviously, was supposed
to very clearly understand all of those cases myself to be ready to answer
some questions and moreover to be sure that each step is a correct way to do
git and it wouldn't cause any permanent damage to anybody's repo. To get that
understanding I created a few nested directories with some really small text
files in them and used those to actually run and inspect consequences of
various git commands which took me, maybe, about two hours maximum. I've never
had a single problem with git ever since.

~~~
iliaznk
P.S. reflog is your best friend

