Making a PR to SecureDrop

Forking and Cloning the Project

Fork SecureDrop on GitHub from the Main Repository to your own profile.
Clone the forked repository.

git clone https://github.com/<your-username>/securedrop.git
cd securedrop

Add the Main Repository as an upstream remote.

git remote add upstream https://github.com/freedomofpress/securedrop.git

Make Your Changes and Push to the Fork

Create a Branch

Create a branch on which you make your changes.

git checkout -B change-one

Make Your Changes and Commit

Now enter the directory of your fork amd make changes as you wish. Run tests for the changes you have made.

If you create a new file, remember to add it with git add.

git add <new-file>

Commit your changes, adding a description of what was added. If you’re not used to Git, the simplest way is to commit all modified files and add a description message of your changes in a single command like this:

git commit -a -m "<Description of changes made>"

Pull the Upstream Changes

We get any updates made in the upstream repository.

git pull upstream develop

Rebasing

Rebasing is the process of moving or combining a sequence of commits to a new base commit. Rebasing is most useful and easily visualized in the context of a feature branching workflow.

Assume the following history exists:

      A---B---C change-one
     /
D---E---F---G develop

From this point, the result of either of the following commands:

git rebase develop
git rebase develop change-one

would be:

                A`--B`--C` change-one
             /
D---E---F---G develop

Note

A and A represents the same set of changes, but have different committer information.

Pushing the Changes to GitHub Fork

Once your changes are committed and rebased, push the changes to your GitHub fork.

git push origin <branch-name>

Making a Pull Request to Get Your Changes Merged in `develop` Branch

1. Through GitHub make a pull request from the branch that you commited your code to.

2. Once PR is made, the Circle CI build server checks all tests and Codecov runs a report on test coverage. The reports are available in the PR page and also emailed to admins.

3. From there, a maintainer will accept your PR or they may request comments for you to address prior to merge. The maintainer may also ask you to squash your commits prior to merge.