<!DOCTYPE html>
<head>
  <title>Patrick DeWitte's DBC Blog</title>
  <meta charset="UTF-8">
  <link rel="stylesheet" type="text/css" href="your-stylesheet-link-here.css">
</head>
<body>
  <main>
    <h1>Phase0/Week1</h1>
    <h2>Gitting good (zing.)</h2>
    <h4>Feb 11, 2016</h4>

    <section>
      <p>
          This week I dove into the awesome world of git and version control. Version control is the ability to track, review, and make changes to a file without overriding any previous versions. Git is the software that enables version control.  GitHub, an online home for your various coding repositories, makes it possible for you or other authors to work on various versions of the same file.
      </p>
      <p>
          Version control is beneficial for many reasons. If you have many contributors to a project, version control allows each of them to work on separate copies (clones) of the file or files without affecting any other contributors' work, or the master file. Version control also allows you to review any previously made changes, updates, or improvements made by yourself or any other contributors. Debugging, or hunting for any faults within the code would be fairly difficult without version control, especially in large applications.
      </p>
      <p>
          Git is helpful in version control due to its ability to track changes on the local level. You may be starting with a clone of someone else's code, or some sort of master source living remotely on GitHub. Git will allow you to work on the code locally, on other branches, which will later allow you to make comparisons to previous versions (other branches) of code living remotely on GitHub.
      </p>
      <p>
          GitHub is ideal for managing all of these different versions of files and branches. While you are working on files on the local level, the master, or most updated version of the code (which is hopefully working) lives on GitHub, untouched. GitHub allows multiple users to clone repositories to their computer, or fork a repository over to their own account, allowing them to work on someone else's master repository, but without making any contributions to the original. Jim and Steve may be working on the same code, but if Jim is done and wants no more changes, Steve may fork Jim's repository, and make all the changes he wants, as Steve will essentially have his own copy of Jim's master. Once the master code is ready to be updated, any changes made on the local level can be pushed to GitHub, reviewed via a Pull Request, and merged after review.
      </p>
      <p>
          Git and GitHub are fairly straightforward, although I know I'll need a lot of practice with both before it's second nature. I'm getting the sense that this is the route through which all code is updated. I'll keep forging ahead to see...
      </p>
      </section>
    </main>
  </body>
  </html>
Add week 1 blog post
Add week 1 blog post
