...
By using the --amend and --force options means that any of the commits that you produce should be clean, non-breaking changes at all times that get merged in, instead of having a set of patches in a PR that may have one or two 'fixup' changes.
GitHub Issue and Pull Requests
(added with approval of the TSC 9/21/21)
A GitHub issue should normally be filed for any bug discovered in EdgeX services, code or documentation flaw (with the exception of those situations noted below) and prior to any PR to fix the bug is submitted. When submitting a PR to fix the bug, the issue should be referenced as a "fix:" (the Conventional Commit fix type) for the bug in the commit comments (see Commit Message guidelines).
When submitting a GitHub issue for a bug, the submitter is requested to provide the "steps to reproduce or see" the bug. When the steps are not provided, the issue should provide some explanation as to why steps to reproduce or how to see the bug are not provided.
No bug issue is required for:
- CI/CD (or other DevOp) needs that typically must be accomplished quickly and across many repositories and are not germane to the EdgeX application/service development
- Immediate / emergency bug fix PRs. In this case, the PR must document both the bug and the fix.
Issue creation for new features is suggested, but not required. Issue creation for features or enhancements is at the discretion of the contributor and typically done in consultation with the affected work group chairperson(s). Issues can be a good way to
- track progress, reference associated features, and seek comments and agreement on scope of work for a feature
- discuss potential features or improvements that have not yet been approved by the community for implementation
- document needs (features or enhancements) that will not be implemented in the near term but are desired in the distant future (providing a record of the need for longer term preservation)
GitHub Flow
The EdgeX project has adopted the GitHub Flow workflow, a lightweight, branch-based workflow that supports teams and projects where deployments are made regularly.
...
# good - ensures that a merge commit is created $ git merge --no-ff my-branch # bad $ git merge my-branch |
|---|
Keep Commit History during the PR Review
(per Monthly Architect's Meeting of 3/15/21)
When committing during the process of PR reviews, try to keep the commit history to make it easier for reviewers to see and follow the prior feedback conversations. This means that, in general (subject to discusssions between committers and reviewers), don't squash the commit history until the PR is approved. Also, don't force push the updates during the review/feedback process. Instead, when making commits during the review process, follow the following commit process:
- Make commits with your new commit comments: git commit -s -m "your review comment with appropriate semantic version type/scope tags"
- Commit without a force: git push origin yourbranch (vs git push -f origin yourbranch)
- On the last commit when the review has been completed , do a force push in order to rebase(or whenever the PR needs to be rebased during the review cycle), a force push is ok if the PR is only being rebased: git push -f origin yourbranch
...