From c7018164d46eb543c9b0afe4d6f9fd1e9d0d7f7c Mon Sep 17 00:00:00 2001 From: Spencer Davies Date: Thu, 18 Aug 2016 09:49:23 -0600 Subject: [PATCH 01/11] Update git push instructions Most of the students' first pushes were failing because there wasn't a master branch on their remote. --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index c2e38265..0928c08a 100644 --- a/README.md +++ b/README.md @@ -34,7 +34,7 @@ This usually looks like this: 2. `git diff` this will show the actual code that has been changed. Again, we want to make sure we don't push anything to GitHub that shouldn't be there. 3. If everything looks good, `git add nameOfMyFile.js` This adds our file(s) to the 'staging area' 4. `git commit -m "The sentence I want associated with this commit message"` which tells your computer 'hey, next time code is pushed to GitHub, take all of this code with it.' -5. `git push origin master` My code is now on GitHub. +5. `git push -u origin master` My code is now on GitHub. The `-u` tells GitHub to create a master branch if one doesn't already exist. You can leave it out if the branch you're pushing to already exists. * If you did this correctly, check your GitHub repository for your new code. From 9aa3ebf0eadd574930a24a9918cd89794d6d14f8 Mon Sep 17 00:00:00 2001 From: Spencer Davies Date: Thu, 18 Aug 2016 10:56:00 -0600 Subject: [PATCH 02/11] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 0928c08a..15433fec 100644 --- a/README.md +++ b/README.md @@ -34,7 +34,7 @@ This usually looks like this: 2. `git diff` this will show the actual code that has been changed. Again, we want to make sure we don't push anything to GitHub that shouldn't be there. 3. If everything looks good, `git add nameOfMyFile.js` This adds our file(s) to the 'staging area' 4. `git commit -m "The sentence I want associated with this commit message"` which tells your computer 'hey, next time code is pushed to GitHub, take all of this code with it.' -5. `git push -u origin master` My code is now on GitHub. The `-u` tells GitHub to create a master branch if one doesn't already exist. You can leave it out if the branch you're pushing to already exists. +5. `git push origin master` My code is now on GitHub. Be sure to include `origin master`, as this tells GitHub which branch you want to push to, and creates the branch if it doesn't exist yet. * If you did this correctly, check your GitHub repository for your new code. From 8b9dd82a2b1a1ec1182b7d5140245f0c6d50a995 Mon Sep 17 00:00:00 2001 From: Candice Humpherys Date: Fri, 26 Aug 2016 09:56:53 -0600 Subject: [PATCH 03/11] grammar, and clarify instructions --- README.md | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index 15433fec..0a747fb5 100644 --- a/README.md +++ b/README.md @@ -17,13 +17,13 @@ Finally, in the last mini-project you'll be mimicking the steps you'll take duri ##Mini-Project 1: Personal Project ### Step 1: Create a Repository on Github -Let's jump ahead a month or two and pretend like we just reached personal projects. You're going to be pushing your code up to GitHub frequently. In order to do that, you first need to create a repository on GitHub to push to. Head over to your GitHub account, then in the top right-hand corner click the '+' button and click 'New repository'. Enter the name of your repository then click 'Create Repository'. This repository is where your code for this project will now live. +Let's jump ahead a month or two and pretend like we just reached personal projects. You're going to be pushing your code up to GitHub frequently. In order to do that, you first need to create a repository on GitHub to push to. Head over to your GitHub account, then in the top right-hand corner click the '+' button and click 'New repository'. Enter the name of your repository then click 'Create Repository'. Do NOT initialize the repository with a README. This repository is where your code for this project will now live. ### Step 2: Set up the Origin Once you create your repository, you'll need to connect that repository with your code on your computer. * Create a folder called 'myProject' then inside that folder create a file called 'myName.js'. Add your name to that file and then save it. * Now in your terminal, navigate to your 'myProject' folder. Once inside that folder, type `git init`. You've just told your computer that you want git to watch the 'myProject' folder and keep track of any changes; basically making it so you can now run git commands inside of this folder. (Warning: Be very careful to make sure you're in the right directory when you run `git init`!) -* Now that you've initialized your 'myProject' folder, we need to tell your computer where the location of your GitHub repository is. To do this you'll create what is called a remote. Basically, we tell our computer "Hey, I created this repo on GitHub, so when I push, I want my code to go to this GitHub repo." To do this, in your terminal type `git remote add origin [Repository URL]` replacing [Repository URL] with your repo's url. To get the url, open the repository you made in step 1 in the browser. Then copy the url out of the address bar. Now whenever you run `git push origin master` your computer knows that origin is pointing to your repo you made on GitHub and it pushes your changes there. +* Now that you've initialized your 'myProject' folder, we need to tell your computer where the location of your GitHub repository is. To do this you'll create what is called a remote. Basically, we tell our computer "Hey, I created this repo on GitHub, so when I push, I want my code to go to this GitHub repo." To do this, in your terminal type `git remote add origin [Repository URL]` replacing [Repository URL] with your repo's url. To get the url, open the repository you made in step 1 in the browser. Then copy the url out of the address bar. Now whenever you run `git push origin master` your computer knows that origin is pointing to your repo you made on GitHub and it pushes your changes there. (If you accidentally DID initialize your repository with a README, you must do a `git pull origin master` first - to get the README file on your computer - before you'll be able to push.) ### Step 3: Push your code to GitHub Now that our remote is set up, you'll need to add your files to the staging area, commit your files to be ready for pushing, then push your files. @@ -42,16 +42,23 @@ This usually looks like this: * Now what we're going to do is walk through how you would normally treat a day's project here at DevMountain. ### Step 1: Fork the Repo -First, you'll want to 'fork' the repo. On the top right of this page, you should see a button that says 'fork.' This will essentially copy all of the code from this repository, but make it as a new repository under your account. As you can imagine, you can't push directly to the DevMountain repo, because that would not secure for DevMountain (anyone could make any changes they want). What you should do is create a fork of this repo, then push to your own fork because it's under your own account. +First, you'll want to 'fork' the repo. On the top right of this page, you should see a button that says 'fork.' This will essentially copy all of the code from this repository, but make it as a new repository under your account. As you can imagine, you can't push directly to the DevMountain repo, because that would not be secure for DevMountain (anyone could make any changes they want). What you should do is create a fork of this repo, then push to your own fork because it's under your own account. ### Step 2: Clone the Fork -* Once you've forked this repo, you're going to want to clone your forked repository. Go to your freshly forked page and copy the url that's on the side under where it says "HTTPS clone URL". Then, head over to your terminal and type `git clone [Repository URL]`, replacing Repositry URL with the URL you just grabbed from GitHub. This takes what's on GitHub and essentially downloads it so you can now make changes to it on your local computer. +* Once you've forked this repo, you're going to want to clone your forked repository. Go to your freshly forked page and copy the url (click on the green "clone or download" button on the right). Then, head over to your terminal and type `git clone [Repository URL]`, replacing Repositry URL with the URL you just grabbed from GitHub. This takes what's on GitHub and essentially downloads it so you can now make changes to it on your local computer. * Once you've cloned your fork, open up your fork in Sublime Text and make a change. Once you've made a change head over to your terminal and type `git status`, you should see that a file has been changed. If you see the file, run through the steps outlined above in Mini-Project 1 (status, diff, add, commit, push). Note that when you run `git push origin master` in this repository, origin is already pointing to your forked repo since you used `git clone`. Unlike the last step, you don't need to tell your computer where to push your code because git already knows. ##Mini-Project 3: Group Project * We're essentially going to redo all the same steps we did in Mini-Project 2, but add one more step. ### Step 1: Re-clone Your Fork + +Note: to re-clone your fork, you must do one of three things: +1. Delete the folder on your computer, or +2. Rename the folder on your computer, or +3. Rename the second clone by doing ```git clone [repo url] [new folder name]``` +If you do not do one of these three things, when you try to do a git clone, it will give you an error saying it already exists. + * Re-clone your fork of this project to your local computer, make a change, add, commit, then push that change. * Go to your forked repo on GitHub and verify your change is there. @@ -59,7 +66,7 @@ First, you'll want to 'fork' the repo. On the top right of this page, you should Let's imagine we're working in groups. If we have everyone pushing to one repo without verifying the quality of the code, things can get messy pretty quick. GitHub fixed this solution with 'Pull Requests.' Basically, you fork a project, make changes to your fork, then you make a Pull Request (PR) back into the original project requesting that some piece of code be added to the original repo. This is how the vast majority of open source code projects work. ### Step 2: Make the PR -* Go to your forked repo and click where it says 'Pull Request.' It should show you the file changes you've made and how they differ from the original repo. If it does, click on the submit button to submit your pull request. +* Go to your forked repo on github and click where it says 'Pull Request.' It should show you the file changes you've made and how they differ from the original repo. If it does, click on the submit button to submit your pull request. * Now, I should see your pull request and I can decide if I want to add that code into the main project or not. ## Contributions From db82d13bf36b0513e3cd359ca5b04a45ad2446f7 Mon Sep 17 00:00:00 2001 From: Candice Humpherys Date: Fri, 26 Aug 2016 10:00:47 -0600 Subject: [PATCH 04/11] last minor edit to PR section --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 0a747fb5..e3d9a7d2 100644 --- a/README.md +++ b/README.md @@ -66,7 +66,7 @@ If you do not do one of these three things, when you try to do a git clone, it w Let's imagine we're working in groups. If we have everyone pushing to one repo without verifying the quality of the code, things can get messy pretty quick. GitHub fixed this solution with 'Pull Requests.' Basically, you fork a project, make changes to your fork, then you make a Pull Request (PR) back into the original project requesting that some piece of code be added to the original repo. This is how the vast majority of open source code projects work. ### Step 2: Make the PR -* Go to your forked repo on github and click where it says 'Pull Request.' It should show you the file changes you've made and how they differ from the original repo. If it does, click on the submit button to submit your pull request. +* Go to your forked repo on github and click where it says 'Pull Request', and click 'New pull request'. It should show you the file changes you've made and how they differ from the original repo. If it does, click on the 'create pull request' button to submit your pull request. * Now, I should see your pull request and I can decide if I want to add that code into the main project or not. ## Contributions From 13b291f8ff6d176b8cc2afb46c6f657e38156d23 Mon Sep 17 00:00:00 2001 From: Ryan Walsh Date: Tue, 21 Mar 2017 14:14:48 -0600 Subject: [PATCH 05/11] fix formatting --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index e3d9a7d2..d8b68864 100644 --- a/README.md +++ b/README.md @@ -3,7 +3,7 @@ learn-git ========= -##Objective +## Objective Practice using git + Github This project will consist of three separate mini-projects to get you comfortable with the kinds of activities you'll be using git for throughout the class. @@ -14,7 +14,7 @@ In the second mini-project, you'll be mimicking the steps you'll take with nearl Finally, in the last mini-project you'll be mimicking the steps you'll take during the group project portion. You'll fork your group's repo, link your computer with your fork, push changes to your GitHub, then make a 'Pull Request' into your group's repo. -##Mini-Project 1: Personal Project +## Mini-Project 1: Personal Project ### Step 1: Create a Repository on Github Let's jump ahead a month or two and pretend like we just reached personal projects. You're going to be pushing your code up to GitHub frequently. In order to do that, you first need to create a repository on GitHub to push to. Head over to your GitHub account, then in the top right-hand corner click the '+' button and click 'New repository'. Enter the name of your repository then click 'Create Repository'. Do NOT initialize the repository with a README. This repository is where your code for this project will now live. From 0b064b786b803355755fc1cfabe7f892e85ef6e2 Mon Sep 17 00:00:00 2001 From: James Lemire Date: Thu, 8 Jun 2017 12:48:17 -0600 Subject: [PATCH 06/11] JL master - Update readme. --- README.md | 230 ++++++++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 189 insertions(+), 41 deletions(-) diff --git a/README.md b/README.md index d8b68864..158170b5 100644 --- a/README.md +++ b/README.md @@ -1,9 +1,7 @@ -learn-git -========= +# Project Summary -## Objective Practice using git + Github This project will consist of three separate mini-projects to get you comfortable with the kinds of activities you'll be using git for throughout the class. @@ -16,64 +14,214 @@ Finally, in the last mini-project you'll be mimicking the steps you'll take duri ## Mini-Project 1: Personal Project -### Step 1: Create a Repository on Github -Let's jump ahead a month or two and pretend like we just reached personal projects. You're going to be pushing your code up to GitHub frequently. In order to do that, you first need to create a repository on GitHub to push to. Head over to your GitHub account, then in the top right-hand corner click the '+' button and click 'New repository'. Enter the name of your repository then click 'Create Repository'. Do NOT initialize the repository with a README. This repository is where your code for this project will now live. +## Step 1 -### Step 2: Set up the Origin -Once you create your repository, you'll need to connect that repository with your code on your computer. -* Create a folder called 'myProject' then inside that folder create a file called 'myName.js'. Add your name to that file and then save it. -* Now in your terminal, navigate to your 'myProject' folder. Once inside that folder, type `git init`. You've just told your computer that you want git to watch the 'myProject' folder and keep track of any changes; basically making it so you can now run git commands inside of this folder. (Warning: Be very careful to make sure you're in the right directory when you run `git init`!) -* Now that you've initialized your 'myProject' folder, we need to tell your computer where the location of your GitHub repository is. To do this you'll create what is called a remote. Basically, we tell our computer "Hey, I created this repo on GitHub, so when I push, I want my code to go to this GitHub repo." To do this, in your terminal type `git remote add origin [Repository URL]` replacing [Repository URL] with your repo's url. To get the url, open the repository you made in step 1 in the browser. Then copy the url out of the address bar. Now whenever you run `git push origin master` your computer knows that origin is pointing to your repo you made on GitHub and it pushes your changes there. (If you accidentally DID initialize your repository with a README, you must do a `git pull origin master` first - to get the README file on your computer - before you'll be able to push.) +### Summary -### Step 3: Push your code to GitHub -Now that our remote is set up, you'll need to add your files to the staging area, commit your files to be ready for pushing, then push your files. +In this step we will create a repository on GitHUB. -This usually looks like this: +### Instructions -1. `git status` --> this will show what files have been changed. We want to make sure not to add any files to GitHub that we don't want there. -2. `git diff` this will show the actual code that has been changed. Again, we want to make sure we don't push anything to GitHub that shouldn't be there. -3. If everything looks good, `git add nameOfMyFile.js` This adds our file(s) to the 'staging area' -4. `git commit -m "The sentence I want associated with this commit message"` which tells your computer 'hey, next time code is pushed to GitHub, take all of this code with it.' -5. `git push origin master` My code is now on GitHub. Be sure to include `origin master`, as this tells GitHub which branch you want to push to, and creates the branch if it doesn't exist yet. +* Go to GitHub. +* Sign in to GitHub. +* On the right side of the page, click on the green `New repository` button. +* Give your repository any name you like and make sure that the repository is public. +* Also make sure that the `Initialize this repository with a README` is NOT checked. -* If you did this correctly, check your GitHub repository for your new code. +## Step 2 -##Mini-Project 2: DevMountain Project -* Now what we're going to do is walk through how you would normally treat a day's project here at DevMountain. +### Summary -### Step 1: Fork the Repo -First, you'll want to 'fork' the repo. On the top right of this page, you should see a button that says 'fork.' This will essentially copy all of the code from this repository, but make it as a new repository under your account. As you can imagine, you can't push directly to the DevMountain repo, because that would not be secure for DevMountain (anyone could make any changes they want). What you should do is create a fork of this repo, then push to your own fork because it's under your own account. +In this step we will setup the origin for the repository. We'll do this by connecting code on our computer to the GitHub repository we just created. -### Step 2: Clone the Fork -* Once you've forked this repo, you're going to want to clone your forked repository. Go to your freshly forked page and copy the url (click on the green "clone or download" button on the right). Then, head over to your terminal and type `git clone [Repository URL]`, replacing Repositry URL with the URL you just grabbed from GitHub. This takes what's on GitHub and essentially downloads it so you can now make changes to it on your local computer. -* Once you've cloned your fork, open up your fork in Sublime Text and make a change. Once you've made a change head over to your terminal and type `git status`, you should see that a file has been changed. If you see the file, run through the steps outlined above in Mini-Project 1 (status, diff, add, commit, push). Note that when you run `git push origin master` in this repository, origin is already pointing to your forked repo since you used `git clone`. Unlike the last step, you don't need to tell your computer where to push your code because git already knows. +### Instructions -##Mini-Project 3: Group Project -* We're essentially going to redo all the same steps we did in Mini-Project 2, but add one more step. +* Create a folder called `myProject`. +* Go into that folder. +* Create a file called `myName.js` and add your name to that file. +* Save the file and open a terminal window. +* In your terminal window, `cd` to your `myProject` folder. O +* Run `git init`. + *
-### Step 1: Re-clone Your Fork + What just happened? -Note: to re-clone your fork, you must do one of three things: -1. Delete the folder on your computer, or -2. Rename the folder on your computer, or -3. Rename the second clone by doing ```git clone [repo url] [new folder name]``` -If you do not do one of these three things, when you try to do a git clone, it will give you an error saying it already exists. +
-* Re-clone your fork of this project to your local computer, make a change, add, commit, then push that change. + You've just told your computer that you want git to watch the `myProject` folder and to keep track of any changes. This also allows us to run git commands inside of the folder. (Warning: Be very careful to make sure you're in the right directory when you run `git init`!) -* Go to your forked repo on GitHub and verify your change is there. +
+* Run `git remote add origin [Repository URL goes here]`. You can get your URL from going to repository you made earlier in your browser and copying the address. + *
-Let's imagine we're working in groups. If we have everyone pushing to one repo without verifying the quality of the code, things can get messy pretty quick. GitHub fixed this solution with 'Pull Requests.' Basically, you fork a project, make changes to your fork, then you make a Pull Request (PR) back into the original project requesting that some piece of code be added to the original repo. This is how the vast majority of open source code projects work. + What just happened? -### Step 2: Make the PR -* Go to your forked repo on github and click where it says 'Pull Request', and click 'New pull request'. It should show you the file changes you've made and how they differ from the original repo. If it does, click on the 'create pull request' button to submit your pull request. -* Now, I should see your pull request and I can decide if I want to add that code into the main project or not. +
+ + Basically, we tell our computer "Hey, I created this repo on GitHub, so when I push, I want my code to go to this GitHub repo." Now whenever you run `git push origin master` your computer knows that origin is pointing to your repo you made on GitHub and it pushes your changes there. + +
+ + ( If you accidentally DID initialize your repository with a README, you must do a `git pull origin master` first - to get the README file on your computer - before you'll be able to push. ) + +
+ +## Step 3: Push your code to GitHub + +### Summary + +In this step, we will push code to GitHub. + +### Instructions + +* Open a terminal window and make sure it is in the directory of `myProject`. +* Run `git status`. + *
+ + What does this do? + +
+ + This will show what files have been changed. This also helps us determine what files we want to add to GitHub and what files we don't want to add to GitHub. + +
+* Run `git diff`. + *
+ + What does this do? + +
+ + This will show the actual code that has been changed. Again, we want to make sure we don't push anything to GitHub that shouldn't be there. + +
+* Run `git add nameOfMyFile.fileExtension`. + *
+ + What does this do? + +
+ + This adds our file(s) to the 'staging area'. This is basically a fail safe if you accidentially add something you don't want. You can view items that our staged by running `git status`. + +
+* Run `git commit -m "The sentence I want associated with this commit message"`. + *
+ + What does this do? + +
+ + This tells your computer: 'Hey, the next time code is pushed to GitHub, take all of this code with it.' The message also specifies what GitHub will display in relation to this commit. + +
+* Run `git push origin master` + *
+ + What does this do? + +
+ + Your code is now pushed to GitHub. Be sure to include `origin master`, as this tells GitHub which branch you want to push to, and creates the branch if it doesn't exist yet. + +
+* Go to your repository on GitHub and see your updates. + +## Mini-Project 2: DevMountain Project + +## Step 1 + +### Summary + +In this step, we will fork this tutorial repository. + +### Instructions + +* On this current GitHub repository, scroll to the top and look for a button that says `fork`. +* Click the `fork` button. + *
+ + What does this do? + +
+ + This will essentially copy all of the code from this repository, but make it as a new repository under your account. As you can imagine, you can't push directly to the DevMountain repo, because that would not be secure for DevMountain (anyone could make any changes they want). What you should do is create a fork of this repo, then push to your own fork because it's under your own account. + +
+ +## Step 2 + +### Summary + +In this step, we will take the forked repository and clone it down to our machine. + +### Instructions + +* Go to your forked repository on GitHub. It should appear under `Your repositories` which is next to the `New repository` button. +* Click on the green `clone or download` button and copy the URL. +* Open a terminal window and navigate to your Desktop. +* Run `git clone [the url you copied]`. + *
+ + What does this do? + +
+ + This takes what's on GitHub and essentially downloads it so you can now make changes to it on your local computer. + +
+ +## Step 3 + +### Summary + +In this step, we will make changes to our clone and push them to GitHub. + +### Instructions + +* Open the folder in your coding IDE. +* Make a change in a file. +* Run through the steps outlined in `Step 3` of the first project ( status, diff, add, commit, push ). + * Since you've cloned this repository, it is already pointing to your forked version. Therefore, you don't need to tell your computer where to push the code. + +## Mini-Project 3: Group Project + +## Step 1 + +### Summary + +To help this process stick in memory we are going to repeat the process of the second project. We'll delete our current fork on our machine and restart the process. + +### Instructions + +* Delete the folder on your Desktop that is the forked repository. +* Re-clone the fork to your desktop. +* Make a change to any file. +* Run through the process of pushing to GitHub ( status, diff, add, commit, push ). + +## Step 2 + +### Summary + +Here is where things start to get different. Let's imagine we're working in groups. If we have everyone pushing to one repo without verifying the quality of the code, things can get messy pretty quick. GitHub fixed this solution with 'Pull Requests.' Basically, you fork a project, make changes to your fork, then you make a Pull Request (PR) back into the original project requesting that some piece of code be added to the original repo. This is how the vast majority of open source code projects work. In this step, we will make a pull-request. + +### Instructions + +* Go to your forked repo on GitHub. +* Locate the button that says `Pull Request` and click it. +* Locate the green button that says `New pull request` and click it. + * You should now see the file changes you've made and how they differ from the original repo. +* Click on the `Create pull request` button to submit your PR. +* Now if you navigate to the original repository and take a look at the `Pull Requests` yours should be there. ## Contributions + If you see a problem or a typo, please fork, make the necessary changes, and create a pull request so we can review your changes and merge them into the master repo and branch. ## Copyright -© DevMountain LLC, 2015. Unauthorized use and/or duplication of this material without express and written permission from DevMountain, LLC is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to DevMountain with appropriate and specific direction to the original content. +© DevMountain LLC, 2017. Unauthorized use and/or duplication of this material without express and written permission from DevMountain, LLC is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to DevMountain with appropriate and specific direction to the original content. +

+

From 044870da897aae1adf5aec2b989f3388c2ebd279 Mon Sep 17 00:00:00 2001 From: Bryan Smith Date: Mon, 26 Mar 2018 19:40:24 -0600 Subject: [PATCH 07/11] updated txt file --- fun.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/fun.txt b/fun.txt index c777ac4d..f536cfd1 100644 --- a/fun.txt +++ b/fun.txt @@ -1 +1,2 @@ “Hello world!” - said everyone, always +"Bye, Felicia" - Ice Cube \ No newline at end of file From d66cb8cc80519e6c4a76123eff53add42a850c24 Mon Sep 17 00:00:00 2001 From: = Date: Mon, 2 Jul 2018 13:38:23 -0600 Subject: [PATCH 08/11] JL master - Fix company logo link. --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 158170b5..9fbd8ce8 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,4 @@ - + # Project Summary @@ -223,5 +223,5 @@ If you see a problem or a typo, please fork, make the necessary changes, and cre © DevMountain LLC, 2017. Unauthorized use and/or duplication of this material without express and written permission from DevMountain, LLC is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to DevMountain with appropriate and specific direction to the original content.

- +

From ede05e1ce9d5bdc92c3f130eaf8a0ac261c7252d Mon Sep 17 00:00:00 2001 From: DevMountain Date: Sun, 28 Apr 2019 22:11:15 -0500 Subject: [PATCH 09/11] test --- fun.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fun.txt b/fun.txt index f536cfd1..1528dfff 100644 --- a/fun.txt +++ b/fun.txt @@ -1,2 +1,3 @@ “Hello world!” - said everyone, always -"Bye, Felicia" - Ice Cube \ No newline at end of file +"Bye, Felicia" - Ice Cube +asdfasdfs \ No newline at end of file From e03215048f4146829564ff0b1d5407e649b61150 Mon Sep 17 00:00:00 2001 From: rogersmykenzie <44181353+rogersmykenzie@users.noreply.github.com> Date: Sun, 28 Apr 2019 22:11:37 -0500 Subject: [PATCH 10/11] Update fun.txt --- fun.txt | 1 - 1 file changed, 1 deletion(-) diff --git a/fun.txt b/fun.txt index 1528dfff..345e35dd 100644 --- a/fun.txt +++ b/fun.txt @@ -1,3 +1,2 @@ “Hello world!” - said everyone, always "Bye, Felicia" - Ice Cube -asdfasdfs \ No newline at end of file From c6048c28ba9c9d2a260f774e95b99e8e0a1883ed Mon Sep 17 00:00:00 2001 From: Josh McCann <42157060+jrmccann2@users.noreply.github.com> Date: Mon, 30 Sep 2019 11:54:50 -0600 Subject: [PATCH 11/11] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 9fbd8ce8..50e5c138 100644 --- a/README.md +++ b/README.md @@ -8,7 +8,7 @@ This project will consist of three separate mini-projects to get you comfortable In the first mini-project, you'll be mimicking the steps you'll take when you first start your personal project. Creating a repository, linking it to your computer, then pushing those changes up to your GitHub. -In the second mini-project, you'll be mimicking the steps you'll take with nearly every DevMountain project you do. You'll 'fork' the DevMountain repository, link your computer with your fork, then pushing those changes up to your GitHub. +In the second mini-project, you'll be mimicking the steps you'll take with nearly every DevMountain project you do. You'll 'fork' the DevMountain repository, link your computer with your fork, then push those changes up to your GitHub. Finally, in the last mini-project you'll be mimicking the steps you'll take during the group project portion. You'll fork your group's repo, link your computer with your fork, push changes to your GitHub, then make a 'Pull Request' into your group's repo.