Skip to content

Latest commit

 

History

History
112 lines (75 loc) · 3.57 KB

CONTRIBUTING.md

File metadata and controls

112 lines (75 loc) · 3.57 KB
Raw

Contributing to SecureEnv

Create an issue

Resolve an issue

Select an issue that you want to resolve.

The recommended workflow is to fork this repository and open pull requests from your fork.

1. Fork, clone & configure SecureEnv upstream

  • Click on the Fork button on GitHub
  • Clone the original repository
  • Add your repository as a new remote
# Clone original repository
git clone [email protected]:PoCInnovation/SecureEnv.git

# Add your fork as a remote
git remote add <fork_name> https://github.com/$YOUR_GITHUB_USER/SecureEnv.git

2. Create a pull request

# Create a new branch
git switch -c my_branch

# Make changes to your branch
# ...

# Commit changes - remember to sign!
git commit -s

# Push your new branch
git push <fork name>

# Create a new pull request from https://github.com/PoCInnovation/SecureEnv/pulls

3. Update your pull request with latest changes

# Switch to the main branch
git switch main

# Pull origin's change
git pull

# Switch to your branch
git switch my_branch

# Rebase your branch changes on top of the updated main branch
git rebase main

# Update your pull request with latest changes
git push -f <fork name>

Commits

DCO

Contributions to this project must be accompanied by a Developer Certificate of Origin (DCO).

All commit messages must contain the Signed-off-by line with an email address that matches the commit author. When committing, use the --signoff flag:

git commit -s

The Signed-off-by line must match the author's real name, otherwise the PR will be rejected.

Commit messages

Please read first this article : How to Write a Git Commit Message.

Then, follow these guidelines:

  • Group Commits: Each commit should represent a meaningful change. Instead, these commits should be squashed together into a single "Add Feature" commit.

For instance, a PR should not look like :

  1. Add Feature X
  2. Fix Typo
  3. Changes to features X
  4. Bugfix for feature X
  5. Fix Linter 7)
  6. ...
  • Each commit should work on its own: it must compile, pass the linter and so on.

This makes life much easier when using git log, git blame, git bisect, etc...
For instance, when doing a git blame on a file to figure out why a change was introduced, it's pretty meaningless to see a Fix linter commit message. "Add Feature X" is much more meaningful.

  • Use git rebase -i main to group commits together and rewrite their commit message

  • To add changes to the previous commit, use git commit --amend -s. This will change the last commit (amend) instead of creating a new commit.

  • Format: Use the imperative mood in the subject line: "If applied, this commit will your subject line here"

  • Add the following prefixes to your commit message to help trigger automated processes:

    • docs: for documentation changes only (e.g., docs: Fix typo in X);
    • test: for changes to tests only (e.g., test: Check if X does Y);
    • chore: general things that should be excluded (e.g., chore: Clean up X);
    • ci: for internal CI specific changes (e.g., ci: Enable X for tests);

Made with ❤️ by PoC