Making a PR to SecureDrop

Making a PR to SecureDrop#

Forking and Cloning the Project#

  1. Fork SecureDrop on GitHub from the Main Repository to your own profile.

  2. Clone the forked repository.

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

  1. 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.