Skip to article frontmatterSkip to article content
Site not loading correctly?

This may be due to an incorrect BASE_URL configuration. See the MyST Documentation for reference.

Lab3: Remote synchronization and ignoring files

IUT d'Orsay, Université Paris-Saclay

Objectives

The goal of this lab is to understand the following concepts and commands:

Version history graph

To better understand this concept, we will look at the version history graph of our current project.

  1. Run git log --oneline to display the repository history where each commit corresponds to one line starting with a code, called the commit hash, allowing the commit to be identified, followed by the commit message.

q

Reminder: press q to quit the log.

  1. Run git log --oneline --graph to see the graph (drawn in ASCII in the terminal) associated with these commits, where each vertex is represented by a star.

Your graph should be linear (a path).

When you learn how to manage multiple branches in your repository, you will be able to add the options --decorate (to display the branch name next to the commits) and --all (to see all branches) to the command git log --oneline --graph.

  1. Define the new command git graph as an alias as follows:

git config --global alias.graph "log --oneline --graph --decorate --all"
Do not abuse aliases

Do not create aliases for every command, because you might not remember the standard commands and vocabulary after a while. In this class, we will only use aliases when it is explicitly mentioned.

  1. Run git graph.

Diff and Pull

Go to the Remote Repo on GitLab.

  1. Click on Code then Web IDE in Open with.

  2. Create a new directory Lab3/ and a file hello-world.cpp with the following code.

hello-world.cpp
#include <iostream>
using namespace std;
int main() {
    cout << "Hello World!" << endl;
    return 0;
}

You can see a 1 on the left sidebar, indicating that a change has been made. If you click on it, you will see a change related to the file hello-world.cpp and the option to save and publish to the main branch (Commit and push to ‘main’).

  1. Add a commit message.

  2. Click the Commit and push to ‘main’ button.

  3. Click on Continue when asked if you want to save to the default branch (main).

Return to your Local Repo and suppose that a collaborator made changes, then published them to the Remote Repo without informing you.

  1. Run git fetch, then git status.

Start with git fetch && git status!

In practice, when you work on a project, it is common that between two work sessions, someone else has modified part of the code. If you start a work session without checking the state of your repositories, you risk encountering conflicts to resolve (for example, if you modify the same parts of the code differently).

Although we will discuss conflict resolution in this course, it is better to avoid them. This is why it is essential to always start with git fetch && git status before deciding what to do!

You can also run git diff origin/main to see precisely the modifications that were made.

  1. Run git diff origin/main to see the differences between the two repositories.

git diff

The command git diff origin/main shows us the difference between the current version of our files (in the Working Tree) and the version of the same files in the Remote Repo (known locally through the remote-tracking branch, i.e. the version known since the last git fetch command). You can navigate this diff in the terminal using the arrow keys on your keyboard.

The diff is displayed as follows:

  • The index line corresponds to internal Git identifiers. This is not useful for normal reading.

  • The prefix a/ corresponds to the version in origin/main.

  • The prefix b/ corresponds to the version in the Working Tree.

  • If the file was created or removed, then it exists in only one version but not the other, therefore, a/ or b/ might be replaced by /dev/null.

  • The blocks @@ -lineVersionA,nbLines +lineVersionB,nbLines @@ indicate the modified lines. For example @@ -1,4 +2,8 @@ means that the area starting at line 1 and spanning 4 lines in the file from a/ was modified and now corresponds to the area starting at line 2 and spanning 8 lines in the same file but in version b/.

  • A line starting with - in red is a line from a/ that is not in b/.

  • A line starting with + in green is a line from b/ that is not in a/.

  • A white line indicates a line that did not change.

  1. To download the changes from the Remote Repo that are not yet on your Local Repo, run git pull.

Show

  1. Run git graph to see the history graph of your project.

  1. Choose a commit hash from a past commit and run git show <commit hash>. Observe.

For example:

git show acbd123
Reminder: press q to quit

