Ask HN: Git alternatives that aren't so complicated?
For the last three years, I've been developing my project strictly on master.
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?
88 comments
[ 9.3 ms ] story [ 282 ms ] thread- 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.
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.
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...
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
- 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.
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.
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.
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'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.
Leaving this here for reference.
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
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.
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?
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.
Git isn't magical. Everything you will need to learn it is already at your fingertips.
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.
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.
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).
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.
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.
- 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
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.
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.
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.
- 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.
Besides, in my experience, a review system such as Gerrit or GitHub has a huge impact on whatever flow is convenient to use.
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
https://trunkbaseddevelopment.com/
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.