TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Learnin' some git. Was: RE: Is this the future of technical writing?
Subject:Learnin' some git. Was: RE: Is this the future of technical writing? From:"Sweet, Gregory (HEALTH)" <gregory -dot- sweet -at- health -dot- ny -dot- gov> To:Julie Stickler <jstickler -at- gmail -dot- com>, "Cardimon, Craig" <ccardimon -at- m-s-g -dot- com> Date:Tue, 28 Oct 2014 19:40:10 +0000
I broke this out into a new thread since learning git really is its own topic.
Yes, he wrote the git documentation at git-scm. And yes it is a bit much if you take it out of order. It is not so much a reference book as it is a lesson plan building from one topic to the next. I struggled mightily to get up to speed on git myself, until I
1. Abandoned the GUI.
2. Read Pro GIt, in order, front to back (OK I skimmed the chapters on internals and installing it on servers since I don't deal with that stuff).
Git does come with its own new unique vocabulary. And until you come to grips with what a push, pull, fetch, merge, remote, branch, head. etc. are you are not going to be successful. Tack on that some Git implementations add their own layers and terms and you can get deep in the weeds quick. Picking the right command out of the GUI is not always so straight forward, but if you learn this stuff from the command line, so you know which commands are shorthand for others and have to keep track of repo , remote, and branch manually, it will be much, much simpler to understand what's happening when you go back to using the GUI. Also the command line coaches you where the GUI doesn't. Don't forget to roll in the Git system you will be using to what you've got to learn. For example Gitblit does not do Pull Requests, it has tickets but GitHub has both Tickets and Pull Requests.
How do you learn the command line stuff? Read the book, front to back, in order. Just do it. It's worth your time.
I just downloaded the revised book and am looking forward to diving in after lunch.
BTW: For my own sanity and learning I put together a Git quick reference card. I just dropped on Git hub to make it easy to share. See https://github.com/gps03/myGitQRC
Cheers!
Greg
> -----Original Message-----
> From: techwr-l-bounces+gregory -dot- sweet=health -dot- ny -dot- gov -at- lists -dot- techwr-l -dot- com
> [mailto:techwr-l-bounces+gregory -dot- sweet=health -dot- ny -dot- gov -at- lists -dot- techwr-l -dot- com]
> On Behalf Of Julie Stickler
> Sent: Tuesday, October 28, 2014 10:41 AM
> To: Cardimon, Craig
> Cc: techwr-l -at- lists -dot- techwr-l -dot- com
> Subject: Re: Is this the future of technical writing?
>
> Oh sweet baby Jeebus I hope not. I'm not sure if he's the fellow that wrote
> the base Git documentation or not (http://git-scm.com/documentation),
> but I can tell you, it's atrocious. I have struggled for the past two years to
> learn my way around Git. I have read and re-read their documentation as I
> struggled to resolve issues I've had with Git, and as many times as I've read
> it, half of it still doesn't make any sense to me because it's so full of jargon
> and makes huge assumptions about what the
> audience understands. And I don't think it has anything to do with the
> fact that I'm a technical writer and not a developer. because many of our
> developers and QA engineers seem to have trouble doing more than the
> basic functions in Git. We rely a lot on our couple of in-house Git experts to
> troubleshoot problems.
>
> Honestly, I don't care what tool chain you used to write your doc, if the doc
> that you produce is not helpful to your users, then you've wasted everyone's
> time. Yours as a writer, and your audience's as a reader.
>
>
>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Read about how Georgia System Operation Corporation improved teamwork, communication, and efficiency using Doc-To-Help | http://bit.ly/1lRPd2l
