Learn Enough Git to Be Dangerous
learnenough.com
learnenough.com
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!
® 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).
> 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
*: 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.)
It is all custom, and the Learn Enough series is using a variation on our web book layout that we created for the parent platform http://www.softcover.io - which is what is hosting the Rails Tutorial.
As far as I remember it it had good pacing and by the end of it I could write useful code (albeit initially brutishly ugly code that I will deny ever having written lol).
Also your book set me on my way with Ruby and Rails. I recommend it at least once a week. Thanks for everything.
Rails. In Python-land, Django hadn't won yet. (My first startup used a half-baked framework I wrote myself on top of Zope. I shudder at the memory.)
Also your book set me on my way with Ruby and Rails. I recommend it at least once a week. Thanks for everything.
You're very welcome! Glad to hear it. :-)
I do offer ebook sales, but of course I'm not selling the individual strips themselves, and the online version is free. Still, your comment has made me realize it's probably a good idea to double-check, so I'll probably drop Randall a line just to make sure.
Thank you for all your work!
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.
In any case, looking forward to reading through it and thanks for putting these out there!
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.
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.
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.
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.
The software is awesome for the purposes of writing the book. The reason I didn't go with softcover as a selling platform is that the new EU VAT rules came in and as a result I had to use someone that supported those new VAT collection rules.
So I ended up using softcover to generate the ebooks and html, but using gumroad (and leanpub) to sell them. So it's totally feasible to use softcover for writing your book but self-host the resulting html and keep control of your sales data etc.
In practice, if you're based outside of the EU then you can probably just ignore these regulations (many smaller US sellers seem to be taking this approach). It's hard to imagine the EU tax authorities chasing you down.
Other platforms that sell items globally tend to charge EU customers more which probably account for the VAT increase, but in the end gives the author roughly the same amount per sale?
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):
"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.
$ git init
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.
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.
Your books are great, I've been buying Learn Enough to be Dangerous preorders for topics I already know well because I learned so much from the Rails Tutorial dot-org. Thanks!
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).
They are also necessary to keep a history where `git blame` can be used effectively.
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!!
https://webcache.googleusercontent.com/search?q=cache:TKD0MW...
:)
git clean -dfx is the most probable way for me to delete something that I never committed.
That can be much scarier than 'git push -f'.
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.