Ask HN: Git alternatives that aren't so complicated?
88 comments
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.
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.
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.
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...
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).
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).
I have no idea what you are doing, I have only ever seen git lose data when I did an interactive rebase, and those are easy enough to backup, as all you need to do is do them on a new branch.
If git is confusing, I suggest reading up on merkle trees and directed graphs - I found git understandable once I grokked its mental model. Still sometimes have to lookup the actual commands, but it is very rarely the case that I am confused by anything.
If git is confusing, I suggest reading up on merkle trees and directed graphs - I found git understandable once I grokked its mental model. Still sometimes have to lookup the actual commands, but it is very rarely the case that I am confused by anything.
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.
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 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.
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).
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'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.
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...
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.
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.
- 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.
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.
* 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?
What, you want my car to roll off?
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.
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.
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)
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)
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.
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
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/
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?
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.
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.
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.
But although it supports branching, the UI is indecipherable to me, and I used console for that.
Use gitk for visualization
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!
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/
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.
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
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.
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.
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.
https://pijul.org/manual/why_pijul.html has a few notes on why one might choose Pijul over Darcs, along with a lot of text on how it’s different from Git.
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
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 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.
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.
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.
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.
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
- 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
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.
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 and the gittutorial manpage which is also available online: https://git-scm.com/docs/gittutorial
What made me understand is this picture: 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
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/activities/hello-world/
- https://try.github.io
Everything else (Mercurial, Subversion) is out of date.
- https://guides.github.com/introduction/flow/
- https://guides.github.com/activities/hello-world/
- https://try.github.io
Everything else (Mercurial, Subversion) is out of date.
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.
- 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.
I don't think recommending git flow is correct here. https://georgestocker.com/2020/03/04/please-stop-recommendin....
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.
Besides, in my experience, a review system such as Gerrit or GitHub has a huge impact on whatever flow is convenient to use.
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.
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.
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.
Git isn't magical. Everything you will need to learn it is already at your fingertips.
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/). 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.
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.
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/) or 'gitless' (gl) as far saner interfaces that don't hide git from you but make the interface simpler and more consistent.
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).
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).
Maybe look at https://gitless.com/ . It provides a simpler interface and workflow, but you can go back to full git anytime.
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.
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.
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
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) 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.
I bought a physical book (Pro Git, which is also open source: 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.
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/
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/
> 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.
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.
https://github.com/k88hudson/git-flight-rules
Leaving this here for reference.
Leaving this here for reference.
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.
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
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
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.
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.
User would still be stuck learning git in order to contribute to almost anything or for the majority of jobs. It might make sense to learn in addition to git I'm not sure its as good an idea instead of.
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, available for free download.
Git For Teams: https://www.oreilly.com/library/view/git-for-teams/978149191...
Other reading:
Patterns for managing source code branches: https://martinfowler.com/articles/branching-patterns.html
Oh shit, git! https://ohshitgit.com/
The guts of git: 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
A simple git branching model: https://gist.github.com/jbenet/ee6c9ac48068889b0912 (2013, still relevant)
And better client software might help too:
Fork (Mac and Windows): https://fork.dev/
GitKraken (Mac, Windows, Linux): https://www.gitkraken.com/
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, available for free download.
Git For Teams: https://www.oreilly.com/library/view/git-for-teams/978149191...
Other reading:
Patterns for managing source code branches: https://martinfowler.com/articles/branching-patterns.html
Oh shit, git! https://ohshitgit.com/
The guts of git: 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
A simple git branching model: https://gist.github.com/jbenet/ee6c9ac48068889b0912 (2013, still relevant)
And better client software might help too:
Fork (Mac and Windows): https://fork.dev/
GitKraken (Mac, Windows, Linux): https://www.gitkraken.com/
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.
Wish #2 would probably be to go back in time and get rid of the staging area.
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.
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.
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.
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.
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.
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.
TortoiseGit can make your life much easier if you haven’t yet found it.
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.
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.
Just a note that TortoiseGit is Windows only.
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.
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.
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.
If you are using Mac, Use [Gitbox](http://gitboxapp.com/), it is a godsend.
> 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.
I hate to be the one to break it to you, but you haven't fiddled with git enough times.
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.
Gitflow plus a copy of smartgit will go a long way
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
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.
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.
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.
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.
P.S. reflog is your best friend
And the reason for this is that every time I try branching, within hours or days, 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.
This just happened again, even though someone else was holding my hand through the process.
At this point, I think I have tried at least 3 times, my minimum for trying something new, and I'm ready to give up on git and try something new, even if it costs me days of learning a new system.
Is there anything you would suggest to someone like me?