style: tweaked syntax of git collab method tabs to fit on one line

mod_version-control.qmd

@@ -38,15 +38,15 @@ You can do this by all working on separate scripts that are trying to do the sam
 
 **Recommendation: Worth Discussing!**
 
-## Work in Shifts
+## Separate Shifts
 
 You might also decide to work together on the same scripts and just stagger the time that you are doing stuff so that all of your changes are made, committed, and pushed before the next person begins work. This is a particularly nice option if you have people in different time zones because someone in Maine can work on code likely before another team member living in Oregon has even woken up much less started working on code.
 
 For this to work _you will need to communicate extensively with the rest of your team_ so that you are absolutely sure that you won't start working before someone else has finished their edits.
 
 **Recommendation: Worth Discussing!**
 
-## Work in Forks
+## Forks
 
 GitHub does offer a "fork" feature where people can make a copy of a given repository that they then 'own'. Forks are connected to the source repository and you can open a pull request to get the edits from one fork into the source repository.
 
@@ -66,15 +66,15 @@ Forks are intended for when you want to take a set of code and then "go your own
 
 **Recommendation: Don't Do This**
 
-## Work in Branches
+## Branches
 
 GitHub also offers a "branch" feature which is similar to forks in some ways. Branches create parallel workspaces within a single repository as opposed to forks that create a copy of a repository under a different user.
 
 These have the same hurdles as forks so check out the first two points in the "Work in Forks" tab. Also, just like forks, this isn't how branches were meant to be used either! Branches exist so that you can leave some version of the code untouched while simultaneously developing some improvement in a branch. That way the user experiences a seamless upgrade while still allowing you to have a messy development period. Branches _are not_ intended for multiple people to be working on the same things at the same time and merge conflicts are the likely outcome of using branches in this way.
 
 **Recommendation: Don't Do This**
 
-## Single Code Author
+## Single Author
 
 You may be tempted to just delegate all code editing to a single person in the group. While this strategy does guarantee that there will never be a merge conflict it is also deeply inequitable as it places an unfair share of the labor of the project on one person.