Live data from Hacker News

Git cheat sheet [pdf]

wizardzines.com

61–70 of 146 posts

Re: Git cheat sheet [pdf]

#61

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)

Thank you! Had never heard of this. Ill give it a try!

Re: Git cheat sheet [pdf]

#62
post #51

Earlier quoted context omitted.

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

It's not possible to alter commits with git. They are immutable. You can only make new commits that are based on existing ones in some way. The distinction is important, because the original commit (such as a commit pre-rebase) still exists after it's been "changed".

> The distinction is important, because the original commit (such as a commit pre-rebase) still exists after it's been "changed".

The original commit will only exist for as long as git deigns not to garbage collect it.

Re: Git cheat sheet [pdf]

#63
post #51

Earlier quoted context omitted.

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

It's not possible to alter commits with git. They are immutable. You can only make new commits that are based on existing ones in some way. The distinction is important, because the original commit (such as a commit pre-rebase) still exists after it's been "changed".

[deleted]

Re: Git cheat sheet [pdf]

#64

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

[deleted]

Re: Git cheat sheet [pdf]

#65
I have a funny little habit that probably stems from a certain degree of paranoia when working on a decent-sized change. I like to keep a local patch of it, as follows: "git diff > works.patch"

Later on, you can apply it if necessary with "git apply works.patch".

Re: Git cheat sheet [pdf]

#66
One of faves isn't listed.

  git log -LstartLine,endLine:fileName
It's like an extended git blame, showing how the specified lines evolved over time, and by who. Tracks the change as the line numbers evolve, and even as the file is moved.

Answers the questions of "who did this, when, and why?" / "How long has it been like that?", etc.

Re: Git cheat sheet [pdf]

#68
post #2

Is there a historical reason why git is needlessly complex? Seeing this cheat sheet really brings it to life.

Some of the complexity comes from the fact that in earlier versions it was reasonably expensive to add new subcommands. As a result more functionality got added to existing subcommands like git checkout. This made the UX more confusing.

In newer versions of git the cost of adding new subcommands is reduced and they've started adding more specific commands like git switch.

Re: Git cheat sheet [pdf]

#69

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.

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.

And that's the only reasonable subset of git there is - I agree. Branches and cherry picks aren't worth the insurmountable headaches they come with

Re: Git cheat sheet [pdf]

#70
post #65

I have a funny little habit that probably stems from a certain degree of paranoia when working on a decent-sized change. I like to keep a local patch of it, as follows: "git diff > works.patch" Later on, you can apply it if necessary with "git apply works.patch".

Do you find that better than a stash or a branch because it shows up in ls?
Post reply on HN