added some explanation for usage and a commenting etiquette section. #9
Conversation
| @@ -1,5 +1,26 @@ | |||
| # obc_software_nextgen_test | |||
| Next generation linux based OBC software | |||
| Fprime software project to be ran on an embedded linux OS | |||
There was a problem hiding this comment.
nit: should 'ran' be 'run'? (caveat: I'm no English expert)
| @@ -18,8 +39,14 @@ The following is a list of possible branch types: | |||
| - documentation | |||
|
|
|||
| ### Branching etiquette | |||
| - Branches must implement/change only a single feature.Changes related to that feature across different layers of code is acceptable. | |||
| - Branches must implement/change only a single feature. Changes related to that feature across different layers of code is acceptable. | |||
| - You may create branches off branches, but they will be merged in the order they were created. You also need to be prepared to accept the risk of having to rebase to a new parent branch parent branch, should those changes be declined. | |||
There was a problem hiding this comment.
nit: 'parent branch' is repeated
More importantly, it may not be possible to guarantee that branches are merged in chronological order, which you point out in this sentence. It might be easier to require that branches are independent, i.e. the merge order doesn't matter. This may also make it easier to enforce a best practice: that no single branch (PR) can break the build or tests.
There was a problem hiding this comment.
Why would we not be able to enforce that branches are merged in chronological order? I agree with making branches independent to prevent from breaking builds and tests, but how would we handle the situation where branches are created off other branches. Or would this just not be allowed?
There was a problem hiding this comment.
The only reason you need to create a branch from a branch is because the new branch has a dependency on the underlying branch. That means that you likely can't make a PR from the new branch, because it will break the build until the underlying branch is merged. What usually happens is you make the PR for the new branch once the underlying branch PR is merged. So it's not that branches off branches aren't allowed, it's that breaking the build is not allowed.
| @@ -18,8 +39,14 @@ The following is a list of possible branch types: | |||
| - documentation | |||
|
|
|||
| ### Branching etiquette | |||
| - Branches must implement/change only a single feature.Changes related to that feature across different layers of code is acceptable. | |||
| - Branches must implement/change only a single feature. Changes related to that feature across different layers of code is acceptable. | |||
| - You may create branches off branches, but they will be merged in the order they were created. You also need to be prepared to accept the risk of having to rebase to a new parent branch parent branch, should those changes be declined. | |||
| - If you discover a bug unrelated to the feature you are working on, switch back to master, make a branch to fix the feature, then make a PR to merge that Bugfix. Chances are you aren't the only one experiencing the bug. You may rebase your development branch off the Bugfix branch. | |||
There was a problem hiding this comment.
nit: make a branch to fix the 'bug', not 'feature'
No description provided.