test icon ```mermaid flowchart TD A[Christmas] -->|Get money| B(Go shopping) B --> C{Let me think} C -->|One| D[Laptop] C -->|Two| E[iPhone] C -->|Three| F[fa:fa-car Car] ``` # Git Guide ## So what is Git? At it's core git is a versioning system to store your code also known as a version control system (VCS). It was developed in 2005 by the creator of the Linux Kernel, Linux Torvalds. The system also allows developers to work on code simultaniously as each developer *checks out* a local copy of the *repository* to make their changes on. These changes can then ve *commited* back to the central repository and other developers can *pull* these updates into their local copy. These are all terms you'll get familure with as we go through this guide. Developers can *branch*, *fork* and *merge* repositories allowing flexible workflows to happen, we'll cover these concepts in the documents and video's that follow. ### Structure of a repo (Stages) To understand all these terms lets first look at a git repository and its stages, this is how code gets from the developers working directory to being synchronised with the remote repository. We can think of this in four main areas, your working directory, a staging area, the local repository and the remote repository. Now depending on if the remote repository already exists depends on if you run a ```git init``` or a ```git clone``` command, and these commands kind of do what they sound like. Init sets up the necessary files to start tracking the changes in a **new** repository on the local file system, where as clone pulls all the current content from the remote repository and copies it to your local repository and sets up your working directory also. If you want to get changes from the remote repository that someone else has uploaded you can run *pull* to bring those changes into your working directory. The staging area comes into play as an intemediate space that sit's between working directory and local repository. A developer *adds* changes to the stage area, if theyare happy with the change they *commit* the changes to the local repository and then when they are happy can *push* those changes to the remote repository. Lets try and visualise this in the diagram below. ```mermaid flowchart TD A[Working Directory] -->|git add| B(Staging Area) B --> |git reset| A B --> |git commit| C(Local Repository) C -->|git push| D[Remote Repository] D --> |git fetch| C D --> |git pull| A ``` ## Commits ### Push ### Tags and Releases ## Branches ### HEAD ## Forks ## Merging ## Getting Setup ## Advanced Setup (Highly Recommended)