Re: Learnin' some git. Was: RE: Is this the future of technical writing?

Subject: Re: Learnin' some git. Was: RE: Is this the future of technical writing?
From: Shawn <shawn -at- cohodata -dot- com>
To: "Sweet, Gregory (HEALTH)" <gregory -dot- sweet -at- health -dot- ny -dot- gov>
Date: Mon, 10 Nov 2014 10:26:47 -0800

To make matters somewhat more challenging, every company implements git in
a slightly different manner. It is a very flexible tool that way.

Even thought I am very technical (spent years as a Network Admin - Novell,
Windows, and Linux servers), I have not yet fully embraced git for
documentation in my current company. I find git`s CLI (via Cygwin terminal)
very cryptic and not quite suitable for documentation (IMO). To date, I've
been using it only as a backup application. Rather unnecessary because I
prefer and depend on my personal 3.5" HDD for off-site backup and my
Dropbox sync for instant cloud recovery.

Until Flare keeps their promise and adds in git support, I will likely not
use git for any important role.

That said, I am always interested in learning how others use git in their
technical communications role.

Best regards,

On Tue, Oct 28, 2014 at 12:40 PM, Sweet, Gregory (HEALTH) <
gregory -dot- sweet -at- health -dot- ny -dot- gov> wrote:

> 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
> Cheers!
> Greg
> >
*Shawn Connelly*
Technical writer
<shawn -at- cohodata -dot- com>

Read about how Georgia System Operation Corporation improved teamwork, communication, and efficiency using Doc-To-Help |


You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-leave -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit for more resources and info.

Looking for articles on Technical Communications? Head over to our online magazine at

Looking for the archived Techwr-l email discussions? Search our public email archives @


Previous by Author: Re: Is the STC worth it?
Next by Author: Re: Flare: Export/Print to PDF w. Single Topic?
Previous by Thread: Getting Acquainted With The Field
Next by Thread: Re: Learnin' some git. Was: RE: Is this the future of technical writing?

What this post helpful? Share it with friends and colleagues:

Sponsored Ads