Propose a feature improvement to an OSS project.
Let other developers review the change and trace its history.
Which flow is generally appropriate?
Submit a branch or patch, explain the change, pass review and tests, and merge it after agreement.
Detailed explanation
Incorrect. Rewriting history and distributing without review loses traceability.
Incorrect. Rewriting history and distributing without review loses traceability.
Correct. A reviewable, tested change preserves quality and history.
Correct. A reviewable, tested change preserves quality and history.
Incorrect. Reviewers need the purpose and test results.
Incorrect. Reviewers need the purpose and test results.
Incorrect. A binary alone cannot show the source diff or validation method.
Incorrect. A binary alone cannot show the source diff or validation method.
Try it yourself
An example you can run in a temporary verification environment.
printf '%s\n' 'patch -> review -> tests -> merge'Expected result
patch -> review -> tests -> mergeKey points
- Diff
- Review
- Testing
- History
Notes
- Environment: OSS開発プロセスの概念確認
- Command output formatting can vary slightly by distribution or tool version.
- Run the example in a temporary directory or process when possible.
Foundation review
Read the scope first
Check whether the command acts on the current shell, a new process, an existing process, or a file.
Verify the observable result
Use the supplied command and compare the output with the expected result.