Guide to git
Git Command Line
Many are drawn to GUI versions of Git, such as GitHub Desktop, GitKraken, and VSCode’s Git integration. However, I believe this is more of a hindrance than a help. If you’re just making mapping or sprite PRs, sure, maybe you can get along just fine with GitHub Desktop. However, these tools lack the expansive features of the command line and are harder to get help with. Command line is far more google-able if you have problems and I highly recommend it. Far more people will be able to assist you if you are using command line than an GUI tool.
Download and install git-scm. You should probably set it up to use the shell of your choice (I use command line on Windows Terminal), or if you prefer Git Bash, use that. Do note that installing it to your system PATH is very useful if you want to use VSCode’s builtin terminal.
Also be sure to set your name/email in your git client so your commits show properly and are attributed properly.
git config --global user.name "Name Here"
git config --global user.email "email here"
Often times the default can expose personal information. So be sure to set this.
Name can just be your GitHub username or something else, doesn’t matter.
As long as the email you put is added to your GitHub account it will work fine and show your icon on commits. GitHub will also provide you with a private email, if you don't have any type of "business" email, it is recommended to use this.
For more details on commit email privacy, read GitHub's guide.
Git Terms Cheat-Sheet
HEAD: Term for the current location on the “commit tree”, basically your current location in history.
Detached HEAD: A state the client can be in, where the history is at a specific point in time, but not attached to a branch. Committing changes is not possible unless the HEAD is re-attached by checking out a branch.
Staging: an in-between state of your local filesystem and a commit. This is so you can have some changes locally but not commit all of them.
Commit: a collection of changes, applied as a “patch” onto the previous (parent) commit. Think of it as a chain link that contains a snapshot of the repository at that time
Branch: A collection of commits in one big chain, that can split off at any time
Merge: Joining two branches
Remote: A secondary git repository to sync changes with, usually GitHub but can be any server that supports the protocol
Upstream: The remote that you are pulling from/pushing to, in that case your fork OR the main beestation repo
Git Commands Cheat-Sheet
git clone (github link) downloads the linked repository into a folder at the current location.
git pull remotename branchname runs
git fetch remotename and then
git merge remotename/branchname
git fetch remotename gets all the new commits from remote
git merge branchname Attempts to merge all new commits from branchname into the current HEAD, through a few strategies that vary:
- Fast-forward - Simple, used when the new changes are directly on top of, as in, have a continous history rooting from the current HEAD. For example, if someone pushed one commit to origin/master, and your local master didn’t have this one commit, it can simply be “fast forwarded” and add the new commit on the end
- Recursive: the normal strategy, it tries to put both the local changes AND the remote changes into one branch by adding the commits in what is called a “merge commit”
- Rebase: this is its own command,
git rebase branchnameThis attempts to take all of your LOCAL changes, and then append them to the end of the REMOTE branch, rather than putting the remote branch into your current one. This is personally my favorite for PRs because it makes a clean commit history, but it also “rewrites” all your commits into new ones, so it’s not suitable for branches used by multiple people because it doesn’t maintain the commit tree
git reset commitsha (or branchname) - Sets the current HEAD to the commit listed OR the branchname listed. If you specify –hard, it will update the local filesystem to match this, if you don’t specify or put –soft, it only updates this in git, keeping your file changes intact
git checkout commitsha (or branchname) - For commits, this will “rewind” you to that commit and also “detaches HEAD”, which basically means you are no longer on a branch and can’t commit stuff. A temporary rewind, essentially. When you check out a branch, it’s basically just moving you to that branch. Do this for new PRs etc.
git branch (branchname) creates a new branch with the current commit history of the branch you are on
git branch -d (branchname) deletes branch with said name
git add (filepath) adds the file to “staging”
git restore --staged (filepath) removes the file from “staging”
git status View what is staged, what is not, also view what branch/commit you are on. VERY useful.
git add . Add ALL local filesystem changes to staging
git checkout -- . Undo all local changes, get rid of them
git checkout HEAD . The same as above but stricter, if it doesn’t work
git checkout HEAD (or --) filepath resets that file to the last commit on your filesystem
git commit -m "Commit message" creates a commit with the current staged changes and adds it to the branch
git push remotename branchname pushes the current local branch to remotename/branchname
git remote add (remotename) (github link) creates a remotename with a github repo so you can push/pull from it
git push -u remotename branchname OR
git pull --set-upstream remotename branchname sets the route from your CURRENT local branch to a remote branch. This makes it so you can just type
git push or
git pull without having to specify the remote or branch.
git reset HEAD~(number) resets current HEAD X commits backwards in the commit history
git checkout HEAD~(number) temporarily rewinds and detaches HEAD X commits back in history
git log show the commit history (q to exit)
git diff HEAD show all the changes you have made locally that are not committed (q to exit)
Merge conflicts can look intimidating, but they aren’t in reality (unless you don’t know how to code).
When two commits change the same part of the same file, git tries to merge them, but can’t, since it would probably break the code if it guessed.
Instead, it lets you do it yourself.
It writes into the file what looks like this
<<<<<<<<<<<<<<<<<< HEAD (version before merge) ================= (new version) >>>>>>>>>>>>>>>>>> commitsha
It usually does that multiple times per file. Basically compare the two, remove the markers and write the file back how it should be if both were merged into one.
Here is an example.
/proc/main() var/the_variable = GLOB.the_var <<<<<<<<<<<<<<<<<< HEAD if(variable?.test()) ================= if(the_variable.test() >>>>>>>>>>>>>>>>>> commitsha do_something()
This would most likely be merged into this:
/proc/main() var/the_variable = GLOB.the_var if(the_variable?.test() do_something()
The inferred history here is the variable was named
variable, and the current branch changed it to
the_variable. However, another branch added the
?. operator to the proccall. When this change was merged in, Git noticed an unexpected change to the variable name and placed a merge conflict. Making sense now? The way to merge it is applying both changes as intended.
DMM files are impossible to merge via text, so we have tooling in the repository to automatically merge them.
tools/mapmerge2/Resolve Map Conflicts
If there are any conflicting tiles, you will be prompted to fix it in your map editor, then you can continue by committing the changes.
For more info, see Map Merger.
DMI files contain multiple images, making merge conflicts always happen if the file is updated by two branches. This means solving them is relatively trivial but can be time consuming. So there’s a tool for it.
tools/dmi/Resolve Icon Conflicts
Automatic Merge Conflict Resolution
Also, perk of using command line, if you want git to AUTO MERGE DMI and DMM, as well as auto-cleanup your maps on commit, just run
tools/hooks/Install. No need to run them manually anymore, they will run automatically if you merge or commit.
Making a basic PR with command line
First, you’ll need to clone the repository:
git clone https://github.com/BeeStation/BeeStation-Hornet/
Then, change directories into the repository with
You will now need to create a branch for your changes, using the master branch for PRs is bad practice.
git branch my-pr-that-does-something
Now the branch is created, but you need to “check it out”, or switch to it:
git checkout my-pr-that-does-something
Make any changes in VSCode. When you’re done, run:
Notice what files now have “unstaged changes”. Any files you do NOT want changes in, run
git checkout HEAD (filepath)
This will delete unwanted changes on your local filesystem.
Any files you DO want to PR changes to, run
git add (filepath), or if you want to add all files, use
. as the filepath.
git status, and confirm all the changes you want are staged.
Now you’re ready to commit. Run:
git commit -m "Put a summary of your changes here"
This will create a commit and add it to the current branch. Run
git log to see the commit history. You can exit with
q and navigate with arrows.
That worked, so now you just need to push the changes to your fork of the repository. So go on GitHub and press the fork button on the top right of BeeStation-Hornet, and you’ll be taken to your new fork repository. You need to add this as a remote on your local client.
git remote add fork https://github.com/(your GitHub username)/BeeStation-Hornet/ (change this to your fork’s link)
Then, you can push to a branch on your fork.
git push -u fork my-pr-that-does-something - The
-u here tells Git to save that this is the path to remote. This means that when you run
git push without passing a remote or branchname, it will know where to push the next time. The same applies to
Done! Now go to your fork on GitHub and refresh, you’ll see something like “changes have recently been pushed to branch my-pr-that-does-something” with a big “Open pull request” button. Press that and make sure it’s going to the main repository. You can also do this manually from the Pull Requests tab on your fork.
How to update your branch from master
click (4) once the merge resolve is done.
|Now commit your changes.|
Q. How can I resolve the map conflicts?
A. See Map Merger
|General||Development, Downloading the source code / hosting a server, Guide to git, Game resources category, Guide to changelogs|
|Database (MySQL)||Setting up the database, MySQL|
|Coding||Understanding SS13 code, SS13 for experienced programmers, Binary flags, Text Formatting|
|Mapping||Guide to mapping, Map merger, Exploration Ruins|
|Spriting||Guide to spriting|
|Wiki||Guide to contributing to the wiki, Wikicode|