Version Control.md

# Version Control

In this lab you will learn the principles of how to organise your code using the Git version control system. By completing this you will have set up and organised the codebase you will be using in your assignment. By completing this lab you will be ready to start developing your assignment.

## Updating Your Profile Picture

Your first step after logging into GitHub is to change your profile avatar to a head and shoulders photo of yourself, just like the one on your ID card. This will help the rest of your team identify you and the staff when marking yoru work. It will also help you see of the config settings are correct so make sure you don't skip this step!

Click on the image in the top-right corner of the web page and choose **Your Profile**.

![GitHub Profile](exercises/.images/github_profile.png)

Now click on the placeholder image and browse for your photo.

## Duplicating a Repository

Carry out the following steps, taken from the [GitHub documentation](https://help.github.com/en/enterprise/2.16/user/articles/duplicating-a-repository). If you are working on a team project, only one person needs to complete this step although the entire team should support this process so they know the required steps.

Temporarily clone this repository to your development computer. This will create a directory on your computer called `temp` which contains the repository files:

`git clone https://github.coventry.ac.uk/web/template-dynamic-websites.git temp`

Create a new **private** repository in the module organisation on the GitHub server and copy the _clone url_ to the clipboard (the one that begins with `https://` and ends in `.git`. The repository name should be your username (the one you use to log into the University computers).

Mirror Push to this new repository, replacing xxx with the url from the clipboard making sure you are _in_ the `temp/` directory:

`cd temp/ && git push --mirror xxx`

Once you are sure the code is in your new repository, delete the temporary local repository.

`cd .. && rm -rf temp/`

Your private repository on GitHub will now contain a complete copy of this template including the commits that were already made.

## Providing Team Access

If you are working on a group project you will now need to give the other team members access to the repository. If you are working on an individual project you can ignore this step.

In the repository home page choose the **Settings** tab then choose **Collaborators and Teams** from the left sidebar. You will find a search box labelled **Search by username, full name or email address** where you can search for the other members of your team.

Each member of the team needs to be given at least **Write** permissions.

## Cloning Your Private Repository

Each person on the team should now clone the online private repository by completing the following steps.

## Local Config Settings

Before you make any commits you need to update the [local config settings](https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup). Start by using the Terminal (or Git Bash on Windows) navigate inside the project. Once you are in this directory run the following commands, substituting you name as it appears on your ID badge and your university email address (without the `uni.` domain prefix).

```bash
git config user.name 'John Doe'
git config user.email 'doej@coventry.ac.uk'
git config core.hooksPath .githooks
```

## Contributing Changes to the Repository

Make sure you have navigated to inside the project directory and have installed all the dependencies using the `npm install` command.

If the `npm install` command doesn't work and gives an error when setting up the template, here is one possible fix:

1. Delete the `node_modules` folder and the `package-lock.json`
2. Run `npm install` again

If it still doesn't work and it gives an error with Python and/or Microsoft Visual version, try installing `Microsoft Visual C++ 2017 Redistributable`

Now you should make a test commit to check the settings are correct. Start by opening the `README.md` file and adding a new line to the file. Try adding your name. Now you need to stage and commit the changes. Whilst this can be done using the VS Code editor we will be doing this manually using the terminal (or bash shell).

 Now use the `status` subcommand to see what files are not staged.

```bash
git status
```

You will see the `README.md` file listed. This needs staging ready to commit.

```bash
git add README.md
git status
```

Now running the `status` subcommand shows that the file is staged. Next we commit and add a short message.

```bash
git commit -m 'my test commit'
git status
```

This will trigger the [ESlint](https://eslint.org) tool to run which will check the quality of the code in the repository. Notice that it may display a number of warnings (but no errors). This indicates where you can improve the quality of the code but the issue is not serious enough to be flagged as an actual error. If there were errors flagged, the commit would be cancelled!

This code is triggered by the bash script located in the `.githooks/` directory. If you are curious, take a look. Can you fix the issues in the file?

Also notice that after the commit has completed another script called `post-commit` has run and identified one or more issues with the `README.md` file. Can you fix this?

Assuming the commit was successful you need to push this to the GitHub remote.

```bash
git remote -v
git push origin master
```

This will push the new commit to the master branch of your default remote repository (origin). If you are working in a team you might get an error at this stage if another member of your team has pushed their commit before you pushed yours! To fix this you need to pull the extra commit(s) to your local repository using the `git pull origin master` command, fix any issues then push your commit. Git will try and auto merge these changes with your changes.

If you have changed the same line as the commit you just pulled you will get a _merge conflict_ message. Open up the file in the editor and you will see that Git has flagged up the offending lines using special blocks. The editor will show both your version of the code and the version you have pulled. You now need to delete the bits you don't want to keep (including the special blocks added by Git) then stage and commit the modified file and push to the remote.

Well done, you have learned the basics of working with Git. There are some more advanced topics but we will be covering these in a later lab. You can now start working on the assignment.