
Git pretty - todd8
http://justinhileman.info/article/git-pretty/
======
js2
This is excellent: opinionated and correct.

 _Guess what happens if you try to git revert a merge? Yeah. Don’t do that._

You can, but you really need to understand what happens when you do so, so
that you're not confused by future merges from the same branch. Straight from
the horse's mouth:

[https://www.kernel.org/pub/software/scm/git/docs/howto/rever...](https://www.kernel.org/pub/software/scm/git/docs/howto/revert-
a-faulty-merge.txt)

~~~
bellerocky
Reverting a merge is totally OK if you kept your history clean and rebased the
branch you're merging into to get updates instead of merging it into your
branch.

Like if you created a new branch from master and you have been merging master
into your branch to get updates in master, once you merge your branch into
master you cannot revert this merge because the act of merging master into
your branch changed which branch owned commits.

If you rebased master into your branch instead everything will be fine. If you
merge your branch into master, reverting that merge will simply undo the merge
as you expected.

------
christop
"Split off a logical chunk from your mess, stage it" should really be another
box with "git add -p".

Being able to pick and choose (and even edit) individual chunks to be staged
is enormously useful. Quite possibly my favourite feature of git.

~~~
digikata
I agree with the git add -p , but I feel that at point, it often should be
followed by a stash then a rebuild and/or some testing. Next, commit and
unstash to continue.

~~~
bobthecow
Yep yep. `git add -p`, `git stash -p`, etc. That's exactly why that bit of the
chart isn't very specific. There's a whole workflow right there, in that one
little cycle. One of these days I'll get around to writing that one up :)

~~~
bulte-rs
git isolate! I've been trying to make something like this :( Unfortunately my
git-fu is failing me.

------
krallja
Mercurial Changeset Evolution is going to solve the "It's safest to let it
stay ugly then" and "Send them a note, let 'em know you're changing history"
problems. No more force pushes or lost data! The new version of history
applies on top of the old version. Immutable data structures, flexible
workflow.

------
LandonAB
As a one person web design/development studio, it's charts like this and
threads like this that keep me off git. I've played with it, used it on a
project but the fact that I am always reading about the messes people get in
with git...I really don't have time to deal with versioning messes.

~~~
apinstein
I'd counter that these messes aren't caused by git; rather they are messes
that without git you wouldn't even bother cleaning up.

However, git lets you fix the mess in such a way that you'll have a clean
commit history. This is really helpful if you're trying to keep your codebase
clean so that `git bisect` will always work nicely, and if you just want to
keep your codebase history really grokkable.

~~~
LandonAB
Oh, I'm not blaming git. I take full blame but still have a hard time
rationalizing the headache.

------
chetanahuja
magit mode in emacs has bailed me out numerous times from git messes. If
you're an emacs and git user but not using magit, you're seriously missing
out.

~~~
npsimons
Dunno, I've been very happy with egg. But then, due to a large part of my
career being maintenance, I've fallen into a lot of self-discipline patterns
that tend to keep me out of messes.

~~~
rcthompson
egg looks pretty similar to magit in terms of functionality. I haven't tried
it, but I would guess either one is fine.

------
scrollaway
That is a really fun poster to have!

I hope of course that people realize you should not rely on this as an
educational tool but merely as a quick reference. Please, don't use any of
these commands without knowing what they do!

------
fiatjaf
"Do you hate them?" was hilarious.

------
philip1209
If you really mess things up, there is Reflog

------
nathancahill
If you like this, check out gitjk[0], it's saved my codebase a handful of
times.

