Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git is too hard

changelog.com

Post reply on HN
Print view View original

431–440 of 821 posts

Re: Git is too hard

#431

Post by linuxftw »

ivanhoe wrote: post #381
rjmunro wrote: post #212

The underlying technology of git is great, but the UX is terrible. The commands are all named wrong. "To create a branch, use git branch, but that doesn't check it out. If you want to create it and check it out at the same time use "git checkout -b", not "git branch --checkout" which would be 1000x more logical (and then there could be an option to make that the default behaviour) Resisting GUI's is not a good idea.…

I don't think memorizing commands is really the problem. Learning just 8 git commands (clone, pull, checkout, checkout -b, commit, push, merge, rebase) will cover like 99% of situations average dev will ever encounter. And when you need something more exotic you usually can google it, usually in under 5 mins. The problem, at least for me, was the complexity of the model which makes the whole thing super scary when yo…

Never use pull, always use fetch. You shouldn't merge changes into your remote tracking branch, it causes nothing but problems.

Re: Git is too hard

#432

Post by ritchiea »

simiones wrote: post #419
ivanhoe wrote: post #381

Earlier quoted context omitted.

I don't think memorizing commands is really the problem. Learning just 8 git commands (clone, pull, checkout, checkout -b, commit, push, merge, rebase) will cover like 99% of situations average dev will ever encounter. And when you need something more exotic you usually can google it, usually in under 5 mins. The problem, at least for me, was the complexity of the model which makes the whole thing super scary when yo…

You forgot log, cherry, stash, blame, which are also daily use commands. You also have to learn a lot of concepts to even understand the help and error messages for these commands - the worktree, the index, the stash, HEAD, ours vs theirs, conflicts, remotes, tracking branches, when it is safe to push -F, etc. Depending on the project you joined, you may also have to immediately learn about git LFS, submodules, squas…

I think of log, cherry-pick, stash & blame "quarterly use" commands rather than "daily use" commands. log maybe monthly, the rest quarterly unless you're doing something wrong.

Re: Git is too hard

#433

Post by psahgal »

I agree that Git is hard, but with the right explanation and a good graphical GUI like SourceTree, I've gotten non-technical team members up to speed on it!

I think the hard part is explaining the distributed nature of the tool, where your branches are completely separate from the branches on the server. When I'm explaining it, I usually talk about branches as work streams, and merging branches means merging work together.

What kind of things tend to trip people up when explaining Git? Maybe I should write a blog post or something...

Re: Git is too hard

#434

Post by nonconvergent »

The main problem I run into with git is communicating with my teams about editing history and how they shouldn't.

Particularly on teams that like to keep main clean and avoid reverts and merge commits in favor of rebasing. Thankfully my current team likes to keep their PRs clean and main is whatever works.

That and merge conflicts, especially on a stale branch. I use cli for most things and Intellij's merge tool for merge conflicts because I can get a clear view of what's what.

Re: Git is too hard

#435

Post by Cloudef »

IshKebab wrote: post #403
Cloudef wrote: post #158

Earlier quoted context omitted.

What's so hard about the CLI?

Single commands do many different things, options are inconsistent, e.g. -n does one thing for one command, and a different thing for others, lots of common tasks require complex sequences of commands, etc. It's pretty telling that there have been multiple attempts to write a saner CLI for Git.

I really don't see the issue. I've never struggled with git and it's already a muscle memory for me.

Re: Git is too hard

#436

Post by CuriousCosmic »

simiones wrote: post #419
ivanhoe wrote: post #381

Earlier quoted context omitted.

I don't think memorizing commands is really the problem. Learning just 8 git commands (clone, pull, checkout, checkout -b, commit, push, merge, rebase) will cover like 99% of situations average dev will ever encounter. And when you need something more exotic you usually can google it, usually in under 5 mins. The problem, at least for me, was the complexity of the model which makes the whole thing super scary when yo…

