
Git Cheat Sheet - akras14
https://gist.github.com/akras14/3d242d80af8388ebca60
======
dispose13432
I think that while Git would be great as a library, as a front-facing program
it's UX could do an improvement:

A good UX is simple things should be simple, but complicated things should be
possible, but now look at the following "basic" git workflow:

1\. Add. I want git to track this file. Yes, sometimes I need to add certain
lines, files, etc. Keep git add, commit, and push. But have a "git update" or
something for beginners (and for 99% of use)

2\. History - How can I go through a file to see its history? "git show REV"?
What if I want a wikipedia style history? What if I want to go through the
history of a file? There should be something like "git history main.c"

3\. Undelete file - This is fairly common, yet, the command is

git checkout $(git rev-list -n 1 HEAD -- "$file")^ -- "$file"

A command like git undelete $file would probably make life easier.

I haven't gotten to the more complex workflow, and I definitely agree that git
is a great revision system, but UX improvements can help

\--- EDIT,

Mandatory xkcd

[https://xkcd.com/1597/](https://xkcd.com/1597/)

~~~
steveklabnik
What would "update" actually do?

For history, "git log", that is "git log file".

Isn't part three the same as "git checkout HEAD~1 -- file" ?

~~~
dispose13432
>What would "update" actually do?

git add . && git commit && git push

>Isn't part three the same as "git checkout HEAD~1 -- file" ?

What if the delete took place three commits ago?

~~~
steveklabnik
Ah okay. I can see that.

Then you use HEAD~3.

~~~
dispose13432
But you first have to find in which commit you deleted the file.

~~~
steveklabnik
Ah ha, we're starting from different assumptions. Makes sense now, thank you!

------
PaulJulius
I'm going to describe a small issue I've been having with Git that I've tried
Googling for in the past but have never found a solution.

I use a custom `git log` alias that prints out a nicely colored commit graph.

    
    
      [alias]
        lg = log --graph --abbrev-commit --decorate --date=relative --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(bold yellow)%d%C(reset)' --all -n 15
    

The issue is that this includes everyone else's branches that have been pushed
to origin. I only want to see the history for local branches. (I guess I'd
also want to be able to see origin/master, but I recognize that there's
nothing distinguishing that from the other branches on origin I don't want to
see.)

I think the issue is that I run `git pull --prune` to get rid of any remote
branches that have been deleted. I usually do this after I pull master, so I
think I should just be running `git pull origin master --prune` as a single
command.

~~~
Ajedi32
Replace `--all` with `origin/master --branches`.

------
NumberSix
A version control system should be simple. Engineers should be able to focus
on getting things to work/done, not battling with a complicated, confusing
version control system.

Most engineers should be performing two operations/two command s the vast
majority of the time:

check-in <latest change> check-out <latest version> or <last good version>

If a file is new, check-in should ask you if you want to add it to the
project.

That should be it.

The proliferation of tutorials, cheat sheets, books, front end user interfaces
like SourceTree for Git is a symptom of a problem.

KISS (Keep It Simple Stupid)

~~~
peterbonney
This is what I used to think. Until I started using it. And mind you I'm not a
power user - I'm barely a developer at all.

I think the reason that git has this proliferation of tutorials, cheat sheets,
etc. is not that it's not easy to use, because (as I've discovered) it _is_
easy to use. No, I think the reason is that people have a pre-conceived
intuition of what version control should be, and that intuition is actually
_wrong_. So when they encounter something that does it _right_ (git) it
doesn't _feel_ right. The tutorials and cheat sheets help the committed user
get over the hump and start to "think git", but if we didn't bring our biases
to the party there wouldn't need to be so many of them.

As for front-end interfaces, some of that is an attempt to shoe-horn git into
something it isn't, which is dumb. But some of it is just adding visual
features that are sometimes nice to have and not easily replicated in a
terminal.

~~~
dispose13432
For example, how often do you use "staging" (as in _not_ git add .) and how
efficient is it's use?

In my workflow, you need a feature - you develop, you build, it works, you
commit.

Because think about it like this, you need a feature. You build, it works,
then before committing you notice a bug.

You fix it. Now you need to commit in two batches, the new feature and the
bug.

This is the commonly given reason for the add/commit/push workflow.

But at some point it's probably faster to either revert, fix bug, then merge
with main than to make your staging precise (especially you don't play with
staging in your IDE where you can test code as you type)

~~~
ciaranm
What? I'd stash the changes I'm working on for the new feature, cut a fresh
branch from whatever trunk/master/develop we're using, fix bug, checkout my
other branch again, stash pop/apply, and we're back to where we were 10
minutes ago (or 5 days, if that's how long the bug-fix took).

Branches are cheap. Stash is cheap. Use them.

------
pbh101
I always give this interactive cheatsheet [1] to git newbies to help them
conceptualize the state transfer.

[1] [http://ndpsoftware.com/git-cheatsheet.html](http://ndpsoftware.com/git-
cheatsheet.html)

------
AceJohnny2
My favourite remains Zack Rusin's, from 9 years ago. The state graph was
pretty useful as I was learning:

[http://zrusin.blogspot.com/2007/09/git-cheat-
sheet.html](http://zrusin.blogspot.com/2007/09/git-cheat-sheet.html)

------
adhip
Better One

[https://services.github.com/on-demand/downloads/github-
git-c...](https://services.github.com/on-demand/downloads/github-git-cheat-
sheet.pdf)

------
akavel
My more intermediate-level cheat sheet: [https://gingkoapp.com/git-
notes](https://gingkoapp.com/git-notes)

------
yranadive
Not as organized as the above two, but having being able to access it from the
commandline beats anything:

[1] Client: [https://github.com/evidanary/grepg-
python](https://github.com/evidanary/grepg-python) [2] Cheat Sheet:
[https://greppage.com/evidanary/5](https://greppage.com/evidanary/5)

------
antman
At this point we need a Git Cheatheets Cheatsheet.

------
mplewis
I'm also maintaining a small Git cheat sheet. It's my personal list of stuff
that I always find useful but can never remember how to type.

Let me know if you find it useful!

[https://gist.github.com/mplewis/a7563c7cb589048a071b](https://gist.github.com/mplewis/a7563c7cb589048a071b)

------
Kiro
> # Unstage pending changes, and reset files to pre-commit state. If

If what?

------
Kiro
git diff --staged should be in there. I always accidentally add stuff I've had
the chance to look at the diff. Then this command comes in handy.

------
guard-of-terra
Don't like how it is based around merges. Cherry-pick workflow is so much
simpler and provides clean history. "No merges" was the policy in every
project I worked.

