From 8d81254d04eab031d303be25cfb623c27fba2d38 Mon Sep 17 00:00:00 2001 From: martincostello Date: Wed, 4 Oct 2023 15:20:19 +0100 Subject: [PATCH] Fix typos Fix some typos and reword a few things. --- docs/community/git-workflow.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/community/git-workflow.md b/docs/community/git-workflow.md index 9253b7220c2..0045b4fd741 100644 --- a/docs/community/git-workflow.md +++ b/docs/community/git-workflow.md @@ -1,6 +1,6 @@ # Git Workflow -The general process for working with Polly is: +Our recommended process for working with Polly is: 1. [Fork](https://docs.github.com/get-started/quickstart/fork-a-repo) our repository on GitHub 2. Clone your fork locally @@ -20,26 +20,26 @@ For an introduction to Git, check out [GitHub's _Git Guide_](https://github.com/ ## Handling Updates from the default branch -While you're working away in your branch, it's possible that one or new commits have been added to the Polly repository's default branch. If this happens you should: +While you're working away in your branch, it's possible that one or more new commits have been added to the repository's default branch. If this happens you shoul 1. [Stash](https://git-scm.com/book/en/v2/Git-Tools-Stashing-and-Cleaning) any uncommitted changes you need to 2. `git checkout main` 3. `git pull upstream main` 4. `git checkout my-branch` 5. `git rebase main` -6. [Sync your fork](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork) (optional) - this this makes sure your remote main branch is up to date +6. [Sync your fork](https://docs.github.com/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork) (optional) - this makes sure your remote main branch is up to date This ensures that your history is "clean" i.e. you have one branch off from `main` followed by your changes in a straight line. Failing to do this ends up with several "messy" merges in your history, which we don't want. This is the reason why you should always work in a branch and you should never be working in, or sending pull requests from, `main`. -Rebasing public commits is [considered to be bad](https://git-scm.com/book/en/v2/Git-Branching-Rebasing#The-Perils-of-Rebasing), which is why we ask you to rebase any updates from `upstream/main`. +Rebasing public commits is [considered to be bad practice](https://git-scm.com/book/en/v2/Git-Branching-Rebasing#The-Perils-of-Rebasing), which is why we ask you to rebase any updates from `upstream/main`. If you're working on a long running feature then you may want to do this quite often, rather than run the risk of potential merge issues further down the line. ## Sending a Pull Request -While working on your feature you may well create several branches, which is fine, but before you send a pull request you should ensure that you have rebased back to a single "Feature branch" - we care about your commits, and we care about your feature branch; but we don't care about how many or which branches you created while you were working on it. +While working on your feature you may well create several branches, which is fine, but before you send a pull request you should ensure that you have rebased back to a single "feature branch" - we care about your commits, and we care about your feature branch; but we don't care about how many or which branches you created while you were working on it. -When you're ready to go you should confirm that you are up to date and rebased with upstream (see _"Handling Updates from the default branch"_ above), and then: +When you're ready to go you should confirm that you are up-to-date and rebased with upstream (see _"Handling Updates from the default branch"_ above), and then: 1. `git push origin my-branch` 1. Send a descriptive [Pull Request][create-a-pr] on GitHub - making sure you have selected the correct branch in the GitHub UI.