When you open logs with git log, git graph, git diff or git show, you can use the q key to quit.

  1. To see a specific file in a past commit, run git show <commit hash>:<file>.

For example:

git show acbd123:Lab1/my-first-file.txt

Ignoring files

  1. Open the directory Lab3/ where the file hello-world.cpp is located.

  2. Compile the code with g++ -o <file name> <file name>.cpp.

For example:

g++ -o hello-world hello-world.cpp

  1. Run the executable hello-world with the command ./hello-world.

Executables are part of the files that we want to ignore.

Why ignore files?

During development, some files must be systematically ignored (for example, files generated during compilation), because they unnecessarily clutter the repository.

For example, a complex game engine like Unity may require up to 1 GB of files to run certain modules, sometimes unused by your game. If these files are not ignored, you may be forced to download or publish 1 GB every time you synchronize your repositories, while the files specific to your game only represent a few MB.

Configuration files can also cause compatibility problems, especially when you synchronize configuration files specific to certain machines with others.

  1. Create the .gitignore file.

Why does .gitignore start with a .?

Files whose names start with . are hidden files (they do not appear when you use a file manager). These are often configuration files.

To display hidden files in a file manager, you can often press Ctrl + H (like ‘Hidden’). The .git directory is ignored by Git natively.

  1. Write the name of the executable hello-world in .gitignore.

If your editor generated other files to ignore...

In this case, you must add the names of these files or directories to .gitignore. For example, .vscode, .vsconfig, etc.

  1. Run git add .gitignore, git commit -m "<message>" and git push to send the .gitignore file to the Remote Repo.

  2. Run git status. What changes compared to usual?

Where are my untracked files?

Normally, since we did not add the executable hello-world with git add, git status tells us that there is an untracked file, potentially important. However, thanks to the .gitignore file, Git recognizes that we chose to ignore hello-world and will never track changes made to this file.

  1. Replace the code in the .gitignore file with the following code.

*
!*.*
!*/
I need to ignore other types of files...

You may have used an editor that generates other types of files to ignore, in addition to files without extensions that we already excluded with the code above.

For example, if .o files were generated and you want to ignore them in the future, add the following line to your .gitignore

*.o

  • *.o allows ignoring all files with this extension.

Another example: if your editor generated a build/ directory, you can add the following line:

build/

This will exclude all contents of directories named build, regardless of their location in the project.

You can even combine everything to ignore files without extensions, .o files, and build/ directories (as well as their contents) with the following expressions in your .gitignore.

*
!*.*
!*/
*.o
build/

  1. Run add, commit, and push to synchronize your repositories.

Removing files

  1. Open the directory Lab3/ and create a file to-be-removed.txt.

  2. Add, commit, and push this file to the Remote Repo.

git rm

You can use git rm <file name> to remove a file that has already been synchronized on both repositories. git rm works similarly to git add, but for removing files. Then, you can do a git commit followed by a git push, as usual, to publish these changes (deletions).

A file that exists only in the Working Tree can be removed simply via a file manager or with the rm command (without git). If you already added (git add) this file to tracked changes (staged changes), you can remove it using git restore --staged <file name>.

  1. Remove the file to-be-removed.txt and synchronize with the Remote Repo.

In your Local Repo and Remote Repo, you should now have the following structure (without considering the hidden .git which must be present in all projects tracked by Git):

Lab1/
├── my-first-file.txt
├── my-second-file.txt
Lab2/
├── <a text file>.txt
Lab3/
├── hello-world.cpp
.gitignore

Other files may be present in your Working Tree but make sure they are ignored (in .gitignore and then with git status).

  1. If you have unwanted files, remove them and synchronize with the Remote Repo.

  1. Return to the objectives and check the points that you have mastered. Practice the commands and concepts that you do not yet fully understand. Ask your instructor for help if needed.

Quiz !

Do not forget to complete the lab quiz on Moodle!

Lab Sessions
Lab2: Discovering GitLab
Lab Sessions
Lab4: Time Travel