Fork and Clone
Learning Competencies
By the end of this exploration, you should be able to:
- Fork a repository
- Clone a forked repository
Summary
You will use this deep-dive exploration to create your forked version of a repo. You will then clone a copy to your machine. This clone is where you will be working on reflections for the rest of your learning exploration and assessments throughout Foundations. By creating a forked version, your changes will not show on the main Dev Academy version.
"A fork is a copy of a repository. Forking a repository allows you to freely experiment with changes without affecting the original project. Most commonly, forks are used to either propose changes to someone else's project or to use someone else's project as a starting point for your own idea." Practice Forking GitHub Help
The words "copy" and a "clone" sound very similar, because in english they are somewhat interchangeable. In Git they mean very different things! Our local, cloned repositories ultimately want to be the same as the remote repository. Like when we make a branch on our local clone, it's destiny is to eventually reunite with the remote repository and finally merge back into the main branch. Local clones want to be the same as their remote counterparts.
Forks are very different, a fork is a "copy" of a repository that then goes off and does it's own thing. If you fork my repository and clone it down, from that point on it's destiny isn't to find it's way back inline with my repo anymore. It has it's own hopes and dreams, separate from whatever my original copy of the repository is doing.
Time Box
| Activity | Time |
|---|---|
| Explore | 45 minutes |
| Fork, Clone | 1-2 hours |
| Reflect | 15 minutes |
Follow the timebox suggestions. If you get stuck, take a quick break and return to it. Reach out to the community on Discord. Let the learning competencies be your guide.
Forking Workflow
Excerpt from AtlassianThe Forking Workflow is fundamentally different from other popular Git workflows. Instead of using a single server-side repository to act as the “central” codebase, it gives every developer their own server-side repository. Each contributor has two Git repositories: a private local one and a public server-side one. The Forking Workflow is most often seen in public open-source projects.
The main advantage of the Forking Workflow is that contributions can be integrated without the need for everybody to push to a single central repository. Developers push to their own server-side repositories, and only the project maintainer can push to the official repository. This allows the maintainer to accept commits from any developer without giving them write access to the official codebase.
The Forking Workflow typically follows a branching model based on the Gitflow Workflow. This means that complete feature branches will be purposed to merge into the original project maintainer's repository. The result is a distributed workflow that allows large, organic teams (including untrusted third parties) to collaborate securely and flexibly. This also makes it an ideal workflow for open source projects.
Explore Forking
Use the timebox suggestions and explore Forking.
Suggested Resources:
Step 1: Fork
Navigate to the reflections repo in the foundations org.
Please create your own version of the repo by forking it to your account. Below is an example of this process using the foundation's repo.
Origin: https://github.com/dev-academy-foundations/reflections
Destination: https://github.com/YOUR-GITHUB-USERNAME/reflections
Figure 1: Fork Repo from origin
Figure 2: View of Forked repo in destination
Step 2: Cloning
Your repository exists on GitHub, but to add or edit files using your text editor, you need it to exist on your computer (i.e. you need to clone it locally).
Figure 3: Clone button
- Click the clone button (copies link) (figure 3)
- You're about to paste the link you just copied. It will create a directory called 'reflections' when you do so. Think about where you want that directory to live. Is it, for example, in
desktop/dev-academy/reflectionsor does it make more sense to have it on your root directory, e.g.users/hinemoana/reflections? There is no correct answer, just a location that makes the most sense to you (that isn't itself a git repo. If you clone it into a folder that is already a git repository, it will never work). - In your terminal, navigate INTO the directory you created/would like to use to hold the cloned repo.
- Enter the command
git cloneand use the keyboard shortcutcmd v(mac) orctrl v(win) to paste - Follow the username and password prompts if required.
Figure 4: Terminal commands for cloning
Step 3: Open in Visual Studio Code
Open VS Code and then open the reflections directory you just cloned. You can do this using the code . command after navigating into the reflections repo using cd.
Figure 5: Local cloned repo viewed in text editor
Step 4: Add your (previous) Reflections
The repo you cloned has a folder for each of the sprints you will do, a my-reflections markdown (.md) file in each folder, and an end-of-sprint file that contains the checklist and final reflections you will do once the sprint is completed.
You'll add your reflections to these files on your local version of repo and push them back up to your forked version on GitHub. Because you're the only one working on this repo, and you're not writing code, you can feel free to just do all of this on your main branch. Remember, the two main purposes of branches are to make collaborating with other people easier, and avoid introducing bugs to your "good" code. You don't have to worry about either of those things in this reflection repository, so committing directly onto the main branch is totally fine.
Have a look around the files in the sprint one folder. Please add your own files if you would like to hold any other reflections or noticings in this repo.
Pro-tip: Use the command line to navigate, open applications and open files.
Open the reflections repo in VS Code. (
code .)Copy and paste your previous reflections into the file. Use markdown to make the question format 'bold' or into headers.
Reflect
Open my-reflections-sprint-1.md in VS Code and add your reflections from this challenge. The questions are under the GitHub Fork & Clone heading in that file.
Stage, commit and push your changes to Github. You can try doing this all in one command to save time! By putting semicolons between commands in the terminal, we can "chain" actions together like this:
git add -A ; git commit -m "do reflection" ; git push.