Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix the link to guidance on how to do Git commits #57

Merged
merged 2 commits into from
May 29, 2024
Merged

Fix the link to guidance on how to do Git commits #57

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
e090584
Fix the link to guidance on how to do Git commits
lawrence-forooghian May 28, 2024
ff814a4
Fix the link to guidance on development flow
lawrence-forooghian May 29, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions best-practices/pull-requests.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -30,7 +30,7 @@ In order for a PR to be merged, everyone who has been tagged as a reviewer must

## PR scope and structure

The scope and structure for a PR should be based on the guiding principles that apply to [commit and history structure](https://ably.atlassian.net/l/c/7QP1L31X): PRs should ideally cover a self-contained set of changes, with an overall scope that is large enough that the overall intent of the changes is clear, and small enough that it is manageable to be reviewed in detail. PRs that are too large tend to result in reviews that are more superficial and less effective.
The scope and structure for a PR should be based on the guiding principles that apply to [commit and history structure](commits.md): PRs should ideally cover a self-contained set of changes, with an overall scope that is large enough that the overall intent of the changes is clear, and small enough that it is manageable to be reviewed in detail. PRs that are too large tend to result in reviews that are more superficial and less effective.

The use of branches generally should follow the policy for [development flow](https://ably.atlassian.net/wiki/spaces/PUB/pages/803766520). If the changes being made are necessarily extensive, then the preferred way to structure the work is as a series of PRs made against an integration branch, so each individual PR remains a manageable size.
VeskeR marked this conversation as resolved.
Show resolved Hide resolved

Expand Down Expand Up @@ -92,7 +92,7 @@ Changes that are made in response to PR reviews can include:
The choice as to how to proceed principally rests with the author, and the actual choice should be made based on the goals of:

- ensuring clarity for the reviewer(s);
- ensuring that the final history meets the [goals for commit history](https://ably.atlassian.net/wiki/Git-best-practices).
- ensuring that the final history meets the [goals for commit history](commits.md).

Adding `!fixup` references allows the specific corrective changes to be seen clearly, and preserves the navigability of the original PR comments. However, depending on the nature and extent of the changes, `!fixup` commits can impair the reviewability of the PR overall - a reviewer may request that changes are consolidated into the actual proposed commits in this case. When this happens, a new branch and PR should be used referencing the old PR, explaining why a new PR is being used (what material change has been made) and the old PR should be closed.

Expand Down
Loading