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

Git cheat sheet [pdf]

wizardzines.com

Post reply on HN
Print view View original

41–50 of 146 posts

Re: Git cheat sheet [pdf]

#41

Post by CSMastermind »

Panzer04 wrote: post #28

I always find it interesting how knowledge makes it hard to comprehend the difficulties other people have. I used to barely understand git, but after a couple of years working at a company that relies on a rebase workflow, I'd like to think I largely understand how it works. Its nice to recognise pretty much every operation on this cheatsheet. Is it common that developers still have issues with git after using it pro…

> Is it common that developers still have issues with git after using it professionally for a couple of years?

As someone who has worked on developer tooling, including building a custom git client at a former job - yes.

Most people learn a few specific workflows not conceptually how things work under the hood.

Visual editors like GitKraken, Submlime Merge, Sourcetree, etc, have made this much better but there's still a big gap.

Re: Git cheat sheet [pdf]

#42

Post by wyldfire »

The biggest eye opener for me is understanding that all those commits are "still in there". Tags and branches merely point to a commit and the commit that branch used to apply to isn't gone.

Many (probably fair to say "nearly all"?) commands will be non destructive in that you can easily refer to older incarnations of your branch.

I'd seen "git reflog" but mostly used it to remind me of "that branch I worked on a while ago".

I gained a semi-healthy fear of operations that could land me in the middle of a conflict resolution that I wasn't interested in handling right now (often because the conflict occurred because I was referring to the wrong commit/branch).

I haven't completely cured that fear but at least I feel pretty comfortable recovering any old work among rebases, etc.

Re: Git cheat sheet [pdf]

#43

Post by erik_seaberg »

cjensen wrote: post #21
behnamoh wrote: post #10

Are there git alternatives that aren't a PITA to master before one can use them in production?

Subversion. It was made by CVS maintainers and a lot of care and thought was put into how it works and how the commands work and what the names of the commands are. Subversion is limited in being an older model of version control where there is exactly one single source of truth. In my mind Git solves a different problem that Linus Torvalds was facing: many people working in parallel with only some of the ideas pushe…

Git is well worth learning for any kind of collaboration or speculative work. It's fundamentally better at resolving merge conflicts, because it doesn't rely on being informed about which files may have been moved or copied. The Subversion maintainers owe me days of effort salvaging my small team's branches.

Re: Git cheat sheet [pdf]

#44

Post by dryanau »

therealdrag0 wrote: post #11
thecrims0nchin wrote: post #3

I liked the way I learned git. I started with sourcetree, a third party git gui. Super simple to use and understand. Then I moved to git gui, this step could be skipped. Then I got tired of pulling up my UIs and learned the terminal commands. Highly suggest this for anyone new, but just my (n=1) experience.

Btw I moved from Sourcetree to Fork. It’s very similar but way more performant and smooth UI (unless ST has improved in last few years)

I like GitKraken, except for the fact that it lacks the ability to show first parent only, i.e. `git log --first-parent`. That feature is available in Visual Studio and Visual Studio Code (Git Graph extension), but I don't like these as much as GitKraken, so I end up switching between command line, GitKraken and VS/Code. It's a bit of a mess. Does Fork support `--first-parent`? It's especially hand in merge-heavy workflows with very noodly graphs that you want to simplify.

Re: Git cheat sheet [pdf]

#45

Post by pixelesque »

johnwheeler wrote: post #25

I'll say it aloud: People need to drop git and look at JJ https://martinvonz.github.io/jj/v0.17.1/ I think even Linus thinks git has a shitty UI. JJ has an amazing workflow.

Going to have to disagree on the lack of an index: I can see workflows where that's simpler, but I'm so used to that now with git (for better or worse) I'm imagining that'd be a pretty big workflow change for me...

Other than playing around with it, I haven't really used it in anger though, so...

Re: Git cheat sheet [pdf]

#46

Post by knighthack »

lacedeconstruct wrote: post #20
SoftTalker wrote: post #7

Earlier quoted context omitted.

All I know of git is clone, pull, commit, and push. That’s all I’ve ever needed. Git can be that simple. Of course it supports more complex uses, which you can learn if you need them.

Life is simple until we play with time, once you start altering the past everything falls apart

This... seems a bit deeper than a comment about just Git.

Re: Git cheat sheet [pdf]

#47

Post by Barrin92 »

thecrims0nchin wrote: post #3

I liked the way I learned git. I started with sourcetree, a third party git gui. Super simple to use and understand. Then I moved to git gui, this step could be skipped. Then I got tired of pulling up my UIs and learned the terminal commands. Highly suggest this for anyone new, but just my (n=1) experience.

>Then I got tired of pulling up my UIs and learned the terminal commands

I'd never revert to terminal commands. Git is basically begging to be interfaced with through a GUI given how much sense it makes to visualize a git repo and its workflows. The moment I started using Magit git started to make sense for me.

Re: Git cheat sheet [pdf]

#48

Post by sunshowers »

behnamoh wrote: post #10

Are there git alternatives that aren't a PITA to master before one can use them in production?

Jujutsu! Git-compatible and a generational leap in source control that most people are going to love.

As a former member of Meta's source control team, I believe this with pretty high confidence -- many of the workflows that we rolled out within Mercurial/Sapling, and caused it to consistently be the most loved developer tool at Meta for many years based on surveys and interviews, have been adopted and improved by Jujutsu. See my testimonial, the first one at [2].

[1] https://martinvonz.github.io/jj

[2] https://martinvonz.github.io/jj/latest/testimonials

(Disclosure: I'm obviously biased towards the Jujutsu workflows, and its creator and I worked together on Mercurial. But I like to think that this specific belief of mine is pretty data-driven, both via stated and revealed preference.)

Re: Git cheat sheet [pdf]

#49

Post by jjayj »

Barrin92 wrote: post #47
thecrims0nchin wrote: post #3

I liked the way I learned git. I started with sourcetree, a third party git gui. Super simple to use and understand. Then I moved to git gui, this step could be skipped. Then I got tired of pulling up my UIs and learned the terminal commands. Highly suggest this for anyone new, but just my (n=1) experience.

>Then I got tired of pulling up my UIs and learned the terminal commands I'd never revert to terminal commands. Git is basically begging to be interfaced with through a GUI given how much sense it makes to visualize a git repo and its workflows. The moment I started using Magit git started to make sense for me.

lazygit is a godsend, personally. `git add`ing individual files is a PITA.

Re: Git cheat sheet [pdf]

#50

Post by Zambyte »

wyldfire wrote: post #42

The biggest eye opener for me is understanding that all those commits are "still in there". Tags and branches merely point to a commit and the commit that branch used to apply to isn't gone. Many (probably fair to say "nearly all"?) commands will be non destructive in that you can easily refer to older incarnations of your branch. I'd seen "git reflog" but mostly used it to remind me of "that branch I worked on a whi…

Jujutsu has 100% cured me of those exact fears. Here are some ways I deal with them:

- I don't know if there will be conflicts when after some operation. I just do the operation and see what happens. If there are conflicts, I either deal with them, undo the operation that caused the conflict, or make a me commit somewhere else, leaving the conflict to be dealt with later.

- I know there is going to be a conflict. In this case I may duplicate the related branches and either try to reconcile them ahead of time, or try to do the conflicting operating and walk through resolving it. If the conflict resolution gets gnarly, I can either undo portions of the resolution and keep trying, put it off and do something else for some time, or abandon the whole tree.

Post reply on HN