<commit_before><!DOCTYPE html>
<head>
  <title>Galen's DBC Tech Blog - Inaugural Post</title>
  <meta charset="UTF-8">
  <link rel="stylesheet" type="text/css" href="your-stylesheet-link-here.css">
</head>

<main>
  <h1>Version Control, git and GitHub</h1>
  <h2>The Inaugural Post</h2>
  <h4>06|14|15</h4>

  <section>
    <p>
     At this point, if you've found this post you are well aware that I've just embarked on a journey into the depths of my nerd-self with Dev Bootcamp.  This program has taken on the considerable challenge of turning this middle school teacher into a master (or at least passable) programmer.  Each week I'm going to be writing about the lastest topics and tools I'm learning about here on my technical blog.  If you're starting now, by the end you just might know a thing or two about programming as well!
    </p>
    <p>
        This was Week 1 of Phase 0, and we covered some of the basics.  Think of it like the first week in a language class.  You don't start out analyzing french existentialism, you start with the alphabet and get SUPER excited when you can say "Bonjour, je m'appelle Galen".  That's where I am now, totally stoked about navigating through my GitHub repos without messing anything up.
    </p>
    <p>
        As that last line gave away, this week we set up our GitHub accounts.  Before we could do that, however, we learned a bit about why GitHub is such an invaluable tool for programmers.  Again, I have an analogy.  Anyone who has ever had to work on a group project knows the misery of, well, group projects.  You do a ton of work on the first section, send it to another group member, and get it back to find that all of your work has somehow been deleted in an attempt to make a chart fit on one page.  You'd love to just command+z your way back to your eloquent paragraphs, but unfortunately the file has already been saved, so your work is gone.
    </p>
    <p>
    In the development of Google Docs, Google at some point introduced the ability to "Revert to a previous version" and college students around the world rejoiced.  Rather than only having access to the most recently saved copy, Google stores multiple versions of your work along the way.  This is, in essence, a <b>version control system, or VCS</b>.  Whereas we used to keep our work in one file that we constantly overwrote with changes, version control keeps track of all the progress of a project through multiple mini-saves, called commits. 
    </p>
    <p>While VCS are helpful across many disciplines, in the tech world where one missing bracket can make your entire website eat itself, it's monumental.  (The eating itself example?  That happened to me in college, mere hours before my final project was due.  Not a happy day.)  <b>Git</b> is a very widely-used VCS that allows you to track progress and revisions of programming-related projects.  To keep organized, git uses a branch system, where the "master" branch is the cleanest, most perfect version of the code.  When making edits, you don't work on the master branch, but instead create a new branch (sometimes called a feature-branch or change-branch).  This allows you to work without the fear of accidentally messing up a year's worth of work.  Once you are ready to apply the update, you merge the change-branch into the master branch.  Here's the great part.  If you accidentally introduced a bug with an update, you can easily return back to the previous version by indicating which commit (remember, a commit is a save) you want to restore.  (No more website eating itself!)
    </p>
    <p>
    Git alone is great when working on a solo project, as all of the branches and commits can be managed locally, on your own computer.  But, in the tech world, projects are rarely done alone.  Team-based projects allow for collaboration that seriously elevates the end result.  So, enter <b>GitHub</b>.  GitHub takes what git does locally and makes it global.  Rather than just storing your files on your computer, it creates a centralized master version of the project online.  This allows multiple people to be working on the same code simultaneously without getting in each other's way.  When you're ready to merge branches (which, again, means apply your updates), you "push" your branch to the remote location (GitHub).  From there, you (or more likely someone else) can review the code and only "pull" it into the master version once everyone is satisfied with the update.  GitHub fosters a culture around collaboration that couldn't be possible otherwise.
    </p>

    <p>
    My brother is a programmer, and the first thing he asked when I started this program was for my GitHub username.  "I want to see your repos!" he said.  At the time I was nervous to give it to him, but now I'm starting to see how much I'm going to rely on GitHub throughout this journey and (hopefully) once I enter the professional world.  If this was confusing, don't worry, I was confused by it as well.  Poke around GitHub a bit on your own, see what makes sense, write down questions.  The GitHub community has some great resources built in that should help point you in the right direction -- check out the help page!
    </p>

    <p>
    That's all for this week!  I know the blog is in its baby-stage right now, but word on the street is that next week we're going to look into beefing it up a bit.  Until then, get at me on Twitter with any comments, feedback or questions: <b> @galencook</b>. </p>

    <h4>Happy coding!</h4>

    <h4>-g</h4>

      <!-- copy and paste as many sections as you want to add paragraphs -->
  </section>
</main><commit_msg>Fix closer<commit_after><!DOCTYPE html>
<head>
  <title>Galen's DBC Tech Blog - Inaugural Post</title>
  <meta charset="UTF-8">
  <link rel="stylesheet" type="text/css" href="your-stylesheet-link-here.css">
