On 16. Oct 2018, at 20:03, Marshall Schor <[email protected]> wrote: > > For working on our own projects, where we have "permissions", is it correct to > think that > > 1) at the Apache writeable-Git spot, we go to the repo, and clone it to our > local computer,
On a social coding site like GitHub, you normally fork only repos that you do not have write permissions to. The purpose of the fork is that you create a space where you can push your changes and offer them to others, usually via a pull request. If you are a maintainer of an open source project and already have write permissions on your GitHub repo, there is no need to fork it. > 2) on the local clone, make a branch Aye > 3) do changes, test etc., and commit to the branch Aye > 4) push the branch back to writable-Git spot (because we have committer > permissions) Aye - if you have commit permissions to the main project repo, you push your branch directly to it. You could even not make a branch and simply push your changes to master (or some other development branch). That would pretty much what you are used to from SVN. But, I would recommend adopting the branching practice. Branching is very cheap and easy in git and you'll only learn to value the branches after making it a habit to create them. > 5) ask the "owner" (or maybe pretend to be the owner) to "pull" the branch > into > the master, after they are satisfied. If you are the sole developer: yes - you merge your own PRs (or as mentioned above, you simply always commit to master) If you are not the sole developer and you have a reasonably active project, you might want to choose that every PR should be reviewed and approved before merging. It is possible to set up GitHub in such a way that merges are not enabled unless certain quality criteria have been met, e.g. unless Jenkins succeeds building the PR, unless the PR branch is up-to-date with respect to the target branch (i.e. no surprises after merge), or unless a configurable number of approvals have been given. Of course, as a project owner, you can always merge. > So in this case, there's no need to make a fork of the repo on the Apache > writeable-Git spot, correct? If you have write permissions to the project repo -> no need to fork. > That was only needed if there were no permissions > to push the new branch back into the original repo? Exactly. > ====== > > In a previous reply, when you don't have permissions, it said: go to the > GitHub > website, fork the "maven-gpg-plugin"repo under your own GitHub account, then > clone *that*. > > When this mentions "the GitHub website", does this refer to > github.com/my-spots, > or github.com/apache/some-new-repo-I-create. I'd say that "GitHub website" in this case refers to "https://github.com/apache/maven-gpg-plugin"; You go there and press the "fork" button - since you do not have karma to commit to that repo. The fork will be created as "https://github.com/mischor/maven-gpg-plugin";. > In other words, should we try to > put forks for this purpose under the "apache" "section" of github? What's the > right "protocol"? You cannot create repos under "https://github.com/apache"; - only INFRA can do that. If you wanted to avoid creating a fork under your own account (https://github.com/mischor), you'd have to ask the Apache PMC to which you want to contribute for committer permissions so that you could push your branch there directly. Cheers, -- Richard
