Git Cheat Sheet

https://gist.github.com/akras14/3d242d80af8388ebca60

by akras14 • 10 years ago

182 57 10 years ago

gist.github.com

adhip• 10 years ago

Better One

https://services.github.com/on-demand/downloads/github-git-c...

dispose134329• 10 years ago

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/

steveklabnik3• 10 years ago

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" ?

dispose134329• 10 years ago

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?

Kiro3• 10 years ago

As soon as a command requires stuff as "HEAD" and "~" I believe there should be an easier way.

tangue• 10 years ago

Yep. I really hope someone forks git with these ideas ...

dispose134329• 10 years ago

I don't even know if it has to be a fork, maybe a few batch/python scripts could be enough.

The problem is that frequently by the time people become experts in a field, they no longer see the beginner's difficulties.

no_protocol• 10 years ago

No need for so much work.

Simple commands can be accomplished by adding a git alias. More complex commands can be just a shell script. Put it on PATH with a name like `git-something` and now you can run `git something`.

AceJohnny22• 10 years ago

Yes, git's "frontend" is complicated and confusing. There are a plethora of tools that purport to replace it, partially or fully, with something more intuitive. Just off the top of my head:

http://gitless.com/

http://www.git-legit.org/

However, they never seem to really take off. Why is that? One thought is also a mandatory XKCD: http://xkcd.com/927/

ashark2• 10 years ago

I think most people just have the 5-6 obscure/painful commands they execute more than once a year stuck in an alias, and don't have a strong enough need for Yet Another Thing to Install on fresh systems.

It's also sometimes hard to know what exactly these extra commands will do if you don't use them often enough to know, so safe use still involves checking the docs, at which point you may as well google for "git [description of thing I need to do]"

grigjd32• 10 years ago

As someone who spent 13 years using CVS, 8 with SVN and 3 with git, I can only say that I greatly disagree with you. The idea of adding a file to track, committing locally and pushing your commits on a branch to a remote makes perfect sense if you spend the thirty minutes it takes to learn what git actually does. Moreover, this is the minimum number of commands to effectively use git correctly.

dispose134329• 10 years ago

1. Sure, if you're an expert, each command is useful. Practically, I commit only when it's ready (building, passes tests). So why would you commit without pushing (unless you're offline)?

2. I know what it does. I've read some manuals :) . The thing is

a. I'm not a VC (Version Control) expert, and most people aren't being paid to be VC experts.

They're paid to produce code.

Now, I (unlike a lot of people) don't mind spending some time learning my text editor (vi) which I use eight hours a day, but I'm not going to become an expert in a tool I use five times a day at most.

I just don't interact with it that often.

b. Good software is really meant to be gradual interaction. Take vi (which is infamous for being complicated) for example, to use vi, you need to know about 4 or 5 commands, each of which is a single letter or two letters at most, "i" to insert, "x" to delete, ":w" to write and ":q" to quit. Now you can use vi as a glorified notepad.

You need a more complicated workflow, you need to copy,paste, undo, fine. Learn each one as you need it.

And this is one of the more obtuse text-editing programs.

Honestly, if I used a text editor as often as I use git, I'd use nano or something.

ruraljuror• 10 years ago

Thanks for posting the xkcd comic. I was intrigued by the phrase "distributed graph theory tree model." It is definitely missing some hyphens. Ultimately I decided it should be "distributed graph-theory-tree model." That is, "graph theory" is an adjective modifying tree, and tree is an adjective modifying model.

joatmon-snoo• 10 years ago

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"

    git log --stat --patch -- main.c

Ajedi322• 10 years ago

Make that an alias:

    git config --global alias.history "log --stat --patch --"

nimchimpsky• 10 years ago

Don't you use an ide/sourcetree ? All that functionality is available.

pbh101• 10 years ago

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

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

guard-of-terra• 10 years ago

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.

NumberSix• 10 years ago

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)

rhodysurf• 10 years ago

Except that doesnt work well for large teams implementing different features in a shared code base. When you have a complex product you may need a complex solution. Which is exactly what git was designed for.

jessaustin2• 10 years ago

One is welcome to use a "Simple Stupid" VCS for one's own projects. Large complex projects, however, need more. That's why git exists, and that's why large complex projects use git.

git isn't that hard to use anyway. If you have a problem, just look at one of the many online cheat sheets. b^)

dispose134329• 10 years ago

If you have a problem, just look at one of the many online cheat sheets.

Honestly, I'm too scared to break history, or of clogging it up with commits like "let's see, maybe this will work" "nope, last commit is junk, let's try again","junk","junk","arghh",".","." :)

peterbonney2• 10 years ago

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.

dispose134329• 10 years ago

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)

dispose134329• 10 years ago

Well, you need branches (beta, development, release, old-release, etc.)

ubercow13• 10 years ago

Well, stick to subversion then?

geezerjay2• 10 years ago

Subversion: for those who think branching and copying directories around a directory tree is the same thing.

geezerjay2• 10 years ago

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

This is a silly statement. This proliferationi of tutorials only indicates that Git has become a very popular tool and there's a lot of people who decided to take their time to write about it.

If you happen to browse through those tutorials, they are essentially all the same, touch precisely the same basic and trivial use patterns, and are devised to help newbies get up and running in no time.

Initialize a local repository. Check out something from a remote repository. Commit a change. Create a branch. Mergue branches. Pull from a remote repository. Push to a remote repository...

That's all. Very basic stuff.

In fact, can you come up with a single distributed VCS that is simpler and easier to use as Git and provides the same level of functionality?

No, you can't.

btschaegg2• 10 years ago

This is essentially the attitude i referred to earlier [1]. You don't see the problem git is actually trying to solve and project your own "world view" onto it - that's how you come up with sentences like "A VCS should do X."

Version control does consist of more workflows than just yours. If you want to have meaningful collaboration with many people, the model you refer to does not work at all (hell, even in the small team I work in currently, it slows everybody down).

If you're not using gits features, use another tool. You're essentially complaining about the UI of a chainsaw, when what you want to use is an axe.

Also, if you're forced to use git, chances are either you or the person(s) forcing you don't see the full picture.

[1] https://news.ycombinator.com/item?id=13182911

antman• 10 years ago

At this point we need a Git Cheatheets Cheatsheet.

yranadive• 10 years ago

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 [2] Cheat Sheet: https://greppage.com/evidanary/5

Kiro3• 10 years ago

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

If what?

Kiro3• 10 years ago

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.

AceJohnny22• 10 years ago

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

PaulJulius• 10 years ago

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.

Ajedi322• 10 years ago

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

mplewis• 10 years ago

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

akavel• 10 years ago

My more intermediate-level cheat sheet: https://gingkoapp.com/git-notes

Git Cheat Sheet

Related Stories