
Learn Enough Git to Be Dangerous - mhartl
http://learnenough.com/git
======
mhartl
I linked to the free online version because that feels like the more HN thing
to do, but there's also an announcement post that includes a 15% launch
discount on ebook sales:

[http://news.railstutorial.org/learn-enough-git-
ebooks/](http://news.railstutorial.org/learn-enough-git-ebooks/)

I'll plan to be around for a bit this afternoon in case anyone has any
questions. I've already gotten a lot of great feedback on _Learn Enough™ Git
to Be Dangerous_ , so thanks for all the support!

~~~
skizm
Wait... The phrase "Learn Enough" is trademarked? Wtf?

~~~
wmboy
™ stands for Trademark Pending

® stands for Registered Trademark

Absolutely anyone can create a term and put ™ after it (even if they never
actually go through with the actual registration process).

~~~
lwf
In the United States at least, ™ doesn't mean "pending" per se — you can use ™
even when you have a registered mark, and marks do not need* to be registered
to be valid:

> Is registration of my mark required?

> No. You can establish rights in a mark based on legitimate use of the mark.

[http://www.uspto.gov/trademarks/basics/register.jsp](http://www.uspto.gov/trademarks/basics/register.jsp)

*: Some countries operate under a first-to-file system, and unregistered trademarks may be at risk even for US-based businesses that operate internationally.

(I am not a laywer and this is not legal advice.)

------
breakingcustom
There are just some people in this world that have the reputation and
thoroughness that makes you only want to learn new things from that one
person. Hartl is one of the few. Thanks and can't wait for the rest!

~~~
mhartl
Wow, thanks! Would you mind shooting me an email (address in profile)? I might
like to include this comment as part of a testimonial section at some point.

------
dEnigma
The initial delay when opening the site, before the text appears below is very
confusing, at least to me. I didn't know if I was supposed to click on
something and tried scrolling up and down to trigger something. The delay
lasted more than five seconds on first load and about 3-4 seconds on reloads
(could be a problem on my end too).

~~~
mhartl
Thanks for the heads-up. We'll look into ways to speed things up in future
releases.

------
BWStearns
I really like this series because of the focus on developing technical
sophistication as opposed to a narrow set of boxes to check. I've shared the
enough command line to be dangerous with a friend who has flirted with the
technical and I think it helped him develop the meta skill of technical
sophistication more than any specific command line skill. It's a greater
achievement than him knowing the all the flags for tar, because who does?

In any case, looking forward to reading through it and thanks for putting
these out there!

~~~
mhartl
Thanks! Developing the theme of _technical sophistication_ has been one of the
most surprising and gratifying side-effects of making tutorials designed for
complete beginners. I'm hoping to continue the theme in each subsequent Learn
Enough tutorial, and I'm thinking of adding it to the next edition of the
_Ruby on Rails Tutorial_ as well.

~~~
BWStearns
Please do! It really struck me as a theme that I hope grows beyond a Hartl-
only concept. It succinctly describes a previously unnamed concept. It's the
thing that you want to impart when you get that exasperated feeling trying to
explain over the phone to a non-technical friend/relative how to go about
fixing something that you yourself don't explicitly know how to fix but could
easily if you were sitting at their computer.

More broadly have you though about a generic way to achieve/impart technical
sophistication intentionally other than as a side effect of getting scraped
knees doing technical things?

~~~
mhartl
_More broadly have you though about a generic way to achieve /impart technical
sophistication intentionally other than as a side effect of getting scraped
knees doing technical things?_

I don't think there's any way to avoid getting a few battle scars, but just
knowing about the idea of technical sophistication (and having a name for it)
turns out to be a huge help, as you observed.

------
wodenokoto
I've been looking forward to this one. Learn enough command line to be
dangerous is the best beginners guide to bash I've seen and it really made me
a lot more comfortable working with cli programs.

~~~
sharkjacobs
I just skimmed the first section of Learn Enough Command Line and discovered
you can hold option to use the mouse to insert the cursor in the middle of a
line.

I thought I knew how to use cli but now I feel like I need to go through this
whole tutorial to see what other incredibly obvious things I've been missing.

~~~
collyw
I would say thats a Unix specific thing more than CLI. It will work on Linux
web browsers. Unfortunately three button trackpads seem to be disappearing.

~~~
Freak_NL
Most Linux distributions by default configure the track-pad to emulate the
middle mouse by clicking the left and right button simultaneously. Not as nice
as an actual third button, but useful if you are on a laptop without a
peripheral mouse attached.

~~~
collyw
Last couple of laptops I have had were not able to click left and right
together. Another one for aesthetics versus usability.

------
ryderm
I can't speak for this book, but Michael Hartl's rails tutorial is what got me
addicted to programming, and is largely responsible for me switching majors to
CS during my undergrad and getting into the industry. He is a great technical
author. Give him your money.

------
noer
Out of curiosity, why do you use suggest using github in this book, but
bitbucket in rails tutorial?

~~~
mhartl
Excellent question. The main reason is that GitHub is great for free public
repos, which I generally like having as the default, and using GitHub also
enables a Secret Bonus™ at the end of the Git tutorial. When it comes to web
apps, though, it's better to err on the side of security, so in that case I
recommend using free private repos at Bitbucket. (These choices were made
mainly because public repos are free at GitHub and private repos are free at
Bitbucket. Both services are great and are definitely worth paying for, but in
a free online tutorial I prefer to recommend things that are also free.)

------
nickjj
Hi Michael,

This is the first I've heard of the softcover platform.

After some research it looks like it was posted on HN about 2 years ago, but
there's only a handful of books posted on the platform compared to let's say
leanpub who has a few thousand.

Since you just posted this book on softcover, it's safe to say you're still
happy using it, but why aren't more authors choosing your platform?

You would think after 2 years it would have gained traction, especially
considering how big your reach is from previously successful tutorials and
books.

I'm a content author and softcover looks nice. My main issue with leanpub is
that all sales data is anonymous and you can't obtain e-mail addresses of your
readers and your platform seems to solve that.

~~~
mhartl
Thanks for the note. Softcover is absolutely amazing for my purposes, but at
this point we think the educational market is more promising than the market
for self-publishing tools, so that's what we're focusing on now. This was
always part of our plan; I personally needed Softcover for the reasons you
mention, but it was an open question whether it would take off as a standalone
platform or whether we would end up focusing on making our own products.

A happy but unintended side-effect of making a platform is that it
dramatically lowers the barrier to _collaborating_ with other authors, and I'm
currently working with several other people on more advanced and varied Learn
Enough tutorials. This sort of collaborative publishing (with full control
over the publication pipeline) would be effectively impossible without
Softcover.

~~~
nickjj
I see, thanks for the reply.

So basically you've been spending your time and resources on creating the
books rather than promoting the platform?

I will certainly reach out to you in the future because having access to
e-mails is enough to move me off leanpub. In leanpub's defense they are a
great bunch of people. I've had a number of conversations with their
developers and they are always on the ball. Also never had any technical
issues with their platform as an author.

------
jakub_g
This series looks very interesting and hitting the sweet spot with high
knowledge density while still being casually readable.

Very nice of the author to put stuff on the website without the paywall.

Two semi-related links (though much different, focusing mostly on syntax):

[https://learnxinyminutes.com/](https://learnxinyminutes.com/)

[http://hyperpolyglot.org/](http://hyperpolyglot.org/)

------
noer
I'm a fan of the "Learn Enough..." series. I've found them to be written in a
really approachable way, ditto on rails tutorial. Great job!

~~~
mhartl
Thanks!

------
nickpsecurity
A previous thread and its uptake in FOSS showed I _really_ need to get a grasp
on Git soon. I'm more about practice than theory so I certainly liked this
line:

"focuses on Git essentials without getting bogged down in lots of heavy
theory."

Bookmarked it for later when I tackle that. Thanks ahead of time for writing
and sharing it.

------
moomoos891
I love you Michael Hartl!

------
gerbilly
>Learn Enough Git to Be Dangerous

$ git init

------
dave2000
Is there supposed to be a free book here? The page doesn't work on mobile; I
zoom in and a rectangle on the left pointlessly expands, covering the screen.

~~~
dave2000
I've whitelisted all the JavaScript on the site and now an additional annoying
box with "keep in touch" is floating over the centre of the page, and if I
scroll the page underneath up and down so that the box doesn't cover it I can
see "content not available". Is this your first site?

------
sotojuan
This looks great. Looking forwards to the Ruby one as well. I also saw Elixir
in the "Coming Soon" section. What are your opinions on the language?

~~~
mhartl
I don't know Elixir yet, but I'm collaborating with someone who does. I think
the plan is he teaches me, then I teach you. :-)

I've heard great things about Elixir, and its design is heavily influenced by
Ruby, so I think it will be a natural fit for Learn Enough to Be Dangerous.

~~~
thirdsun
Additionally a fully featured Phoenix Tutorial would be very welcome as well -
however that's probably a silly thing to suggest if you have to learn Elixir
first.

------
kiddz
Why didn't you do a corresponding screencast?

~~~
mhartl
Oh, that's definitely planned. :-) Even better, my Learn Enough to Be
Dangerous cofounders and I are working on a subscription service that will
integrate text and videos for the command line, text editor, and Git
tutorials, with many more to come (including the upcoming 4th edition of the
Ruby on Rails Tutorial). See
[http://learnenough.com/](http://learnenough.com/) to get some idea of what
we've got in store.

------
frozenport
git push --force?

~~~
mhartl
The `git push --force` command didn't quite make the cut, but if you can think
of a place where it fits into the current tutorial I'm certainly open to
adding it. Maybe it fits in as an exercise somewhere?

UPDATE: yebyen has suggested this was a meant as a joke. If so—good one!

UPDATE 2: I don't mean to imply that force-pushing isn't useful! As several
commenters below have noted, it most certainly is. But it's also most
certainly _dangerous_.

~~~
mmanfrin
I've seen `git push -f` used quite a bit over my career. Maybe it's bad
practice, but it's useful for:

1\. Organizations that want single-commit branches (e.g., where there's a lot
of cherry picking going on in a git-flow style to get certain features pushed
out) but you also want to keep 'savepoint' commits while developing. Squashing
a bunch of commits requires a -f if you've already pushed.

2\. Rebasing a branch (without making a bubble merge).

3\. For truly small quick fixes you notice when you've just pushed to CI (like
you left in a debug or a focus on some tests).

~~~
sjrd
Much more than that. `git push -f` and `git rebase -i` are _essential_ tools
to keep a history where _every commit passes CI_. And that is very important
for `git bisect`ing things later.

They are also necessary to keep a history where `git blame` can be used
effectively.

~~~
brianwawok
Rebasing shared branches is pretty nasty. Do people really keep a policy of
"every branch must pass CI" ?

I like rebase on my branches so I merge as a single commit at the head of the
branch I am merging into, but rebasing a shared branch is total ick.

As for needing every branch to pass CI forever to use git bisect.. that seems
a bit extreme. I think I have used git bisect like 3 times in the past 5
years? And each time I wrote a very simple unit test and fed it into git
bisect and was able to figure it out without a problem. If you are using git
bisect constantly I guess I can see, but that has another smell. Who cares
when it was broke, just fix the broke thing!!

~~~
mmanfrin
On shared branches, I think the rules are different. Rebasing a shared branch
is very sticky. But for single-dev branches, I think rebasing/forcing is fine
-- do what you want until it enters the main stream.

~~~
brianwawok
Sure but I think OP was advocating rebasing a shared branch so that git bisect
would always pass on each commit

~~~
setpatchaddress
git -f on a shared branch is a surefire way to lose commits. OMFG. It's better
not to allow it at all. git revert will undo damage adequately, just not
cleanly.

~~~
brianwawok
You usually won't lose commits with reflog, especially the more users of a
repo the more reflogs.. but yes a disaster to go find them again...

------
juped
Nothing in git is dangerous except push. This book advocates pushing quite
often, making its title pretty accurate.

:)

~~~
hvis
git reset --hard

~~~
slavik81
Generally recoverable by checking git reflog and doing another git reset
--hard back to how it was before.

git clean -dfx is the most probable way for me to delete something that I
never committed.

~~~
hvis
You missed the point of the '\--hard' argument. It destroys the local,
uncommitted changes.

That can be much scarier than 'git push -f'.

~~~
slavik81
Apparently we both need to write better, because you missed the point of my
example. Most—if not all—local changes that would be destroyed by git reset
--hard show up in git status.

git clean -dfx will wipe out ignored files, which do not show up in git
status, so it's much easier to forget about something you meant to keep.

~~~
hvis
I've never used 'git clean -dfx' routinely during development. On the other
hand, I've seen a colleague lose a few hours' work by forgetting to commit a
specific file out of a set, and then doing 'git reset --hard' for some reason.
'git status' didn't save him. Luckily, he did commit the corresponding tests
file.

------
samstave
This is wonderful thank you.

------
jeffwass
Nice logo!

~~~
Anjin
Thanks! There's also another variant that I created that we are using for our
beta testing "Special Ops" team signup page:
[http://www.learnenough.com/special-ops](http://www.learnenough.com/special-
ops)

~~~
jeffwass
FYI, that page renders strangely on Safari on my iPhone. The text runs past
the white rectangle background on the left half of the screen.

~~~
Anjin
Thanks. There were some quick changes that got pushed out as the post started
gathering steam today.

------
randiLee
This is great, thanks.