You forgot log, cherry, stash, blame, which are also daily use commands. You also have to learn a lot of concepts to even understand the help and error messages for these commands - the worktree, the index, the stash, HEAD, ours vs theirs, conflicts, remotes, tracking branches, when it is safe to push -F, etc. Depending on the project you joined, you may also have to immediately learn about git LFS, submodules, squas…

Don't forget `rebase -i`, `reflog`, and `bisect`.

Rebasing is always a good skill to know for when someone inevitably commits binary files or secrets to a repo and you have to do a bit of surgery to fix it.

Bisect of course isn't required knowledge but by god is it one of the most useful git commands a developer could know.

Re: Git is too hard

#437

Post by holtalanm »

thrwyoilarticle wrote: post #213
rakoo wrote: post #167

> I’ve used it since GitHub was in beta This is the root of the author's issue. As another commented, git is born in a world where computers are mostly offline, people are highly technical, and will spend a lot of time manually crafting the messages they will send to the numerous collaborators. It is an alone-first software. What the author wants (and exactly what I want as well: https://news.ycombinator.com/item?id=…

+1. The very first question: >Oh, I just pushed a change. I really didn’t wanna push that, so how do I undo it? Is a Github problem, not a git problem. You might as well ask how to unsend an email. If you don't know what git push means, you shouldn't be using it and are playing with intellectual property fire. The conflation of Github with git is responsible for a lot of confusion. Having Github be your first interac…

> Is a Github problem, not a git problem.

Git (the software) consists of two things. the git client (on your machine) and the git server (wherever you push).

It is most definitely not a GitHub problem if you pushed your changes to a local network git server, for example.

Re: Git is too hard

#438

Post by simiones »

ritchiea wrote: post #432
simiones wrote: post #419

Earlier quoted context omitted.

You forgot log, cherry, stash, blame, which are also daily use commands. You also have to learn a lot of concepts to even understand the help and error messages for these commands - the worktree, the index, the stash, HEAD, ours vs theirs, conflicts, remotes, tracking branches, when it is safe to push -F, etc. Depending on the project you joined, you may also have to immediately learn about git LFS, submodules, squas…

I think of log, cherry-pick, stash & blame "quarterly use" commands rather than "daily use" commands. log maybe monthly, the rest quarterly unless you're doing something wrong.

How can you pull without using stash? Do you always commit everything before pulling?

You also need the log daily to know things like "what changes made it into this build", or almost everytime I fix a merge conflict, to understand why something is the way it is.

I can grant that cherry-pick & blame are more rarely used, though blame is often on by default in many editors, and cherry-pick is something my team does daily around every release (since we don't want to merge the trunk into the release branch the day of the release for 1 bugfix).

Re: Git is too hard

#439

Post by samwestdev »

linuxftw wrote: post #431
ivanhoe wrote: post #381

Earlier quoted context omitted.

I don't think memorizing commands is really the problem. Learning just 8 git commands (clone, pull, checkout, checkout -b, commit, push, merge, rebase) will cover like 99% of situations average dev will ever encounter. And when you need something more exotic you usually can google it, usually in under 5 mins. The problem, at least for me, was the complexity of the model which makes the whole thing super scary when yo…

Never use pull, always use fetch. You shouldn't merge changes into your remote tracking branch, it causes nothing but problems.

Explain

Re: Git is too hard

#440

Post by csours »

CuriousCosmic wrote: post #436
simiones wrote: post #419

Earlier quoted context omitted.

You forgot log, cherry, stash, blame, which are also daily use commands. You also have to learn a lot of concepts to even understand the help and error messages for these commands - the worktree, the index, the stash, HEAD, ours vs theirs, conflicts, remotes, tracking branches, when it is safe to push -F, etc. Depending on the project you joined, you may also have to immediately learn about git LFS, submodules, squas…

Don't forget `rebase -i`, `reflog`, and `bisect`. Rebasing is always a good skill to know for when someone inevitably commits binary files or secrets to a repo and you have to do a bit of surgery to fix it. Bisect of course isn't required knowledge but by god is it one of the most useful git commands a developer could know.

Or you just do a handful of memorized commands and delete your repos when you break something and start from scratch.
Post reply on HN