Guide to git: Difference between revisions

From BeeStation Wiki
Jump to navigation Jump to search
m (Itsmeowdev moved page Setting up git to Guide to git: More accurate to new content)
No edit summary
Line 1: Line 1:
'''WARNING: This guide is heavily outdated, and if you follow it, it's likely nobody will be able to help you if things go wrong.'''
<span id="git-command-line"></span>
= Git Command Line =


Follow this guide and use GitKraken instead: https://forums.yogstation.net/index.php?threads/release-the-gitkraken-how-to-make-your-first-pull-request.15099/
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.


----
<span id="the-setup"></span>
== The Setup ==


This guide uses TortoiseGIT. While there are other programs out there, this one is the most commonly used. This guide is for Windows only.
Download and install [git:|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.
TortoiseGIT is a simple enough program but other clients or the git command line are recommended once you are familiar with the basics.


It's recommended if you don't want to read this that you just watch this video:https://www.youtube.com/watch?v=ZDR433b0HJY
Also be sure to set your name/email in your git client so your commits show properly and are attributed properly.


Some further videos that are recommended watching for any git user:
<code>git config --global user.name &quot;Name Here&quot;</code> <code>git config --global user.email &quot;[email protected]&quot;</code>


https://www.youtube.com/watch?v=MYP56QJpDr4 - Git from bits up
Often times the default can expose personal information. So be ''sure'' to set this.


https://www.youtube.com/watch?v=4XpnKHJAok8 - Linus Torvalds (yes that linus) on git
As long as the email you put is added to your GitHub account it will work fine and show your icon on commits. Name can just be your GitHub username or something else, doesn’t matter.


== If you are having trouble ==
<span id="git-terms-cheat-sheet"></span>
Watch this video guide if you are having difficulty with any step below. [http://www.youtube.com/watch?v=Z5tTCo6IHLg]
== Git Terms Cheat-Sheet ==
If you have further problems, contact someone on [[Community|#coderbus]]


== Step 1 - Install Git ==
'''HEAD:''' Term for the current location on the “commit tree”, basically your current location in history.


* Go here: http://git-scm.com/downloads
'''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.
* Download the Windows Git program.
* It should look something like 'Git-1.7.11-preview20120620.exe'
* Install it and leave everything on default (just keep clicking next).
* Wait till the installer has finished.
* Step 1 over!


== Step 2 - Register on Github ==
'''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.


* Head over here: https://github.com/
'''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
* Click '''Signup and Pricing''' in the top right-hand corner.
* Click the ''Create free account button'''.
* Create an account with your username and email.
* Done!


== Step 3 - Configure Git ==
'''Branch:''' A collection of commits in one big chain, that can split off at any time


'''OPTIONAL!'''
'''Merge:''' Joining two branches


* Head here: https://help.github.com/articles/set-up-git/#setting-up-git
'''Remote:''' A secondary git repository to sync changes with, usually GitHub but can be any server that supports the protocol
* Follow the guide above from steps 2 to 4, you can install Git for Windows if you want however it's not recommended
* Now you have Git all setup, but if you're command line illiterate like me, you'll wanna have some fancy graphics!


== Step 4 - TortoiseGit ==
'''Upstream:''' The remote that you are pulling from/pushing to, in that case your fork OR the main beestation repo


* Go here: http://code.google.com/p/tortoisegit/wiki/Download
<span id="git-commands-cheat-sheet"></span>
* Download the right TortoiseGit for your system.
== Git Commands Cheat-Sheet ==
* When installing, click '''OpenSSH''' rather than TortoisePLink
* Finish installing.


== Step 5 - Forking Code ==
<code>git clone (github link)</code> downloads the linked repository into a folder at the current location.


* Head over to: https://github.com/tgstation/tgstation
<code>git pull remotename branchname</code> runs <code>git fetch remotename</code> and then <code>git merge remotename/branchname</code>
* Click the '''Fork''' button in the top right corner.
* The page you'll be directed to is now your fork. You'll be pushing updates here, and making pull requests to have them merged the main (master) repository.
* Copy the HTTP URL. It's next to the '''HTTP''' '''GIT''' and '''Git Read-Only''' buttons. It'll look something like: https://github.com/NAME/tgstation


== Step 6 - Downloading the Code ==
<code>git fetch remotename</code> gets all the new commits from remote


* Find a computer folder where you don't mind the code sitting.
<span id="merging-strategies"></span>
* Right click and choose '''Git Clone...'''
=== Merging Strategies ===
* The URL field should be filled with the URL of your Fork. If not, paste it in.
* Click Next and watch flying tortoises bring you your code.


== Step 7 - Setting up TortoiseGit ==
<code>git merge branchname</code> Attempts to merge all new commits from branchname into the current HEAD, through a few strategies that vary:


* Right click '''on the folder that was created''' (usually called tgstation13), and go to '''TortoiseGit''' and then click on '''Settings'''.
* 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
* Click on '''Remote''' under '''Git'''.
* 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”
* There should be one thing on the list of remotes, with the name: '''origin'''.
* Rebase: this is its own command, <code>git rebase branchname</code> This 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
* You're now adding the main repository as a source you can pull updates from.
* In the '''Remote''' box type in '''upstream'''.
* In the '''URL:''' box put: https://github.com/tgstation/tgstation.git
* Click '''Add New/Save'''.
* Click '''Ok'''.
* Almost done!


== Step 8 - Updating your Repo ==
<code>git reset commitsha (or branchname)</code> - 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


* Updating your repo with the master should be done before trying anything.
<code>git checkout commitsha (or branchname)</code> - 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.
* Right-click the folder your repo is in and select '''TortoiseGit''' then '''Pull'''.
* Click the radial button next to '''Remote''' and make sure '''upstream''' (or whatever you called it) is selected next to it.
* The '''remote branch''' should be set to '''master'''.
* Then click '''Ok'''. This will pull the latest changes from the master repo.


== Step 9 - Making a Branch ==
<code>git branch (branchname)</code> creates a new branch with the current commit history of the branch you are on
* '''Branching your repo is very important for organising your commits, you should have a different branch for each unrelated code change (e.g. if you wanted to make some new sprites for one item and change the properties of another these should be in seperate branches), as Pull requests work off branches rather than commits this will allow you to make a seperate Pull Request per change. Doing this streamlines the whole process and will save everyone a bunch of headaches.'''
* Right-click in your working folder. Then choose '''TortoiseGit''', and '''Create Branch...'''
* Type in your new branch name
* (Optional) Tick '''Switch to new branch'''
* Press '''Okay''' and your new branch is created


To switch between Branches:
<code>git branch -d (branchname)</code> deletes branch with said name
* Right-click in your working folder. Then choose '''TortoiseGit''', and '''Switch/Checkout...'''
* Choose your Branch then press '''Okay'''


== Step 10 - Making a Commit ==
<code>git add (filepath)</code> adds the file to “staging”


* A commit is confirmed change of the files in your repo, it's how you make changes permanently to the files in your repo, so try not to commit without making sure it works (though subsequent commits can fix it).
<code>git restore --staged (filepath)</code> removes the file from “staging”
* As said before, you should use different branches to separate your commits/changes.  Don't commit to master.  It should be clean, so you can fall back on it if needed.
* To make your commits, you need to edit the files using BYOND's inbuilt editing tools. Make sure to [[Coding Standards|follow coding standards]] when making your changes! When you're finished, right click the folder you're working with and choose '''Git Commit -> "[Your Branch Name]"''' (Example: Git Commit -> "My_First_Branch")
* You can then select only the files you want to be committed by ticking or unticking them. You should also write a detailed commit summary, detailing what happened in that commit.
* Click '''Ok''' and the commit will be committed to your local repo!


== Step 11 - Making a Pull Request ==
<code>git status</code> View what is staged, what is not, also view what branch/commit you are on. VERY useful.


* Right-click in your working folder. Then choose '''TortoiseGit''', and '''Push...'''
<code>git add .</code> Add ALL local filesystem changes to staging
* Set '''Local''' and '''Remote''' to the name of the branch you committed before. (e.g. My_First_Branch)
* Under Destination, set Remote: to '''origin'''.
* Click '''Ok'''. This'll upload your changes to your remote repo (the one on GitHub).
* Head to your GitHub repo e.g https://github.com/NAME/tgstation13.git
* Click '''Pull Request''' at the top right.
* [[Getting_Your_Pull_Accepted|Give this a quick read.]]
* Fill out a summary and then create the pull request.
* You're done! In many cases there will be issues pointed out by other contributors, unfortunate merge conflicts, and other things that will require you to revisit your pull request.
* Optionally, view step 13 for a guide on cleaner commit logs, '''cleaner commits help maintainers review!'''


== Step 12 - Checking Out Github PRs Locally (Optional) ==
<code>git checkout -- .</code> Undo all local changes, get rid of them
*'''This is a must for maintainers who need to easily test other people's code!'''
*Locate the section for your Github remote in the .git/config file. Note that it is hidden by default. It looks like this:


:[remote "upstream"]
<code>git checkout HEAD .</code> The same as above but stricter, if it doesn’t work
::fetch = +refs/heads/*:refs/remotes/upstream/*
::url = https://github.com/tgstation/tgstation.git


*Now add the following line:
<code>git checkout HEAD (or --) filepath</code> resets that file to the last commit on your filesystem
::fetch = +refs/pull/*/head:refs/remotes/upstream/pr/*


*Fetch from the upstream remote.
<code>git commit -m &quot;Commit message&quot;</code> creates a commit with the current staged changes and adds it to the branch
*To check out a particular pull request, use Switch/Checkout and select the branch from the drop-down list.


=== Git command line verison ===
<code>git push remotename branchname</code> pushes the current local branch to remotename/branchname


No editing of the git config file needed, just do git fetch <remote> pull/<pr>/head:target_branch usually something like git fetch upstream pull/26271/head:pr-26271.
<code>git remote add (remotename) (github link)</code> creates a remotename with a github repo so you can push/pull from it


Then you can checkout the target_branch
<code>git push -u remotename branchname</code> OR <code>git pull --set-upstream remotename branchname</code> sets the route from your CURRENT local branch to a remote branch. This makes it so you can just type <code>git push</code> or <code>git pull</code> without having to specify the remote or branch.


== Step 13 - Clean commits (Optional) ==
<code>git reset HEAD~(number)</code> resets current HEAD X commits backwards in the commit history
*'''This is a guide specifically for TortoiseGit, our recommended client'''
* Your commit logs are filthy, full of one or two line commits that fix an error that makes you look bad, and the commit is called "Whoops" or "oops"
* Navigate to your '''local version of the branch'''
* Ensure it is up to date with the '''remote'''
* Go to '''Show log'''
* Select all the commits associated with this change or PR
* Right click and choose '''Combine to one commit'''
* This will open up the standard commit interface for TortoiseGit, with the commit logs of the selected commits merged together
* Perform the normal routine for a commit
* Go to '''push''' your branch to the '''remote branch'''
* Ensure '''Force Overwrite Existing Branch (may discard changes)''' is selected to make sure the PR/Remote updates to contain just this squashed commit


<code>git checkout HEAD~(number)</code> temporarily rewinds and detaches HEAD X commits back in history


{{Contribution guides}}
<code>git log</code> show the commit history (q to exit)
[[Category:Game Resources]] [[Category:Guides]]
 
<code>git diff HEAD</code> show all the changes you have made locally that are not committed (q to exit)
 
<span id="merge-conflicts"></span>
== Merge Conflicts ==
 
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
 
<pre>&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt; HEAD
(version before merge)
=================
(new version)
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; commitsha</pre>
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.
 
<pre>/proc/main()
    var/the_variable = GLOB.the_var
&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt; HEAD
    if(variable?.test())
=================
    if(the_variable.test()
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; commitsha
        do_something()</pre>
This would most likely be merged into this:
 
<pre>/proc/main()
    var/the_variable = GLOB.the_var
    if(the_variable?.test()
        do_something()</pre>
The inferred history here is the variable was named <code>variable</code>, and the current branch changed it to <code>the_variable</code>. However, another branch added the <code>?.</code> 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.
 
<span id="mapping-conflicts"></span>
=== Mapping Conflicts ===
 
DMM files are impossible to merge via text, so we have tooling in the repository to automatically merge them.
 
Run <code>tools/mapmerge2/Resolve Map Conflicts</code>
 
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.
 
<span id="icon-conflicts"></span>
=== Icon Conflicts ===
 
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.
 
Run <code>tools/dmi/Resolve Icon Conflicts</code>
 
<span id="automatic-merge-conflict-resolution"></span>
=== 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 <code>tools/hooks/Install</code>. No need to run them manually anymore, they will run automatically if you merge or commit.
 
<span id="making-a-basic-pr-with-command-line"></span>
== Making a basic PR with command line ==
 
First, you’ll need to clone the repository:
 
<code>git clone https://github.com/BeeStation/BeeStation-Hornet/</code>
 
Then, change directories into the repository with <code>cd</code>.
 
You will now need to create a branch for your changes, using the master branch for PRs is bad practice.
 
<code>git branch my-pr-that-does-something</code>
 
Now the branch is created, but you need to “check it out”, or switch to it:
 
<code>git checkout my-pr-that-does-something</code>
 
Make any changes in VSCode. When you’re done, run:
 
<code>git status</code>
 
Notice what files now have “unstaged changes”. Any files you do NOT want changes in, run
 
<code>git checkout HEAD (filepath)</code>
 
This will delete unwanted changes on your local filesystem.
 
Any files you DO want to PR changes to, run
 
<code>git add (filepath)</code>, or if you want to add all files, use <code>.</code> as the filepath.
 
Now run <code>git status</code>, and confirm all the changes you want are staged.
 
Now you’re ready to commit. Run:
 
<code>git commit -m &quot;Put a summary of your changes here&quot;</code>
 
This will create a commit and add it to the current branch. Run <code>git log</code> to see the commit history. You can exit with <code>q</code> 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.
 
<code>git remote add fork https://github.com/(your GitHub username)/BeeStation-Hornet/</code> (change this to your fork’s link)
 
Then, you can push to a branch on your fork.
 
<code>git push -u fork my-pr-that-does-something</code> - The <code>-u</code> here tells Git to save that this is the path to remote. This means that when you run <code>git push</code> without passing a remote or branchname, it will know where to push the next time. The same applies to <code>git pull</code>.
 
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.

Revision as of 21:22, 27 March 2023

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.

The Setup

Download and install [git:|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 protected]"

Often times the default can expose personal information. So be sure to set this.

As long as the email you put is added to your GitHub account it will work fine and show your icon on commits. Name can just be your GitHub username or something else, doesn’t matter.

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

Merging Strategies

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 branchname This 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

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.

Mapping Conflicts

DMM files are impossible to merge via text, so we have tooling in the repository to automatically merge them.

Run 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.

Icon Conflicts

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.

Run 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 cd.

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:

git status

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.

Now run 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 git pull.

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.