###### tags: `Guide To Contibuting`

# Source Control

## Step 1 - GitHub

1. Make a GitHub account [here](https://github.com). We all know English here so you probably know how to do that.
- If you really need help ping me on discord I guess? But no, really, this should be easy

2. Our repository is located at <https://github.com/Citadel-Station-13/Citadel-Station-13>

3. Top right, click Fork.
- What this does is make a fork of the repository to your account. You'll be writing to this fork (and occasionally updating your local copy of our repository and your fork's `master` branch with ours).

4. Once it's done, it's time to set up git.

## Step 2 - Git Setup
There are a number of ways to download the source code. Some are described here, an alternative all-inclusive guide is also located at <https://www.tgstation13.org/wiki/Downloading_the_source_code>

### Option 1 - GUI

### Option 2 - Command Line

- [Git Setup - Command Line](/lcZ36GzISXeyX9QLOmniIg)
- This is on a separate page because I don't want to scare anyone off. This is not that hard though so uh, as a command line user, I suggest you give it a try if you're serious about doing advanced development. It has a learning curve but it's far more efficient a lot of the time.

## Making a pull request

\<WIP\>!!

## Conflict resolution
So you have a merge conflict.
Congratulations! There's literally no way to avoid this no matter what you do, because other people edit the code too.
These are a **good thing.** Sometimes a merge doesn't conflict, but changes **fundamental code, breaking the master branch from compiling or working right.** Merge conflicts are amazing for letting you know that code has changed, and that you now need to edit your code to fit.

Unfortunately, it's also not that easy to explain how to fix it, because each conflict is different.
In general though, you get this.

\<WIP\>!!

## !!!MAP CHANGES - READ THIS!!! - Map Merge, TGM
- Go to the mapping section and read the section on mapmerge/TGM.

## Lower Level Git (skippable) - *why* is my code conflicting, what even is Git?

Git is a **source control system**. It handles the coordination of having multiple people edit the code at once pretty well, usually preventing the codebase from becoming a dumpster fire of "everybody edits".

- I highly recommend you read the book on git-scm.com if you have spare time. Or don't because it's technical. It's a fun and very educational read, even if it'll fry your brain the first few times around if you're new.

However, it isn't magical. When two people edit the same file at once, it'll try its best to figure out which changes go where, but, when it cannot, a **merge conflict** happens.

The previous sections explained what it is and how to fix it. This section explains how these happen for those who's interested.

Git is at its heart a powerful, low-level tool.
When you look at the code as a human, you see lines of code doing things (or you hopefully do with enough understanding).
You know which parts of it to care about.
- You're not going to care if there's an extra newline somewhere that doesn't disrupt code logic when reading what code does.
- You're not going to be able to even **see** without special editors like visual studio code and notepad++ being explicitly configured to render different newline characters, what kind of **newline** it is.
- There's 2 ways for the computer to represent a new line. I won't go too much into it but call them LF, and CR+LF. They have different byte-values.
- Windows uses CRLF
- Literally everyone else uses LF
- Our codebase is configured to auto-sanitize to LF for compatibility and to lessen line ending conflicts.
- The computer sees every line and every piece of data on that line as, well, data. When it checks for what's different, it **will** care about all the things you do not.
- You edit out a newline in the middle of someone's code. A human trying to merge the code together will go: "Oh, this newline is different but all the changes still apply, let's just merge it together properly because why would I care about an extra newline unless I'm a maintainer or good samitarian who cares about making code pretty?"
- The computer will throw a merge conflict because it sees a line being edited by you, in the middle of data it's merging, because it doesn't know if it's intentional or not. You now have to fix this.
- Similar things go for spaces, tabs, line endings
- You literally cannot see these things.
- The computer can, because CRLF and LF have different byte values.
- Git uses linux diff tools.
- If a line has **any** different byte values/data, it's a different line, unless you explicitly tell it to do special processing which you won't in this case.
- This means if you save an entire file as CRLF, and another guy saves it as LF and commits it.. congratulations, you now have an entire file conflicting, even though you might have edited only one line in it.
- Our codebase's automatic systems help prevent this but eventually this'll happen.
- There's a few ways to fix it when it does but it can get really obnoxious which is why we try to prevent it in the first place.

This system allows for a pretty optimized way of checking if data is being edited by two people at once and flags things pretty accurately. It's an amazing tool even if it can get annoying at times.

There's also quirks with git like it being able to detect when you **move** a file and automatically merge changes into it without conflicting too hard. This is only sometimes a thing; Sometimes you luck out, sometimes you get a very obnoxious merge conflict. This is just how open source development goes with more than one person.

- To make life easier on yourself and others, try not to screw with spacing, try to atomize your PRs, etc, and try not to put yourself in a position where you have to change 100 files at once unless you *have* to.