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

[Shawn <shawn -at- cohodata -dot- com>]

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,
Shawn

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
> https://github.com/gps03/myGitQRC
>
> 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 | http://bit.ly/1lRPd2l

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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
http://www.techwhirl.com/email-discussion-groups/ for more resources and info.

Looking for articles on Technical Communications?  Head over to our online magazine at http://techwhirl.com

Looking for the archived Techwr-l email discussions?  Search our public email archives @ http://techwr-l.com/archives