discuss: Getting Started With Working With Git
Subject:
Re: Getting Started With Working With Git
From:
"Martin A. Brown" ####@####.####
Date:
4 Feb 2016 00:29:52 +0000
Message-Id: <alpine.LSU.2.11.1602031525290.2025@znpeba.jbaqresebt.arg>
Hi there again Paul,
>How can I start submitting to Git? Is there a getting started guide
>I can read?
Yes, there are probably (entirely too many) starting points for
learning git. I will provide a few framing notes and some links,
although I confess to never having taught anybody about git before.
Some framing notes:
* git is a distributed version control system
* every file is hashed and stored by its hash
* all other objects are also identified by a hash; blob, tree,
commit, tags, files and other objects are also identified by a
hash; this is fundamental to git (and, similarly hg)
computer scientists refer to this as content addressable
storage [0])
* each person who has a copy (clone) of the 'git' repo has the
whole repository with its entire history
* the special .git directory contains the repository and entire
history of the repository; most times you want to be working at
the newest edge of history and making your changes there; by
default when you 'git clone', you'll not only get the whole
repository (required), but also a complete checkout into your
local working directory of the most recent (newest) master
branch; this represents the newest files
* each git history is stored internally as a special kind of tree
called a directed acyclic graph (DAG); a copied repository
history can be newer (more changes than on the original) or
older (the original has been updated SINCE copying or cloning)
(to visualize the DAG, see: https://github.com/tLDP/LDP/network
for our project; I don't quite understand why my name is there
and not mkomarinski's who has recently contributed, but you can
get the idea of independent "forks" of a project proceeding in
independent histories and watch them get merged back into the
canonical TLDP repository) [You can look at this on any
github.com project you like--useful for visualizing the
abstract concept here.]
* by convention, each project identifies a canonical repository
Ours is: http://github.com/tLDP/LDP (for most of our documents)
It is merely convention that a specific repository is regarded
as the canonical repository. But, that's useful for us humans.
* when somebody makes changes in his/her git repository and wishes
the canonical source to accept them, this is called a "pull
request" because the admins of the canonical service will,
essentially accept and merge in the changes by PULLing the
changes into the canonical repository
* if multiple contributors make changes to the same file (in
separate locations), you MIGHT have a problem with merging those
changes; this is where careful attention is required by the
person accepting the 'pull request' and ideally the person
initiating the request
* internally, each contributor's copy of the git repository may be
at a different position in a shared history; some may be ahead
of the canonical repository; some may be behind;
Links:
* The canonical git documentation and pages:
http://git-scm.com/doc
* GitHub has a Hello World tutorial that you can walk through
with your own account. They also provide a training system
that is targeted to CLI freaks and their web interface:
https://guides.github.com/activities/hello-world/
https://training.github.com/kit/
* This was instructive for me when trying to conceptualize git.
http://eagain.net/articles/git-for-computer-scientists/
* Here's another, more colloquial introduction to the concepts
around git (I like it, even though I haven't finished reading
it yet):
http://gitolite.com/gcs.html#(1)
There are probably other links and resources, however, I'm not sure
which ones to best suggest. I found the O'Reilly book pretty useful
when I was still becoming familiar with git:
http://shop.oreilly.com/product/0636920022862.do
(Of course, I can't find my copy now! Too much moving around!)
Finally, here's what I might suggest to get started, assuming you
are comfortable with github.com:
* make a github.com account for yourself
* fork the TLDP repo
* make a trivial change (CLI or web interface) to one of the
one of our document (say, for example,
LDP/LDP/howto/linuxdoc/Template-Linuxdoc-Small-HOWTO.sgml)
* issue a pull request
* enjoy an cup of tea to celebrate success when your first pull
request is accepted into the canonical repository
Comments:
* I don't completely 'get' the way that github.com works as I'm
web interface impaired, i.e. I prefer the CLI. I hope I didn't
suggest anything that is impossible or tricky with their UI.
* If you don't like github.com, you can still clone freely without
registering on their service; and we (somebody, probably me for
now) can apply patches supplied via email.
* I would recommend trying to understand the git conceptual model
first and then play a little bit.
Thank you for asking....
Good luck and enjoy,
-Martin
[0] https://en.wikipedia.org/wiki/Content-addressable_storage
--
Martin A. Brown
http://linux-ip.net/
