Git

One of the core tools we will be working with throughout the module is git. Git is a tool for version control and in modern software development a tool like git is a core requirement of any sensible modern development workflow for two reasons:

  • It allows you to determine what you changed when and return to a previous version if necessary.
  • It provides an easy avenue to backing up your code.

When working in teams there is the additional benefit that large numbers of developers can work on the same codebase at the same time.

Creating a Repository

Creating a local repository is as simple as running the following command (in the client-seitige-web-anwendungen):

$ git init

For this module you should initialise your git repository not in the week01 folder, but in its parent folder (which I hope you gave a name relevant to this module). The reason for this is that you do not want to have to deal with up to 15 different repositories for a single module.

Note

If you want to delete a local repository, simply delete the .git directory in the root directory of the repository and your local repository is gone. Be careful, this cannot be undone.

Repository Status

To view the current status of your local repository run

$ git status

If you have made changes that you have not yet committed, then this will list the changed files. If everything is up to date, then it will also tell you so. Finally, if your repository is linked to a remote repository, it will tell you the state of your local repository relative to the remote repository.

Ignoring Files

Not everything that you have in your project should also go into your repository. In particular files that are automatically generated, binary executables that are built from your source code, and temporary files should never be included in your repository. To let git know that certain things should be ignored, you create a .gitignore file and into that you add filenames and patterns that should be ignored. Create one now and then add the following content:

node_modules

If you now run

$ git status

again, you will see that the node_modules directory is no longer listed.

Committing Changes

Changes that you have made to the local filesystem are not automatically applied to the repository. Instead it is up to you to decide when to do so. Two useful heuristics for this are:

  • Commit when you have finished part or all of a task.
  • Commit when you know you will not return for a significant time.

To commit a change in git you need to go through two steps. The first is to stage the change by adding it to the index:

$ git add .

Instead of . (which is the current directory and all its modified children) you can also specify one or more specific files, if you only want to commit some of the changed files.

Then run the actual commit:

$ git commit -m "Message to use to describe the commit"

For the message you should use a descriptive message, so that when you come back to your code in the future, you will, just from the commit message, be able to roughly see what you did. Git enforces a relatively short initial commit message length, so really think in high-level terms for the message.

Note

The first time you do this, git will ask you to set up name and email address to attribute your commits. Just follow the instructions in those.

Discarding Changes

Sometimes you have tried something out and it has not worked and you want to go back to something that worked. If you have never committed the file, you can simply delete it, but if you want to return to the last committed version run

$ git checkout -- .

As with the add command, you can use a specific filename instead of the . to only discard the changes on that file.

Pushing to a Remote Repository

A local repository is nice and useful, but to properly use git you need to push your changes to a remote repository. Only this can keep your work safer from data loss. The Department of Computer science run their own remote git repository system at https://gitlab.informatik.uni-halle.de, which you can access using your standard university login.

Using that (or any other remote git service that you wish to use), create a new online git project for this module. Then run

$ git remote add origin PROJECT_GIT_URL

You can find the PROJECT_GIT_URL somewhere on the online repository page and it should look something like git@gitlab.informatik.uni-halle.de:USERNAME/PROJECT_NAME.git or https://gitlab.informatik.uni-halle.de/USERNAME/PROJECT_NAME.git.

The first time you want to push something, you need to run

$ git push --set-upstream origin master

After that you can just run

$ git push

To push your changes up to your repository. Check the online repository to see if it worked.