Home
User documentation is available in the online manual. This wiki is primarily about maintaining the application.
Git Extensions is completely open source software built entirely by volunteer contributors who use it every day. The project exists for you and because of you.
The primary way to contribute to Git Extensions is by writing code, but if you're not a developer there are still ways you can help. We always need help with:
- Helping our users - have a look at open issues and provide more relevant details, known workarounds, exact reproduction steps, ...
- Creating tutorials and integration guides
- Help with UI and UX design
- Improving our documentation (https://git-extensions-documentation.readthedocs.io/en/latest/)
- Improving and adding new translations
- Testing and quality assurance - have a look at open pull requests and write a code review. Or build it locally and verify that the proposed changes work as intended.
- Promoting Git Extensions to others
- Donations - as a non-profit organisation we're always grateful to receive any and all donations to help our work and pay for services (such as cloud hosting)
If you wish to contribute to the project, please familiarise yourself with the following guidelines.
- Follow the Coding Style
- Follow the Coding Patterns
- Minimal supported Git version is 2.11, you should have this in mind when adding new features
- Reuse UserControls before implementing things twice
- Make sure your change doesn't introduce compiler warnings
- When creating new Forms/Controls, take care of scalability and resisability (use layout managers).
You pull-request should contain a single functional self-contained change, that can be easily reasoned about and that can be reverted, if necessary. On occasion a pull-request may contain additional non-functional commits which are necessary for or complimentary to the change. E.g.
commit1: update packages (non functional)
commit2: make the real change (functional)
commit3: code maintenance/refactor (non functional)
It is perfectly acceptable to make a lot of small commits until the work is done and approved, but be ready to squash and rebase, if necessary.
Put yourself in shoes of reviewers and your fellow developers - no one really cares that it took another developer 57 commits to deliver his/her change, that they fixed typos or responded to reviews 29 times, reworked the implementation 22 times and fixed unit tests 6 times? All you care the change is done and delivered.
If you wish to help maintain the documentation, then please see the following links for further information.
- Overview: an overview of how the repository is organised and documentation is created.
- Current Release: how to update the documentation for the currently released version of Git Extensions.
- Future Release: how to update the documentation for future versions of Git Extensions. This is for the developers of Git Extensions who are adding new features or bug fixes that will be released at some future date
- Run
Setup\BuildInstallers.cmdto build the installers