
Git Cheat Sheet - dallamaneni
http://luisbg.blogalia.com//historias/76017
======
AceJohnny2
I really like this one by Zack Rusin from 2007:

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

In nice printable format with a sort of "state diagram" for commits (workspace
<-> index <-> local commit <-> remote commit)

------
castratikron
Another one: git pull --rebase. If you've made a commit or two but others have
pushed before you've had a change to pull, you can do a rebase to avoid the
separate branch and merge that a regular git pull will attempt to do. I don't
know if I'd trust it on very out of date branches though.

~~~
rev_bird
Recently found out about the usefulness of this command -- was _amazed_ at how
much simpler it made integrating changes. It can get tricky with conflicts,
but now the commits in my pull requests aren't getting polluted with commits
that are just "Pulling in changes" full of other people's code.

~~~
jcrites
Yes. I'd highly recommend making `git pull --rebase` the default behavior of
your `git pull` operation. I'd thought that the Git folks were going to make
this the default behavior at some point. It really ought to be.

`git pull --rebase` is a much better conceptual way to integrate changes from
your upstream when working together collaboratively. The rationale is this: a
newly released change should be, in the ideal case, simply an incremental diff
against the head of the branch. It may have been developed by forking off at
some point in the past, and incorporating changes over time, but those are
implementation details of how the diff has been constructed. Once the diff is
ready to go, ready to be committed, it's just an incremental change to the
head.

By working in a branch and using `git pull --rebase` to incorporate upstream
changes, you keep your code in a constant state of being "an incremental
addition" to the primary branch. Indeed, it's very similar to what happens
with Perforce when one runs `p4 sync ...`, by comparison - your local code is
updated to account for the new remote contents. Finally when you submit, your
change looks like a single incremental commit, or series of commits. The
resulting history is simple and linear.

Sometimes people object to this because they claim that source history should
be the "true history of what happened", whatever that means. I believe those
arguments miss the point of source history. Source code history is always an
abstraction over what really happened. Imagine an extreme example: an IDE that
generates a single source commit for _every keypress you type_ while editing a
file. That's the true history of what really happened. But is it useful to
commit that history to a repository? Of course not - that history is kept
locally in your IDE as undo buffer. Similarly, it's often not useful to
pollute the commit history with implementation details of how you developed
the change (sometimes, but not often).

When you develop changes locally and push them upstream, you rightfully make a
judgment call about what level of detail about the development process should
be exposed in the history, and what level of detail should be hidden. For
example, you might hide detail by combining many keypresses into one commit,
as is conventional, or by squashing multiple related commits into a single
commit. You might hide the detail about how your change was developed over
time by using rebase to make it appear as if it's an incremental change to the
head, even if it was developed over time and involved several integrations
from the upstream. Sometimes these history-abstracting changes are not
appropriate, such as if you truly need to develop a branch in parallel with
the main branch, that many people are collaborating on. In that case, a branch
may be appropriate. Most of the time, it's ideal to develop changes directly
on the master branch, as an incremental change to it, using `git pull
--rebase` to keep local changes up to date, which will result in a simple,
linear history.

~~~
throw_away
git config --global pull.rebase true

~~~
rev_bird
Ooooohhh I'm going to be the cool kid at work on Monday when I unleash this
one. Thanks.

------
zwiteof
As an aerospace engineer who codes rather than a software engineer, is there a
cheatsheet that talks about how to use git from a "when do I commit/merge/etc"
rather than a "this the command to perform commit/merge/etc"? Basically, an
"Idiot's Guide to Making My Life Easier with Git"

I've tried to use git a few times at work, but I always end up forgetting to
use it for awhile when deadlines start creeping up so it becomes "well, the
code works in it's current state and it's been 2 months since I committed, so
I should probably update the repo" which doesn't seem much better than
periodically backing up the folder.

~~~
jcrites
I have found the tutorials and references on git-scm.com to be effective.
[http://git-scm.com/doc](http://git-scm.com/doc)

Learning and adopting Git was definitely worth it for me and organizations
I've worked with. It provides advantages that are difficult to describe in
words and best experienced first hand [1]. Once you understand it, it's like a
swiss army knife, or a power tool capable of manipulating source code commits
any way one desires. The user experience might not be simple, but the
_semantics_ are simple in a way that makes operations easy to perform in Git
that are challenging in other source control systems.

You can probably take better advantage of source control than checking in on a
monthly basis. Personally, I recommend checking in about every 30 minutes to
folks I work with. However, we're used to quick release cycles where code
might reach production hours after we submit it, not years. I personally favor
frequent commits also because it acts as an additional layer of protection
against data loss, as well as facilitating frequent code reviews and
visibility by coworkers, frequent integration testing, etc. These benefits
support developing code as a team, and support a quick release process.

If you'd like to learn Git, then I'd recommend integrating it into your daily
habits such that you're committing regularly, perhaps every 30 minutes to an
hour. It will be difficult to learn the tool effectively if you use it only
once per month.

[1] I'm happy to try if anyone wishes, but there are plenty of arguments out
there. I would summarize by saying that Git simply works better than anything
else I've used, including CVS, Subversion, Perforce, etc. Upon familiarizing
myself with Git, it feels like those tools, through lack of capability, create
a lot of problems and friction that Git avoids.

------
yeukhon

        git add .
    
        Add all modified files to be commited
    

I think this adds only files relative to the current path?

One I use from time to time is _git add -p_ (-p stands for patch) , useful if
you have a large set of changes, you keep forgetting to commit incrementally
upfront, and you want to split your changes into one or more commits.

 _git checkout -b BRANCH_NAME_ will create a new branch locally.

Also, if you have time, look at pre-commit hook for your project :-) tired of
running your favorite test harness plugin for your project manually or waiting
for your Jenkins server to get the job?

Last, is git fetch vs git pull still a debate? I always use git fetch because
that seems to be most preferable, fetch then rebase is the right path, most
clean way to merge changes with some upstream / branch.

------
base698
I made the below presentation for a talk a while ago. The notes have roughly
what I said in the presentation to try to demystify the internals.

[https://docs.google.com/presentation/d/1t8grwHN0SB7HGgD9Jv9g...](https://docs.google.com/presentation/d/1t8grwHN0SB7HGgD9Jv9gRjJthoRzBDHK6Iw77TFhXXc/edit#slide=id.ge423a65cf_0_84)

------
Trufa
I've set up a collaborative cheatsheet in github some time ago, if anyone
wants to collaborate, you're more than welcome:

[https://github.com/trufa/git-cheatsheet](https://github.com/trufa/git-
cheatsheet)

------
obituary_latte
Thanks. I love git but can only be generously considered as a casual user.
There are still many things that confuse me (e.g. Tags) and as such there is a
ton of functionality I still don't understand. These types of posts help. It's
appreciated.

~~~
karlshea
Tags are just like slapping a post-it note on a commit so you can find it
later without memorizing a commit hash.

------
vectored
Thank you. I work in a very old-fashioned research lab that we managed to drag
to git recently. I haven't been able to convince the team to read the git
book. This could be more helpful.

------
bonobo3000
heres one i like:

"git stash branch <branchname>"

like "git stash" it stashes away all the untracked modifications you have, but
it puts them onto another branch. i often end up making partial progress on
things that should be conceptually in different branches at once - this way,
you can stash unrelated changes into different branches, and then merge each
branch as you finish.