</head>

<main>
  <h1>Version Control, git and GitHub</h1>
  <h2>The Inaugural Post</h2>
  <h4>06|14|15</h4>

  <section>
    <p>
     At this point, if you've found this post you are well aware that I've just embarked on a journey into the depths of my nerd-self with Dev Bootcamp.  This program has taken on the considerable challenge of turning this middle school teacher into a master (or at least passable) programmer.  Each week I'm going to be writing about the lastest topics and tools I'm learning about here on my technical blog.  If you're starting now, by the end you just might know a thing or two about programming as well!
    </p>
    <p>
        This was Week 1 of Phase 0, and we covered some of the basics.  Think of it like the first week in a language class.  You don't start out analyzing french existentialism, you start with the alphabet and get SUPER excited when you can say "Bonjour, je m'appelle Galen".  That's where I am now, totally stoked about navigating through my GitHub repos without messing anything up.
    </p>
    <p>
        As that last line gave away, this week we set up our GitHub accounts.  Before we could do that, however, we learned a bit about why GitHub is such an invaluable tool for programmers.  Again, I have an analogy.  Anyone who has ever had to work on a group project knows the misery of, well, group projects.  You do a ton of work on the first section, send it to another group member, and get it back to find that all of your work has somehow been deleted in an attempt to make a chart fit on one page.  You'd love to just command+z your way back to your eloquent paragraphs, but unfortunately the file has already been saved, so your work is gone.
    </p>
    <p>
    In the development of Google Docs, Google at some point introduced the ability to "Revert to a previous version" and college students around the world rejoiced.  Rather than only having access to the most recently saved copy, Google stores multiple versions of your work along the way.  This is, in essence, a <b>version control system, or VCS</b>.  Whereas we used to keep our work in one file that we constantly overwrote with changes, version control keeps track of all the progress of a project through multiple mini-saves, called commits. 
    </p>
    <p>While VCS are helpful across many disciplines, in the tech world where one missing bracket can make your entire website eat itself, it's monumental.  (The eating itself example?  That happened to me in college, mere hours before my final project was due.  Not a happy day.)  <b>Git</b> is a very widely-used VCS that allows you to track progress and revisions of programming-related projects.  To keep organized, git uses a branch system, where the "master" branch is the cleanest, most perfect version of the code.  When making edits, you don't work on the master branch, but instead create a new branch (sometimes called a feature-branch or change-branch).  This allows you to work without the fear of accidentally messing up a year's worth of work.  Once you are ready to apply the update, you merge the change-branch into the master branch.  Here's the great part.  If you accidentally introduced a bug with an update, you can easily return back to the previous version by indicating which commit (remember, a commit is a save) you want to restore.  (No more website eating itself!)
    </p>
    <p>
    Git alone is great when working on a solo project, as all of the branches and commits can be managed locally, on your own computer.  But, in the tech world, projects are rarely done alone.  Team-based projects allow for collaboration that seriously elevates the end result.  So, enter <b>GitHub</b>.  GitHub takes what git does locally and makes it global.  Rather than just storing your files on your computer, it creates a centralized master version of the project online.  This allows multiple people to be working on the same code simultaneously without getting in each other's way.  When you're ready to merge branches (which, again, means apply your updates), you "push" your branch to the remote location (GitHub).  From there, you (or more likely someone else) can review the code and only "pull" it into the master version once everyone is satisfied with the update.  GitHub fosters a culture around collaboration that couldn't be possible otherwise.
    </p>

    <p>
    My brother is a programmer, and the first thing he asked when I started this program was for my GitHub username.  "I want to see your repos!" he said.  At the time I was nervous to give it to him, but now I'm starting to see how much I'm going to rely on GitHub throughout this journey and (hopefully) once I enter the professional world.  If this was confusing, don't worry, I was confused by it as well.  Poke around GitHub a bit on your own, see what makes sense, write down questions.  The GitHub community has some great resources built in that should help point you in the right direction -- check out the help page!
    </p>

    <p>
    That's all for this week!  I know the blog is in its baby-stage right now, but word on the street is that next week we're going to look into beefing it up a bit.  Until then, get at me on Twitter with any comments, feedback or questions: <b> @galencook</b>. </p>
</br>
    <h4>Happy coding!</h4>
</br>
    <h4>-g</h4>

      <!-- copy and paste as many sections as you want to add paragraphs -->
  </section>
</main>
{'fraction_non_alphanumeric': 0.056298132247499334, 'fraction_numerical': 0.0033637248827122243, 'mean_word_length': 3.719298245614035, 'pattern_counts': {'":': 0, '<': 97, '<?xml version=': 0, '>': 97, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1836920', 'n_tokens_mistral': 2997, 'n_tokens_neox': 2832, 'n_words': 1858}