Skip to content

Update README.md #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
SiennaSSM wants to merge 1 commit into from
Closed

Update README.md #1

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
114 changes: 112 additions & 2 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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).
# 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.