Comment by formerly_proven | Hacker News Reader

Comment by formerly_proven | Hacker News Reader

formerly_proven

> I use git almost exclusively from the command line in a terminal.

Is certainly key. Most git frontends seem to be really quite bad for many reasons. Though "Push failed, want to pull, merge and push again? [Yes]" => constant "merged ssh://upstream.server/foo/bar/repo.git merged into branch master" commits being added to the history certainly irks my OCD the most. These frontends also seem to try and hide what git does, which leads to incorrect and confused mental models and much more frustration down the line than just learning to do it the git way directly. Yes, git is a "my way or the high way" tool, that's not great or something to emulate, but it is what it is. Trying to work around that only results in more pain.

Only use the git command line, use gitk for browsing history graphically if need be, and git-gui for preparing commits. git-gui seems to be the best GUI for making commits (and is probably written in Perl with Tk).

Logical conclusion from "only use the git command line": Also never make a dirty merge from your web browser.

I would like to say that not all git front ends are like that. I used to be a CLI only user, but now you can pry magit from my cold, dead hands. It's very close to the command line in what it does, it's very easy to see what exactly it does, and where it abstracts from git commands, it does so while following Git's mental model very well.

It has great discoverability while at the same time being an amazingly streamlined power user tool.

In other words, there can be great git front ends. It's just that most of them suck, usually because of a desire to dumb down the git UI. If you don't do that, and accept Git's complexity it can work out great.

I’ll second this and note that the discoverability of magit has helped me learn about features of git I didn’t even know existed, while simultaneously making them super easy to work with. Worktrees is the particular example that springs to mind.

It also helps to provide sane defaults, for example -f being force-push-with-lease instead of a regular force push when pushing.

The thing I love about magit is that it teaches you how git works instead of trying to hide it from you.

I'm an old school developer, but really hate the complexity and syntax of git.

Therefore, I use the GUI that comes with Visual Studio Code and the "Git Graph" plugin.

I work with juniors, which for some reason always want to do things in the command line. A lot of times I have to help them out with git issues, and can always to that using the GUI. When I see them work in the command line, it's always so slow for them to type in things.

Want to switch branches? Click lower left and select your branch. Want to sync with server? Click lower left on the sync icon Want to commit? Just type your commit message and CTRL-Enter. Stop wasting time adding files on the command line. Want to prune your origin branches? Click on the Git menu and prune pull.

For this last one, I always need to look up the syntax when doing it on the command line.

Git is already complex enough (compared to SVN), so if you're junior, for god sake use the GUI menu!

Odd.

I have had precisely the opposite. Junior Devs using the GUI ( in VSCode ) but breaking things badly.

And then I have to help them out using the command-line

Maybe you have a point. I can imagine when things are failing, they start clicking all kinds of things.

My juniors get stuck on the command line and then contact me :).

So maybe it is indeed better that they use their limited knowledge of the command line ;).

Where I work all the juniors try to use the git cli because the Internet has them thinking that using a GUI is looked down upon, but they don't even bother to learn the cli very deeply so they fail, break things and make messes.

One guy kept having to comb through dozens of local branches that had since been deleted from GitLab because he never pruned any of them. Fortunately, this is the most common type of breakage or mess - one that only affects the developer locally, because we protect the master branch on our server and use pull requests.

In VS Code I only have to know `Ctrl+Shift+P` to use their git "GUI" (if you can even call it that). One thing I like about it that you don't get with the cli (out of the box) is an instant overview of all the available commands without having to type much or switch views.

The juniors where I work have also been brainwashed to use Macs which they struggle with; mostly due to the bad window management, non-discoverable features and their lack of will to spend any time learning their tools deeply or customizing them. Meanwhile, I've been using Linux since the start of my career in the late 90s, I learned the basic Git flow over 10 years ago and have almost never had to use the git cli in that entire time while churning out hundreds of project.

> In VS Code I only have to know `Ctrl+Shift+P` to use their git "GUI"

You don't even need to know that; the operations are available through a fairly straightforward, reasonably discoverable GUI, without using the command palette, which has a nice heiriachical structure.

OTOH, neither of those paths is much good if you don't already understand the semantics of git operations.

Push and Pull almost always from the cli. But one of the things I find tools like Sourcetree useful for is selecting which changes (hunks, files or selected lines) to stage for commit, which is in my opinion much easier than with the CLI only.

> selecting which changes (hunks, files or selected lines) to stage for commit

I never understood why people feel the need do this. If you are working on a bug or feature, why put unrelated changes in that branch? It only creates confusion and probably messes up your tests too. And for what? It seems like a chaotic way of working to me.

Who said they were unrelated? Sometimes a single commit is the best presentation of a bug fix/feature implementation, sometimes it makes more sense to split the work into multiple commits.

I can understand that. But in my mind, if things are separate enough that I want multiple commits, then I would work on them separately. If a feature needs A, but A needs B, then I would work on B, commit that and only then work on A. Sometimes working on A will cause me to change the committed B part a little, but that's fine. At the moment in time that I committed B it was a perfectly reasonable solution that I can revert back to.

You know what, typing it out I can totally see why people do it the other way. A matter of personal preference probably.

For me, I often don't know exactly how I am going to do something until I have done it.

Once it's done I will split the changes into commits that make logical sense, for someone wondering how the new code changes the behaviour of the existing code.

For example I might be working on a specific feature and discover that my dev environment is missing something (For example replacing node by nodemon). I will make the change on the build script but I will not commit before testing the process for a couple of days, and certainly not before finishing the feature/bug I'm working on.

Try git add -uip

Lazygit (https://github.com/jesseduffield/lazygit) is pretty awesome.

GitKraken allows you to set "pull fast-forward only" or "pull rebase" as the default, very nice. This gets you out of most of those problems.

You can also do merge by dragging branches in the GUI which for me lowers the risk of taking the wrong branch. And it has a nicer looking interactive rebase than the command line which is very good for beginners.

You should give GitKraken a chance: https://www.gitkraken.com/

I just did a week ago! And I still find Sourcetree's interface a lot clearer and cleaner for this specific purpose.

do yourself a favour and look at the eclipse git client

Reply on news.ycombinator.com