Creating Proper Pull Requests
It's completely fine to just submit a small pull request without first making an issue, but if it's a big change that will require a lot of planning and reviewing, it's best you start with writing an issue first.
The steps given below are for the main Redox project - submodules and other projects may vary, though most of the approach is the same.
Using Git in terminal
- In an appropriate directory, e.g.
~/tryredox, clone the Redox repository to your computer using one of the following commands:
git clone https://gitlab.redox-os.org/redox-os/redox.git --origin upstream --recursive
git clone email@example.com:redox-os/redox.git --origin upstream --recursive
- Use HTTPS if you don't know which one to use. (Recommended: learn about SSH if you don't want to have to login every time you push/pull!)
- If you used
bootstrap.sh(see Building Redox), the
git clonewas done for you and you can skip this step.
- Change to the newly created redox directory and rebase to ensure you're using the latest changes:
cd redox git rebase upstream master
- You should have a fork of the repository on GitLab and a local copy on your computer. The local copy should have two remotes;
upstreamshould be set to the main repository and
originshould be your fork. Log into Redox Gitlab and fork the Repository - look for the button in the upper right.
- Add your fork to your list of git remotes with
git remote add origin https://gitlab.redox-os.org/MY_USERNAME/redox.git
git remote add origin firstname.lastname@example.org:MY_USERNAME/redox.git
- Note: If you made an error in your
git remotecommand, use
git remote remove originand try again.
- Alternatively, if you already have a fork and copy of the repo, you can simply check to make sure you're up-to-date. Fetch the upstream, rebase with local commits, and update the submodules:
Usually, when syncing your local copy with the master branch, you will want to rebase instead of merge. This is because it will create duplicate commits that don't actually do anything when merged into the master branch.
git fetch upstream master git rebase upstream/master git submodule update --recursive --init
- Before you start to make changes, you will want to create a separate branch, and keep the
masterbranch of your fork identical to the main repository, so that you can compare your changes with the main branch and test out a more stable build if you need to. Create a separate branch:
git checkout -b MY_BRANCH
- Make your changes and test them.
Commit messages should describe their changes in present-tense, e.g. "
git add . --all git commit -m "COMMIT MESSAGE"
Add stuff to file.ext" instead of "
added stuff to file.ext". Try to remove duplicate/merge commits from PRs as these clutter up history, and may make it hard to read.
- Optionally run rustfmt on the files you changed and commit again if it did anything (check with
- Test your changes with
- Pull from upstream:
git fetch upstream git rebase upstream/master
- Note: try not to use
git pull, it is equivalent to doing
git fetch upstream; git merge master upstream/master.
Repeat step 10 to make sure the rebase still builds and starts.
Push your changes to your fork:
git push origin MY_BRANCH
On Redox GitLab, create a Merge Request, following the template. Describe your changes. Submit!
If your merge requests is ready, send the link on Redox Merge Requests room.
Using GitLab web interface
- Open the project repository that you want and click in "Fork" to create your fork.
- Click in "Web IDE" to open the GitLab IDE for browsers and make your changes.
- Click in "Create commit" to apply your changes (try to not flood your fork with little commits, it's Ok to make bigger commits).
- Return to the main page of your fork (you can click on the name in the top left position inside of Web IDE).
- Click in the "Merge Requests" on the left side.
- Select your fork branch and create the merge request.
- If your merge requests is ready, send the link on Redox Merge Requests room.