Mentions légales du service

Skip to content
Snippets Groups Projects
Commit 6912a1c8 authored by MALANDAIN Mathias's avatar MALANDAIN Mathias
Browse files

Add footers + write down a few extras

parent bcb07a32
No related branches found
No related tags found
No related merge requests found
......@@ -45,4 +45,6 @@ It is impossible to overstate how the use of GitLab makes collaborating on a sof
----
Of course, before that, [**we have to go through a bit of setup**]({{'/01-setup' | relative_url }}).
\ No newline at end of file
Of course, before that, [**we have to go through a bit of setup**]({{'/01-setup' | relative_url }}).
You may also go back to the [detailed table of contents]({{'/index#toc' | relative_url }}).
\ No newline at end of file
......@@ -139,4 +139,6 @@ See that third icon, the weird branching stuff? This is the button to access the
----
Everything is ready! [**Time to create our first project.**]({{'/02-creating-projects' | relative_url }})
\ No newline at end of file
Everything is ready! [**Time to create our first project.**]({{'/02-creating-projects' | relative_url }})
You may also go back to the [detailed table of contents]({{'/index#toc' | relative_url }}).
\ No newline at end of file
......@@ -227,4 +227,6 @@ Done! Refresh the webpage for your project, and this is what you will see:
There are already a few things you can do online by clicking buttons, and GitLab provides a pretty nice online IDE (Integrated Development Environment), but this is **not** what you want to do. GitLab is based on Git, and Git makes it possible to work, in a collaborative manner, on a local copy of a project.
Brace yourselves: [**It is time to learn how Git works.**]({{'/03-linear-git-project' | relative_url }})
\ No newline at end of file
Brace yourselves: [**It is time to learn how Git works.**]({{'/03-linear-git-project' | relative_url }})
You may also go back to the [detailed table of contents]({{'/index#toc' | relative_url }}).
\ No newline at end of file
......@@ -264,4 +264,6 @@ If several commits are involved in the conflict, you might have to repeat this p
----
Now that the stage (no pun intended) is set, get ready to dive in. [**Time to introduce the best features of all: branches and issues.**]({{'/04-branches-issues' | relative_url }})
\ No newline at end of file
Now that the stage (no pun intended) is set, get ready to dive in. [**Time to introduce the best features of all: branches and issues.**]({{'/04-branches-issues' | relative_url }})
You may also go back to the [detailed table of contents]({{'/index#toc' | relative_url }}).
\ No newline at end of file
......@@ -720,4 +720,6 @@ And that was it!
----
This was a lot of information (and both Git and GitLab offer way more features than what we have seen). With all these tools at our disposal, and the huge degree of freedom that Git actually leaves its users, it is pretty easy to still "do the wrong things". Good practices are required to ensure that our project can live and grow in the best possible way, and [**this is what the next part is about**]({{'/05-good-practices' | relative_url }}).
\ No newline at end of file
This was a lot of information (and both Git and GitLab offer way more features than what we have seen). With all these tools at our disposal, and the huge degree of freedom that Git actually leaves its users, it is pretty easy to still "do the wrong things". Good practices are required to ensure that our project can live and grow in the best possible way, and [**this is what the next part is about**]({{'/05-good-practices' | relative_url }}).
You may also go back to the [detailed table of contents]({{'/index#toc' | relative_url }}).
\ No newline at end of file
......@@ -572,4 +572,6 @@ Please allow me to just write a few ones that I think everyone should know and k
----
We have come quite far in all things related to software development, Git and GitLab. I hope you did not try and read it in a single sitting (if you did, you should really go take a nap). The next part will be way simpler, now that we went through all the tough stuff: it is about [**using Git directly from VSCode**]({{'/06-vscode' | relative_url }}).
\ No newline at end of file
We have come quite far in all things related to software development, Git and GitLab. I hope you did not try and read it in a single sitting (if you did, you should really go take a nap). The next part will be way simpler, now that we went through all the tough stuff: it is about [**using Git directly from VSCode**]({{'/06-vscode' | relative_url }}).
You may also go back to the [detailed table of contents]({{'/index#toc' | relative_url }}).
\ No newline at end of file
......@@ -153,21 +153,21 @@ And it's over. My changes are on the repo.
Alright, fast-forward to monday morning. I am back in my office, and I know changes were made on the repo. Maybe I asked VSCode to fetch on a regular basis, so that it will `git fetch` as soon as I open my working copy. Or maybe I did not, in which case I can just ask nicely by clicking on the three dots:
![](../assets/img/06-vscode/C-web-ide/vscode-sync-05.jpg){: .mx-auto.d-block :}
![](../assets/img/06-vscode/D-fetch-pull/vscode-sync-05.jpg){: .mx-auto.d-block :}
I can then click "Fetch", aaaaaaaand...
![](../assets/img/06-vscode/C-web-ide/vscode-sync-06.jpg){: .mx-auto.d-block :}
![](../assets/img/06-vscode/D-fetch-pull/vscode-sync-06.jpg){: .mx-auto.d-block :}
...as usual.
In both cases, my Git panel now has something to tell me:
![](../assets/img/06-vscode/C-web-ide/vscode-sync-07.jpg){: .mx-auto.d-block :}
![](../assets/img/06-vscode/D-fetch-pull/vscode-sync-07.jpg){: .mx-auto.d-block :}
Basically, there are changes on the repo, and I should sync with it. The downwards arrow indicates that I should "download" changes, from the repo to my working copy. Alright then. "*click*"
![](../assets/img/06-vscode/C-web-ide/vscode-sync-08.jpg){: .mx-auto.d-block :}
![](../assets/img/06-vscode/D-fetch-pull/vscode-sync-08.jpg){: .mx-auto.d-block :}
Actually, in our situation, right now, we will only be pulling, not pushing, but fine, go ahead. (If I am really confident in my knowledge of Git, I may pick the "Don't show again" option. Just remember that "Overconfidence precedes carelessness." Just sayin'.)
......@@ -335,4 +335,6 @@ This illustrates why one should, at least in my opinion, learn to use Git "the h
----
If you are interested in how Git works under the hood, [**the next section of this tutorial is for you.**]({{'/07-internals' | relative_url }})
\ No newline at end of file
If you are interested in how Git works under the hood, [**the next section of this tutorial is for you.**]({{'/07-internals' | relative_url }})
You may also go back to the [detailed table of contents]({{'/index#toc' | relative_url }}).
\ No newline at end of file
......@@ -117,4 +117,6 @@ Also, you can go to your project's page on GitLab, pick a commit, and see every
----
But wait, there's more! [**Here is more extra stuff thay one could be interested in.**]({{'/08-advanced' | relative_url }}) Advanced branch management, hints for your CI pipelines, a bit of troubleshooting, you name it.
\ No newline at end of file
But wait, there's more! [**Here is more extra stuff thay one could be interested in.**]({{'/08-advanced' | relative_url }}) Advanced branch management, hints for your CI pipelines, a bit of troubleshooting, you name it.
You may also go back to the [detailed table of contents]({{'/index#toc' | relative_url }}).
\ No newline at end of file
......@@ -74,7 +74,15 @@ These are the most used options for `git clean`; the rest is [here](https://git-
* In most (in not all) cases, **you should do a dry run *before* the actual cleanup by adding the `-n` option**.
</div>
# Rebasing (how to keep up with a source branch) {#rebase}
# Juggling between branches {#juggling}
The title of this section is admittedly vague, so let us have a brief look at what is covered below:
* *rebasing*, i.e., keeping up with the branch from which our current working branch was created;
* *interactive rebasing*, i.e., reorganizing commits on a local branch (while also rebasing, if we are feeling daring);
* *cherrypicking*, i.e., applying one or several commits on a different branch.
## Rebasing (how to keep up with a source branch) {#rebase}
There are already a lot of very good resources about `git rebase`, probably because it is a command that seems pretty frightening at first, but is actually a very powerful and beautiful command. This is why I will only get to the "why" and the 101 here, before providing you a few links. Also, this is kind of a "pure Git" command, which is not exactly the scope of this tutorial.
......@@ -109,11 +117,43 @@ Oh, also, before we forget: rebasing is great, but for local branches only.
{: .box-error}
**Do not rebase a branch that was pushed to the repo:** if you do so, you will then have to force push, that is, to rewrite the public history of the repo, and this is a very bad practice. Not only is it generally deemed disrespectful and unsafe, but it will also cause you a lot of problems when anyone then tries to interact with the branch from their working copy.
A pretty good reference about rebasing is [the Git SCM page about it](https://git-scm.com/book/en/v2/Git-Branching-Rebasing). It features just the right amount of examples, every time along with the basic commands needed in the corresponding situations. It just suffers from two minor issues:
* At the time of writing, it still uses the kind of deprecated `git checkout` command instead of `git switch` (this is a pretty common thing we already discussed before).
* It assumes that both branches are already up-to-date on your computer, which might not be the case: before running the rebase itself, remember to `pull` the changes on the branch you want to rebase into.
If you want to understand the difference, in a nutshell, between rebasing and merging, there's [a nice page on the Atlassian website](https://www.atlassian.com/git/tutorials/merging-vs-rebasing) about this, as well as countless questions on Stack Overflow, some of which are [very short and to the point](https://stackoverflow.com/questions/804115/when-do-you-use-git-rebase-instead-of-git-merge), others [way more detailed](https://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions).
On the Atlassian page, there is also something about... *interactive* rebasing? What the heck is this? Well, glad you asked.
## Interactive rebasing (how to clean up your mess before pushing) {#irebase}
As we just saw, one of the most common uses (if not *the* typical use-case) of rebasing goes something like this: you are working locally on a branch (say, `feature`) that you created from a source branch (say, `main`), and you want to keep up with what's happening on `main`, so that you will not be drowning in conflicts once you open a MR to `main`. Thus, you rebase on a regular basis (pun not intended, sorry about this). How nice.
But what about filling two needs with one deed? (Not the most common idiom, but as long as I hold the reins, there will be no bird stoning on this website.)
**Assume** that the history of local branch `feature` is kind of a mess. This happens all the time: you need to develop 3 different methods that work together for implementing a given feature, but only see a mistake in method A once it is used by method B, resulting in a bug. You fix the mistake, commit the result, realize that your fix is actually not enough, change method A again, commit again... oh, and between those two commits, you took a few minutes to write the docstring for method C. (Also, if you are anything like me, you were probably a bit salty when writing some of the commit messages, so... why not also change those before you have to push this branch?)
{: .box-success}
**Interactive rebasing** consists in manipulating a series of commits so as to reorder them, edit their messages, delete or squash commits, split a commit into several ones, and so on. It is effectively a way of cleaning up the history of (all or part of) a branch before pushing it.
Speaking of which, of course:
{: .box-error}
**TODO:** Add references
Just like good ol' rebasing, interactive rebasing rewrites history. Hence, **do NOT use interactive rebasing on a branch that was already pushed on the remote**.
The basic course of action is as follows:
* See where you want to start rebasing: you can get the short hash of the commit *just before* the sequence of commits you want to change (e.g., `4f29ed1`), or count the number of commits you want to take into account, in which case the `HEAD~<number_of_commits>` shortcut will come in handy (e.g., `HEAD~5` if you want to change the last 5 commits), or even manipulate the whole branch by using the name of the branch it was branched off (e.g., `main`).
* In the latter case, **make sure that you just rebased!** Otherwise, you will be trying to do two things at the same time (integrating fresh changes from `main` into your branch *and* manipulating your local history), and I absolutely do not recommend trying this.
* Launch the interactive rebase session (`git rebase -i 4f29ed1` or `git rebase -i HEAD~5` or `git rebase -i main` in our examples).
* A text file appears, listing the commits and prefixing them with a short description of the operation to be performed on each commit. Every commit is initially prefixed with keyword `pick` (basically, keep the commit exactly as it is). Below this list is a long comment telling you what keywords can be used. Change the file as you want (you can also move lines up and down to reorder commits).
* Save and exit (hopefully).
I found [this very nice article by Blake DeBoer](https://dev.to/blakedeboer/beginners-guide-to-interactive-rebasing-1ob) about interactive rebasing, based on a not-that-simple example, and 100% performed from the terminal. It is, in my opinion, a way better introduction than the thousands of pages showing you the basics ("I want to rename a commit") and leaving you with that. I hope you enjoy.
# Interactive rebasing (how to clean up your mess before pushing) {#irebase}
Also, you should definitely play with `git rebase -i` on a dummy project. You might very well realize that it is actually pretty simple to use, while also proving incredibly powerful in a lot of cases. This is how you gain confidence in your Git skills, and this is how, in a few weeks or months, your collaborators may thank you for providing them with very clear and organized branches in your MRs.
## Cherrypicking (how to move commits around) {#cherrypick}
{: .box-error}
**TODO:** Cherrypicking
......@@ -329,4 +369,6 @@ The first rule that applies to the current pipeline will take precedence. In the
----
Aaaand you reached the end of this whole mess of a tutorial 🎉
\ No newline at end of file
Aaaand you reached the end of this whole mess of a tutorial 🎉
Just in case, [here is the table of contents]({{'/index#toc' | relative_url }}).
\ No newline at end of file
File suppressed by a .gitattributes entry or the file's encoding is unsupported.
......@@ -19,7 +19,7 @@ On the other hand, I remember all these hours that I spent exploring Git and Git
This is the step-by-step guide that I wish I had been provided when I discovered Git and GitLab. It starts from the very beginning (that is, installing Git and configuring your GitLab account), and holds your hand until you know all the tools you need to efficiently maintain your development projects.
# Table of contents
# Table of contents {#toc}
You can go through this tutorial in order, in which case I advise you to practice at the same time. [**Everything starts here.**]({{'/00-what-why' | relative_url }}) (At some point, you should also make sure that you are aware of [**some basic development practices**]({{'/05-good-practices#practices' | relative_url }}).)
......@@ -87,12 +87,14 @@ If you are already somewhat accustomed to Git and GitLab, you may also directly
* [**Extra: Advanced Git commands and troubleshooting hints**]({{'/08-advanced' | relative_url }})
* [Branch management: `git fetch --all/--prune`]({{'/08-advanced#git-fetch' | relative_url }})
* [Cleaning up your local copy]({{'/08-advanced#cleanup' | relative_url }})
* [Rebasing (how to make history linear without rewriting it)]({{'/08-advanced#rebase' | relative_url }})
* [Interactive rebasing (how to clean up your mess before pushing)]({{'/08-advanced#irebase' | relative_url }})
* [Searching for bugs with `git-bisect`]({{'/08-advanced#git-bisect' | relative_url }})
* [Juggling with branches]({{'/08-advanced#juggling' | relative_url }})
* [Rebasing (how to keep up with a source branch)]({{'/08-advanced#rebase' | relative_url }})
* [Interactive rebasing (how to clean up your mess before pushing)]({{'/08-advanced#irebase' | relative_url }})
* [**(WIP)** Cherrypicking (how to move commits around)]({{'/08-advanced#cherrypick' | relative_url }})
* [**(WIP)** Searching for bugs with `git-bisect`]({{'/08-advanced#git-bisect' | relative_url }})
* [Forks and pull requests]({{'/08-advanced#fork' | relative_url }})
* [CI pipelines: `.gitlab-ci.yml` examples]({{'/08-advanced#gitlab-ci' | relative_url }})
* [How to fix a commit to the wrong branch?]({{'/08-advanced#wrong-branch' | relative_url }})
* [**(WIP)** How to fix a commit to the wrong branch?]({{'/08-advanced#wrong-branch' | relative_url }})
In any case, [please do not hesitate to contact me](mailto:mathias.malandain@inria.fr) for any (constructive) criticism, requests or suggestions you may have. Enjoy!
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment