-
Notifications
You must be signed in to change notification settings - Fork 16
Git workflow
Martin J. Kühn edited this page Mar 11, 2024
·
8 revisions
- There is a main but no release or develop branch. The main branch is always stable and the latest release can be found as a tagged commit on the main branch. Stable means that all tests pass.
- All actual work is done in task branches, regardless of whether it's a feature, a bugfix, or a performance analysis.
- Task branches are generally created from the main branch.
- Please never rebase your branches, always use merging (with the main or other changes) such that committed changes can be followed in the history. There will be a squashed commit, when the changes are added to the main branch.
- The name of a task branch satisfies the following template: "issueId-issueName".
- Each commit must have a meaningful commit message.
- In general, we should try to keep the branches working. However, if you need to commit a non-working change, please begin the commit message with "[ci skip] non-working" for the following reasons
- Nobody attempts to checkout this commit with the assumption it would work.
- [ci skip] prevents the CI from running
- If we release a new version of the software, we create a tag for the version on the main branch
- Please keep all issue related communication within the issue or pull request
The software development process is inspired by Scrum and the development of the core developers is organized in sprints. The rules below only partially apply to external (non-core) contributors.
- A sprint is a temporal limited cycle of a fixed time, in our case three weeks.
- The scope of work will be defined in a sprint meeting where work is related to issues.
- MEmilio-related issues are categorized in three different classes: agent-based modeling, equation-based modeling and MEmilio: data, tools and more. If a clear categorization is not possible, issues may be assigned to more than one classes.
- Sprints are organized via the new GitHub Project boards: https://github.com/DLR-SC/memilio/projects
- At the latest in the morning before every sprint meeting, all developers are encouraged to think about which issues should be processed in the upcoming sprint independent of if those issues are tasks for oneself or someone else. Therefore, those issues are marked with the upcoming project. Every developer should put the issues they want to work on or request others to work on to the "SprintBacklog" and attribute them with the next sprint number.
- Shortly before the meeting every developer should already look at the project issues and think about the time needed for realization.
- In the meeting, we go through the different issues, and clarify questions and comments.
- For every single programming task, bug report, discussion item etc. open a new issue.
- Every issue should contain a detailed description of the task and subtasks even understandable for all developers in the project.
- A new issue has no status label. Additional labels should be appended, see the label list below. At this point in time, it is not necessary to assign it to someone.
- Every issue should be tagged with as least one of the projects, if possible.
- Tasks (issues) which are attributed to a sprint are tracked in an issue board to be found under "Projects".
- When you start working on an issue, make sure it is attributed to the current sprint.
- Then, you assign it to you and move it into the column "In Progress" or change the label to "status::in progress". If code changes are involved, create a branch. If you are working with a partner, mention the partner in the issue description. The assignee is responsible for the ticket.
- You should only work on one ticket at a time. It shouldn't happen that two tickets are "In Progress" at the same time.
- If you completed the issue, set pull request to "Ready for Review". Check that all coding requirements of the author (automatically added as check boxes) are met. Assign the pull request to the person who should review your work and move the issue into the column "in review" or change the status to "status::in review".
- The task of the reviewer is to check the code for correctness, compliance of the coding guidelines, completeness, quality etc.
- If the review has finished and the review has complains the issue is moved too "status::in progress" again, the issue is reassigned to the original assignee and the threads have to be resolved. Add the "WIP" tag before the the merge request again.
- If the reviewer approves the work, the new code can be merged and the issue is automatically "Closed".
- The reviewer is allowed to make small changes in the comments or documentation, e.g., remove typos. Also small changes as, e.g., adding/deleting spaces or empty lines can be done by the reviewer directly to speed up the process.
- For all other changes which concern the code and its functionality, the reviewer has to write a comment or make a suggestion which than goes back to the developer (see above).
- To honor original authors as well as reviewers and reviewing suggestions, reviewers should be added as coauthors when merging a pull request. To do so, add the following line(s) at the end of the commit message:
COMMIT_MSG
--- empty line ---
Co-authored-by: NAME <[email protected]>
The full list of labels that should be used to identify issues can be found here