Skip to content

Commit

Permalink
Update SCMGuide.md (#777)
Browse files Browse the repository at this point in the history
  • Loading branch information
ferdonline committed Oct 14, 2020
1 parent fc74b85 commit 8570e8e
Showing 1 changed file with 10 additions and 10 deletions.
20 changes: 10 additions & 10 deletions docs/scm/guide/SCMGuide.md
Original file line number Diff line number Diff line change
Expand Up @@ -163,12 +163,12 @@ When working on a feature branch, especially if development spans over some days
1. The branch is public: **Merge**!
Especially critical with long-running, public branches must not have their histories rewritten. Really want a rebase? Then use a new branch for that: checkout the target branch with a new name and merge the source branch.
2. Feature branch to be "_merge squashed_". Without conflicts consider **merging**. Decisive factors could be keeping reviews valid, or easier conflict resolution:
1. **Merge** (GitHub model): With original commits we ensure no behavior changes and GitHub Reviews are kept valid. Extra merge commits squashed anyway at the end.
2. **Rebase** (Gerrit model). Simplifies the branch. Re-testing the last commit is required.
1. **Merge** (GitHub model): With original commits we ensure no behavior changes and GitHub Reviews are kept valid. Extra merge commits squashed anyway at the end.
2. **Rebase** (Gerrit model). Simplifies the branch. Re-testing the last commit is required.
3. Feature branch to be "_traditionally merged_": **depends** :
1. Consider **merging,** mainly if everything is tidy. It's no-op, keeps reviews valid, etc.
1. Consider **merging,** mainly if everything is tidy. It's no-op, keeps reviews valid, etc.
If you need cleanup/prefer rebase **** **do rebase** and **retest all commits**
2. If fast-forwarded is required, you must **rebase** (and **retest all commits** )
2. If fast-forwarded is required, you must **rebase** (and **retest all commits** )

### Reviewing

Expand All @@ -177,12 +177,12 @@ Reviewers share responsibility on the merged code and thus should dedicate some
1. **Make sure the requirements are fulfilled**.
Patches should do what they advertise. They don't need to solve a full issue - contributions are even encouraged to be split in several independent patches. However there should be a clear description matching the implementation.
2. **Ensure the patch works as expected**
1. Quick review on Web UI may be sufficient if the patch is simple (e.g. single line or documentation) and risk of breaking things is reduced
2. Otherwise checkout locally the code to have the full picture.
1. Quick review on Web UI may be sufficient if the patch is simple (e.g. single line or documentation) and risk of breaking things is reduced
2. Otherwise checkout locally the code to have the full picture.
3. **Ensure high code quality standards**
1. Minimalistic, self-contained changes
2. Simple implementations, avoiding globals, long functions, side-effects
3. Compliance with code style conventions, self-explanatory code/comments
1. Minimalistic, self-contained changes
2. Simple implementations, avoiding globals, long functions, side-effects
3. Compliance with code style conventions, self-explanatory code/comments
4. **Use comments and suggestions.** Give the author the possibility of argumenting for/against a request. In case you, as a reviewer, want to suggest a specific and significant change you may open a sub-Pull-Request.
5. **Quick changes & fixes**. Such non-functional modifications (e.g. typos, code style, ...) may be pushed directly to save review cycles and thus time.

Expand Down Expand Up @@ -465,4 +465,4 @@ Suggestions for this process are:
## Footnotes
[1](#sdfootnote1anc)It might be confusing the fact that GitHub seems to be the server-side of a local git clone. GitHub in reality manages Git repositories and, even though people interact very often with it as the main server, from Git perspective it is simply "one" peer. Nothing prevents people from deleting the repository from GitHub and creating clones in any other server or even another folder in their disk and do PUSH/PULL's to any of those.

[2](#sdfootnote2anc) Technical note: Git does not store deltas. It indeed has to compute the diff and apply on another commit.
[2](#sdfootnote2anc) Technical note: Git does not store deltas. It indeed has to compute the diff and apply on another commit.

0 comments on commit 8570e8e

Please sign in to comment.