Doc revisions

content/docs/butler-flow.mdx

@@ -3,17 +3,18 @@ title: Butler Flow
 description: Discover Butler Flow, a lightweight branch-based development workflow that improves upon GitHub Flow with GitButler's virtual branches.
 ---
 
-Butler Flow is a lightweight, branch-based workflow enabled by GitButler virtual branch functionality.
+Butler Flow is a lightweight, branch-based workflow enabled by GitButler's virtual branch functionality.
 
-Most modern software development teams today that want to set up a culture of shipping, who push to production every day, who are constantly testing and deploying, one of the most popular and effective development workflows is [GitHub Flow](https://docs.github.com/en/get-started/quickstart/github-flow).
+For most modern software development teams that want to set up a culture of shipping, who push to production every day, who are constantly testing and deploying, one of the most popular and effective development workflows is [GitHub Flow](https://docs.github.com/en/get-started/quickstart/github-flow).
 
 These are wise words, enterprising men quote 'em. Don't act surprised, you guys, [cuz I wrote 'em](https://scottchacon.com/2011/08/31/github-flow).
 
-However, a decade later, and with a new and more powerful branching toolset, we're able to amend that basic workflow to be simpler, faster, more flexible and less error prone. Let's take a quick minute to explore what the Butler Flow is for software development teams using GitButler and how this can make all of our lives easier.
+However, a decade later, and with a new and more powerful branching toolset, we're able to amend that basic workflow to be simpler, faster, more flexible, and less error prone. Let's take a quick minute to explore what the Butler Flow is for software development teams using GitButler and how this can make all of our lives easier.
 
 ## Overview
 
-- In a nutshell, the basic development cycle is very simple.
+In a nutshell, the basic development cycle is very simple.
+
 - All work is based off a "target branch", which is a representation of released production code.
 - All work immediately exists in a branch.
 - Work can be shared with teammates for review as early as possible.
@@ -23,23 +24,23 @@ However, a decade later, and with a new and more powerful branching toolset, we'
 
 ### The Target Branch
 
-In stock Git tooling, there is nothing specified as the production branch, no special "trunk". It is only by convention that this is enforced.
+In stock, vamilla Git tooling, there is nothing specified as the production branch, no special "trunk". It is only by convention that this is enforced.
 
 In GitButler, virtual branches will not work without the specification of a special "target branch". Everything exists in relation to this special branch, everything that differs from it must be accounted for by being owned by some other branch, until those changes are integrated.
 
 ### Virtual Branches
 
-Once you choose a target branch, everything that is in your working directory and not ignored by the Git ignore specification must be owned by a virtual branch. If you don't have one active, GitButler will automatically create one for you.
+Once you choose a target branch, everything that is in your working directory and not ignored by the Git Ignore specification must be owned by a virtual branch. If you don't have one active, GitButler will automatically create one for you.
 
 All subsequent changes to your working directory, either by applying other branches or directly modifying files, must be owned by a virtual branch.
 
 Branches are meant to be small, independent and rapidly integrated. However, longer lived branches can be continuously re-integrated, keeping them clean and mergeable for long periods of time if needed, while still being shareable and reviewable with your team.
 
-Virtual branches can be started and ended entirely independently of each other. Developers can work on longer branches, while starting, reviewing, finishing, merging and deleting small ones without ever changing branch context.
+Virtual branches can be started and ended entirely independently of each other. Developers can work on longer branches, while starting, reviewing, finishing, merging, and deleting small ones without ever changing branch context.
 
 ### Collaboration
 
-All coworkers' work, whether created and managed by GitButler or not, exists on the central server as normal Git branches. These will automatically be pulled down and kept up to date by GitButler and can be converted into virtual branches and applied to your working directory in addition to your branches.
+All your team's work, whether created and managed by GitButler or not, exists on the central server as normal Git branches. These will automatically be pulled down and kept up to date by GitButler and can be converted into virtual branches and applied to your working directory in addition to your branches.
 
 This allows you to integrate work from the rest of your team continuously and early, while still keeping non-dependent changes separated and independently reviewable and mergable. It allows you to review code without needing to entirely switch contexts, and to do so early and often in an executable environment.
 

content/docs/overview.mdx

@@ -8,11 +8,11 @@ import ImageSection from "@/components/ImageSection"
 
 GitButler lets you work on several branches at the same time, committing and stashing them independently and simultaneously. Here is a general overview of how this works and how you can use it.
 
-One of the main strengths of GitButler is it's incredible versatility around branch management. You can decide to create multiple independent branches to work on from a single working directory simultaneously, or you can create dependent, stacked branches and merge them in a particular order.
+One of the main strengths of GitButler is its incredible versatility around branch management. You can decide to create multiple independent branches to work on from a single working directory simultaneously, or you can create dependent, stacked branches and merge them in a particular order.
 
 We refer to our independent branches as "virtual" branches and our dependent branches as "stacked" branches.
 
-This ability to do multiple dependant or independent branches at the same time is something that is not possible with vanilla Git.
+This ability to do multiple dependant or independent branches at the same time is something that's not possible with vanilla Git.
 
 <ImageSection
   className="mx-auto"
@@ -23,12 +23,12 @@ This ability to do multiple dependant or independent branches at the same time i
 />
 
 <Callout type="warn">
-  When using GitButler, we will setup a special branch to handle the multiple branches in away that
-  Git can understand a bit better. This means that if you use vanilla git branching commands like
+  When using GitButler, we setup a special branch to handle the multiple branches in a way that
+  Git can understand a bit better. This means if you use vanilla git branching commands like
   `git switch`, GitButler will pause and ask you to return to GitButler's method when you return.
 </Callout>
 
-The reason is that stock Git can only handle one branch at a time, it does not have tooling to use or understand multiple, so most commands having to do with the index or HEAD or branching (commit, branch, checkout, etc) may behave unexpectedly.
+The reason is stock Git can only handle one branch at a time, it does not have tooling to use or understand multiple branches, so most commands having to do with the index or HEAD or branching (commit, branch, checkout, etc) may behave unexpectedly.
 
 <Callout type="info">
   To understand why and how to get out of any difficulties you run into, please read our
@@ -38,21 +38,21 @@ The reason is that stock Git can only handle one branch at a time, it does not h
 
 ## Target Branch
 
-With virtual branches, you are not working off of local main or master branches. Everything that you do is on a virtual branch, automatically.
+With virtual branches, you are not working off local main or master branches. Everything that you do is on a virtual branch, automatically.
 
 Similar to GitHub, where you specify a default branch to use to merge your Pull Requests into by default, GitButler requires a "Target Branch". This is understood to be whatever your concept of "production" is. Typically what represents deployed, production code that cannot or should not be rolled back. Generally this would be something like `origin/master` or `origin/main`.
 
 Once a target branch is specified, everything in your working directory that differs from it is branched code and must belong to a virtual branch.
 
-This means that you don't have to create a new branch when you want to start working, you simply start working and then change the branch name later. There is no local "main" or "master" because it doesn't make sense. Everything is a branch, with work that is meant to eventually be integrated into your target branch.
+This means you don't need to create a new branch when you want to start working, you simply start working and then change the branch name later. There is no local "main" or "master" because it doesn't make sense. Everything is a branch, with work that is meant to eventually be integrated into your target branch.
 
 ## Virtual Branches
 
 You can easily work in a single branch at a time, but GitButler can handle several virtual branches at the same time. If you have 3 different changes in one file, you can drag each of the changes to a different virtual branch lane and commit and push them independently.
 
 Each virtual branch is kept in a vertical lane, similar to a kanban board, and every file and difference is similar to a card that you can drag between the lanes until they are committed there.
 
-Each time you commit on a virtual branch, GitButler calculates what that branch would have looked like if the changes you dragged onto it were the only things in your working directory and commits a file tree that looks like that. If you push that commit and inspect it on GitHub (or whatever upstream service you use to collaborate), it should look like that was the only change you made, even though you could potentially still have multiple branches applied in your working directory.
+Each time you commit on a virtual branch, GitButler calculates what that branch would have looked like if the changes you dragged onto it were the only things in your working directory and commits a file tree that reresents that work. If you push that commit and inspect it on GitHub (or whatever upstream service you use to collaborate), it should look like that was the only change you made, even though you could potentially still have multiple branches applied in your working directory.
 
 ## Applying and Unapplying Branches
 
@@ -69,7 +69,7 @@ Since there isn't just a single branch you can be on, you don't "switch" branche
 
 ## Merging Upstream
 
-Eventually you will have work merged into the branch you chose as your target branch, which will need to be reconciled with all your virtual branches to keep them up to date with where they will eventually need to merge to.
+Eventually, you will have work merged into the branch you chose as your target branch, which will need to be reconciled with all your virtual branches to keep them up to date with where they will eventually need to merge to.
 
 <ImageSection
   className="mx-auto"
@@ -79,15 +79,15 @@ Eventually you will have work merged into the branch you chose as your target br
   subtitle="Updating from upstream will automatically remove integrated branches and rebase other branches on top of the new work."
 />
 
-Upstream work will automatically be shown on the top of your window as "X upstream commits". When you click that, you will see the incoming work and how to update your active branches on top of it.
+Upstream work will automatically be shown on the top of your window as "X upstream commits". When you click there, you will see the incoming work and you will be directed on how to update your active branches on top of it.
 
 For each virtual branch you have, we will show you if the incoming upstream work has conflicts with each branch. If there are conflicts, you can choose to stash the branch or go ahead and rebase with conflicts, which you can fix later.
 
-If a virtual branch is entirely integrated into upstream, it will be removed and deleted when those changes are integrated. So you can just keep a virtual branch applied locally until it is integrated and it will go away automatically.
+If a virtual branch is entirely integrated into upstream, it will be removed and deleted when those changes are integrated. So you can keep a virtual branch applied locally until it is integrated and it will go away automatically.
 
 ## Conflicting Branches
 
-If you do rebase work that has conflicts, the commit will be marked as being in a conflicted state and you can check it out and fix it whenever you wish.
+If you do rebase work with conflicts, the commit will be marked as being in a conflicted state and you can check it out and fix it whenever you wish.
 
 <ImageSection
   className="mx-auto"
@@ -107,7 +107,7 @@ This is different from how you might have dealt with conflicts in Git before. If
   subtitle="Resolving a conflict by individual commit"
 />
 
-This will check out the conflicts into your working directory and you can let us know when you're done resolving it and we'll rebase everything above it.
+This will check out the conflicts into your working directory and you can let us know when you're done resolving it and GitButler will rebase everything above it.
 
 <ImageSection
   className="mx-auto"
@@ -119,4 +119,4 @@ This will check out the conflicts into your working directory and you can let us
 
 ## The End
 
-That is our general overview of how our branching model and workflow works. We've found that it's way easier and faster than constantly switching back and forth between branches, managing branches all the time, and all the other overhead that comes with branching in Git, while still being able to easily create pull requests and integrate features.
+That is our general overview of how our branching model and workflow works. We've found that it's way easier and faster than constantly switching back and forth between branches, managing branches all the time, and all the other overhead that comes with branching in Git, while still easily creating pull requests and integrating features.