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
