dsource.org moved

[Rikki Cattermole via Digitalmars-d-announce]

On 25/04/2015 3:33 p.m., Jonathan M Davis wrote:
> 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

Also if you are on Windows or OSX, use SourceTree[0]. I cannot recommend 
this enough.
It'll install git, wrap it up nicely for you and even show pretty 
imagery regarding the current state of the repo!

[0] http://www.sourcetreeapp.com/