params.json

{
  "name": "Git Gud Git Guide",
  "tagline": "Intermediate level git tutorial",
  "body": "Welcome to the git adventure! It is time for you to embark on your journey through the many wonders of git.\r\n\r\nThis tutorial assumes you have installed git on your computer, and preferably tried it out a little. During the course of this adventure you will create a small, rather useless python program. You don't need any previous python experience to follow, in fact this might even teach you some basic (probably bad) python. Make sure to read the instructions so you don't miss anything.\r\n\r\nI try to not explain too much about what's going on behind the scenes, since I think the reason a lot of people don't use many of git's functions is that they're all hidden inside pages and pages of backstory in tutorials or documentation. Thus, this tutorial mostly explains how, not why. I'd recommend going though this tutorial for a good overview of what can be done, and then reading up on the more confusing things after. \r\n\r\nLet's start!\r\n\r\n# Commits and status checking\r\n\r\nStart by [setting up a repo](https://help.github.com/articles/creating-a-new-repository/) and [cloning it to your computer](https://help.github.com/articles/cloning-a-repository/). I called mine `favorites`. Open up the repo in your terminal. Begin by creating an empty file called `main.py`.\r\n\r\nLet's take a look at the status of the repo using \r\n\r\n```\r\n> git status\r\n```\r\n\r\nOur new file is under \"Untracked files\". This basically means that the repo doesn't know and doesn't care about this file at the moment. To start tracking the file, we type \r\n\r\n```\r\n> git add main.py\r\n```\r\n\r\n`main.py` is now ready to be commited! Type\r\n\r\n```\r\n> git commit\r\n```\r\nThis will open your text editor and allow you to type a commit message. Write something like \"Add main.py\", save it and exit. You can now check `git status` again and see that everything is commited.\r\n\r\nLet's add some content to `main.py`, \r\n\r\n```\r\ndef print_favorites():\r\n   print('Hello world!')\r\n```\r\n\r\nTime to commit again. When committing, I like to use the flag `-m` (for message) to write a commit message directly on the command line. So I would write\r\n\r\n```\r\n> git commit -m \"Add a print function\"\r\n```   \r\n\r\nThis is nice if you want to write short messages for small changes, maybe in your private repo. It will be very useful during this tutorial. Otherwise, a good convention is writing multiple-lined commit messages, where the first line stands on its own and the following lines expand on the contents of the commit. Always remember to write descriptive commit messages! I may or may not follow that advice during this tutorial.\r\n\r\nOur changes are now saved, but only locally. To send the commit to GitHub, making it backed up and available anywhere, we use `git push`.\r\n\r\n```\r\n> git push\r\n```\r\n\r\nWe added a function, but we're not calling it yet. Add a call to `print_favorites`:\r\n\r\n```\r\ndef print_favorites():\r\n  print('Hello world!')\r\n\r\nprint_favorites()\r\n```\r\nYou can now run this using `> python main.py` (if you happen to have Python, otherwise it's not really important.)\r\n\r\n## git diff and git status -v\r\n\r\nAn important thing to do before committing is to check what's being commited. With `git status` you can check what files are being commited, but to see what lines of code are being commited you can use `git diff`. Try that now and make sure you are only committing the new funticon call. I often find sneaky debug prints that I forgot to remove this way.\r\n\r\n```\r\n> git diff\r\n```\r\n\r\nCheck `git status`. This time `main.py` is not under \"untracked files\" but under \"tracked files not staged for commit\". We could do `git add` again to stage it, but for files in this category it's enough to add the `-a` (for all) flag to the commit command to have them all staged and commited. \r\n\r\n```\r\n> git commit -a -m \"Add call to print_favorites\"\r\n```\r\n\r\nMutliple flags can be combined, so an equvialent command is\r\n\r\n```\r\n> git commit -am \"Add call to print_favorites\"\r\n```\r\n\r\nThose are the basics! Do `git push` and continue on.\r\n\r\n# Collaborating and conflicting\r\n\r\n## Merges\r\n\r\nTime for some more serious business. We're going to stage some situations that happen as you collaborate, and practice dealing with them.\r\n\r\nLet's expand `main.py` by adding some of your favorite things! I'll be writing mine in the examples but feel free to write whatever you want. Just don't go off the trail since we are doing this to stage some git situations. First, add your favorite animal. \r\n\r\n```\r\nanimal = 'cat'\r\n\r\ndef print_favorites():\r\n  print('Hello world!')\r\n\r\nprint_favorites()\r\n```\r\n\r\nCheck the diff, commit and push.\r\n\r\n## Introducing the NPC\r\n\r\nActually, this would be easier with some help. Your childhood friend Isabelle knows everything about you so she can add things too. We're gonna pretend to be Isabelle now, by cloning the repo again in a different folder. Do that now.\r\n\r\n``` \r\n> cd ../isabelle (create a folder somewhere outside the repo)\r\nisabelle > git clone [your repo]\r\n```\r\n\r\nShe adds your favorite movie, commits and pushes.\r\n\r\n```\r\nanimal = 'cat'\r\nmovie = 'fight club'\r\n\r\ndef print_favorites():\r\n...\r\n```\r\n\r\n```\r\nisabelle > git commit -am \"Add favorite movie\"\r\nisabelle > git push\r\n```\r\n\r\nMeanwhile, you start adding some printing functionality.\r\n\r\n```\r\nanimal = 'cat'\r\n\r\ndef hello()\r\n\r\ndef print_favorites():\r\n  print('Hello world!')\r\n  print('My favorite animal is', animal)\r\n...\r\n```\r\n\r\nNow, commit and try to push. What happens? You can't, since there are new changes in the remote repository. You will need to pull those changes first, using git pull.\r\n\r\n```\r\n> git pull\r\n```\r\n\r\nOops, what's this? Suddenly your editor pops up.\r\n\r\nYou and Isabelle have both made changes in the same file, which can make git a little confused. In this case however, the changes are in different parts of the file, so git can automatically figure out what the file should look like. It does however need to make a new commit for these changes, which is why it is now promptiong you for a merge commit message. You don't really need to write anything since there is a preset commit message, so just save and exit. Some people even set their clients to automatically create the merge commit in these situations.\r\n\r\nNow the merge is done, and a new commit has been created. Go ahead and push.\r\nThis beautiful MS Paint image shows what happened:\r\n\r\n![Merging](http://puu.sh/oEJyG/c9c44342f6.png)\r\n\r\nBoth the print and the movie commits were based off the animal commit, then a merge commit was created where both changes are present. \r\n\r\nSo that's fine and dandy and represents the reality of the situation. But it sort of... doesn't look too clean, and all these merge commits eventually start cluttering up the commit history. What if we could, instead of having two commits based off the animal commit, pretend like our print commit was based off the movie commit? Then we would get a clean sequence like this:\r\n\r\n![Rebasing](http://puu.sh/oEJDc/048946710c.png)\r\n\r\n## Rebasing\r\n\r\nThis can be done using rebasing. Many people always do a rebase when they pull down new changes. Let's get ourselves into the same situation again to try it out. Do `git pull` in Isabelle's repo. Isabelle adds your favorite book, commits and pushes:\r\n\r\n```\r\nbook = 'en annan gryning'\r\n```\r\n```\r\nisabelle > git commit -am \"Add favorite book\" \r\nisabelle > git push\r\n```\r\n\r\nAnd you add a print for the movie:\r\n\r\n```\r\nprint('My favorite movie is', movie)\r\n```\r\nAfter committing, instead of `git pull`, let's write `git pull -r`. (r for rebase)\r\n\r\n```\r\n> git pull -r\r\n```\r\n\r\nNow we have the situation in the image above, and a much cleaner log! Happy times. \r\n\r\n## Rainy day scenarios\r\n\r\nThe above were some very nice and friendly situations. Sometimes, git won't be able to figure out how to consolidate different changes in the same file. Let's try a scenario like that! \r\n\r\n(Remember to pull in Isabelles repo!)\r\nIsabelle is still adding things, she just added your favorite food, commited and pushed:\r\n\r\n```\r\nfood = 'pizza'\r\n```\r\n\r\n```\r\nisabelle > git commit -am \"Add favorite food\" \r\nisabelle > git push\r\n```\r\n\r\nMeanwhile, you add your favorite programming language:\r\n\r\n```\r\nlanguage = 'c++'\r\n```\r\nThe changes were made to the same line in the code, so this should cause a conflict. Let's try an ordinary pull first.\r\n\r\n```\r\n> git commit -am \"Add favorite programming language\"\r\n> git pull\r\n```\r\n\r\nOh no, it's a merge conflict! Time to panic!!! Or not. This isn't really scary at all. Let's take a look at what happened to the file.\r\n\r\n```\r\nanimal = 'cat'\r\nmovie = 'fight club'\r\nbook = 'en annan gryning'\r\n<<<<<<< HEAD\r\nlanguage = 'c++'\r\n=======\r\nfood = 'pizza'\r\n>>>>>>> e330d67ec9a9f1200117e0cdbfc8d2de05371e3a\r\n```\r\n\r\nThe conflicting parts are marked out with <<<<<<'s and ======='s. You can see what it looked like before, what your change is, and what the other person(s) changes are. Now it's up to you to decide what to keep and what to discard. In our case, we just keep both lines.\r\n\r\n```\r\nanimal = 'cat'\r\nmovie = 'fight club'\r\nbook = 'en annan gryning'\r\nlanguage = 'c++'\r\nfood = 'pizza'\r\n```\r\n\r\nThere we go! Now we have to commit this.\r\n\r\n```\r\n> git commit -am \"Merge\"\r\n```\r\n\r\nThat's how you deal with a merge conflict. You may find yourself in tricker situations when more lines of code are involved. Never panic though, just look through all the conflicts, and perhaps reach out to the person who made the conflicting changes if something is unclear.\r\n\r\nYou can also simplify merging using mergetools, but that's for another guide. Google it!\r\n\r\n## Rebasing again \r\n\r\nSince I introduced rebasing, we should take a look at what happens when you get a merge conflict during a rebase. The process is almost the same but the instructions from the client can look a little confusing.\r\n\r\nRecreate a similar scenario by adding new print statements in both Isabelle's and your repo. \r\n\r\n```\r\nisabelle > git pull\r\nisabelle > (add print for book)\r\nisabelle > git commit -am \"Print favorite book\" \r\nisabelle > git push\r\n```\r\n\r\n```\r\n> (add print for language)\r\n> git commit -am \"Print favorite programming language\"\r\n```\r\nNow do \r\n\r\n```\r\n> git pull -r\r\n```\r\n\r\nThis message looks way scarier than the ordinary merge conflict message. Note that it tells us to do `git rebase --continue` when we've resolved the conflict. Resolve it by keeping both changes and save the file. Now try this command. \r\n\r\n```\r\n> git rebase --continue\r\n```\r\n\r\nGit tells us that we need to do an add first. Do that.\r\n\r\n```\r\n> git add main.py\r\n> git rebase --continue\r\n```\r\n\r\nAnd there we go, ready to push! \r\n\r\nThat's about as scary as things normally get when collaborating with others. Grab a friend and start a project, or go help out with an open source one!\r\n\r\n\r\n# Doing many things at once - \r\n# branching and stashing\r\n\r\n## Stashing\r\n\r\nYou've started working on something new: a list with your favorite games. You're about halfway done, not ready to commit yet.\r\n\r\n```\r\ngames = ['pikmin', 'zelda ocarina of']\r\n```\r\n\r\nSuddenly, Isabelle pings you, saying there is still a print statement missing (for the favorite food) and it's really blocking her work, so you should fix it asap. And you're in the middle of your game list, you're not ready to commit it yet... What to do...\r\n\r\nNew command - git stash!\r\n\r\n```\r\n> git stash\r\n```\r\n\r\nThis takes all your uncommited changes and temporarily hides them in your 'stash'. You now have a clean working directory, and can easily add the print statement, commit and push. Do this. Check with `git diff` that you have the right changes before and after stashing.\r\n\r\nNow that everything is fixed, use `git stash apply` to go back to where you were.\r\n\r\n```\r\n> git stash apply\r\n```\r\n\r\nNow, finish up the list, commit and push!\r\n\r\n```\r\ngames = ['pikmin', 'zelda ocarina of time', 'starcraft 2']\r\n```\r\n\r\n## Branching \r\n\r\nSometimes you will make changes that are so large that you want to be able to work on it and make a few commits before actually letting those changes appear in the main project, for example if you're adding a large new feature. Then you may need something called a branch. This gives you something like a copy of the repo, where you can work without disturbing the \"master branch\", which is where we've been working so far.\r\n\r\nYou switch between branches using `git checkout [branchname]`, and to create a new branch, you can add the flag `-b`. It's time for a large refactoring of the favorites program, so let's create a branch for it.\r\n\r\n```\r\n> git checkout -b dictionary\r\n```\r\n\r\nSwitching to a new branch can be done at any point before a commit, the unsaved changes don't really belong anywhere until then. So if you start out on something on the master branch and realize midway through that it should have its own branch, just switch before committing. \r\n\r\nOur big change is putting all these odd variables we have into a dictionary, a Python structure kind of like a map in Java. First we create the dictionary, replacing the variables:\r\n\r\n```\r\nfavorites = {\r\n    'animal' : 'cat',\r\n    'movie' : 'fight club',\r\n    'book' : 'en annan gryning',\r\n    'language' : 'c++',\r\n    'food' : 'pizza'\r\n}\r\n```\r\n\r\nCommit this, just like you normally would. Try switching back to the master branch using `git checkout master` to see that the changes can't be found there. Switch back using `git checkout dictionary`.\r\nSince we have healthy amounts of paranoia, we want to push this in case our laptop gets stolen on the way home. We can push half-finished work since it's on a branch. \r\n\r\nTo push a branch, we need a little bit of extra magic. Try a `git push` and the client will tell you what to do, namely\r\n\r\n```\r\n> git push --set-upstream origin dictionary\r\n```\r\n\r\nThis will set the upstream to \"origin\", which is where the master branch pushes to (GitHub). From now on we can just push and pull normally on this branch. \r\n\r\nPulling down a new branch also needs an incantation. We want Isabelle to rewrite the print function in a smart way, since she knows everything about dictionaries. She will first need to do git pull, or a git fetch, to get the information about the new branch. Git fetch does only the first part of git pull, getting the information from upstream without trying to merge anything. This could be useful if you don't want to touch the master branch at that moment. Now, to pull the branch, she basically needs to create her own branch that tracks the remote branch, which is why the command needed looks a bit complicated. Just copypaste to try it out!\r\n\r\n```\r\nisabelle > git fetch\r\nisabelle > git checkout -b dictionary origin/dictionary\r\n```\r\n\r\nThis creates a new branch in her local repository, with the same name as the remote branch. YOu could name it to whatever you want, this is just for convenience.\r\n\r\nIsabelle rewrites the print method to make use of the dictionary.\r\n\r\n```\r\ndef print_favorites():\r\n  for key, item in favorites.items():\r\n    print('My favorite {} is {}.'.format(key, item))\r\n\r\nprint_favorites()\r\n```\r\n\r\nShe commits this, like a normal commit. She can also push it without issues since the upstream was already set. \r\n\r\nNow you can pull this branch, using git pull while having the branch checked out. This change is ready to go into production! We now want to merge it into the master branch.\r\n\r\nCheck out the master branch.\r\n\r\n```\r\n> git checkout master\r\n```\r\n\r\nTo start merging, do \r\n\r\n```\r\n> git merge dictionary\r\n```\r\n\r\nMerge conflicts when merging a branch are fixed in the standard way, resolve the conflicts and commit the results. You can also add the -r flag here to rebase instead of merging. I'm going to leave this as an exercise for the reader. \r\n\r\nYou can now go ahead and push! \r\n\r\n## Cleaning up \r\n\r\nIt can be a good idea to delete the branch, so you don't start stacking them up. This is slightly involved, you need to delete the remote branch once, then the \"tracking branches\" for everyone that was tracking it (you and Isabelle) and finally the local branches for everyone that had them. In that order, the commands are\r\n\r\n```\r\n> git push origin -d dictionary\r\n> git fetch -p\r\n> git branch -d dictionary\r\n```\r\n\r\nDeleting the local branches is not super important, you will probably not notice them being around. This concludes branches!\r\n\r\n# Fixing oopsies and cleaning up the log\r\n\r\n## Amend\r\n\r\nSometimes you commit something and more or less instantly regret it. It could be because of a typo in the commit message or the you forgot to remove some debugging prints. In those cases, our best friend is `amend`.\r\n\r\nYou add a nice welcome message to your program.\r\n\r\n```\r\ndef print_favorites():\r\n    print('Welcome to my favorites!')\r\n    ...\r\n```\r\n\r\nYou commit using\r\n\r\n```\r\n> git commit -am \"Add welcom message\"\r\n```\r\n\r\nOh no, that's a typo. No fear, do\r\n\r\n```\r\n> git commit --amend\r\n```\r\n\r\nand you editor will open, allowing you to change your message. \r\n\r\nYou decide to try running the program, \r\n\r\n```\r\npython main.py\r\n```\r\nand realize it would be much nicer if there was an empty line after the welcome message. That should just be added to the commit we had. Make the change, adding an empty `print()` statement. Add this to the commit using \r\n\r\n```\r\n> git commit -a --amend --no-edit\r\n```\r\n\r\nwhich lets you skip editing the commit message. Note the `-a` flag, you need to remember to stage your changes for commit. \r\n\r\nYou can basically do any change, add new files, remove files, change files, and then just do `git commit --amend` to add that change to the latest commit. However, once you've pushed it, consider it gone. Changing things that have been made public is almost never a good idea, since other people may have started using them already. Go ahead and push this commit. \r\n\r\n## Reset\r\n\r\nSometimes you just don't want the commit anymore. That can mean two things: That you want to keep the changes, just not have them in a commit, or that you want to remove all the changes you made.\r\n\r\nTo only undo the act of committing, use  \r\n\r\n```\r\n> git reset --soft HEAD~1\r\n```\r\n\r\nIf you also want to remove all the changes you made, and make it like you just pulled the previous commit, use\r\n```\r\n> git reset --hard HEAD~1\r\n```\r\nThis WILL delete your changes, so only use this if you really want to. In some cases, it's better to reset files one by one to make sure you know what you're resetting. To do this, use\r\n\r\n```\r\n> git checkout --main.py\r\n```\r\n\r\nMake some bogus edits in `main.py` to try these commands out.\r\n\r\n## Interactive rebase\r\n\r\nCreate a new branch called songs, and start adding your favorite tunes. To create a situation, we're going to add one song per commit. Go!\r\n\r\n```\r\n> git checkout -b songs\r\n> (add dictionary with one song)\r\n> git commit -am \"Add song dictionary with song x\"\r\n> (add dictionary with one song)\r\n> git commit -am \"Add song y\"\r\n...\r\n```\r\nThe end result should be something like\r\n```\r\nsongs = { \r\n    'the killers' : 'mr brightside',\r\n    'goldfrapp' : 'rocket',\r\n    'inka marka' : 'loy loy loy'\r\n    }\r\n```\r\n\r\nWhen you're done, also add some print statements for the songs in `print_favorites`. \r\n\r\n```\r\nprint('My favorite songs are:')\r\nfor key, item in songs.items():\r\n  print('{} by {}'.format(key, item))\r\n```\r\n\r\nCommit this. If you check `git status` now, you'll see that we have 4 commits pending. These are all the commits from the branch, and you can see them using `git log`. Try it.\r\n\r\n```\r\n> git log\r\n```\r\n\r\nSometimes you do want the change split up into several commits, and in that case you could just go ahead and push. But sometimes it's cleaner to have just one commit explaining your change, e.g. \"Add favorite songs and print them\". This can be achieved using interactive rebasing. Do\r\n\r\n```\r\n> git rebase -i \r\n\r\npick a982c8c Add song dictionary with whats your problem\r\npick 4482745 Add rocket\r\npick 6575534 Add loy loy loy\r\npick 57c845b Print favorite songs\r\n\r\n# Rebase 8e77232..0d49872 onto 8e77232\r\n#\r\n# Commands:\r\n#  p, pick = use commit\r\n#  r, reword = use commit, but edit the commit message\r\n#  e, edit = use commit, but stop for amending\r\n#  s, squash = use commit, but meld into previous commit\r\n#  f, fixup = like \"squash\", but discard this commit's log message\r\n#  x, exec = run command (the rest of the line) using shell\r\n#\r\n# These lines can be re-ordered; they are executed from top to bottom.\r\n#\r\n# If you remove a line here THAT COMMIT WILL BE LOST.\r\n#\r\n# However, if you remove everything, the rebase will be aborted.\r\n```\r\n\r\nWe want to merge the commits, so we can use either `squash` or `fixup`. `squash` lets us write a new commit message, while `fixup` uses the top commit's message. Squashing can be nice if you want to reuse parts of different commit messages. Otherwise, you can use fixup to just use the top one, or combine fixup with reword to edit the top message. Let's go with the latter option.\r\n\r\n```\r\nr a982c8c Add song dictionary with whats your problem\r\nf 4482745 Add rocket\r\nf 6575534 Add loy loy loy\r\nf 57c845b Print favorite songs\r\n```\r\n\r\nSet the commit message to something nice like \"Add favorite songs and print them\". Check `git log` again. Very cool! NOTE that this should not be done if more people have access to and are using your commits, as in the previous example.\r\n\r\nNow you can merge this branch into master and push it.\r\n\r\n```\r\n> git checkout master\r\n> git merge songs\r\n> git push\r\n```\r\n\r\n# Pull requests and forks\r\n\r\n## Pull requests\r\n\r\nUsing pull requests is a more involved way of merging a branch with master. If you are working on a larger project that may even be in production, it is a good idea to have your teammates look over your code before you merge it. Also, if you wrote some code for a project that you don't have writing rights to, such as an open source project, you will need to do a pull request and have the owners merge your code. \r\n\r\nWe'll try both these scenarios. First, there is one very obvious thing missing from our project, printing the games. Create a branch and fix that.\r\n\r\n```\r\n> git checkout -b games\r\n```\r\n\r\n```\r\nprint('My favorite games are:)\r\n[print(game) for game in games]\r\n```\r\n\r\nNow, hit up your repo on GitHub. Go to your branches, and find the games branch. (This is where the clutter will really show if you neglect deleting branches.) Here, click \"Create Pull Request\". This will take you to a page where you can see all the changes you're trying to add, and you can write a description of them. Make sure to make this good, or your change might not even be considered! When you're done, click on \"Send pull request\". The relevant people should be notified, and now you just gotta wait for them to look it over. Isabelle takes a look, tries the program, and notices that it prints a long block of text. \"Add some blank lines to make the output more readable\", she comments. \r\n\r\nIt is very important to remember that comments on your code are always a good opportunity to learn. Respect them, learn from them, but don't take them personally. Sure, five-minutes-ago you may have made a mistake, but from-now-on-you sure won't make that one again (at least not this week), and it's all thanks to the feedback you got. \r\n\r\nAfter receiving feedback, you can discuss it in the comments, and also make additional commits. Make a commit adding blank lines in appropriate places. After this, you could make a comment like \"I added blank lines, how does it look?\" and Isabelle may respond with \"Great, go ahead and merge.\"\r\n\r\nWhen there are not conflicts, you can merge using the big green \"Merge pull request\" button on GitHub. Otherwise, you can always merge locally and push, and GitHub will notice that the merge is done. Either way should work for us right now so go pick one and do it. Afterwards, GitHub will offer you a nice button to delete the branch. Good job!\r\n\r\n## Forks \r\n\r\nIf you want to work on a repo that's not yours, instead of a branch you do a fork. This creates a copy of the repo that you're free to do what you want with (though you should of course consider licenses). Sometimes you do this just to make a tweak of some project for your own use, but sometimes you want to add an improvement that could benefit other users, so you want it to be added to the original repo. This is often appreciated, and it is done using pull requests just like in the previous section. Time to try it out!\r\n\r\nThere is a Hall of Fame for the brave souls who completed this tutorial [here](https://powion.github.io/halloffame). The final test you need to pass to belong on this list is adding yourself to it! Go to the repository [here](https://github.com/powion/halloffame). In the top right corner, there should be a \"Fork\" button. Go ahead, click it! \r\n\r\nA fork of the halloffame repo should be created on your GitHub account. Clone this to your computer, and open up the file `index.html`. In there you can find the hall of fame list (search for \"ENTER YOUR NAME\"). There are some instructions on how to enter your name, follow those and look at previous entries and you should be able to figure it out. Add your name to the list, do an extra check with `git diff` so everything looks ok, and commit and push. \r\n\r\n```\r\n...\r\n\r\nAwesome Humanbeing<br>\r\n<a href=\"https://github.com/coolgit\">Cool Gitlearner</a><br>\r\nYOURNAMEHERE!\r\n\r\n...\r\n```\r\n\r\nNow, go to your fork repo on GitHub, and open the tab \"Pull requests\" found at the top. \r\n\r\n![Pull request tab location](http://puu.sh/oFf6q/e5fcbbd76b.png)\r\n\r\nClick the big green \"New pull request\" button. You will see the diff between your fork and the original halloffame repo. Click the big green \"Create pull request\" button (obviously not to be confused with the big green \"New pull request\" button from the previous page) and you can write a lovely message to me explaining why I should approve this change. (Basically \"I made it here, put me on dat list\"). Feel free to add small feedback comments here if you want. Press the last big green \"Create pull request\" button to send it to me for review. I'll accept it as soon as I can, so check back! Every new name makes me happy, so I look forward to adding yours. \r\n\r\n## The end\r\n\r\nThat concludes the tutorial! I hope you enjoyed it and/or learned something new. If there are changes you think should be made to this tutorial, go ahead and send me a pull request!  \r\n",
  "note": "Don't delete this file! It's used internally to help with page regeneration."
}