Merge branch 'gitcli-basics' into 'main'

Merge latest from Gitcli basics into main

See merge request !7

03-cli-basics/README.md

@@ -112,6 +112,45 @@ On GitLab, the project welcome page displays information about the latest commit
 
 ![gitlab_after_push.png](./media/gitlab_after_push.png)
 
+## Keeping a local repository synchronized with a remote repository
+
+A same remote repository can be cloned several times: by different people on each of their machines, by a single user on different machines, by a single user in different directories on the same machine.
+
+When someone pushes modifications from a clone (local repository) to the original remote repository, *these modifications do not get pushed to every existing clone*. It is the duty of the owner of each local repository to ensure that the local copy does not get too far behind the remote repository.
+
+### Fetching information about the remote repository
+
+The `git fetch` [command](https://git-scm.com/docs/git-fetch)] retrieves information about all modifications made to the current branch of the remote repository, since the local repository was last synchronized. *It does not modify the local repository.*".
+
+After completing a fetch operation, doing `git status` will display how many commits have to be "replayed" in the local repository in order to synchronize it again with the remote repository.
+
+The following example screenshot shows the output of a `git log` on a local repository:
+![git_log_before_fetch.png](./media/git_log_before_fetch.png)
+As can be seen, the most recent commit known to the local repository dates from Nov 16 (and has an id starting with `3367`)
+
+The following screenshot shows the curent state of the remote repository on GitLab :
+![gitlab_log_latest.png](./media/gitlab_log_latest.png)
+Notice that in the remote repository, there is an additionnal commit, dating from Nov 18 (with an identifier starting with `8de7`)
+
+The local repository is thus one commit behind the remote repository. The following screenshot displays the output the a `git fetch` command in the local repository:
+![git_fetch.png](./media/git_fetch.png)
+
+The `git status` command now displays the difference (expressed in the number of commits) between the current local repository and the remote repository it was cloned from.
+![git_status_after_fetch.png](./media/git_status_after_fetch.png)
+
+### Applying remote changes to the local repository
+Actually synchronizing the local repository, with the information retrieved through `git fetch` is performed with the `git pull` (command)[(https://git-scm.com/docs/git-pull)]. Which has the following result on our example:
+![git_pull.png](./media/git_pull.png)
+
+### Important notes
+It would have been possible to run `git pull` without running `git fetch` before. This would  have fetched the remote commits and applied them to the local repository in a single step. Running `git fetch` beforehand lets you check how far behind your local repository is before trying to apply the changes with `git pull` (which is a proxy for the risk of having to manage conflicts when applying the changes, more on that later). Running `git pull` directly is OK if you know you're not far behind the remote repository.
+
+
+
+
+
+
+
 
 
 

03-cli-basics/exercises.md

@@ -26,4 +26,13 @@
   7. Commit all your latest changes.
   8. After checking all went well, propagate the changes to the remote GitLab project.
 
+## Synchronize your local repository afer making changes to the remote repository
+  1. Using the GitLab Web interface, make some changes to your remote repository (add an entry to the `.md` file, and add an image).
+  1. On your workstation, in your local repository:
+      1. Fetch the latest commit(s) from the remote repository.
+      2. Check that your local repository is at least one commit behind.
+      3. Synchronize your local repository with the latest commits from the remote repository.
+
+
+