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/
              • Re... Stewart Gordon via Digitalmars-d-announce
              • Re... lobo via Digitalmars-d-announce
              • Re... Vladimir Panteleev via Digitalmars-d-announce
              • Re... Stewart Gordon via Digitalmars-d-announce
              • Re... Stewart Gordon via Digitalmars-d-announce
              • Re... Vladimir Panteleev via Digitalmars-d-announce
              • Re... Stewart Gordon via Digitalmars-d-announce
              • Re... Jacob Carlborg via Digitalmars-d-announce
              • Re... Stewart Gordon via Digitalmars-d-announce
              • Re... Jonathan M Davis via Digitalmars-d-announce
              • Re... Rikki Cattermole via Digitalmars-d-announce
              • Re... Kagamin via Digitalmars-d-announce
              • Re... Rikki Cattermole via Digitalmars-d-announce
              • Re... tired_eyes via Digitalmars-d-announce
              • Re... Vladimir Panteleev via Digitalmars-d-announce
              • Re... tired_eyes via Digitalmars-d-announce
  • Re: dsource.org moved Stewart Gordon via Digitalmars-d-announce

Reply via email to