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?
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.
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.
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.
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.
- 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.
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.
* 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.
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.
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
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?
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.
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!
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.
Having said that, a couple of alternatives that are more modern and less complicated (by design that is, not necesseralily implementation):
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
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.
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
- https://guides.github.com/introduction/flow/
- https://guides.github.com/activities/hello-world/
Everything else (Mercurial, Subversion) is out of date.
- 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.
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
Git isn't magical. Everything you will need to learn it is already at your fingertips.
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.
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).
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.
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/
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.
Leaving this here for reference.
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.
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/
Wish #2 would probably be to go back in time and get rid of the staging area.
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.
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.
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.
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.
I hate to be the one to break it to you, but you haven't fiddled with git enough times.
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.
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.
