I started programming 7 years ago. After watching dozens of YouTube tutorials, I decided to take things more seriously and enroll in a coding bootc...
For further actions, you may consider blocking this person and/or reporting abuse
Not harsh at all, @alexsaezm! I know where you're coming from. I already had a decent understanding of Git before I moved on to Git clients, which was definitely helpful.
That said, I think a good Git client can definitely make you a better developer. With all the visual aid they provide, you can create granular commits with ease, resolve merge conflicts in a nutshell and quickly pinpoint what changed in a specific branch or period of time.
Of course, everything you do with a Git client can be done over the command line. But my repositories look much more organized and readable after I took my time to learn how to properly use the superpowers Tower gave me 🙂
Thank you for this. I've been struggling with git and, like you, have become frustrated that I'm spending time trying to figure this out when I want to be focused on more important things. I never thought to try to find an easier way. I've downloaded Git Force to try out a free option.
Thanks for reading,@angelabowen! Let me know how it goes.
Feel free to give Tower a try as well, since you can use without any limitations for 30 days.
The advice is sound, but who needs a client when vscode (you’re writing code with that, right?) has full integration with git{hub,lab} anyway?
Thanks for reading! Haha, actually I go back and forth between Sublime and VS Code depending on the task. But that's a post for another day :)
IMO, VS Code is perfectly fine for that quick commit/push where only a couple of lines were modified. I'm a fan of granular commits though, and after an entire afternoon of work I often need to review what changed. Before pushing, I launch Tower to have a look at the diffs (to decide which chunks will be staged), or if I need to perform a more complex operation like interactive rebase or a merge.
The problem I find with the CLI git command is people run commands and don't/can't understand what state they're currently in which gets them more trouble! Not a failing of git itself, just the lack of easy visibility into where they're at.
The number of times I've seen someone rebase just to merge their branch into itself is astounding :(
That's a great point @dogers. Git newbies will often type a series of commands without really knowing what's happening due to the lack of visual aid.
For those who haven't got a habit to check the state, there exists a bunch of state-exposing shell helpers like
liquidprompt,bash-git-prompt, etc.That is a strong statement, let see your arguments.
Here I completely agree, I propose this link every single time to my readers
Learn git concepts, not commands
Nico Riedmann ・ Jun 2 '19 ・ 36 min read
In fact that's also exactly the main issue with the git CLI
It adds a ton of unnecessary accidental complexity on top of learning the concepts of version control, which I do agree is the real goal. People should be learning about working in parallel (banches) and collaborating (pull requests) and so on.
Instead they have stupid errors on top of stupid errors: they made a typo in the name of the branch, or they didn't get command flag right, or the cli want them to specifiy the origin for the 24th time, or they don't have a visual clue that they were on the wrong branch or needed to pull.
Actually nobody uses just the git CLI, why do you think hard core users have super sophisticated shell git prompt and tons of git aliases? That's their own version of a better git client.
Did we forget about usability? Are developers not people?
Watch people using git with less than 1000th hours of practice and you will see how terrible the CLI is.
In fact the vast majority of projects have a small number of people who contribute to it and it's absolutely easier to work with one remote.
Again for most projects you are better off with letting the git history of the pull request showing what actually happened, instead of what actually happen. What's the point of pretending you never make mistake? The only history that count is in the main branch. Enable "Squash and merge" by default and you divide the number of fucking up and time wasted by a large amount.
you mean bisect? again YAGNI for most people
The thing is that git was invented for the Linux Kernel project which indeed work in a very weird way (bazaar style) with hundreds or thousands of developers who are really good at mastering low level details. Also they use emails for issues and pull requests, which is why git doesn't support that.
So there is indeed a huge reason why git is the way it is. But that reason probably don't apply to your projects unless you work in a bazaar style fully decentralized manner with hundred of developpers. If that's your context, git is the best tool possible for it.
For the rest of us the real question is what allows us to focus best on the task at hand.
And that's why we use GitHub instead of just git, and better (for us) git clients like for me lazygit or IntelliJ
If so, I haven't yet met a visual Git client suitable for me, my flows and manners. Standard CLI (with own aliases, of course) is still best.
And, the reason would be the same as @alexsaezm defined - all clients are limited and adjusted to a minor subset of features and scenarios, effectively dropping chance to get out of their Procrustean bed.
I disagree. Thats like telling people "The worst advice ever is to tell people that are learning how to program to use an IDE". Yes, you can program with notepad or a text editor and compile using a CLI. But using an IDE can take out a lot of frustration with getting through the fundamentals. Same with using a git client. Once they get the foundations of git into their head using a client they can go on and dive deeper into the topic using a CLI. Then use which one they find more helpful. TBH 90% of devs really only need to use a client.
The git client that really worked for me is Cycligent Git Tool. How it presented the git "model" matched my mental model of git. Alas, it appears to be abandonware. And since it wasn't open source, it's deadware. Especially since it wasn't finished yet, and had not-yet-implemented features.
I use git on the command line, predominantly. Sometimes, I use Atlassian Sourcetree, for some operations that work better in a GUI than command line.
My former boss highly recommends SmartGit as the best GUI client. I have not used it yet. Someday.
I've tried Tower and GitKraken. That was about 4 or 5 years ago. I recall that Tower was good, and in my team review I gave it thumbs-up. And that GitKraken seemed very nice — to my sensibilities — but didn't scale to the size of my project, so at the time it got thumbs-down. Maybe the scaling problem has been fixed.
GitHub is not about usability - the latter is sick there. It is about social networking in development (initially, only public FOSS development). Well, this is definitely not a programmer's task itself.
Still the best client I've met is the standard CLI ;)
Personally, I love Fork (fork.dev/) although unfortunately there's no Linux version right now. I like to have a TUI client knocking about too, in case of any issues - gitui is the current favourite (github.com/extrawurst/gitui/)
Thanks for the suggestions! I will give gitui a shot 😀
Thanks for the answer.
In fact we agree on many things: on learning by doing, on learning the concepts, that there are git aid tools that don't hide the concepts so those are ok, that collaboration tools are needed on top of git...
Personal opinion here: that's exactly the point.
For me as a maintainer what matters in a PR is that it's focused on one thing. That one thing could cover many files if you rename a function used everywhere or reformat everything, but conceptually that's only one thing.
A PR that does only one thing lowers the cognitive load for everyone involved. So if the PR can't be squashed it's a useful friction, a signal that the PR does more than one thing and can be splitted in smaller ones.
Not saying it's easy, saying it's useful. And if the PR can be squashed and merged, then the history inside the PR doesn't matter. That's why I prefer to keep the "rewriting the history" stuff for the exceptional cases.
git programmers are super talented C programmers.
They are good at many important things: performance, scalability, concepts, portability, features, and tons of low-level details we have no idea of.
Because they are hardcore talented C programmers, they are not however good at usability.
This is not an issue for me, this means that they are building the foundation on top of which others build usable software.
... like GitHub for example.
Git would not have been such a massive success without GitHub
GitHub is not "just" a git remote where you git push your stuff.
GitHub is what made git understandable for the larger public and it proposed its own different way of collaborating on code.
That's why I say fear not the git clients.
Avoid the bad ones yes, but adopt the good ones.
Why not simplify those complex environments then?
Also, Do you know what blackboxing is?
For a simple flow, cloning, staging, committing and pushing is enough for a regular developer.
The amount of use cases of multiple remotes can be counted with one hand. On one finger actually: when contributing to a FOSS project with having your own forked repository of it and you want to keep getting up-to-date with the upstream repository. I've never had to deal with multiple remotes at my jobs.
Merging and conflict-resolving is still horrible error-prone without visual Git client (and anything vim-emac-like is not visual). It is also sad git does not provide a way to stage changes per line.
The requirement of using rebase means your git-flow is too complex, and/or the commits are too big. With the Law of Murphy in mind, rebasing is something your rather not want to do.
Never had to do that. gitk is sufficient enough.
No Linux version? I'll stick with GitKraken then
At this time, Tower is only available for macOS and Windows, as they are both native apps.
Oddly phrased response. You can make native apps for Linux too
An IDE does hide how to compile, error highlighting, formatting, use of a terminal, vertical/horizontal layout of multiple code source files, etc. Which was my point.