fork_and_branch_workflow.md

docs/gemstones/git/fork_and_branch_workflow.md

@@ -1,7 +1,7 @@
 ---
 title: Fork and Branch Git workflow
 author: Wale Soyinka
-contributors:
+contributors: Ganna Zhyrnova
 tags:
   - GitHub
   - git
@@ -17,7 +17,7 @@ tags:
 
 In this workflow type, contributors fork the main repository to their own GitHub account, create feature branches for their work, and then submit contributions via pull requests from these branches.
 
-This Gemstone walks-through how to set up a local repository for contributing to a GitHub project. It starts with the initial project forking, local and remote repositpry setup, commiting changes and finally creating a pull request (PR) to submit your contributions.
+This Gemstone walks through how to set up a local repository to contribute to a GitHub project. It starts with the initial project forking, setting up a local and remote repository, committing changes, and creating a pull request (PR) to submit your contributions.
 
 ## Prerequisites 
 
@@ -42,15 +42,15 @@ This Gemstone walks-through how to set up a local repository for contributing to
    ```
    git remote -vv
    ```
-4. Fetch latest changes from upstream remote:
+4. Fetch the latest changes from the upstream remote:
    ```
    git fetch upstream
    ```
 5. Create and checkout a new feature branch named your-feature-branch:
    ```
    git checkout -b your-feature-branch
    ```
-6. Make changes, add new files and commit your changes to your local repo:
+6. Make changes, add new files, and commit your changes to your local repo:
    ```
    git add .
    git commit -m "Your commit message"
@@ -69,7 +69,7 @@ This Gemstone walks-through how to set up a local repository for contributing to
    ```
    The options used in this *gh pr create* command are:
 
-   `--base` main: Specifies the base branch in the upstream repository where the changes are to be merged.
+   `--base` main: Specifies the base branch in the upstream repository where the changes will be merged.
    `--head` your-feature-branch: Indicates the head branch from your fork that contains the changes.
    `--title` "Your PR Title": Sets the title for the pull request.
    `--body` "Description of your changes": Provides a detailed description of the changes in the pull request.
@@ -82,15 +82,15 @@ The high-level steps involved are:
 
 1. Fork the Repository: Create a personal copy of the project's repository on your GitHub account.
 2. Clone the Fork: Clone your fork to your local machine for development work.
-3. Set Upstream Remote: Add the original project repository as an 'upstream' remote to stay updated with its changes.
-4. Create a Feature Branch: For each new feature or fix, create a new branch from the updated main branch. Branch names should be descriptive of the feature or fix.
+3. Set Upstream Remote: To stay updated with its changes, add the original project repository as an 'upstream' remote.
+4. Create a Feature Branch: Create a new branch from the updated main branch for each new feature or fix. Branch names should describe the feature or fix.
 5. Commit Changes: Make your changes and commit them with clear and concise commit messages.
-6. Sync with Upstream: Regularly sync your fork and feature branch with the upstream main branch to incorporate any new changes and reduce merge conflicts.
+6. Sync with Upstream: Regularly sync your fork and feature branch with the upstream main branch to incorporate new changes and reduce merge conflicts.
 7. Create a Pull Request (PR): Push your feature branch to your fork on GitHub and open a PR against the main project. Your PR should clearly describe the changes and link to any relevant issues.
-8. Respond to Feedback: Collaborate on review feedback until the PR is either merged or closed.
+8. Respond to Feedback: Collaborate on review feedback until the PR is merged or closed.
 
 Benefits:
 
 - Isolates development work to specific branches, keeping the main branch clean.
-- Makes it easier to review and integrate changes.
+- It makes it easier to review and integrate changes.
 - Reduces the risk of conflicts with the main project’s evolving codebase.