# Git: Laboratory 1 Version control is today an essential part of software development. A version control system keeps track of all changes that take place in a project: What was changed, who changed it and when it was made. It also enables several people to work in parallel on a project. The purpose of this lab is that you should learn how to use version control systems, specifically Git, which is the most popular version control tool today. Although we use Git here, the knowledge will also be useful in other version control systems. Almost all concepts that are reviewed here are also applicable in e.g. [Mercurial](https://www.mercurial-scm.org). The lab is much easier to implement if you are comfortable with the basics of Git. Therefore, it is recommended to go through a quick tutorial before, for example [try.github.io](https://try.github.io/). ** Note ** - Read throughout the lab before starting. ## Documentation. - [https://git-scm.com/doc](https://git-scm.com/doc): Contains all information you need about GIT. There are also some films if you prefer information in that way. - [https://git-scm.com/book/en/v2](https://git-scm.com/book/en/v2): Perfect if you prefer information in book form instead. The content is largely the same as the link above. - [https://www.conventionalcommits.org/en/v1.0.0/](https://www.conventionalcommits.org/en/v1.0.0/): A good attempt to formalize the structure of commit messages based on industry practices. - [http://chris.beams.io/posts/git-commit/](http://chris.beams.io/posts/git-commit/): Good article going through how to write commit messages to effectively communicate the changes and motivation behind them. - [https://about.gitlab.com/blog/what-is-gitflow/](https://about.gitlab.com/blog/what-is-gitflow/): A blog post about gitflow and working with Git. - [https://semver.org/](https://semver.org/): The official documentation of semantic version numbering. ## Task Start by downloading (clone) the Lab's repository located at [https://gitlab.liu.se/large-scale-dev/git-web-server](https://gitlab.liu.se/large-scale-dev/git-web-server). This repository contains several "Branches". The two main ones are _master_ and _develop_. In addition to these two, there are also a number of so-called "Topic Branches". Get acquainted with the history and how these branches look. ### Passing tasks. Take notes on your actions. You will have to reproduce them in the screencast later. - To begin with, show how to develop a new function. When developing a new feature, it is good to do it on a new Branch, then merge it with the original one. That is, joining the new branch with the original branch. Create a new branch from Develop and implement a new function (add a piece of text at the end of _README.md_) in this way. - Once you've merged your change, get some other updates into _develop_. The idea is that you should get the changes that are made in the _implement-api_ and _add-tests_. Start by merging _add-tests_ with Develop using the _merge_ command. - Merge _implement-api_ with _develop_ by making a rebase. - Commit "Remove Important Structs" is erroneous and it breaks the code. Make sure to remove it by means of a reset. Make sure to only remove this commit, nothing else. ### For higher grades In addition to the steps above, you should also do these: - After that you see that there are two commits "add a todo in todo.go" and "Add One More Todo in Todo.go" that really should be one commit. Fix this. - There is another repo at [https://gitlab.liu.se/large-scale-dev/git-lab-remote2](https://gitlab.liu.se/large-scale-dev/git-lab-remote2). Add it as a new remote. - On the new remote, there is a commit on the Branch Implement API ("Refactor Database Configuration") that you would like to apply to your Develop. Use Cherry-Pick to do this. ### Finishing touches and reporting When the changes are complete, create a new repo on [gitlab.liu.se](gitlab.liu.se) and push your changes there. Make sure all changes are located in the _Master_ branch before you do it. The task is reported by recording a screencast (hard limit: 10 minutes) where you **carry out** the different steps from the initial state. Be sure to explain what is happening in every step. Specifically, explain the difference between Merge and Rebase by discussing how the information is stored in Git. Upload the recording to your GitLab repository and send a mail to your lab assistant with the link to the repository. Make sure that your lab assistant has access to the code (*Reporter* role). Optionally, you may demonstrate the lab live to a lab assistant (**only** during scheduled lab sessions). The same requirements apply.