<commit_before><!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8">
  <title>Week 1 blog</title>
</head>
<body>
  <h1>Week 1 blog</h1>
 
  <article>
  <p>
      Here we are at the beginning of Dev Bootcamp week one, and I feel like I've learned a lot. The scope of the development world gets bigger and bigger every day. I never knew there was so much to learn, but I'm really enjoying the process so far. One of the key things I learned about this week is version control. This is a way that developers can communicate changes that they make to files between one another, because version control is an effective record keeping strategy. In essence, version control is a series of snapshots of changes made to a file, such as modifications made to a series of code. Rather than tracking every single change individually, version control keeps track of a series of changes made, either by one person, or group members collaborating on a project. 

      </p>
      <p>This is more helpful when looking at changes because you are not seeing the minutae of every single syntax correction or other minor change. Rather, you can see a set of changes that were made, why they were made, and how they change the source material. For instance, if I were to proofread this blog post after submitting it, I can commit a set of changes stating that I corrected spelling and syntax errors generally. Version control keeps track of the new version of this file, rather than explaining each change made individually. Of course, it is good to be specific when explaining changes made to a file, but version control doesn't keep track of every keystroke like, for instance, the track changes setting on Microsoft Word does. 
      </p>

      <p> One of the main benefits of version control is that multiple people can modify the same file simultaneously. Rather than overwriting each other's work, version control tracks and merges all of the changes. This makes it very easy to review changes as they come, understand why they were made, and reference every change as they are committed to the version control hub, whether it be GitHub or something else.

    </p>
    <p>
       Git is a program that allows changes to be committed and tracked. The nice thing about git is that you do not have to commit changes until you are ready to, and you must tell git that you are adding and committing changes in a two step process. This ensures that you are confident about the changes you are committing, or in other words, submitting, to the original file. Rather than overwriting previous work, git and GitHub merge the changes to the master branch and require an explaination of the changes made in order to make the reasoning behind the changes clear to all parties, including the creator, down the line.

    </p>
    <p>
      The way that git does this is through branches. Branches are sets of changes that will eventually lead back to the original, or master, branch. They are called branches because while they connect to the original file, they to not affect change directly upon it, and the branches must be merged for the changes to be reflected on the original file. Branches can be reviewed and eventually merged through GitHub, which is a webstie that allows for remote storing and tracking of files and changes in repositories on the site. Git is the software used to add, commit, and push on a local device.
    </p>

     <p>
        GitHub is a good way to store files and track changes because it is a website, so files can be accessed remotely. This makes things like big open source projects possible, because people from all over the world are able to access the files and submit their own changes. On smaller scales, groups working remotely can access and contribute to the same files without having to share the files between one another directly. The files can be accessed simultaneously, and the changes can all be merged into the master branch. Therefore, using GitHub is ideal for working on projects among many people. However, there are benefits to working on solo projects using GitHub. The main benefit is version control; being able to review changes that were made and why, in case there are mistakes that need to be changed later. It is a great way of keeping a record of the evolution of a project from inception, and every step of changes along the way.
    </p>
    </article>
</body>
</html><commit_msg>Update file<commit_after><!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8">
  <title>Week 1 blog</title>
</head>
<body>
  <h1>Week 1 blog</h1>
 
  <article>
  <p>
      Here we are at the beginning of Dev Bootcamp week one, and I feel like I've learned a lot. The scope of the development world gets bigger and bigger every day. I never knew there was so much to learn, but I'm really enjoying the process so far. One of the key things I learned about this week is version control. This is a way that developers can communicate changes that they make to files between one another, because version control is an effective record keeping strategy. In essence, version control is a series of snapshots of changes made to a file, such as modifications made to a series of code. Rather than tracking every single change individually, version control keeps track of a series of changes made, either by one person, or group members collaborating on a project. 

      </p>
      <p>This is more helpful when looking at changes because you are not seeing the minutae of every single syntax correction or other minor change. Rather, you can see a set of changes that were made, why they were made, and how they change the source material. For instance, if I were to proofread this blog post after submitting it, I can commit a set of changes stating that I corrected spelling and syntax errors generally. Version control keeps track of the new version of this file, rather than explaining each change made individually. Of course, it is good to be specific when explaining changes made to a file, but version control doesn't keep track of every keystroke like, for instance, the track changes setting on Microsoft Word does. 
      </p>

      <p> One of the main benefits of version control is that multiple people can modify the same file simultaneously. Rather than overwriting each other's work, version control tracks and merges all of the changes. This makes it very easy to review changes as they come, understand why they were made, and reference every change as they are committed to the version control hub, whether it be GitHub or something else.

    </p>
    <p>
       Git is a program that allows changes to be committed and tracked. The nice thing about git is that you do not have to commit changes until you are ready to, and you must tell git that you are adding and committing changes in a two step process. This ensures that you are confident about the changes you are committing, or in other words, submitting, to the original file. Rather than overwriting previous work, git and GitHub merge the changes to the master branch and require an explaination of the changes made in order to make the reasoning behind the changes clear to all parties, including the creator, down the line.

    </p>
    <p>
      The way that git does this is through branches. Branches are sets of changes that will eventually lead back to the original, or master, branch. They are called branches because while they connect to the original file, they to not affect change directly upon it, and the branches must be merged for the changes to be reflected on the original file. Branches can be reviewed and eventually merged through GitHub, which is a webstie that allows for remote storing and tracking of files and changes in repositories on the site. Git is the software used to add, commit, and push on a local device.
    </p>

     <p>
        GitHub is a good way to store files and track changes because it is a website, so files can be accessed remotely. This makes things like big open source projects possible, because people from all over the world are able to access the files and submit their own changes. On smaller scales, groups working remotely can access and contribute to the same files without having to share the files between one another directly. The files can be accessed simultaneously, and the changes can all be merged into the master branch. Therefore, using GitHub is ideal for working on projects among many people. However, there are benefits to working on solo projects using GitHub. The main benefit is version control; being able to review changes that were made and why, in case there are mistakes that need to be changed later. It is a great way of keeping a record of the evolution of a project from inception, and every step of changes along the way.
    </p>
    </article>
</body>
</html>

<!--
What HTML5 tags have you used in this challenge and continue to return to often? Why?

The main tag we used was the article tag. I keep returning to this for blog posts, becasue it defines where the post should be. I also tend to use the <h1> tag a lot, because often I have at least one heading, and I use <h1> first as taught for good practices. I also find the <p> tag helpful for separating paragraphs.

How do elements get laid out on a page? What is the order the browser uses to display elements?

The elements get laid out on the page how I define them. It follows the head and the body in a linear order, just like it does in the code itself. The head contains the title and the body contains all of the content. It gets displayed however you tell it to, but it looks like without CSS or some other styling, the code pretty much always looks the same, regardless of whether or not it is <nav>, <article>, etc. This is untrue for the <footer>, but I've always had it close to the end of my body tag anyway, so I'm not sure if that makes much of a difference.

What did you learn about Sublime in this challenge? Do you think you'll create more handy snippets at a later date? What about research some shortcuts that already exist?

The snippet we created certainly was helpful, but I'm not sure if I'll be making more anytime soon. I'm sure once I'm coding more actively, and have similar projects, snippets will save a lot of time in terms of repeating the same code structures.
-->
{'fraction_non_alphanumeric': 0.035175879396984924, 'fraction_numerical': 0.001256281407035176, 'mean_word_length': 3.9493065518890482, 'pattern_counts': {'":': 0, '<': 62, '<?xml version=': 0, '>': 62, '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': '5412279', 'n_tokens_mistral': 2365, 'n_tokens_neox': 2279, 'n_words': 1772}