[0] [https://github.com/mapmeld/gitjk](https://github.com/mapmeld/gitjk)

------
tarblog
What does "I don't think it means what you think it means" refer to?

~~~
pimlottc
I don't think it's specifically about reverting merge commits but rather the
fact that "git revert" is quite different from "svn revert" which may not be
immediately clear and may not meet everyone's understanding of the term
"revert" \- which is to say, it does not simply "get rid of" the unwanted
commit but rather creates a new one that has the net effect of undoing that
commit's changes.

~~~
tricolon
I keep meaning to make an alias for it called "git anticommit".

------
JoshTriplett
Nice chart, at least for a reminder of the command you're likely to need.
However, "Is it already on GitHub" should be "have you already pushed it
publically". Reminder: git is distributed.

~~~
rwallace
Git is distributed indeed, but good writing style prefers specifics to
abstract generalities. It's better to use Github as your example and expect
the reader to understand - or if appropriate, explain in a separate paragraph
- that there are other options for public repositories.

------
ladislas
Great tool for young interns! :D

I think there is a small mistake though, for the "I accidentally commited
something": the answers yes and no for "Has anyone else seen it?" are
inverted.

~~~
burntsushi
Hmm, I don't think so. The answer for "yes" is to do a `git revert`, which
does _not_ modify history. Instead, it creates a new commit.

The answers for "no" all involve modifying history, which I think is generally
perceived to be quite OK so long as you aren't modifying history that is
public.

~~~
ladislas
yep you're right and the question was already answered in the comments. :)

------
jrochkind1
SO useful, thanks!

This is an area where I get completely lost with regard to the 'right' thing
to do to fix things up.

------
aristidb
There should be a section for git filter-branch.

:>

------
gcb4
git is only good for people that was working like Linus. if you didn't have
been accepting patches by email but instead had a fluid svn, perforce, etc
central repository and people already collaborating with commit powers, then
if you move to git "just because" (which is the reason of 99% migrations)
you're going to have a bad time.

sadly, my company decided to move just to use pull requests as a poor man's
code review tool. sigh. I'm the 99%

~~~
findjashua
Sounds more like resistance to change than anything wrong with Git. I used
perforce at my previous company, and while Git's learning curve was higher, I
definitely see the advantages of a distributed version control system over a
centralized one:

1\. Not having to check out files means I can work offline.

2\. When working on multiple features, it's much easier to create a new Git
branch than it is to create a new Perforce workspace.

3\. People really tend to abuse Perforce's 'lock file' feature. I'm glad this
isn't possible in Git.

4\. I haven't really noticed any drawbacks to the pull-request feature. You
can still review and comment on diffs on Github.

5\. It's the version control of choice for open source software, so if you use
any third-party libraries (and I hope you do!), you'll probably need to know
how to use Git anyway.

I can't really think of anything I miss from Perforce.

Edit: these advantages are not specific to Git, but any distributed version
control system. If you find Git to be too difficult, don't worry, it's not the
only game in town. I've heard Mercury is much easier to pick up. Good luck!

~~~
recursive
Why would you need to know how to use any version control software at all to
use a third party library? I mean, I do both, but haven't really seen a
connection.

~~~
smt88
Before git-based package managers became the norm, it wasn't uncommon to
track/update dependencies manually using command-line git.

Also "using" a third-party library hopefully results in finding bugs, fixing
them, and submitting a pull request to the project.

~~~
pimlottc
> Before git-based package managers became the norm

When did using git-based package managers become the norm?

> it wasn't uncommon to track/update dependencies manually using command-line
> git.

Are you saying you normally update your third-party libs with the latest from
HEAD instead of using versioned release artifacts?

(I'm guessing you're speaking from a JS dev perspective?)

~~~
smt88
> When did using git-based package managers become the norm?

I'm a web developer, so my response was hastily written thinking about my own
narrow scope. I'm sure that non-web developers can go their whole lives
without interacting with git, but it's impossible for web developers.

Npm (Node), Composer (PHP), and Bower (web) package managers all use git (and
often GitHub itself) pretty religiously. I know that one or more of those may
support other VCS repos, but git is the de facto flavor.

> Are you saying you normally update your third-party libs with the latest
> from HEAD instead of using versioned release artifacts?

Not exactly. First of all, that's what I _used_ to do before every language
had its own package manager.

Second, I do use versioned releases. However, I use the tagged versions that
are determined by the author(s) of the library. I'm not just pulling down a
bleeding-edge, un-tested library, and I don't get every single commit.

