From: "Junio C Hamano" <gitster@xxxxxxxxx>
Jordan DE GEA <jordan.de-gea@xxxxxxxxxxxxxxxx> writes:
+TRIANGULAR WORKFLOW
+-------------------
+
+In some projects, you cannot push directly to the project but have to
+suggest your commits to the maintainer (e.g. pull requests).
+For these projects, it's common to use what's called a *triangular
+workflow*:
+
+- Taking the last version of the project by fetching (e.g.
+ **UPSTREAM**)
+- Writing modifications and push them to a fork (e.g. **PUBLIC-FORK**)
+- Opening a pull request
+- Checking of changes by the maintainer and, merging them into the
+ **UPSTREAM** repository if accepted
+
+
+........................................
+------------------ -----------------
+| UPSTREAM | maintainer | PUBLIC-FORK |
+| git/git |- - - - - - - -| me/remote |
+------------------ ← -----------------
+ \ /
+ \ /
+ fetch↓\ /↑push
+ \ /
+ \ /
+ -------------
+ | LOCAL |
+ -------------
+........................................
I agree with other commenters that "PUBLIC-FORK" is a name that does
not capture the essense of the triangular being the next step
forward, compared to the "central shared repository" workflow, to
take advantage of the distributed nature of Git.
"Where you push so that somebody else can fetch from there" does not
have to be public. You may be submitting a course assignment there,
only to be seen by your professor but not by others in the class.
Also, you do not your call "LOCAL" a "LOCAL-FORK" and that is a good
thing. In a distributed world, everything is a fork, so adding
"-FORK" to a name is pretty much meaningless.
So neither "PUBLIC" nor "FORK" in "PUBLIC-FORK" is a good word to
describe this thing.
The only reason you are pushing there is because your "LOCAL" is
either not accessible from outside world, and/or you do not want to
give a direct access to it (otherwise you could have allowed an
access to whoever is going to fetch from you direct access to
"LOCAL" and be done with it without creating "PUBLIC-FORK").
That is why I reminded that we earlier in the design phase called
this "publish"; it is a place you give access to others a selected
work of yours that you choose to give them access to.
Given that clarification I'd be happier to go with it being one's 'Publish'
repo.
My initial reticence was because of the association of "publish" with vanity
publishing and other forms of over-sharing and self promotion.
A clarification/explanation that calling it a 'publish' repo is about
granting access, and possible open access, would make it more acceptable.
Whether you
are a leaf contributor, a student who got stuck and wants to ask
suggestions from your friends after looking your code over, or an
integrator of a big public project, I would view the act to push
into such a place you give selective visibility to your work to
others as publishing your work.
Agreed, in that context.
--
Philip
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html