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.
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.
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
> 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
<shawn -at- cohodata -dot- com>
Read about how Georgia System Operation Corporation improved teamwork, communication, and efficiency using Doc-To-Help | http://bit.ly/1lRPd2l