On Sunday, 23 July 2017, at 16:50:40 BST, Terry Coles wrote:
> Is there a 'proper' way to grab a copy of a program from Github
> without making a Pull Request?
In git terminology, there exist both pulls and pull requests,
which are different things.
If you issue a pull request, you are asking somebody else to
"pull" your changes into their local repository.
Whereas, if you do a pull, that would be you pulling changes into
your local repository.
It's confusing that these are so similarly named, if you ask me.
Lots of students on my degree course were tripped up by that when
first introduced to git.
My beginner's understanding is that you need to "clone" the
repository; that is, make a local copy of the repository, which
is then managed by the git(1) program on your machine. You would
do this using the git-clone(1) command in a terminal, or some
equivalent in a GUI frontend to git.
Having created your local repository, you can use it as a working
directory for development, testing, debugging and so on, and use
git commands to manage it and track changes locally.
I suspect that git is something that different teams and projects
will have different ways of using. But in any case, at some point
you will reach a stage where you or your team feel that the
changes you've made are (a) worth keeping and (b) at some
sensible juncture where it makes sense to record the changes. At
this point, you would make a commit, and give it a useful
description, using git-commit(1).
Commits represent a snapshot of the contents of the repository,
and initially exist only locally. They derive from previous
commits, and are in principle (somewhat) immutable, so that when
you push them to another repository, they fit nicely into the
existing graph that contains the commits upon which they were
based.
Having made one or more commits locally, you can "push" them from
your local repository to the remote repository, or "pull" them
the other way if somebody else made a change (or sent you a pull
request). Predictably, the commands are git-push(1) and git-
pull(1). I think of this as synchronising the graph of commits
between the different copies of the repository, though I suspect
there are subtleties that this mental model ignores.
git(1) doesn't inherently enforce a single, central, remote
repository; you could just as well be pushing and pulling between
several distributed repositories in some other topology. However,
the commonality between the different possible topologies seems
to be that all the repositories share the same graph of commits.
I suppose different projects probably have different policies or
conventions for when and in what manner to push, pull, issue pull
requests, and whatever other tricks git has up its sleeve that
I've not yet discovered.
Other things that seem important to read the manual on include:
git-checkout(1)
git-branch(1)
git-merge(1)
My understanding of these is weak, so I won't attempt to explain
them myself, but I recall having to read about them in order
reach my current understanding of git.
I expect somebody with more git experience can answer your
questions more precisely and concisely, but hopefully my
meandering beginner's perspective is also useful.
Patrick
--
Next meeting: Bournemouth, Tuesday, 2017-08-01 20:00
Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/
New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
