You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[EGD-5241] Update development workflow documentation
Remove the obligation to update the changelog with every PR. Remove
obligation to start a change description with "Change" verb. Add some
other minor spelling and grammar fixes.
Update commit message template to reflect the changes.
Copy file name to clipboardExpand all lines: doc/development_workflow.md
+9-9
Original file line number
Diff line number
Diff line change
@@ -15,18 +15,19 @@ Each commit that makes it from your branch or fork into the master branch must h
15
15
If you're part of the MuditaOS core development team, your commit's title *must* start with a Jira ticket number in square brackets e.g. `[EGD-5555]`.
16
16
17
17
Commits from the community will be accompanied by a relevant Jira ticket number during the merge. Don't add commits that are out of the scope of the Jira issue you are working on.
18
+
You should have exactly one commit in a single PR.
18
19
19
20
Your commit's subject line should be a single sentence describing what you are changing using present simple tense and an imperative mood. Please follow these rules:
20
21
21
-
- It must start with one of the following verbs: "Add", "Change" or "Fix", depending on whether you are adding a new feature, changing its behavior, or fixing it. This sentence will be a part of the project changelog, so please ensure it will be clear to the non-technical readers.
22
+
- It must start with a verb. This sentence will be a part of the project changelog, so please ensure it will be clear to the non-technical readers.
23
+
- If you are adding a new feature start with "Add"; start with "Fix" if you are fixing one.
22
24
- Don't use proper names such as names of classes or functions.
23
25
- Try to be as concise as possible in the limit of 72 characters (including the Jira ticket number - 11 characters).
24
26
- Don't end the subject line with a period.
25
27
26
28
Then, in the commit message, you must include a short description of what the commit is changing in the project. You should be clear about
27
29
your motivation to do the change and how it influences the project.
28
-
29
-
If it's impossible to provide any of the above information, then your commit is likely excessive or redundant and should be squashed with another commit.
30
+
Focus more on *why* than *how*.
30
31
31
32
An example of a correctly formatted commit:
32
33
```
@@ -50,13 +51,12 @@ You can add a commit template and hook that will help with proper defining both
50
51
51
52
Before submitting a Pull Request please go through some basic checks:
52
53
53
-
- test your changes on both Linux and RT1051 platforms (please pay special attention to the things you might break unintentionally, e.g. when working on calling funcionality, check call log too)
- test your changes on both Linux and RT1051 platforms (please pay special attention to the things you might break unintentionally, e.g. when working on calling, check call log too,
55
55
- run unit tests (`make check`),
56
56
- check if your code formatting complies with [`.clang-format`](../clang-format),
57
-
- whenever you add a thirdparty software to MuditaOS source code, please make sure that the software component is added to a dedicated [section in `LICENSE.md` file on MuditaOS GitHub repository](../LICENSE.md) with a link to the text of the license where applicable.
57
+
- whenever you add third-party software to MuditaOS source code, please make sure that the software component is added to a dedicated [section in `LICENSE.md` file on MuditaOS GitHub repository](../LICENSE.md) with a link to the text of the license where applicable.
58
58
59
-
As a part of our continuous integration proccess we will be soon introducing our own [test harness](../test/README.md).
59
+
As a part of our continuous integration process we will be soon introducing our own [test harness](../test/README.md).
60
60
61
61
## Submit a Pull Request
62
62
@@ -78,7 +78,7 @@ During a PR review, team members will ask you questions regarding your solution.
78
78
79
79
## PR review - act on feedback
80
80
81
-
Add changes to your PR that are requested by reviewers and push the feature branch once again. Update comments requesting changes with a simple `Done`. Don't resolve discussion on your own, it's the reviewer's responsibility to do so.
81
+
Add changes to your PR that are requested by reviewers and push the feature branch once again. Update comments requesting changes with a simple `Done`. Don't resolve a discussion on your own, it's the reviewer's responsibility to do so.
82
82
83
83
## Merge to `master` branch
84
84
@@ -110,7 +110,7 @@ git rebase origin/master # update branch you are at to origin/master
110
110
111
111
`Rebase` changes your commit history (moves them on top). This means two things:
112
112
113
-
- when you did a lot of changes in a lot of places - either `git push` your branch on server, or make its copy
113
+
- when you did a lot of changes in a lot of places - either `git push` your branch to the server, or make its copy
114
114
- when you're happy of `git rebase` results - you'll need to push your branch with force to server - since you've changed its history (updated it)
0 commit comments