diff --git a/Programmation/Exercices/serie_15_git/1-local_repository/README.md b/Programmation/Exercices/serie_15_git/1-local_repository/README.md new file mode 100644 index 0000000000000000000000000000000000000000..f109d27910ed05a2e7316096b76b280e91eef6c8 --- /dev/null +++ b/Programmation/Exercices/serie_15_git/1-local_repository/README.md @@ -0,0 +1,216 @@ +# Working locally + +The first exercises will teach you to use git locally. +This means that everything is going to be stored in the local repository (i.e. the `.git` folder). +We also repeat that you not delete that folder, or you'll lose your (local) repository. + +We strongly suggest that: +- you to print the status after each command (`git status`), to be sure to understand in what state you put your files and repository, +- to print the log after each commit to see the evolution of your commits. + +# Exercise 1: initialize your local repository + +Let's initialize the repository. +First create a directory that will contain your work and repository, that is to say the working directory. + +For example: +``` +$ mkdir git-workshop-local +``` +and change into your newly created directory: +``` +$ cd git-workshop-local +``` + +Now you can initialize your repository with `git init`: +``` +$ git init +``` +Git will output a message stating that the repository is initialized. +Confirm that there is a `.git` subdirectory in your working directory. + +# Exercise 2: add new files and do your first commit + +Start by adding a new file in your working directory. +You can create a file named after your name `alfred.escher.txt` which contains your full name: +``` +Alfred Escher +``` +if your first and last name are respectively Alfred and Escher. + +Try to see what is the status of the new file. +Do you understand the status? +Then try to change its status to be able to commit it: +- first add it to the staging area. This is done with the `git add` command. What do you observe? Can you find the information stating that your file is ready to be committed (i.e. in the staging area)? +- commit the content of the staging area with the `git commit` command: `git commit -m "my first commit message"` where you can see that a message is directly attached to the commit with the `-m` option. + +Once this is done, check the status. +Did you expect such output? + +Note that you can use the `*` to add several files. +For example to add all the Python script files (the files with the `py` extension) you can use: +``` +$ git add *.py +``` +You can also add a whole directory and it's content if needed: +``` +$ git add my_directory +``` + +# Exercise 3: modifying files + +Edit the file with your name in it (or any other committed file). +For example you can add the workshop's date next to your name: +``` +Alfred Escher 2020.07.18 +``` +or remove your last name: +``` +Alfred +``` + +Check the status. +What do you see? +Do you understand the output? + +Add the modified file to the staging area. + +While files are in the staging area, Git can show you all the modifications that are going to be committed with the `git diff` command. + +If you want to see them for a specific file you can add the file name after the `git diff` command: +``` +$ git diff --staged alfred.escher.txt +``` + +Now commit (with a message) your you modifications to the repository. +You can check if everything went well by checking the status of the repository and the log with `git log`. + +# Exercise 4: move or rename files + +## Moving files + +Create a subdirectory (for example `users`) in your working directory and move a committed file to this new subdirectory with the `git mv` command. +Note that you can also move several files or wholes directories at once, like it's done with the `add`. + +Try to commit this change and check the status between each step to be sure to understand what is happening. + +Now repeat the exercises with the `mv` command (i.e. you moved your file without using git). +You should notice that more steps are required to commit the change. + + +## Renaming files + +Renaming a file is simply a move to the same location with a different name, e.g.: +``` +$ git mv alfred.escher.txt jerome.franel.txt +``` +Try it, and inspect the status of the file. +Create a commit if you want. + +Note that the recommended practice is to use `git mv` isntead of and `mv` followed by a `git add`. + +# Exercise 5: deleting files + +Try to delete (i.e. remove) a committed file with the `git rm` command, +e.g.: +``` +$ git rm alfred.escher.txt +``` +and try to commit that change. +Note that, like with the `git add` command you can move several files or wholes directories. + +Then try the same exercises with the `rm` command on a committed file, e.g.: +``` +$ rm alfred.escher.txt +``` + +Note that the recommended practice is to use `git rm` isntead of and `rm` followed by a `git add`. + +# Reverting mistakes + +What happen if you did an horrible mistake? +Like deleting a super important function from your source, or adding a feature that totally break the code. + +No worries! +This is the focus of the next two exercises. +There are two ways of restoring the file: the `checkout` (exercise 6) and the `reset` (exercise 7) but this depend "where" your files are. + +# Exercise 6: checkout of an old commit + +If the file is **committed** you should use the `checkout` command to revert to a specific commit. +To do this, you need the commit number. +This one is usually available through the `log` command. +Then you provide to `checkout` the commit number, the `--` and the file you want to checkout, e.g.: +``` +$ git checkout cb3aa8 -- alfred.escher.txt +``` +as you can see, the whole commit number is not needed. +The first 4 characters should be enough. + +What do you expect to see in the status? +Do you understand the output? + +What about the content of the file? +Does it correspond to the checkout old commit? + +If you want to keep it like it is in the older state, you need to **create a new commit** with that version of the file. Try it. + +If you want to checkout a full commit, use the command like that: +``` +$ git checkout cb3aa8 . +``` +It's very **important that you don't forget the** `.` and that you execute the command at the **root of your working directory**. +The `.` indicate that git should checkout all file in the content directory and all the subdirectories only. +This is why you should be at the root. + +To make these change permanent, you should **create a new commit** after the checkout. + +Note that there exist other ways to **really revert commits**. +But we only show you the operations you can revert (i.e. the non-destructive ones). + +# Exercise 7: reset a file + +What can you do if a file should not be part in the commit, but it's nevertheless **in the staging area**? + +If you want to remove a file from the staging area, simply use `reset` followed by the file name: +``` +$ git reset alfred.escher.txt +``` + +Add a modified file to the staging area and check the status. +Then try to remove it from the staging area with the `git reset` command and check the status. + +Did you see the output stating that your file is not staged anymore? + +# Exercise 8: ignoring files or directories + +Some files may be private or have no point of being part of the repository. +So we can keep them untracked. +In that case Git will not monitor or manage them. +However having a huge list of untracked files may makes the `git status` output hard to read. + +Create three files: `temp_result_01.csv`, `temp_result_02.csv` and `temp_result_03.csv` to emulate temporary and unwanted files in your repository. + +Then you should see them as untracked with `git status`. +This should "pollute" your output. + +Fortunately Git can use a list of file to ignore. +To do so you need to create a hidden file named `.gitignore` (do not forget the `.` at the begining). +And you can add in the `.gitignore` file the file names to ignore in that file: +``` +temp_result_01.csv +temp_result_02.csv +temp_result_03.csv +``` + +And then you can see that the file are not listed anymore as untracked with `git status`. + +And of course the `.gitignore` is a file to manage like any other file in Git. +You should commit it in the repository. + +It's possible to use pattern to make the `.gitignore` more readable and easier to fill. +For example we also could have written in the `.gitignore` file: +``` +temp_result_*.csv +``` +You'll find more information about patterns in the [documentation](https://git-scm.com/docs/gitignore). diff --git a/Programmation/Exercices/serie_15_git/2-remote_repository/README.md b/Programmation/Exercices/serie_15_git/2-remote_repository/README.md new file mode 100644 index 0000000000000000000000000000000000000000..265dc8bc8ce3242affe91e9696a7f30f1ede0765 --- /dev/null +++ b/Programmation/Exercices/serie_15_git/2-remote_repository/README.md @@ -0,0 +1,172 @@ +# Working with a remote and GitLab + +In the previous case the repository was only local. +But it's common with Git to work with a remote repository. +That is to say, one which is not on the local machine. + +For example in the centralized workflow, one can see the remote as the `shared repository`: + + + +Usually the remote is on a machine which is always accessible: +- not turned off, +- connected to the network. + +For example a GitHub repository is (should be always) available as it is the case for HEPIA's GitLab. + +Here you'll learn to work with remote repository on GitLab. +We'll study two use cases: +1. You start a new project from scratch on GitLab. +2. You already have an existing project and you want to use Git and GitLab to manage it. + +Check first if you can connect to [HEPIA's GitLab](https://githepia.hesge.ch/) using your HEPIA credentials. + +Note: depending on the configuration, the default branch may not be master anymore, but main. +If the commands don't work with master, try to use main instead. + +# Exercise 1: add your SSH key to GitLab + +If you already setup your SSH key with GitLab, you can jump to Exercise 2. + +If not, there are two cases: +- you already have an SSH key. Check if you have a file name `id_rsa.pub` in your `.ssh` folder. + +- You don't have an SSH key. So you should generate by following this nice [tutorial](https://help.github.com/en/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent). Follow the instruction in the "Generating a new SSH key" section. +At the end of the process this will generate a file named `.ssh/id_rsa.pub`. + +To use your SSH key, add it in your [GitLab user settings](https://githepia.hesge.ch/-/profile/keys): + + + +Past the content of `id_rsa.pub` in the **Key** text area and name it by adding a name in the **title** text field. Beware of not adding your private key. +Then click on the **Add key** button. + +This is needed in order to be correctly identified by the server, otherwise the server cannot know who you are when you'll use `git`. + +# Exercise 2: create a remote GitLab repository + +To create a new project (i.e. a new repository), on the top burger menu, go to: +``` +projects -> your projects -> View all projects +``` + + + +Then click on the green button labeled `New project`, then `Create blank project` and fill the requested information. + + + +That's all! +You created an empty repository. You'll learn to clone it in the next exercise. + +# Exercise 3: cloning a remote repository + +Try to clone the repository you just created with the `git clone` command. +To do it you should use its SSH address. +You can find the address here: + + + +and then use it with the clone command. + +**Do not clone your remote in the local repository you created in the previous exercises!** This because the working directory already contains a local repository. We'll see how to add a remote in an existing local repository in a next exercise. + +For example: +``` +$ git clone git@ssh.hesge.ch:my-gitlab-repository.git +``` +and the output should states that the repository has been cloned. +Git will create a directory having the name of the project and will contain a `.git` subdirecory. +This new directory will be your working directory. + +If you experience difficulties, do not hesitate to ask one of the teaching assistants. + +Once a repository is cloned, you can add, edit and delete files, and also (see the next exercise) you can push and pull updates. + +# Exercise 4: synchronizing with the remote + +Create at least one commit in your new repository. +From this point your commits only exist in your **local repository**. +If you want your commits to be available on the remote, you have to synchronized them. + +The synchronization can be done in two "directions": +- from the remote to your local machine: you **pull** from the remote to your machine, +- from your local machine to the remote: you **push** to the remote. + + + +## The PUSH direction +In this case we're interested in **pushing our commit to the remote**. +To do so, you use the command `git push`: +``` +$ git push origin master +``` +Here `origin` is the name of the remote. +By default it has this name, unless you explicitly change it. + +As we're using branches, you're only working with the default and only branch: `master` or `main`. +When you push something you have to specify where it is: +- the name of the remote, +- and the corresponding branch on the remote. + +## The PULL direction + +Great, now your commits have been pushed to the remote. But how can a fellow developer get them? Or simply how can you get them on a different machines? + +Again you have to synchronize your local repository with the remote. +This must be done from the machine where you need to **pull** the remote repository. +To do so, you use the command `git pull`: +``` +$ git pull origin master +``` +in that specific case, the output will indicate that both repositories (the local one and the remote) are synchronized. + +You can "simulate" having local repositories on different machine by **cloning the remote** repository in **another directory**. + +Then you will push and pull from these different directories to see what happen. +For example: +``` +$ mkdir machine_a +$ cd machine_a +$ git clone git@ssh.hesge.ch:my-gitlab-project.git +``` +then add a new file or modify one of the existing file and commit the modification wihout pushing. + +Then repeat this in another directory, i.e.: +``` +$ mkdir machine_b +$ cd machine_b +$ git clone git@ssh.hesge.ch:my-gitlab-project.git +``` + +Do you see the commit? +Does it correspond to what you expected? +Do a `git log` to understand what happened. + +Go to `machine_a` and push your commits: +``` +$ git push origin master +``` +and then go to `machine_b`. +Do you see the commit done from `machine_a`? + +Now from `machine_b` pull the remote: +``` +$ git pull origin master +``` +Do you understand the output? +Do you see now the new commit from `machine_a`? +Do a `git log` to check that everything is fine. + +# Exercise 5: working with an existing project + +To integrate Git and GitLab with an already existing project or working directory: +- First create a new project on GitLab. Let's assume it is `my-gitlab-project`. +- Then on your machine go to your existing working directory. For example let's say `my-existing-project`. +- Then init the repository (like in the previous exercise) wit `git init` in `my-existing-project`. +- Finally add the remote: +`git remote add origin git@ssh.hesge.ch:my-gitlab-project.git` + +You can find the address of the remote like we found the address used with the clone command. + +You can now use git to add the files and create a commit that you can push on your remote GitLab repository. All like you did in the previous exercises. diff --git a/Programmation/Exercices/serie_15_git/2-remote_repository/fig/centralWF.png b/Programmation/Exercices/serie_15_git/2-remote_repository/fig/centralWF.png new file mode 100644 index 0000000000000000000000000000000000000000..d5d660f5be293547703bafe728340859debd499e Binary files /dev/null and b/Programmation/Exercices/serie_15_git/2-remote_repository/fig/centralWF.png differ diff --git a/Programmation/Exercices/serie_15_git/2-remote_repository/fig/git_flow_command.png b/Programmation/Exercices/serie_15_git/2-remote_repository/fig/git_flow_command.png new file mode 100644 index 0000000000000000000000000000000000000000..6d291d6c8e106c16c34f0f7f62d7106f0271f57d Binary files /dev/null and b/Programmation/Exercices/serie_15_git/2-remote_repository/fig/git_flow_command.png differ diff --git a/Programmation/Exercices/serie_15_git/2-remote_repository/fig/gitlab_repo_add.png b/Programmation/Exercices/serie_15_git/2-remote_repository/fig/gitlab_repo_add.png new file mode 100644 index 0000000000000000000000000000000000000000..7015b60e613d7958ee4cb1b302c1c5b1ff0d16f9 Binary files /dev/null and b/Programmation/Exercices/serie_15_git/2-remote_repository/fig/gitlab_repo_add.png differ diff --git a/Programmation/Exercices/serie_15_git/2-remote_repository/fig/gitlab_ssh.png b/Programmation/Exercices/serie_15_git/2-remote_repository/fig/gitlab_ssh.png new file mode 100644 index 0000000000000000000000000000000000000000..a015b084c0fb04a3a5dee02734d8d9e2396188d4 Binary files /dev/null and b/Programmation/Exercices/serie_15_git/2-remote_repository/fig/gitlab_ssh.png differ diff --git a/Programmation/Exercices/serie_15_git/2-remote_repository/fig/gl_proj.png b/Programmation/Exercices/serie_15_git/2-remote_repository/fig/gl_proj.png new file mode 100644 index 0000000000000000000000000000000000000000..6866c070d637b8dda9b6b29bf83bac11897ba4da Binary files /dev/null and b/Programmation/Exercices/serie_15_git/2-remote_repository/fig/gl_proj.png differ diff --git a/Programmation/Exercices/serie_15_git/2-remote_repository/fig/new_proj_gl.png b/Programmation/Exercices/serie_15_git/2-remote_repository/fig/new_proj_gl.png new file mode 100644 index 0000000000000000000000000000000000000000..29ea7d8f50ef7353496da256192103c09df4aa24 Binary files /dev/null and b/Programmation/Exercices/serie_15_git/2-remote_repository/fig/new_proj_gl.png differ