From 116b5b811bffa298b850f90b349fe84a9510b4ee Mon Sep 17 00:00:00 2001 From: SiennaSSM Date: Wed, 16 Sep 2026 01:18:55 -0400 Subject: [PATCH 1/2] Update README.md Add .gitingore Modified README to include an article and created gitignore document copied from slideshow link --- .gitignore | 129 +++++++++++++++++++++++++++++++++++++++++++++++++++++ README.md | 114 +++++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 241 insertions(+), 2 deletions(-) create mode 100644 .gitignore diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..fe87284 --- /dev/null +++ b/.gitignore @@ -0,0 +1,129 @@ +# Compiled source # +################### +*.com +*.class +*.dll +*.exe +*.o +*.so + +# Packages # +############ +# it's better to unpack these files and commit the raw source +# git has its own built in compression methods +*.7z +*.dmg +*.gz +*.iso +*.jar +*.rar +*.tar +*.zip + +# Logs and databases # +###################### +*.log +*.sql +*.sqlite + +# OS generated files # +###################### +.DS_Store +.DS_Store? +._* +.Spotlight-V100 +.Trashes +ehthumbs.db +Thumbs.db + +# Typical Node.js artifacts # +############################# + +# NPM lock file - while this is often included in real projects, for practice projects it's best to ignore it to not artificially bloat the git log statistics of lines of code added, removed, etc. +package-lock.json + +# Logs +logs +*.log +npm-debug.log* +yarn-debug.log* +yarn-error.log* + +# Runtime data +pids +*.pid +*.seed +*.pid.lock + +# Directory for instrumented libs generated by jscoverage/JSCover +lib-cov + +# Coverage directory used by tools like istanbul +coverage + +# nyc test coverage +.nyc_output + +# Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files) +.grunt + +# Bower dependency directory (https://bower.io/) +bower_components + +# node-waf configuration +.lock-wscript + +# Compiled binary addons (https://nodejs.org/api/addons.html) +build/Release + +# Dependency directories +node_modules/ +**/node_modules/ +jspm_packages/ +**/jspm_packages + +# Results of React build script +build/ +**/build/ + +# React dependencies +.pnp +.pnp.js + +# dotconfig artifacts +.env.local +.env.development.local +.env.test.local +.env.production.local + +# TypeScript v1 declaration files +typings/ + +# Optional npm cache directory +.npm + +# Optional eslint cache +.eslintcache + +# Optional REPL history +.node_repl_history + +# Output of 'npm pack' +*.tgz + +# Yarn Integrity file +.yarn-integrity + +# dotenv environment variables file +.env + +# next.js build output +.next + + +## Emacs artefacts ## +*~ + +## Jekyll artifacts +**/.jekyll-cache +**/_site/ \ No newline at end of file diff --git a/README.md b/README.md index 1621800..33919e5 100644 --- a/README.md +++ b/README.md @@ -1,2 +1,112 @@ -# Git Practice -A simple project to practice a few git/github workflows. Replace the contents of this file with the contents indicated in the [instructions](./instructions.md). \ No newline at end of file +# Instructions + +In this assignment, you will familiarize yourself with two common **version control** workflows using **`git`** and **GitHub**: a **[centralized workflow](#centralized-workflow)**; and a **[forking workflow](#forking-workflow)** (also known as the **"open source workflow"**). + +With the centralized workflow, you will set up a **remote** repository on GitHub and a **local** **cloned** **repository** for your own project and practice **pushing** and **pulling** to/from this remote repository. + +With the forking workflow, you will contribute to another student's project by **forking** their repository, making changes to your copy, and issuing a **pull request** to them to incorporate your changes. + +Performing changes to projects using these two workflows will also allow you to review the archives of the repositories to ensure that your git and GitHub accounts are configured correctly. + +Execute the following instructions in order. + +## Before you get started + +### Disclosure + +Note that with version control systems such as `git`, it is easy to verify what work has or has not been done by whom on any project via the [log files](https://knowledge.kitchen/content/courses/software-engineering/slides/git-and-github/#logs). So activity using such systems cannot be faked (not that you would ever consider such a thing)! + +### Install Git and create GitHub account + +1. Download and install `git` on your local machine, if you haven't already done so. + +1. Create an account on [GitHub](https://github.com), if you don't already have one. + +## Centralized workflow + +In this part, we will try out a simple **centralized workflow**, where developers work with two copies of a repository: a **local** copy, where changes are made; and a **remote** copy, where completed changes are uploaded in order to be backed-up and shared with others. + +You will `commit` changes to your local copy and `push` them to your remote copy. + +### Create a remote repository on GitHub + +Create a new `Fork` of this repository on GitHub - this creates a clone of it in your own GitHub account. The fork copy in your own account (i.e. your own "`remote`" copy) is the copy that you will continue to work on. + +### Clone it to your local computer + +1. Clone your remote repository on GitHub to your own local machine (i.e. create a "`local`" clone of your "`remote`"). + +2. Create a `README.md` file in that directory using valid Markdown syntax. **Edit** this file such that it includes the following: + +#### https://dev.to/mukeshkuiry/12-free-and-fun-api-for-your-next-project-5eem +I think this is a cool article because it includes APIs that I wouldn't otherwise be likely to find. I think the cats are silly and cute, I'm unsure how I could use them in a project, maybe on a personal website. I also like the advice slip API, I think that could work very nicely with a loading screen. The Trivia API could also be good for a loading screen, or even as the base for a game on it's own. As I was going through the options of this article, I found it interesting how I never would have individually searched for any of these APIs. But being presented with them inspired little ideas on how to incorporate them into larger projects, it's a nice creative push. + +3. **Commit** your `README.md` file to the local repository, including a meaningful commit message. +4. Open a Terminal window, navigate to your project's main directory, and verify that your changes have been done correctly. Do this by running the command, `git log`. + - Ensure that every commit shows your correct git username in the `Author` field. We require that your git username be the same as your GitHub username on all commits. + - Ensure that each commit has only a single line message. We require single-line commit messages and do not accept multiple-line commit messages. + - If your commits do not meet these requirements, fix the mistakes. Make some small changes to your `README.md` file and try committing again. + - Do not move forward until you are sure your commits are showing up correctly in the logs according to our requirements. + +### Push changes to the remote repository + +1. **Push** the latest version of the files in your local repository to the GitHub repository you created. +1. Your two repositories (the local and the remote) should now be in-sync. +1. Verify this by visiting your remote repository in a web browser and confirming that the `README.md` file there shows all the same changes you made on your own local copy. + +### Share your repository with others + +1. Share the link to your GitHub repository using the course's messaging app and invite others to collaborate... they will do so via the **forking workflow** outlined below. + +## Forking workflow + +In this part, we will practice the **forking workflow**, also known as the **open source workflow**. Developers following this type of workflow interact with at least 3 different copies of a repository: the original **remote** repository that the developer wishes to make changes to; a remote **clone** of that official repositor, known as a "`fork`"; and a local clone of the fork. + +You will `commit` changes to your local copy of the repository, `push` those changes to your remote fork of the original, and then issue a **Pull Request** from your fork to the original remote repository where you wish your changes to ultimately be incorporated. + +### Configure GitHub correctly + +In order for Pull Requests on GitHub to be counted as yours, it is necessary that your GitHub username matches exactly your `git` username and that you do not have any other `Name` value in your GitHub Profile. + +- Go to your GitHub Profile page in your web browser and remove any `Name` value in your profile. Save any changes. + +### Find another repository to work with + +1. Wait for other students to also share their repository links from the centralized workflow part of this assignment. +2. Select one of the other students' GitHub repository links that you find interesting. + +### Fork that repository + +1. **Fork** that repository on GitHub - you now have a clone of that repository in your own GitHub account. We'll refer to this repository as "your forked repository". + +### Make a local clone of that fork + +1. **Clone** your forked repository from GitHub to a new directory on your local machine (not the same directory as your original repository). We'll refer to this repository as "your local copy". + +### Create a branch + +1. **Create a new branch** of your forked repository on your local copy where, you will make changes to it. Switch to (i.e `checkout`) that branch. +2. Edit the `README.md` file in your local copy to include a comment from you about that same article mentioned in the file. + - Make it look well-formatted and written following standard document writing styles, using Markdown syntax. + - Include your name in the edit you make, so we can clearly see who did it (we can also verify this with the Git logs). +3. Commit these changes to your local copy, including a meaningful single-line commit message. + +### Push changes to your remote fork + +1. **Pull** any changes others may have made to the remote repository on GitHub while you were working. +2. **Push** your changes to your forked repository on GitHub. +3. The branch you created with the changes you made will now be updated on your forked repository on GitHub. + +### Issue a pull request to the original repository + +1. [Make a pull request](https://help.github.com/articles/creating-a-pull-request/) on the other student's original repository from which you forked yours, asking them politely to include your changes in their original repository + +### Accept contributions to your repository + +1. Make sure at least one other student has made a pull request with some changes to your own original repository - use the course's messaging app to coordinate this. +2. If the pull request changes you dislike, leave a response indicating why you have not accepted them, asking the other contributor to fix the problems. +3. Once you are happy with the changes, accept them. +4. Pull the updated files to the local repository of your project. +5. Merge any and all branches to the `main`/`master` branch (whichever is the default in your repository). +6. Commit any changes, including a meaningful commit message. +7. Push the result to the remote repository on GitHub. \ No newline at end of file From a2297fa860198e5895fbb8620187262eaea6236c Mon Sep 17 00:00:00 2001 From: SiennaSSM Date: Wed, 16 Sep 2026 01:28:42 -0400 Subject: [PATCH 2/2] Update README Visual Cleaned up the README format fixing previous misinterpretation of directions --- README.md | 113 +++--------------------------------------------------- 1 file changed, 6 insertions(+), 107 deletions(-) diff --git a/README.md b/README.md index 33919e5..efaaa24 100644 --- a/README.md +++ b/README.md @@ -1,112 +1,11 @@ -# Instructions -In this assignment, you will familiarize yourself with two common **version control** workflows using **`git`** and **GitHub**: a **[centralized workflow](#centralized-workflow)**; and a **[forking workflow](#forking-workflow)** (also known as the **"open source workflow"**). +# Git Practice -With the centralized workflow, you will set up a **remote** repository on GitHub and a **local** **cloned** **repository** for your own project and practice **pushing** and **pulling** to/from this remote repository. +___ -With the forking workflow, you will contribute to another student's project by **forking** their repository, making changes to your copy, and issuing a **pull request** to them to incorporate your changes. +### Interesting Article -Performing changes to projects using these two workflows will also allow you to review the archives of the repositories to ensure that your git and GitHub accounts are configured correctly. +___ -Execute the following instructions in order. - -## Before you get started - -### Disclosure - -Note that with version control systems such as `git`, it is easy to verify what work has or has not been done by whom on any project via the [log files](https://knowledge.kitchen/content/courses/software-engineering/slides/git-and-github/#logs). So activity using such systems cannot be faked (not that you would ever consider such a thing)! - -### Install Git and create GitHub account - -1. Download and install `git` on your local machine, if you haven't already done so. - -1. Create an account on [GitHub](https://github.com), if you don't already have one. - -## Centralized workflow - -In this part, we will try out a simple **centralized workflow**, where developers work with two copies of a repository: a **local** copy, where changes are made; and a **remote** copy, where completed changes are uploaded in order to be backed-up and shared with others. - -You will `commit` changes to your local copy and `push` them to your remote copy. - -### Create a remote repository on GitHub - -Create a new `Fork` of this repository on GitHub - this creates a clone of it in your own GitHub account. The fork copy in your own account (i.e. your own "`remote`" copy) is the copy that you will continue to work on. - -### Clone it to your local computer - -1. Clone your remote repository on GitHub to your own local machine (i.e. create a "`local`" clone of your "`remote`"). - -2. Create a `README.md` file in that directory using valid Markdown syntax. **Edit** this file such that it includes the following: - -#### https://dev.to/mukeshkuiry/12-free-and-fun-api-for-your-next-project-5eem -I think this is a cool article because it includes APIs that I wouldn't otherwise be likely to find. I think the cats are silly and cute, I'm unsure how I could use them in a project, maybe on a personal website. I also like the advice slip API, I think that could work very nicely with a loading screen. The Trivia API could also be good for a loading screen, or even as the base for a game on it's own. As I was going through the options of this article, I found it interesting how I never would have individually searched for any of these APIs. But being presented with them inspired little ideas on how to incorporate them into larger projects, it's a nice creative push. - -3. **Commit** your `README.md` file to the local repository, including a meaningful commit message. -4. Open a Terminal window, navigate to your project's main directory, and verify that your changes have been done correctly. Do this by running the command, `git log`. - - Ensure that every commit shows your correct git username in the `Author` field. We require that your git username be the same as your GitHub username on all commits. - - Ensure that each commit has only a single line message. We require single-line commit messages and do not accept multiple-line commit messages. - - If your commits do not meet these requirements, fix the mistakes. Make some small changes to your `README.md` file and try committing again. - - Do not move forward until you are sure your commits are showing up correctly in the logs according to our requirements. - -### Push changes to the remote repository - -1. **Push** the latest version of the files in your local repository to the GitHub repository you created. -1. Your two repositories (the local and the remote) should now be in-sync. -1. Verify this by visiting your remote repository in a web browser and confirming that the `README.md` file there shows all the same changes you made on your own local copy. - -### Share your repository with others - -1. Share the link to your GitHub repository using the course's messaging app and invite others to collaborate... they will do so via the **forking workflow** outlined below. - -## Forking workflow - -In this part, we will practice the **forking workflow**, also known as the **open source workflow**. Developers following this type of workflow interact with at least 3 different copies of a repository: the original **remote** repository that the developer wishes to make changes to; a remote **clone** of that official repositor, known as a "`fork`"; and a local clone of the fork. - -You will `commit` changes to your local copy of the repository, `push` those changes to your remote fork of the original, and then issue a **Pull Request** from your fork to the original remote repository where you wish your changes to ultimately be incorporated. - -### Configure GitHub correctly - -In order for Pull Requests on GitHub to be counted as yours, it is necessary that your GitHub username matches exactly your `git` username and that you do not have any other `Name` value in your GitHub Profile. - -- Go to your GitHub Profile page in your web browser and remove any `Name` value in your profile. Save any changes. - -### Find another repository to work with - -1. Wait for other students to also share their repository links from the centralized workflow part of this assignment. -2. Select one of the other students' GitHub repository links that you find interesting. - -### Fork that repository - -1. **Fork** that repository on GitHub - you now have a clone of that repository in your own GitHub account. We'll refer to this repository as "your forked repository". - -### Make a local clone of that fork - -1. **Clone** your forked repository from GitHub to a new directory on your local machine (not the same directory as your original repository). We'll refer to this repository as "your local copy". - -### Create a branch - -1. **Create a new branch** of your forked repository on your local copy where, you will make changes to it. Switch to (i.e `checkout`) that branch. -2. Edit the `README.md` file in your local copy to include a comment from you about that same article mentioned in the file. - - Make it look well-formatted and written following standard document writing styles, using Markdown syntax. - - Include your name in the edit you make, so we can clearly see who did it (we can also verify this with the Git logs). -3. Commit these changes to your local copy, including a meaningful single-line commit message. - -### Push changes to your remote fork - -1. **Pull** any changes others may have made to the remote repository on GitHub while you were working. -2. **Push** your changes to your forked repository on GitHub. -3. The branch you created with the changes you made will now be updated on your forked repository on GitHub. - -### Issue a pull request to the original repository - -1. [Make a pull request](https://help.github.com/articles/creating-a-pull-request/) on the other student's original repository from which you forked yours, asking them politely to include your changes in their original repository - -### Accept contributions to your repository - -1. Make sure at least one other student has made a pull request with some changes to your own original repository - use the course's messaging app to coordinate this. -2. If the pull request changes you dislike, leave a response indicating why you have not accepted them, asking the other contributor to fix the problems. -3. Once you are happy with the changes, accept them. -4. Pull the updated files to the local repository of your project. -5. Merge any and all branches to the `main`/`master` branch (whichever is the default in your repository). -6. Commit any changes, including a meaningful commit message. -7. Push the result to the remote repository on GitHub. \ No newline at end of file +**https://dev.to/mukeshkuiry/12-free-and-fun-api-for-your-next-project-5eem** +I think this is a cool article because it includes APIs that I wouldn't otherwise be likely to find. I think the cats are silly and cute, I'm unsure how I could use them in a project, maybe on a personal website. I also like the advice slip API, I think that could work very nicely with a loading screen. The Trivia API could also be good for a loading screen, or even as the base for a game on it's own. As I was going through the options of this article, I found it interesting how I never would have individually searched for any of these APIs. But being presented with them inspired little ideas on how to incorporate them into larger projects, it's a nice creative push. \ No newline at end of file