On Friday, 24 April 2015 at 21:48:30 UTC, Stewart Gordon wrote:
On 22/04/2015 08:20, Jacob Carlborg wrote:
<snip>
If you're forking a project on Github you get your own copy of
the project. The projects
are linked but the repositories are not. What I mean by that
is on your fork you'll see
that it is a fork with a link back to the original project.
From the original project you
can also view all forks.
The repositories are not linked in the sense that there's no
automatic syncing of code
between them. The fork needs to manually pull from the
original repository to get the
latest changes.
I guess the word "link" has too many meanings. :p
So a fork is really a working copy of the master repository,
and the code that the user will typically edit is in turn a
working copy of this. And "commit" and "push" in Git terms
basically mean to commit to the local fork and to commit the
fork to the master repo respectively.
So if "pull" means to update one's fork, what is a "pull
request" requesting exactly?
With git, technically, no repo is more important than another,
since it's a distributed source control system rather than a
centralized one. Everyone gets their own, independent repo, with
its own commit history. Pushing and pulling and whatnot don't
care about which repo is the "primary" repo or anything like
that. It's just taking a set of commits from one repo and putting
them in the other repo.
"Committing" is _always_ to your local repo. You never commit to
another repo.
"Pushing" is when you control both repo A and repo B, and from
the machine with repo A on it, you push a set of commits into
repo B. It therefore requires that you have the permissions to
manipulate repo A directly on the machine that it's on (since
you're doing the operation on that machine) and that you have
write permissions for repo B (since you're commanding repo B to
take your commits from repo A).
"Pulling" is when you do the commands from the machine with repo
A on it and take the code from repo B and put it in repo A. You
only need read permissions for repo B in that case (so it could
be a public repo that you have no control over whatsoever).
The typical workflow with github is that you create a branch on
your local machine and make commits with whatever changes you're
making. You then push that branch into your github repo for that
project. So, you've created a branch there which then matches
your local branch (and if you need to make further commits, those
would have to be pushed separately). Then you create a pull
request from your github repo for the target repo (typically the
primary repo for the project, but it could be the repo of someone
else you're working with). Typically, it's targeting the master
branch of the target repo, but it could be for any branch in that
repo. Whoever controls the target repo is notified of your pull
request. They can then look over the code, suggest changes, etc.
Once they're satisfied with it, they can hit the merge button on
github. That tells github to pull the code from the branch in
your github repo into the target repo. After that, anyone who
pulls from the target repo will get your changes. And normally,
you'd delete the branch that you used for that pull request and
create a new one for whatever your next set of changes are.
So, normally, you only push to your own github repo, and
everything else is done via pulling.
Now, you _can_ just push to the primary repo rather than your own
github repo if you have the permissions for it, but then the code
doesn't get reviewed, and only folks who have push permissions
for that repo can do that (which most folks won't have).
Operating that way is basically operating how svn operates, which
pretty much everyone using git will tell you not to do.
Hopefully, that explanation helps, but you really should read
some of the guides out there for this, since they'll have pretty
pictures (which can help considerably) and probably explain it
better than I do. e.g.
https://guides.github.com/introduction/flow/index.html
http://nvie.com/posts/a-successful-git-branching-model/
https://blogs.atlassian.com/2014/01/simple-git-workflow-simple/
https://sandofsky.com/blog/git-workflow.html
- Jonathan M Davis
