Git: Laboratory 1

Version management is today an essential part of software development. A version management 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 management systems, specifically git, which today is the most popular version management tool. Although we use git here, the knowledge will also be useful in other version management systems. Almost all concepts that are reviewed here are also applicable in e.g.Mercurial.

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.

Note - Read throughout the laboration before starting.

Documentation.

• 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: Perfect if you prefer information in book form instead. The content is largely the same as the link above.
• http://chris.beams.io/posts/git-commit/: good article going through how to write commit messages toEffectively communicate the changes and motivation behind them.
• http://documentup.com/SKWP/git-WorkFlows-Book: Going through a popular method for working with Git.
• http://www.fredonism.com/archive/a-practical-take-on-gitflow-and-semantic-versioning: interesting article on version numbering.

Task

Start by downloading (Git Clone) the Lab's "Repository" located at git@gitlab.liu.se:Large-scale-dev/git-web-server.git. 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.

• 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 "Merga" it with the original one. That is, joining the new branch with the original branch. Expire from Develop and implement a new function (add a number of text at the end of README.MD) in this way.
• Once you've joined your change, get some other updates in Develop. The idea is that you should get the changes that are made in the implement-API and _ADD tests. Start by joining ADD-TESTS with Develop using the Merge command.
• Merge implement-API with Develop by making a rebase.
• Committen "Remove Important Structs" is stupid to have with then it breaks the code. Make sure to forget it by means of a reset.

For higher grades

To get a higher grade then it requires you to do a little extra. 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.
• It is another repo at git@gitlab.liu.se:Large-Scale-dev/git-lab-remote2.git. 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 touces and reporting

When the changes are complete, create a new repo on [gitlab.liu.se] (gitlab.liu.se) and Push up 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 where you carry out the different steps. 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.

# Git: Laboratory 1 Version management is today an essential part of software development. A version management 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 management systems, specifically git, which today is the most popular version management tool. Although we use git here, the knowledge will also be useful in other version management 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 laboration 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. - [http://chris.beams.io/posts/git-commit/](http://chris.beams.io/posts/git-commit/): good article going through how to write commit messages toEffectively communicate the changes and motivation behind them. - [http://documentup.com/SKWP/git-WorkFlows-Book](http://documentup.com/SKWP/GIT-WORKFLOWSBOOK): Going through a popular method for working with Git. - [http://www.fredonism.com/archive/a-practical-take-on-gitflow-and-semantic-versioning](http://www.fredonism.com/archive/a-practical-take-on-GitFlow-and-semantic version /): interesting article on version numbering. ## Task Start by downloading (Git Clone) the Lab's "Repository" located at git@gitlab.liu.se:Large-scale-dev/git-web-server.git. 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. - 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 "Merga" it with the original one. That is, joining the new branch with the original branch. Expire from Develop and implement a new function (add a number of text at the end of _README.MD_) in this way. - Once you've joined your change, get some other updates in _Develop_. The idea is that you should get the changes that are made in the _implement-API_ and _ADD tests. Start by joining _ADD-TESTS_ with Develop using the _Merge_ command. - Merge _implement-API_ with _Develop_ by making a rebase. - Committen "Remove Important Structs" is stupid to have with then it breaks the code. Make sure to forget it by means of a reset. ### For higher grades To get a higher grade then it requires you to do a little extra. 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. - It is another repo at git@gitlab.liu.se:Large-Scale-dev/git-lab-remote2.git. 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 touces and reporting When the changes are complete, create a new repo on [gitlab.liu.se] (gitlab.liu.se) and Push up 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 where you carry out the different steps. 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.