Development workflow
| Git |
|---|
|
Git is a version control system, used to store all files required to build FlightGear. |
This page is meant to be a high-level introduction to the development workflow of FlightGear, that is, the process developers follow to contribute their work to the project.
The big picture
Everything is stored in several Git repositories (collection of files) on GitLab. You can find a list of them in the FlightGear Git page.
Only a handful of developers have commit access, that is, the right to make changes to those repositories without prior approval. This is done to ensure that only people showing a good, consistent contribution track record and good judgement are able to perform such modifications unsupervised.[1] For this reason, once a developer contributes some work, it will need to be staged for approval by another contributor having commit access.
Life of a patch
|
|
The contribution process can be divided in the following phases.
- Fork the repositories you would like to contribute to. In this context, a fork is a personal copy of the original repository created for your proposed modifications until they are accepted into the project. It is created on the same infrastructure as the official repositories.
- Clone the forks of the repositories. A clone is a local copy of a fork, kept in sync with changes in the offical repositories. You will need to clone the fork repository to your local machine which create a copy of its data to your computer. This will establish the fork as a remote repository named "origin"
- Establish the original repositories as an "upstream" remote. Updates in the upstream remote can be pulled into your local clone.
- Perform the desired modifications locally in a branch and push them to your clone.
- When you are ready to get your work accepted, submit a merge request. A developer will check your contribution before merging it into the project repositories. Fix any issues that are found during the review.
- Once your work is included,
- monitor the work items, the mailing lists and the forum to check for bugs you might have inadvertently introduced.
- pull the changes from upstream, remove your local branch and push to origin.
When is a Fork needed and when it's not
If you are contributing changes to Flightgear, you need a fork of the official Flightgear reposotories on GitLab.
If you are not contributing, and only wish to build flightgear, you do not need a fork. Instead, you should simply clone the official Flightgear Repositories as origin. In this case, an upstream remote connection is unnecessary.
Scenery and aircraft contributions
Due (mostly) to their file size, scenery and aircraft are stored using different file management systems and, thus, do not follow the process outlined in this article.
- Scenery contributions should be submitted to the FlightGear Scenery Database.
- Aircraft contributors should follow the instructions given in FGAddon.
Tips
- If you need to take a design decision or want to get some preliminary feedback, ask people on the flightgear-devel@lists.sourceforge.net mailing list and/or on the forum.
| References |