Re: [PLUG] Git: net time gain or loss?

[Fred Stluka <fred@bristle.com>]

On 12/20/18 8:22 PM, JP Vossen wrote:
> I found Bzr really easy, because it's very friendly and has great 
> docs. In a way that hurt me with Git, because I expect the same and am 
> always disappointed.  Note, I have the Bat Book and have read it at 
> least twice.  But I shouldn't have had to!
JP, I'm not sure what your complaint is about the Git docs.

I'm a huge fan of O'Reilly books, but I never bothered with the
O'Reilly Git book (the "Bat Book") because the free on-line Git
docs and manuals are SO GOOD.

There was a book called "Pro Git" that was very popular, and
better than the on-line docs, but in 2011 or so, it got donated
as FOSS and replaced the on-line docs.  I bought a hard copy
at Amazon, but also downloaded the free PDF file.  It's also
available free in e-book formats like epub and mobi.  See the
fully indexed, clickable, searchable HTML version at:
- https://git-scm.com/book/

I think it's REALLY well written.  Lots of VERY simple and easy
to understand pictures, illustrating the concepts of VCS and Git.

I claim that within 30 minutes of reading, the average new dev
on your team should be able to learn Git enough to start work.
Can install Git, edit code, stage, diff, commit, push, pull, tag,
etc., with a solid understanding of what, how and why.

Another 30 minutes to learn everything there is to know about
branching.

*Details to support that claim:*

Within the 1st 4 printed pages (mostly filled by 3 large but
simple pics), you know what VCS is, and why distributed is
better than not.

4 more pages with 3 pics tell you the history, advantages, and
basic operations of Git.

5 more pages and you have it installed on Linux, Mac or
Windows, or from source (4 separate sets of instructions).
And configured to use your preferred editor, diff tool, etc.
And you know how to use the built in help.

Chapter 2 is a total of 32 pages and tells you pretty much
everything you need to know to be productive, with LOTS of
detailed examples, exact CLI syntax, etc:
- Creating or cloning a repo
- Local files vs staged changes vs committed changes
   - Seeing all local files, seeing all staged files, etc
   - Diff commands to see local changes, staged changes, etc.
   - Renaming, moving and deleting files
   - Staging, unstaging, committing
- Configuring Git to ignore files that you don't want in VCS
- Viewing history (the "git log" command, plus 7 pages of
   detailed examples of how to slice and dice the history by
   file, committer, time range, stats, summaries, printf-style
   formatting of the history output, visual graphs of the
   relationships between commits, using the gitk GUI tool to
   browse the history as graphs plus drill down details of
   files and diffs in each commit, etc. -- really WAY more
   than I expected to find in a "Git Basics" chapter)
- Amending your most recent commit
- Working with local and remote repos (showing them,
   pushing, pulling, fetching, etc.)
- Tagging commits (creating, showing, deleting, moving,
   verifying, and sharing tags -- again WAY more than I
   expected in a "Git Basics" chapter)
- Git aliases, tips/tricks, and other convenience features

The pages are short, with a large font, lots of pictures,
and clear indicators of what you can really afford to skip
at first.  Even if you read all 45 pages in detail, you're
probably done in a half hour or so.  And can now be
VERY productive on your first Git project.

Chapter 3 is only 31 pages, more than half of which is
consumed by 42 large VERY clear pictures.  It has 2 parts:
- "Branching" (23 pages) that does a great job of explaining
   EVERYTHING there is to know about branches (creating,
   merging, deleting, local vs remote, etc.)
- Rebasing (8 pages) that I should never have even bothered
   to read.  I've NEVER done a rebase in my 8 years of using
   Git, even though I was usually the most senior dev on the
   team and was the sys admin for our Git repo before we
   moved it to BitBucket or GitHub.  If anyone on any of those
   project was ever doing a rebase, it would have been me or
   someone that I taught how.

The rest of the book covers all sorts of topics that the typical
dev doesn't need to know:
- Creating a repo for the team at BitBucket or GitHub
- Setting up a remote server repo if you don't want to use
   BitBucket or GitHub
- Various workflows for various types of projects (as we've
   discussed here quite a bit)
- Cherry-picking (for 8 years, I've always been the only one
   on the team who had any idea how to do this, and have
   only done so in emergency situations caused by the team
   not yet learning to use branches properly)
- Advanced tools for patching, stashing, re-writing history,
   squashing, re-ordering, submodules, etc.)
- Git "bisect" (very useful on occasion, but a VERY advanced
   feature)
- Customizing Git
- Diffing binary files (yes, you CAN, but do you really want to?)
- Git "hooks" (client-side and server-side)
- Enforcing policies
- SVN and Perforce (pros/cons vs Git, converting, integrating
   with Git, use of "git svn" and "git-p4" commands, etc.)
- Git internals

Are the Bzr docs really better than that?

--Fred
------------------------------------------------------------------------
Fred Stluka -- Bristle Software, Inc. -- http://bristle.com
#DontBeATrump -- Make America Honorable Again!
------------------------------------------------------------------------

___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug