Difference between revisions of "Creating GitHub Pull Requests"

From Gentoo Wiki
Jump to:navigation Jump to:search
Line 10: Line 10:
 
Afterwards, follow the suggestions given by reviewers and push updates until the pull request is fully approved. If you do not receive a reply within a reasonable time, please make sure to ping us on the pull request. When it's ready and approved, we'll merge it.
 
Afterwards, follow the suggestions given by reviewers and push updates until the pull request is fully approved. If you do not receive a reply within a reasonable time, please make sure to ping us on the pull request. When it's ready and approved, we'll merge it.
  
It is recommended that you try to keep the same commit structure as you'd use when committing straight to Gentoo as a developer, and follow the best git practices (atomic changes, proper commit messages). For smaller changes, we can squash and reword the commits for you. However, if you're going to actively maintain multiple packages or submit larger changes, we will require you to squash, split and word your commits appropriately. Please see the git documentation on [https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History rewriting history]. Once you've got updated commit set, use <code>git push --force</code> to overwrite your previous commits on the pull request branch.
+
Please keep the same commit structure as you would use when committing straight to Gentoo as a developer, and follow the best git practices (atomic changes, proper commit messages). For smaller changes, we can squash and reword the commits for you. However, if you are going to actively maintain multiple packages or submit larger changes, we will require you to squash, split and word your commits appropriately. Please see the git documentation on [https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History rewriting history]. Once you've got updated commit set, use <code>git push --force</code> to overwrite your previous commits on the pull request branch.
  
 
=== Step 0: User configures the local repository ===
 
=== Step 0: User configures the local repository ===

Revision as of 16:32, 1 December 2017

GitHub pull requests for Users and Proxied Maintainers (please shorten this)

Workflow of a user contribution. The green arrows show the path of contribution. Grey arrows are optional, possible access directions.

The most efficient way of submitting your contributions is through pull requests on our GitHub repository. At the moment, it gives the best response time, the widest audience for reviews and some nice scripting (including CI) to help.

Tip
Once you push your new branch, visit the GitHub page of your fork. GitHub will show you a banner suggesting creating a pull request. Using it, you can avoid the necessity of specifying the fork and branch manually.

Once the pull request is created, our tooling will automatically CC the relevant people (maintainers and/or proxy-maint team) and perform basic QA checks via pkgcheck. If any issues are reported, please fix them or explicitly ask for help. Our reviewers may skip pull requests which are marked as not passing CI.

Afterwards, follow the suggestions given by reviewers and push updates until the pull request is fully approved. If you do not receive a reply within a reasonable time, please make sure to ping us on the pull request. When it's ready and approved, we'll merge it.

Please keep the same commit structure as you would use when committing straight to Gentoo as a developer, and follow the best git practices (atomic changes, proper commit messages). For smaller changes, we can squash and reword the commits for you. However, if you are going to actively maintain multiple packages or submit larger changes, we will require you to squash, split and word your commits appropriately. Please see the git documentation on rewriting history. Once you've got updated commit set, use git push --force to overwrite your previous commits on the pull request branch.

Step 0: User configures the local repository

Copy the upstream Gentoo repository under the remote name "upstream".

user $git clone -o upstream git+ssh://git@git.gentoo.org/repo/gentoo.git
Github fork.png

Fork the Gentoo repository on GitHub and then add it under the remote name "github" to your local repository.

user $git remote add github <YOURURLHERE>

Step 1: User updates the local repository

Circular workflow step1.png

Say you are making changes to package app-foo/bar. Create a local branch with your changes:

user $git checkout -b app-foo/bar

Make your changes and make sure to run repoman to check for basic errors:

user $repoman -dx full

Then commit your changes.


Step 2: User makes a pull request

Now that you've made your changes and updated your local branch, it's time to send it off to GitHub and make a PR (Pull Request) to the Gentoo Developers.

Start by pushing the branch with your changes to your GitHub repository:

user $git push github app-foo/bar

Then create a pull request from your GitHub repository's local branch to the Gentoo repository's master branch. When your changes have been merged, you may delete your local repository's branch with:

user $git branch -d app-foo/bar
Circular workflow step2.png

Step 3: Developer fetches the PR and reviews

Circular workflow step3.png
dev $curl -s -L "https://github.com/gentoo/gentoo/pull/1.patch" | git am -s -S
dev $repoman full -x
dev $ # tests

Step 4: Developer merges to the tree

Circular workflow step4.png
dev $git push --signed origin master

References

https://www.gentoo.org/glep/glep-0066.html
https://wiki.gentoo.org/wiki/Gentoo_git_workflow
https://wiki.gentoo.org/wiki/Gentoo_GitHub
https://www.gentoo.org/glep/glep-0063.html
https://wiki.gentoo.org/wiki/Project:GitHub/Pull_requests