Hacker News Reader

Comment by adaboese | Hacker News Reader

I cannot be the only one that gets away with only knowing:

  git pull
  git merge x
  git checkout [-b] foo
  git commit
  git push

View on HN

Git is conceptually simple but has a baroque UI. I really recommend spending 15 minutes to understand it conceptually:

objects: blobs, trees, commits, annotated tags

refs: branches (local, remote-tracking), tags, HEAD

other: working tree, index (aka cache aka staging area), remotes

There's lots of good guides out there: git from the bottom up, git for computer scientists, and the git parable are some that spring to mind. The Git Book is also excellent but it's more than 15 minutes of your time.

All the commands become way less mystifying when you understand what they are manipulating. You'll never get into a state where you want to `rm -rf` the entire repo and start with a new clone. There will hopefully be no more teeth grinding or keyboard mashing.

I've used a lot of VCSs over the years (rcs, sccs, cvs, subversion, clearcase, mercurial, git) and I swear git is the one I find least frustrating. The others may have had simpler interfaces, but they were either conceptually more complex, overly rigid in their design and behavior, or both (looking at you clearcase).

Look, I get it: a lot of folks see git as a necessary evil that's part of their day job. I disagree. I think it's really worth spending the time to learn well, probably like you invested some time in your editor and other tooling.

I mean, it's easier than C++. :-)

> The others may have had simpler interfaces, but they were either conceptually more complex, overly rigid in their design and behavior, or both

Most of the time, I'll humbly trade "overly rigid in their design and behavior" for "simpler interfaces". Please master VCS, discipline me !

For me, git becomes unintelligible when there's a crazy train-track map of branching and merging.

So I usually do whatever I can to keep a single straight-line master history.

I branch off for a task, then after a while my branch isn't joined at the tip of master. So I rebase locally until it is. Then when the PR happens, master gets my changes added to the top, with no extra noise from merge commits.

Even if the local-rebase workflow is slightly more complicated, the payoff is a really clean history, making future reasoning about branches much easier. Not to mention merge conflicts are easier to solve when you rebase early & often.

That's because you've apparently used some command to look at that history, none of his commands ever show that

I think this is a pretty sensible approach. Git feels like one of those tools where you are given a lot of power but it's your responsibility to use it in a sensible way. A bit like with Excel or spreadsheets. You can do a lot but you can also make a big mess pretty quickly.

In my observation, the problem comes when there is a "merge main to the feature branch before merging"

This step is when newbies get confused because the diffs are the wrong way, and I've seen people often losing merge hunks from master when there are conflicts which can be disastrous (not a git issue, I've seen people do the same in SVN).

The proper solution IMO would be for git to have a "merge --reintegrate" which would do the opposite merge: take the main branch and merge the current feature branch to it... after success, you have a new feature branch.

This is why I also prefer rebase and cleaner history (but a common mistake here is to squash after PR approval... that should be done before, not after).

> For me, git becomes unintelligible when there's a crazy train-track map of branching and merging.

Consider finding peace by inverting your perspective: if your organization’s development process (for whatever reason, many of them legitimate) involves a crazy train-track of features being developed in parallel, isn’t it great that you're all at least using something that can keep track of it?

For a small team that should be unnecessary.

Frequent rebasing when you’re on a side branch of development is smart, but doesn’t conflict with my point.

Also, really, who looks back into the depths of history? There’s a reason a lot of backup schemes rotate a set of tapes over 30 or even 14 days. For that reason I am not a fan of rewriting history for “clarity”: I consider it wasted effort.

For the same reason I don’t care about branches for explorations that turned out to go nowhere — just mark the head abandoned and stop worrying about it.

I definitely can't work without `git add`. Other commands I use daily or almost-daily (frequently enough that I have aliases for them) are `git add -p`, `git commit --amend`, `git rebase`, `git rebase -i`, `git stash`...

Then there's of course `git log`, `git diff`, and `git status`, but I presume you know about those as well.

You are probably missing "git add" but otherwise, it is fine... unless you fuck up.

Unfucking thing is what of most of my knowledge of git goes to. Committing in the wrong branch, the wrong files, starting from the wrong commit, etc... Before you push, almost all mistakes are fixable, but it requires knowing a few more commands.

Then there are the project specific things. For instance, I worked on a project where we didn't have a central server we could push to and pull from (airgap). So we had to work with bundles. Git does that really well (it really is decentralized), but it is uncommon. Some people prefer a rebase-based workflow, some use cherry-picking extensively, some projects are more prone to conflicts than others, etc...

