dsource.org moved

Fri Apr 24 20:33:31 PDT 2015

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