Git

Git is one of the most important tools at your disposal. Code is not only about what it is but also what is was.

A word of warning. Using the built-in VCS of VS Code and IntelliJ, often leads to unforseen consequences. It is seriously worth it to learn use and the command line tools.

Getting Started §1

For more information, you can look at the Official Guide.

Setup Terminal §1.1

You should be able to access your git tools using the terminal. If you are on Windows and have not installed Git Bash yet, you should.

Setup User §1.2

To get started with git, you first have to setup your user.

$ git config --global user.name "Your Name"
$ git config --global user.email sXXXXXX@student.dtu.dk

To see that it has been configured correctly you should be able to run the following command and

$ git config --list

Setup Default Editor §1.3

It is also a good idea to setup VS Code as editor so that you can edit your messages. This only works if you setup shell tools for VS Code.

$ git config --global core.editor "code --wait"

To see that it worked you can run:

$ git config --global -e

The Normal Operations §2

As part of your normal development routine you only need 7 commands git add, git restore, git commit git switch, git fetch, git merge, and git push.

To learn more about this you should take a look at https://learngitbranching.js.org

Clone the repository. §2.1

To download the repository (if you have setup your ssh-key Gitlab (§2)), you can simply run (where YY is the year, and XX is your group-number):

$ git clone git@gitlab.gbar.dtu.dk:02325/sYY/fordel-XX.git

This will create a folder with the repository in. You can navigate to the folder with cd

$ cd fordel-XX

Creating branches. §2.2

When you start out the first thing you want to do is to create a feature branch, this a branch in your git tree that tracks your changes.

$ git switch -c 'my-feature'

You can push this to the server for backup using the following command:

$ git push --set-upstream origin

Status, Staging files, and Commiting §2.3

Now you are ready to work on the code. After you have done a little bit of work, you want to check the status of the code:

$ git status

Now you can choose what files to add to your next commit (called staged):

$ git add <file>

Or simply everything:

$ git add -A

If you have added to much, you can run to remove that file again.

$ git restore --staged <file>

And then commit it (if you do not add the -m an editor will be opened):

$ git commit -m "My cool commit"

After this you can push the branch to the server.

$ git push

Merge Requests. §2.4

When you are done with the feature, or want to include your solution into main you open a pull-request (see Gitlab (§1))

Fetching and Rebase §2.5

Finally, you probably want to use some of your group-members code as well. The best approach is not to write to each-others branches but instead download their branch and apply your changes on top of theirs in your own branch. This is called rebasing.

First we download the repository.

$ git fetch

Then you can replay your changes on-top of for example the main branch. This pretends like you already knew the current state of the main when you began coding.

To get an idea of how it works; please take a look at https://www.youtube.com/watch?v=f1wnYdLEpgI.

Advanced Usage §3

This section contains some of the advanced features of git.

Creating tags §3.1

A great way of keeping track of commits across branches are git commits. To tag a commit, you need to run the following command.

$ git tag <your-cool-tag-name>

Tags are like branches but they do not update when we make changes to the repository. Forexample the following gets you back:

$ git switch <your-cool-tag-name>

To push all branches to your remote (like Gitlab), you simply have to run:

$ git push --tags

Package Up a Git Repository §3.2

When it is time to hand in your code, you can can bundle up your git repository, using the following command:

$ git bundle create f2.bundle --all

This should make a f2.bundle which you can hand in online.

To be sure that everything is correct, you can clone the resulting bundle, and run your acceptance test on it.

$ git clone -b main f2.bundle fordel-final

The Mailmap file §3.3

Sometimes we commit have with a wrong email. To still get the right attribution, we can add other identities to the .mailmap file.

Your file should look like this and contain one line per wrong email.

Student Name <sXXXXXX@student.dtu.dk> <old.wrong.email@example.com>
Student Name <sXXXXXX@student.dtu.dk> <my.other.wrong@email.com>
...

To check that everything works please run this command, and it should not contain an wrong email.

git log --pretty=format:"%h (%as) - %aE / %aN : %s"

Check out the full documentation in https://git-scm.com/docs/gitmailmap.

Git

Get­ting S­tart­ed §1

Set­up Ter­mi­nal §1.1

Set­up User §1.2

Set­up De­fault Ed­i­tor §1.3

The Nor­mal Oper­a­tions §2

Clone the repos­i­to­ry. §2.1

Cre­at­ing branch­es. §2.2

S­ta­tus, Stag­ing files, and Com­mit­ing §2.3

Merge Re­quest­s. §2.4

Fetch­ing and Re­base §2.5

Ad­vanced Us­age §3

Cre­at­ing tags §3.1

Pack­age Up a Git Repos­i­to­ry §3.2