From 7ffcca72c27e29e9e8e90cc5a6b03e4e3d576d86 Mon Sep 17 00:00:00 2001
From: Aidan MacKenzie <102439396+aidanmackenzie@users.noreply.github.com>
Date: Thu, 2 Nov 2023 16:43:31 -0400
Subject: [PATCH] Update git-for-the-ss14-developer.md
Just need to add conclusion.
---
.../setup/git-for-the-ss14-developer.md | 86 +++++++++----------
1 file changed, 42 insertions(+), 44 deletions(-)
diff --git a/src/en/general-development/setup/git-for-the-ss14-developer.md b/src/en/general-development/setup/git-for-the-ss14-developer.md
index b0218d596..45aa95166 100644
--- a/src/en/general-development/setup/git-for-the-ss14-developer.md
+++ b/src/en/general-development/setup/git-for-the-ss14-developer.md
@@ -73,7 +73,7 @@ Navigate to somewhere on your computer where you want to put the local repositor
-Right click to see TortoiseGit's context menu stuff:
+Right click to see TortoiseGit's context menu:
![](https://i.imgur.com/QGmrQmH.png)
@@ -135,27 +135,27 @@ Every Git command will look something like this--`git` and then a keyword like `
@@ -284,7 +284,7 @@ The `-b` in `git checkout` here means 'checkout this branch, and create it if it
Now, you can work freely with this branch as you please without fear of messing up your all-important master branch.
-Switching between branches is pretty easy: it's called **checking out** a branch. When you do this, your files and folders locally will be changed to match the branch, so Git will yell at you if you have local changes and you try to check out.
+Switching between branches is also quite easy: it's called **checking out** a branch. When you do this, your files and folders locally will be changed to match the branch, so Git will warn you if you have local changes and you try to check out.
Checking out a branch:
@@ -314,13 +314,13 @@ Checking out a branch:
TortoiseGit
-After this completes, you have a local repository that you can now modify! There's still some more setup to go through, though.
+After this completes, you have a local repository that you can now modify! There's still some more setup to go through though.
### 2.3 Submodule woes
-**Pay attention to this!** If you don't do this, you'll get a lot of weird errors about stuff not being available when you actually try to build the game.
+**Very important, please pay attention to this!** If you don't do this, you'll get a lot of undesireable errors about things not being available when you actually try to build the game.
Space Station 14 has a *lot* of submodules--most notably our engine, RobustToolbox. Submodules are just repositories inside a repository, and they need to be updated manually by you. Or do they?
We have an automatic submodule updater so you don’t have to worry about running `git submodule update --init --recursive` (the command for manually updating submodules) all the time.
-Run `RUN_THIS.py` inside the repo you downloaded with Python. Preferably from a terminal too (`python RUN_THIS.py` or `python3 RUN_THIS.py`). This should take a few seconds so if it instantly stops you probably aren’t using Python 3.7+ or something.
+Run `RUN_THIS.py` inside the repo you downloaded with Python. Preferably from a terminal too (`python RUN_THIS.py` or `python3 RUN_THIS.py`). This should take a few seconds so if it instantly stops there's a reasonable chance you aren’t using Python 3.7 or greater.
If you are on Windows and get redirected to the Microsoft Store or encounter a message in your terminal claiming that Python is not installed when you attempt to run the above command, you will need to disable the Microsoft shortcut that might be causing this issue. You can do this by searching for `Manage App Execution Aliases` in the Windows search and then turning off the two Python references.
If you do want to modify the engine directly however, or you want to update the submodule manually (the auto updating can be a pain occasionally), make a file called DISABLE_SUBMODULE_AUTOUPDATE inside the BuildChecker/ directory.
-If you ever need to manually update RobustToolbox for whatever reason you can use `cd RobustToolbox; git checkout v0.4.87`(replace `v0.4.87` with the latest RobustToolbox release) then you can use `cd..\` to get back into your SS14 repo. This is also an example of using `cd` to navigate files from the comfort of your command line.
+If you ever find yourself needing to manually update RobustToolbox you can use `cd RobustToolbox; git checkout v0.4.87`(replace `v0.4.87` with the latest RobustToolbox release) then you can use `cd..\` to get back into your SS14 repo. Note that this is also an example of using `cd` to navigate files from the comfort of your command line.
## 3. Setting up remotes
-When you cloned your remote repository, a **remote** was automatically added to your local repository. **Remotes** are just named URLs to remote repositories that Git keeps track of so you can do stuff like download (pull) new changes to the code or upload (push) code to your forked repository.
+When you cloned your remote repository, a **remote** was automatically added to your local repository. **Remotes** are just named URLs to remote repositories that Git keeps track of so you can download (pull) new changes to the code or upload (push) code to your forked repository.
In this case, the remote automatically added is called`origin` and it points to `https://github.com/[username-here]/space-station-14` (or whatever you named the remote repository).
@@ -193,19 +193,19 @@ One issue: we don't have a reference to the original `space-wizards/space-statio
All this does is add a new remote named `upstream` that points to the original `space-wizards/space-station-14` repository. Now we can receive updates from the main repository whenever we want! (see below on how to do that).
-The convention is to call the remote pointing to the original repository `upstream` but you can technically call it whatever you like. I'll be referring to it as 'the upstream', though, and it's terminology Git guides use as well.
+The convention is to call the remote pointing to the original repository `upstream` but you can technically call it whatever you like. From here on out we'll be referring to it as 'the upstream', as it's terminology Git guides often use as well.
## 4. Branching & Commits
-Branches and commits are two of the most important concepts in Git, and most of the work you do will revolve around them.
+Branches and commits are two of the most important concepts in Git, and the majority of the work you do will revolve around them.
### 4.1 Whats a commit?
-Like I mentioned before, **commits** are just packaged up changes to the code. As the developer, you choose which changes go into a commit and when to commit those changes. **Committing** refers to creating a commit, and it essentially makes a save point that you can go back to at any time.
+Like I mentioned before, **commits** are just packaged up changes to the code. As the developer, you choose which changes go into a commit and when to commit those changes. **Committing** refers to creating a commit, and the core idea behind it is that it makes a save point that you can go back to at any time.
Commits have an author, timestamp, a message, and some code changes attached to them. They also have a really long 'commit hash', a unique identifier used to refer to different commits.
-Commits are how history is built up--you can actually view the history of every single commit made to the SS14 repository from the beginning, which is pretty cool:
+Commits are how history is built up--you can actually view the history of every single commit made to the SS14 repository from the beginning, which can give you an intersting timeline into the game:
![](https://i.imgur.com/HQDdw6h.png)
@@ -213,17 +213,17 @@ Commits are how history is built up--you can actually view the history of every
### 4.2 What's a branch?
-**Branches** are very, very important. They're basically just a list of changes to the code (commits). The default branch is 'master', and all of our servers use that branch to compile the code.
+**Branches** are an absolutely vital concept. At their core, branches are separate copies/versions of the code (commits) that branch off of the main code. The default branch is 'master', and all of our servers use that branch to compile the code.
You're pretty much always 'on a branch' when you're working with your code, and you can switch which branch you're working on easily.
Generally, branches are named for whatever you're going to be working on in them, but it doesn't *really* matter what they're named.
-You can make as many branches as you like. When you create a branch, it 'branches out' (no shit, really?) from the current branch you're on and becomes its own independent thing you can add commits to.
+You can make as many branches as you like. When you create a branch, it 'branches out' from the current branch you're on and becomes its own independent thing you can add commits to.
![](https://i.imgur.com/ByMugxu.png=500x300)
-In this diagram, each little node is a different commit, and each color is a different branch.
+In this diagram, each little node is a different commit, and each color is a different branch. As you can see, enough branches and you start to get a proper code tree!
#### Branch merging
@@ -240,15 +240,15 @@ Pull requests show all this info very well:
In this pull request, Swept started out by creating a new branch. Since he now had a fresh branch free of interference to work with, he started working on the feature and created commits to 'save his progress' whenever he felt it was necessary. These commits were added to the branch sequentially, and you can see the evolution of the branch as more code was written. We'll talk more about pull requests later.
-#### But whyyy?
+#### But why branch?
-Okay, technically, sure, you can just do all of your work on the `master` branch and pull request from there. But, creating different branches makes it easy to understand where you are, how many changes you've made, and it makes it possible to work on multiple features at once.
+Sure, you can just do all of your work on the `master` branch and pull request from there. But, creating different branches makes it easy to understand where you are, how many changes you've made, and it makes it possible to work on multiple features at once.
-Also we'll close your PR if it's from your `master` branch (it can very easily cause issues) so don't do it.
+Also, as a note, we'll close your PR if it's from your `master` branch (it can very easily cause issues) so avoid doing it.
### 4.3 Making and working with branches
-Making branches is pretty easy. Let's make a new branch called `funny-feature`:
+Making branches is quite simple. Let's make a new branch called `funny-feature`:
TortoiseGit
-Then, make whatever local changes you want! It doesn't really matter. Make a new file, delete everything, change one line in a file, etc. It won't affect your `master` branch, because this is`funny-feature` land now!
+Then, feel free to make whatever local changes you want! It won't have a direct impact on your `master` branch. Make a new file, delete everything, change one line in a file, etc. It won't affect your `master` branch, because we're in the `funny-feature` branch!
### 4.4 Staging and committing changes to your branch
One more important thing: Before you can `commit` your changes, you have to `add` your changes to the **staging area**. All this means is that you're specifying which files you want to commit. This is helpful, because you *almost never* want to commit submodule changes, so you avoid that by not adding them to the staging area.
-As mentioned before, commits always come with a message, which is just a short, imperative description of what's being done in that commit. Or you can be a chad and name every commit "changes stuff", up to you.
+As mentioned before, commits always come with a message, which is just a short, imperative description of what's being done in that commit.
If you want to see what you've currently changed, and what's in the staging area, it's pretty easy:
@@ -329,7 +329,7 @@ If you want to see what you've currently changed, and what's in the staging area
![](https://i.imgur.com/xmZKKWJ.png)
-TortoiseGit also shows changed files/folders (a red icon in the bottom right) in the Windows Explorer which is really nice and why I have it installed in the first place.
+TortoiseGit also shows changed files/folders (a red icon in the bottom right) in the Windows Explorer which is very user friendly and why I have it installed in the first place.