Is this a suggested process for using GitHub with a team?

I am getting help from other developers for the first time on a repo that I am administrating, and I want to make sure I understand how the flow of work should go. The repo is setup under an Organization, and the other developers are members of a team with read access. I have owner access. Here is what I am thinking would be the flow of work:

  1. He forks the repo
  2. He creates a new branch
  3. He makes changes, adding commits
  4. He submits a pull request
  5. I merge the pull request into the upstream branch

Am I on the right track here?

  • Reapply Git commits from copied fork repository to original repository
  • Get git current branch/tag name
  • Can git be configured to disable merges for particular file types?
  • git push to existing remote branch
  • Gitlab: Unable to clone by http (cloning by ssh works well)
  • Is there a command to undo git-flow feature start?
  • Is it possible to have a tracked .gitignore AND an untracked .gitignore?
  • git remove file from stash
  • How to unshelve changes using git-p4
  • How to make Git submodules easier for non-programmers?
  • How to erase a published Git commit from history?
  • Can Git handles this use cases?
  • One Solution collect form web for “Is this a suggested process for using GitHub with a team?”

    Yes, that’s how we do things. (He makes the branch on his own fork.) But what you’re missing is how people keep their own branches coordinated with the main fork’s master branch.

    We handle this by regularly rebasing off the main “upstream” branch’s master, and using our own repository’s master branch as a copy of upstream’s:

    On our own repository’s master:

    $ git fetch upstream
    $ git rebase upstream/master
    $ git push origin master
    

    Periodically, on our branches:

    $ git rebase master
    

    We’re also careful to avoid changing the same lines of the same files.

    Git Baby is a git and github fan, let's start git clone.