The most important command:

    git reset --hard

This is my favorite. It allows one to easily create "service" branches based on tags where you apply to that tag a select set of commits from the development branch that you can then easily deploy to PROD without including the rest of the (perhaps not sufficiently tested) commits and without having a convoluted branching strategy.

Or:

  git reset --soft HEAD~1

that's my list too, pretty much (+ the obvious `git add` and `git status` others have mentioned)

I throw in a `git reflog` once in a while, and the other day I patted myself on the back for my first use of `git tag -a mytag -m "This is my first tag!"` followed by `git push origin mytag`. I felt like god

now as much as I hate Xcode, its UI for looking at all my current changes and staging them by blocks of line for commit is like a superpower. as a solo developer working on brand new code, not all of my lines of thinking follow very atomic git commits, so it's nice to separate, say, some refactoring code from some actually new functionality when committing changes

Really?? I would have a very hard time without:

  git log
  git show
  git status
  git blame
  git diff
  git add
  git reset

My "minimalist" list of git commands:

    git add
    git blame
    git branch
    git checkout
    git cherry-pick
    git clone
    git commit
    git diff
    git fetch
    git log
    git merge
    git pull
    git push
    git reset
    git rm
    git stash
    git status

17 commands in total. I don't think it is possible to be a professional software engineer without being familiar with them. Granted, some of these you may need more frequently than others.

My guess is, the OC relies on their IDE/editor for the functionality provided by some of these commands. But then, why not just go all the way. Just use all VC features provided by your IDE, and claim that you need zero git commands.

FWIW that's 99% of my usage of git

(well... it's about 1% because I do everything using the eclipse git UI, but that's the same behavior you get from that commands)

Because your IDE shows line-based blame and allows to check out old file versions via right-click? :) Mee too

Possibly `git branch NEWBRANCHNAME` instead of `git checkout -b NEWBRANCHNAME`. When I need to show git to someone in order for them to contribute to something, I give them only these incantations --- and instructions to ask me if weird git things happen.

You then need to do both `git branch xxx` and `git checkout xxx` though.

If you teach "checkout to move around and add -b when moving to a new branch the first time" that works pretty well

It's `git switch [-c]` nowadays.

I've given up trying to configure git push the branch I'm on so I type this little dance each time :

    git switch -c foo
    git push 
    > did you mean git push --args-with-branch-name?
    sigh, copy, paste, enter

I know a decent amount of git, but day to day I use GUIs (Sublime Merge).

protip: If you want to switch branch you can now use "git switch [-c] foo". If you want to restore files you can do "git restore .".

Basically you can stop using checkout.

*edit*: fixed switch branch creation parameter.

I think perhaps you meant "git switch [-c] foo"

Correct thank you.

"THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE."

I will keep using them so I can keep using old software. How new is it? Does ubuntu or debian have it?

They have been introduced in git 2.23 released in august 2019.

And is in Ubuntu 22.04 and Debian 11.

Until it's actually removed, muscle memory will keep me using checkout.

Unless you are superhuman and never make mistaeks, you should put "git rebase" (with and without -i) on top of your list of things to learn.

Let us also hope they do a git diff before pushing changes.

You’re definitely not the only one, but you will level up if you learn branching. After that you can become the guru amongst your peers and a god among men if you learn how to use ‘git reflog’. ;) That will help you learn how fix almost any git accident.

`git add` sometimes

If you get errors, save your work elsewhere, delete the project, and download a fresh copy.

I manage with even less, any merging under my watch happens as a strategy with pulling

you're def not the only one. but learning more pays dividends in confidence and resilience. fyi, pull is just shorthand for fetch && merge

To cleanup the history before asking for a review.

git rebase HEAD~2 -i

git commit —amend

You don't need to know many more commands than those - maybe aside of "reset", "rebase" and "fetch" which definitely come handy regularly, and maybe a few more for showing status or browsing commit graph (unless you use some GUI for that) - as whenever you need anything else you'll usually just look it up anyway, either in the man or on the Web. However, if your mental model of git is limited to these commands only, you're doing yourself a disservice that leads to https://xkcd.com/1597/

I'm nothing without git rebase -i.

you don't need git add? no git status? i take my hat off to you, sir!

Yes, this is very good. Also, rebasing is evil.

you can't make do with only that if you're in a team of 2 even

Reply on news.ycombinator.com