Pull Request Workflow

The Trilinos Pull Request Testing page describes what a developer can expect when submitting a pull request and a few special labels that can be applied to pull requests to achieve desired behavior.

There are multiple effective workflows that can be used to submit Pull Requests. The workflow described below assumes that a developer simply wants to make some changes to the Trilinos/develop branch and is not already working on a topic or other branch. Pull requests can also be submitted against other branches, for example release branches, using an analogous approach. Pull requests should not be submitted directly against the master branch, but rather should be submitted to develop, and then promoted via the develop->master testing process. Click on the arrow to see additional details about many of the below steps.

1. Fork Setup (one time only)

Create a personal fork of Trilinos on GitHub. Go to the Trilinos repository page on GitHub and click on "Fork" near the upper right corner of the screen.

2. Cloning the fork and setting the remotes (one time only)

• git clone [email protected]:<your_github_username>/Trilinos.git Trilinos.fork
• cd Trilinos.fork/
• git remote add upstream [email protected]:trilinos/Trilinos

3. Update fork from main repository

• git fetch upstream
• git checkout --track origin/develop
• git pull upstream develop
• git push

("develop" in the above commands can be replaced with the name of another branch to update that branch.)

4. Create and checkout a branch to make changes on

• git checkout develop
• git branch <my_branch_name>
• git checkout <my_branch_name>

5. Make, commit, and test changes to new branch

6. Bring in the most recent changes from develop

• git fetch
• git checkout <my_branch_name>

At this point, changes can either be merged in from the develop branch, or changes made to <my_branch_name> can be rebased against the current version of develop using one of the following commands. There are pros and cons to rebasing or merging. Very briefly, rebasing maintains a nicer history, while merging is safe to do in all cases.

• git merge upstream/develop

or

• git rebase upstream/develop

7. Test with most recent changes from develop

8. Push branch to GitHub fork

• git checkout <my_branch_name>
• git push origin <my_branch_name>

9. Create pull request on GitHub

The process for submitting a Trilinos pull request is the same as for other GitHub pull requests, except there are a few extra details to note. Most importantly, the pull request must be submitted against the develop branch of the trilinos/Trilinos GitHub repository, or the Trilinos Autotester will not process the pull request.

See the Trilinos Pull Request Testing page for information about a few special labels that can be applied to pull requests to achieve desired behavior and for a general overview of the Trilinos pull request testing capability.

10. Delete branch after the pull request has been merged

• git push --delete origin branchname