Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
94 lines (74 loc) · 3.95 KB

CONTRIBUTING.md

File metadata and controls

94 lines (74 loc) · 3.95 KB
Raw

Contributing

Hi there! We're thrilled that you'd like to contribute to GCM 🎉. Your help is essential for keeping it great.

Contributions to GCM are released to the public under the project's open source license.

Please note that this project is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its terms.

Start with an issue

  1. Open an issue to discuss the change you want to see. This helps us coordinate and reduce duplication.
  2. Once we've had some discussion, you're ready to code!

Submitting a pull request

  1. Fork and clone the repository
  2. Follow development setup and restore dependencies: dotnet restore
  3. Make sure the full solution test suite passes on your machine: dotnet test git-credential-manager.slnx
  4. Create a new branch: git switch -c my-branch-name
  5. Make your change, add tests, and make sure all tests pass
  6. For UI updates, exercise the relevant flow through the main executable: dotnet run --project src/git-credential-manager -- get. See debugging instructions for stdin and startup arguments.
  7. Organize your changes into one or more logical, descriptive commits.
  8. Push to your fork and submit a pull request
  9. Pat your self on the back and wait for your pull request to be reviewed and merged.

Here are a few things you can do that will increase the likelihood of your pull request being accepted:

  • Match existing code style.
  • Write tests.
  • Keep your change as focused as possible. If there are multiple changes you would like to make that are not dependent upon each other, consider submitting them as separate pull requests.

Run the full solution test suite for every code change. Targeted tests are useful while iterating, but do not replace the full run. Platform-specific tests skip on other operating systems; CI covers the Windows, macOS, and Linux matrix. See testing for test infrastructure and coverage instructions.

Commits

Make each commit one logical change. Include the tests and documentation for a behaviour change in the same commit; keep unrelated refactors and formatting separate.

Use area: short imperative summary for the subject, with a concrete area, lowercase text after the colon, no trailing period, and at most 72 characters. Explain why the change is needed in the body, wrapping prose at about 72 characters.

Credit meaningful AI assistance with Assisted-by: <human-readable model name>. We don't require the Signed-off-by trailer (git commit -s) on commits, but it is recommended.

Please watch this very helpful video that outlines the commit message conventions and best practices for open source projects.

Development resources

The developer documentation index links to build, debugging, architecture, threading, and provider guidance.

Resources