docs: fix typos, unpublish git tutorial
continuous-integration/drone/push Build is passing
Details
continuous-integration/drone/push Build is passing
Details
This commit is contained in:
parent
6ea381e7c2
commit
dc4a053369
GPG Key ID:
BD7789E705CB8DCA
|
|
@ -45,24 +45,24 @@ now free as in /free beer/ and in /freedom/.
|
|||
#+end_center
|
||||
|
||||
You can find the installer of ALYS for Alter/Ego on the repository
|
||||
linked above as well as a free license file. Regarding its UTAU
|
||||
linked above as well as a free licence file. Regarding its UTAU
|
||||
version, its prototype is already configured with ~oto.ini~ files, but
|
||||
the source file for its Alter/Ego version are stripped of any
|
||||
configuration.
|
||||
|
||||
** What’s New?
|
||||
Therefore, ALYS is now available under three different licences:
|
||||
- The character is now under the free [[https://creativecommons.org/licenses/by-nc/4.0/][CC-BY-NC-4.0 license]]
|
||||
- The character is now under the free [[https://creativecommons.org/licenses/by-nc/4.0/][CC-BY-NC-4.0 licence]]
|
||||
- The UTAU vocal libraries are now under the [[https://www.gnu.org/licenses/gpl-3.0.en.html][GPL-3.0license ]] ([[https://choosealicense.com/licenses/gpl-3.0/][short
|
||||
readable version]])
|
||||
- The Alter/Ego is still under a proprietary license under my name but
|
||||
- The Alter/Ego is still under a proprietary licence under my name, but
|
||||
it is now available free of charge
|
||||
|
||||
Basically, this means you can do whatever you wish with the character
|
||||
as long as it is non-commercial and you credit [[https://www.instagram.com/hsaphirya/][Saphirya]], ALYS’
|
||||
as long as it is non-commercial, and you credit [[https://www.instagram.com/hsaphirya/][Saphirya]], ALYS’
|
||||
designer. The UTAU vocal libraries can be used, modified, and
|
||||
redistributed as much as you wish as long as it stays under the
|
||||
GPL-3.0 license. And you are free to use the Alter/Ego vocal libraries
|
||||
GPL-3.0 licence. And you are free to use the Alter/Ego vocal libraries
|
||||
as much as you wish, but you cannot redistribute or modify them.
|
||||
|
||||
I also decided to release ALYS’ very first, secret, unreleased,
|
||||
|
|
@ -72,7 +72,7 @@ people could hear through ALYS’ first songs. It is released more as a
|
|||
way of preserving the fact it existed rather preserving a usable vocal
|
||||
library. (I don’t even remember what it sounds like.)
|
||||
|
||||
if you have any question, you are free to send me an email at
|
||||
If you have any question, you are free to email me at
|
||||
[[mailto:lucien@phundrak.com][lucien@phundrak.com]] or open an issue on the repository mentioned
|
||||
above.
|
||||
* Conlanging :@conlang:
|
||||
|
|
@ -253,6 +253,12 @@ Maintenant, au travail !
|
|||
:EXPORT_DATE: 2020-11-28
|
||||
:export_hugo_menu: :menu "main"
|
||||
:END:
|
||||
/Edit on October 28th 2023:/ This article was written on November 28th
|
||||
2020, almost three years ago. Since then, I have noticed issues with
|
||||
the current implementation of my dynamic C array, as noted by some
|
||||
readers in the comments below. I will probably rewrite a new dynamic
|
||||
array in C some time in the future addressing these issues.
|
||||
|
||||
Although C is a very, very popular language, it is also known to be
|
||||
quite tiny: memory is handled manually, and much of what is available
|
||||
in its standard library is a given in all other languages. But C being
|
||||
|
|
@ -428,11 +434,11 @@ to take new data from the user. But first, let me explain a bit how
|
|||
this dynamic array which I call vector works in C.
|
||||
|
||||
As you saw earlier, a vector is initialized with a fixed amount of
|
||||
memory allocated to the vector so people can store their data in these
|
||||
arrays. Now, imagine you have an array of four elements and you wish
|
||||
to add one more, what to do? You can reallocate your array with
|
||||
memory allocated to the vector, so people can store their data in
|
||||
these arrays. Now, imagine you have an array of four elements, and you
|
||||
wish to add one more, what to do? You can reallocate your array with
|
||||
~realloc~ with one more slot for your element, so now you have an array
|
||||
for five elements with your four original elements an a free slot for
|
||||
for five elements with your four original elements and a free slot for
|
||||
your fifth. Cool, now you can add new elements as you need them!
|
||||
|
||||
Except that if you want to add some tens of thousands of new elements,
|
||||
|
|
@ -446,7 +452,7 @@ then a sixteen-slots array. And in a couple more calls to ~realloc~,
|
|||
we’ll quickly reach our tens of thousands slots array, way faster than
|
||||
by incrementing its capacity one by one.
|
||||
|
||||
/“But, we’ll end up with a lot of unused memory if we need just one more element than 2^{16} elements! We don’t need a 2^{17} elements array for 2^{16}+1 elements!”/
|
||||
/“But, we’ll end up with a lot of unused memory if we need just one more element than 2^{16} elements! We don’t need a 2^{17} elements array for 2^{16}+1 elements!”/
|
||||
|
||||
You’re completely right, but that’s a tradeoff. Would you rather have
|
||||
a slow but memory-efficient program, or a fast but memory-hungry
|
||||
|
|
@ -466,7 +472,7 @@ static void vec_realloc(Vector *const self) NONNULL;
|
|||
|
||||
Its implementation is rather simple: double its capacity, and
|
||||
reallocate its array twice its previous size. Of course, there is an
|
||||
assertion on whether the arrays has been correctly reallocated to
|
||||
assertion on whether the arrays have been correctly reallocated to
|
||||
ensure memory safety.
|
||||
#+NAME: vector-vec_realloc-c
|
||||
#+BEGIN_SRC c
|
||||
|
|
@ -509,7 +515,7 @@ And this is it! There may be a function added later that will allow
|
|||
the insertion of a new value in any valid position between the first
|
||||
and last position of an array (not counting the unused slots of said
|
||||
array), and if I implement this it will imply a reimplementation of
|
||||
~vec_push~ so that ~vec_push~ relies of this potential new ~vec_insert~.
|
||||
~vec_push~ so that ~vec_push~ relies on this potential new ~vec_insert~.
|
||||
|
||||
*** Retrieving Data
|
||||
Two functions are available when retrieving data: ~vec_safe_at~ which
|
||||
|
|
@ -569,7 +575,7 @@ void *vec_last(Vector const *const self)
|
|||
}
|
||||
#+END_SRC
|
||||
|
||||
For the sake of the Object Oriented Programming paradigm, two
|
||||
For the sake of the Object-Oriented Programming paradigm, two
|
||||
functions were also declared in order to retrieve some data that could
|
||||
otherwise be easily accessible:
|
||||
#+NAME: vector-vec_length_capacity-h
|
||||
|
|
@ -649,7 +655,7 @@ static void vec_maybe_delete_element(Vector const *self,
|
|||
Its implementation is quite simple: if a destructor exists, then the
|
||||
element at the requested index will be destroyed through this
|
||||
destructor. Otherwise, nothing is done with the destructor, hence the
|
||||
name of the function ~vec_maybe_delete_element~. However it should be
|
||||
name of the function ~vec_maybe_delete_element~. However, it should be
|
||||
noted that the element will be freed from memory, so if the user needs
|
||||
it before popping it, they need to retrieve it with something like
|
||||
~vec_at~ and store it elsewhere.
|
||||
|
|
@ -683,7 +689,7 @@ void vec_pop_at(Vector *const t_self, size_t const t_index)
|
|||
}
|
||||
#+END_SRC
|
||||
|
||||
A check is performed at the beninning of the function: that the
|
||||
A check is performed at the beginning of the function: that the
|
||||
element we want to pop actually exists. If it does not, the function
|
||||
does nothing, otherwise the function deletes the element if needed.
|
||||
The call to ~vec_maybe_delete_element~ will free the requested element.
|
||||
|
|
@ -826,7 +832,7 @@ the ones that stand out the most for me.
|
|||
During the last couple of years, LSP has given text editors incredible
|
||||
capabilities, giving them IDE-like features relatively easily. Aside
|
||||
from Elisp development, most of the code I write is now done with the
|
||||
help of an LSP server, running along Emacs and analyzing my code,
|
||||
help of an LSP server, running along Emacs and analysing my code,
|
||||
suggesting and performing changes and actions for me.
|
||||
|
||||
Several integrations of LSP exist for Emacs, such as [[https://emacs-lsp.github.io/lsp-mode/][LSP Mode]], [[https://github.com/joaotavora/eglot][Eglot]],
|
||||
|
|
@ -872,9 +878,9 @@ Tree-Sitter supports the current major modes :
|
|||
- ~typescript-ts-mode~
|
||||
|
||||
Tree-Sitter also holds for now a special status in the new ~emacs-29~
|
||||
branch since new features can still be added to it, as its merging
|
||||
with the master branch is still recent. So we might see the list of
|
||||
major modes for Emacs get a bit longer yet, especially considering
|
||||
branch since new features can still be added to it, as its merge with
|
||||
the master branch is still recent. So we might see the list of major
|
||||
modes for Emacs get a bit longer yet, especially considering
|
||||
Tree-Sitter tries to make adding new languages relatively easy.
|
||||
|
||||
If you can’t wait to test Tree-Sitter, there is already [[https://emacs-tree-sitter.github.io/][another package]]
|
||||
|
|
@ -1087,7 +1093,7 @@ post if you are interested in how I got there.
|
|||
|
||||
**** Update 2021-11-22
|
||||
I’ve put the code presented here as a complete package. You can find
|
||||
it in [[https://labs.phundrak.com/phundrak/org-unique-id][this repository]] or in its [[https://github.com/Phundrak/org-unique-id][Github mirror]] (be aware the latter may
|
||||
it in [[https://labs.phundrak.com/phundrak/org-unique-id][this repository]] or in its [[https://github.com/Phundrak/org-unique-id][GitHub mirror]] (be aware the latter may
|
||||
not be as up-to-date as the former is. Installation instructions are
|
||||
in the README.
|
||||
|
||||
|
|
@ -1167,11 +1173,11 @@ removed from ~<head>~):
|
|||
</html>
|
||||
#+END_SRC
|
||||
|
||||
As you can see, all the anchors are in the fomat of ~org[a-f0-9]{7}~.
|
||||
As you can see, all the anchors are in the format of ~org[a-f0-9]{7}~.
|
||||
First, this is not really meaningful if you want to read the anchor
|
||||
and guess where it will lead you. But secondly, these anchors will
|
||||
change each time you export your Org file to HTML. If I want to share
|
||||
a URL to my website and to a specific heading,… well I can’t, it will
|
||||
a URL to my website and to a specific heading, … well I can’t, it will
|
||||
change the next time I update the document. And I don’t want to have
|
||||
to set a ~CUSTOM_ID~ property for each one of my headings manually. So,
|
||||
what to do?
|
||||
|
|
@ -1183,9 +1189,9 @@ remedy that (it’s a great read, go take a look). And it worked, and
|
|||
for some time I used their code in my Emacs configuration file in
|
||||
order to generate unique custom IDs for my Org headers. Basically what
|
||||
the code does is it detects if ~auto-id:t~ is set in an ~#+OPTIONS~
|
||||
header. If it is, then it will iterate over all of the Org headers,
|
||||
and for each one of them it will insert a ~CUSTOM_ID~, which is made
|
||||
from a UUID generated by Emacs. And tada! we get for each header a
|
||||
header. If it is, then it will iterate over all the Org headers, and
|
||||
for each one of them it will insert a ~CUSTOM_ID~, which is made from a
|
||||
UUID generated by Emacs. And tadah! we get for each header a
|
||||
~h-[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}~ custom
|
||||
ID that won’t change next time we export our Org file to HTML when we
|
||||
save our file, and only for headings which don’t already have a
|
||||
|
|
@ -1194,8 +1200,8 @@ save our file, and only for headings which don’t already have a
|
|||
Except…
|
||||
|
||||
*** These headers are not meaningful
|
||||
Ok, alright, that’s still a huge step forward, we don’t have to type
|
||||
any ~CUSTOM_ID~ property manually anymore, it’s done automatically for
|
||||
OK, alright, that’s still a huge step forward, we don’t have to type
|
||||
any ~CUSTOM_ID~ property manually any more, it’s done automatically for
|
||||
us. But, when I send someone a link like
|
||||
~https://langue.phundrak.com/eittland#h-76fc0b91-e41c-42ad-8652-bba029632333~,
|
||||
the first reaction to this URL is often something along the lines of
|
||||
|
|
@ -1203,7 +1209,8 @@ the first reaction to this URL is often something along the lines of
|
|||
comes to the anchor. How am I supposed to guess it links to the
|
||||
description of the vowels of the Eittlandic language? (That’s a
|
||||
constructed language I’m working on, you won’t find anything about it
|
||||
outside my website.)
|
||||
outside my website. Also, this link is dead now, it got simplified
|
||||
thanks to Vuepres.)
|
||||
|
||||
So, I went back to my configuration file for Emacs, and through some
|
||||
trial and error, I finally found a way to get a consistent custom ID
|
||||
|
|
@ -1343,751 +1350,7 @@ ID on each save, regardless of whether a custom ID already exists or
|
|||
not, but it’s at the risk an ID manually set will get overwritten.
|
||||
|
||||
* Linux :@linux:
|
||||
** [Fr] Tutoriel Git et Github :linux:git:tutorial:tutoriel:
|
||||
:PROPERTIES:
|
||||
:EXPORT_FILE_NAME: tutoriel-git-et-github
|
||||
:EXPORT_DATE: 2020-06-05
|
||||
:export_hugo_menu: :menu "main"
|
||||
:END:
|
||||
#+TOC: headlines 1 local
|
||||
|
||||
*** Git ? Qu'est-ce donc ?
|
||||
Git est un logiciel de version de fichiers permettant de garder une
|
||||
trace de toutes les modifications apportées au fichiers suivis dans un
|
||||
répertoire (un dépôt) et ses sous-répertoires –sous couvert qu’ils
|
||||
n’aient pas été ignorés explicitement. Il permet également de
|
||||
conserver plusieurs versions parallèles du projet, comme par exemple
|
||||
une version stable et une version de développement, et permet l’ajout
|
||||
de modifications d’une de ces versions parallèles à une autre via des
|
||||
fusions partielles ou totales de branches, avec une automatisation des
|
||||
fusions de fichiers lorsqu’il n’y a pas de conflit entre ces derniers.
|
||||
|
||||
Avant de continuer, sache que je suis bilingue français-sarcasme, si
|
||||
tu es du genre à t’énerver pour un rien, cette page est à haut risque
|
||||
pour toi.
|
||||
|
||||
Toujours là ? Tu auras été prévenu·e.
|
||||
|
||||
*** Ça a l’air cool, comment ça s’obtient ?
|
||||
**** Et surtout, comment ça s’installe ?
|
||||
Très bonne question Kevin. Tout d’abord, il faut t’assurer que git
|
||||
soit installé sur ton système et utilisable depuis le terminal. Sous
|
||||
GNU/Linux, tu peux l’installer via ton gestionnaire de paquet, ce qui
|
||||
rendra la commande accessible directement depuis le terminal. Tu auras
|
||||
sans doute besoin de préfixer la commande avec ~sudo~. Si tu n’as pas
|
||||
les droits pour utiliser ~sudo~, demande à celui qui a les droits (ton
|
||||
administrateur système ou ton papa (j’avais prévenu que je n’allais
|
||||
pas être sympa dans ce tutoriel)).
|
||||
#+BEGIN_SRC sh
|
||||
$ apt install git # Debian, Ubuntu et les distros basées dessus
|
||||
$ yum install git # CentOS
|
||||
$ dnf -y install git # Fedora
|
||||
$ pacman -S git # ArchLinux et les distros basées dessus
|
||||
$ emerge --ask --verbose dec-vcs/git # Gentoo
|
||||
#+END_SRC
|
||||
|
||||
#+CAPTION: >install gentoo
|
||||
[[./img/install-gentoo.jpg]]
|
||||
|
||||
Si tu n’es pas sous GNU/Linux mais que tu as au moins le goût d’être
|
||||
sous un OS de type Unix, tu peux exécuter la commande correspondante à
|
||||
ton OS suivant :
|
||||
#+BEGIN_SRC sh
|
||||
$ pkg install git # FreeBSD
|
||||
$ brew install git # macOS avec brew
|
||||
$ port install git +svn +doc +bash_completion +gitweb # macOS avec MacPorts
|
||||
#+END_SRC
|
||||
|
||||
Si tu es sous Windows, soit tu utilises le WSL (Windows Subsystem for
|
||||
Linux), soit… bonne chance. Toutes les commandes seront en syntaxe
|
||||
Unix dans ce tutoriel, mais si tu as bien deux neurones, tu devrais
|
||||
pouvoir tout de même suivre le tutoriel.
|
||||
|
||||
**** Ok c’est bon, et il y a une configuration à faire ?
|
||||
Tu peux configurer Git si tu le souhaites, oui. En général, il est
|
||||
recommandé de paramétrer au moins son nom et son e-mail. Tu peux les
|
||||
paramétrer via la ligne de commande :
|
||||
#+BEGIN_SRC sh
|
||||
$ git config --global user.name "Kévin Masturbin"
|
||||
$ git config --global user.email "kevin.du.neuftrwa@hotmail.com"
|
||||
#+END_SRC
|
||||
|
||||
Tu peux aussi éditer le fichier =~/.gitconfig= comme suit :
|
||||
#+BEGIN_SRC toml
|
||||
[user]
|
||||
email = ton@email.truc
|
||||
name = Ton nom
|
||||
#+END_SRC
|
||||
|
||||
Cela permettra d’associer ton nom et ton adresse mail à tes commits.
|
||||
Par défaut, ceux qui sont enregistrés avec ton compte utilisateur de
|
||||
ton PC sont mis par défaut dans ces paramètres, mais on met quasiment
|
||||
tous un nom à la con quand on le créé. Et ça permet d’avoir les même
|
||||
paramètres si tu es sur un autre ordinateur.
|
||||
|
||||
Il y a encore pas mal de paramètres que tu peux gérer avec ce fichier,
|
||||
je reparlerai de certains plus tard, mais pour le reste, la
|
||||
documentation en ligne sur ~gitconfig~ ne manque pas.
|
||||
|
||||
*** Ok très bien, comment on l’utilise maintenant ?
|
||||
Du calme Jean-Kevin, ralentis un peu. Comme le dit ce vieux dicton
|
||||
Chinois :
|
||||
#+begin_quote
|
||||
Celui qui marche trop vite…… marche…………… trop… vite…? C’est compliqué les
|
||||
dictons chinois…
|
||||
#+end_quote
|
||||
|
||||
De toutes façons, ce dicton est une contrefaçon, donc la qualité de la
|
||||
citation n’est pas extraordinaire. Bref.
|
||||
|
||||
**** Je commence comment ?
|
||||
Si tu souhaites créer un dépôt git, rien de plus simple : créé ton
|
||||
répertoire dans lequel tu travailleras, et déplace-y-toi. Ensuite, tu
|
||||
pourra initialiser ton dépôt via la commande ~git init~.
|
||||
#+BEGIN_SRC text
|
||||
$ mkdir monsuperprojet
|
||||
$ cd monsuperprojet
|
||||
$ git init
|
||||
Initialized empty Git repository in /tmp/monsuperprojet/.git/
|
||||
#+END_SRC
|
||||
|
||||
Si tu obtiens à peu près le même message après la dernière commande,
|
||||
félicitations ! Tu viens de créer ton premier dépôt git. En
|
||||
l’occurrence, j’ai créé mon dépôt dans ~/tmp~, mais toi tu peux voir un
|
||||
truc du genre ~/home/corentin/monsuperprojet~ à la place. Tu peux
|
||||
vérifier que tout va bien en rentrant la commande ~git status~.
|
||||
#+BEGIN_SRC text
|
||||
$ git status
|
||||
On branch master
|
||||
|
||||
No commits yet
|
||||
|
||||
nothing to commit (create/copy files and use "git add" to track)
|
||||
#+END_SRC
|
||||
|
||||
Parfait ! Ah, et ne met rien d’important dans ~/tmp~, ce dossier est
|
||||
réinitialisé à chaque redémarrage de ta machine. Ou alors, met-y
|
||||
uniquement des fichiers que tu ne souhaites avoir que temporairement
|
||||
sur ta machine (comme ce meme que tu télécharges depuis Reddit pour le
|
||||
reposter sur Discord).
|
||||
|
||||
**** Et pour rajouter des fichiers ?
|
||||
Maintenant tu peux commencer à travailler sur ton projet. Mais tout
|
||||
d’abord, on va voir ce qu’il se passe si jamais on créé un fichier
|
||||
dans le dépôt. Créé un fichier ~main.c~ dans lequel tu vas entrer ce
|
||||
code :
|
||||
#+BEGIN_SRC c
|
||||
#include <stdio.h>
|
||||
|
||||
int main(int ac, char* av[]) {
|
||||
printf("Hello World!\n");
|
||||
return 0;
|
||||
}
|
||||
#+END_SRC
|
||||
|
||||
Bref, si tu exécutes à nouveau git status, tu obtients cette sortie :
|
||||
#+BEGIN_SRC text
|
||||
$ git status
|
||||
On branch master
|
||||
|
||||
No commits yet
|
||||
|
||||
Untracked files:
|
||||
(use "git add <file>..." to include in what will be committed)
|
||||
|
||||
main.c
|
||||
|
||||
nothing added to commit but untracked files present (use "git add" to track)
|
||||
#+END_SRC
|
||||
|
||||
Tu commences à comprendre un peu le bail ? Git vient de détecter qu’un
|
||||
nouveau fichier a été créé qu’il ne connaissait pas avant. Suivons ses
|
||||
bon conseils et ajoutons le fichier au dépôt.
|
||||
#+BEGIN_SRC text
|
||||
$ git add main.c
|
||||
$ git status
|
||||
On branch master
|
||||
|
||||
No commits yet
|
||||
|
||||
Changes to be committed:
|
||||
(use "git rm --cached <file>..." to unstage)
|
||||
|
||||
new file: main.c
|
||||
#+END_SRC
|
||||
|
||||
Super, maintenant git va surveiller les changements du fichier, mais
|
||||
attention, il n’a pas encore enregistré son état. Pour l’instant il
|
||||
sait juste que le fichier est là, dans un certain état, mais rien ne
|
||||
garanti encore qu’on pourra retrouver cet état plus tard. On appelle
|
||||
ça le /staging/. Pour ce faire, il faut créer ce qu’on appelle un
|
||||
/commit/. En gros, il s’agit d’un enregistrement des modifications
|
||||
apportées à un ou plusieurs fichiers (dans leur globalité ou
|
||||
partiellement, on verra ça plus tard), le tout avec un commentaire.
|
||||
#+BEGIN_SRC text
|
||||
$ git commit -m "Un petit pas pour moi, un grand pas pour mon projet"
|
||||
[master (root-commit) 89139ef] Un petit pas pour moi, un grand pas pour mon projet
|
||||
1 file changed, 6 insertions(+)
|
||||
create mode 100644 main.c
|
||||
#+END_SRC
|
||||
|
||||
Parfait ! Certains éléments peuvent être un peu différent chez toi,
|
||||
comme par exemple la référence du commit juste avant le message. Ça,
|
||||
c’est un truc qui est géré automatiquement par git. Et voilà, on a
|
||||
l’état de notre répertoire qui est enregistré et qui sera disponible
|
||||
plus tard. Maintenant, tu sais comment enregistrer des état de ton
|
||||
dépôt via les commits.
|
||||
|
||||
**** Cool, mais j’ai accidentellement mis un fichier en staging
|
||||
Si jamais tu as un staging que tu veux annuler, tu peux utiliser la
|
||||
commande ~git reset HEAD nomdufichier~ (ou plusieurs noms de fichiers)
|
||||
pour annuler le staging. Une fois le fichier qui n’est plus dans ton
|
||||
staging, tu peux même annuler toutes les modifications que tu as
|
||||
apporté au fichier depuis ton dernier commit avec la commande ~git
|
||||
checkout -- nomdufichier~, et tu peux aussi mettre plusieurs noms de
|
||||
fichiers. Par exemple, si j’ai modifié mon ~main.c~ en modifiant ainsi
|
||||
les arguments du ~main()~ :
|
||||
#+BEGIN_SRC c
|
||||
#include <stdio.h>
|
||||
|
||||
int main(void) {
|
||||
printf("Hello World!\n");
|
||||
return 0;
|
||||
}
|
||||
#+END_SRC
|
||||
|
||||
Je peux annuler tout ça via ces commandes :
|
||||
#+BEGIN_SRC text
|
||||
$ git reset HEAD main.c
|
||||
Unstaged changes after reset:
|
||||
M main.c
|
||||
$ git checkout -- main.c
|
||||
$ git status
|
||||
On branch master
|
||||
nothing to commit, working tree clean
|
||||
#+END_SRC
|
||||
|
||||
Si je fait un ~cat main.c~, je vois qu’il est revenu à son état initial.
|
||||
|
||||
Et petite remarque concernant les arguments de la fonction ~main~ en C :
|
||||
on peut leur donner le nom que l’on souhaite (personellement j’aime
|
||||
bien parfois metre ~ac~ et ~av~ au lieu de ~argc~ et ~argv~), ça ne changera
|
||||
strictement rien au comportement du code. Et si l’on ne souhaite pas
|
||||
utiliser les arguments reçus par le ~main~, on peut simplement déclarer
|
||||
la fonction main comme ~main(void)~. Au moins, c’est clair pour le
|
||||
compilateur et le lecteur du code : on s’en fiche des arguments du
|
||||
~main~.
|
||||
|
||||
Par contre, chose importante : mettre void en arguments du main est du
|
||||
C, *et ce n’est pas valide en C++*. /Le C++ n’est pas du C avec des
|
||||
fonctionnalités en plus/.
|
||||
|
||||
**** En fait, j’ai juste oublié un truc dans mon commit précédent
|
||||
Si jamais tu veux à la place ajouter la modification d’un fichier au
|
||||
dernier commit (mettons, tu as oublié d’ajouter également un fichier
|
||||
texte), tu peux utiliser l’option ~--amend~ lors du commit du fichier
|
||||
oublié.
|
||||
#+BEGIN_SRC text
|
||||
$ git add main.c # J’ai refait les modifications annulées plus tôt
|
||||
$ git commit -m "second commit"
|
||||
[master 97f698a] second commit
|
||||
1 file changed, 1 insertion(+), 1 deletion(-)
|
||||
$ echo "C’est un super projet !" > projet.txt
|
||||
$ git add projet.txt
|
||||
$ git commit --amend -m "second commit + oubli"
|
||||
[master 9aff4c0] second commit + oubli
|
||||
Date: Fri Oct 5 11:10:56 2018 +0200
|
||||
2 files changed, 2 insertions(+), 1 deletion(-)
|
||||
create mode 100644 projet.txt
|
||||
#+END_SRC
|
||||
|
||||
En gros, le commit que tu viens de faire a remplacé le précédent en
|
||||
conservant les informations du commit précédent, mis à part son
|
||||
commentaire. Si tu ne met pas l’option ~-m "ton texte"~ lors de
|
||||
l’amendement du commit, ton éditeur texte par défaut va s’ouvrir pour
|
||||
que tu puisses modifier le texte du commit précédent si tu le
|
||||
souhaite. Si jamais vim s’ouvre et que tu n’as aucune idée de comment
|
||||
sortir de cet enfant du démon, tu as juste à appuyer sur la touche
|
||||
Échap (au cas où), puis à taper ~:wq~ (~w~ pour écrire le fichier, ~q~ pour
|
||||
quitter), puis tu appuie sur la touche Entrée. Si tu as Nano qui s’est
|
||||
ouvert, alors il faut taper Ctrl-X. Dans tous les cas, tu aurais dû
|
||||
utiliser Emacs.
|
||||
|
||||
**** Euh, j’ai oublié ce que j’ai changé lors du dernier commit
|
||||
Pas de panique ! Tu peux entrer la commande ~git diff~ afin de voir ce
|
||||
que tout ce que tu as modifié lors de ton dernier commit. Et si tu ne
|
||||
souhaite voir les modifications que d’un certain fichier, tu peux
|
||||
ajouter le nom de ton fichier à la fin de la commande.
|
||||
#+BEGIN_SRC text
|
||||
$ echo "C’est un super projet !" > projet.txt
|
||||
$ git diff
|
||||
diff --git a/projet.txt b/projet.txt
|
||||
index 03b0f20..b93413f 100644
|
||||
--- a/projet.txt
|
||||
+++ b/projet.txt
|
||||
@@ -1 +1 @@
|
||||
-projet
|
||||
+C’est un super projet !
|
||||
#+END_SRC
|
||||
|
||||
Tu peux également voir les différences de fichiers entre deux commits
|
||||
en entrant leur référence. Pour avoir la référence, tu peux rentrer la
|
||||
commande ~git log~ pour avoir un petit historique des commits.
|
||||
#+BEGIN_SRC text
|
||||
$ git log
|
||||
commit 4380d8717261644b81a1858920406645cf409028 (HEAD -> master)
|
||||
Author: Phuntsok Drak-pa <phundrak@phundrak.fr>
|
||||
Date: Fri Oct 5 11:59:40 2018 +0200
|
||||
|
||||
new commit
|
||||
|
||||
commit 59c21c6aa7e3ec7edd229f81b87becbc7ec13596
|
||||
Author: Phuntsok Drak-pa <phundrak@phundrak.fr>
|
||||
Date: Fri Oct 5 11:10:56 2018 +0200
|
||||
|
||||
nouveau texte
|
||||
|
||||
commit 89139ef233d07a64d3025de47f8b6e8ce7470318
|
||||
Author: Phuntsok Drak-pa <phundrak@phundrak.fr>
|
||||
Date: Fri Oct 5 10:56:58 2018 +0200
|
||||
|
||||
Un petit pas pour moi, un grand pas pour mon projet
|
||||
#+END_SRC
|
||||
|
||||
Bon, c’est un peu long et un peu trop d’infos d’un coup, généralement
|
||||
je préfère taper ~git log --oneline --graph --decorate~ afin d’avoir un
|
||||
affichage comme suit :
|
||||
#+BEGIN_SRC text
|
||||
$ git log --oneline --graph --decorate
|
||||
,* 4380d87 (HEAD -> master) new commit
|
||||
,* 59c21c6 nouveau texte
|
||||
,* 89139ef Un petit pas pour moi, un grand pas pour mon projet
|
||||
#+END_SRC
|
||||
|
||||
Plus propre, non ? Et les références sont plus courtes, ce qui est
|
||||
plus agréable à taper. Allez, comparons les deux derniers commits.
|
||||
#+BEGIN_SRC text
|
||||
$ git add .
|
||||
$ git commit -m "new commit"
|
||||
$ git log --oneline --graph --decorate
|
||||
,* 4380d87 (HEAD -> master) new commit
|
||||
,* 59c21c6 nouveau texte
|
||||
,* 89139ef Un petit pas pour moi, un grand pas pour mon projet
|
||||
$ git diff 59c21c6 4380d87
|
||||
diff --git a/projet.txt b/projet.txt
|
||||
index 03b0f20..b93413f 100644
|
||||
--- a/projet.txt
|
||||
+++ b/projet.txt
|
||||
@@ -1 +1 @@
|
||||
-projet
|
||||
+C’est un super projet !
|
||||
#+END_SRC
|
||||
|
||||
**** Il y a des fichiers dont je me fiche dans mon dépôt
|
||||
Dans ce cas, il est grand temps de te présenter le fichier ~.gitignore~.
|
||||
Comme son nom l’indique, il permet au dépôt d’ignorer des fichiers
|
||||
selon ce que tu lui indiqueras. Par exemple, si tu veux ignorer tous
|
||||
les fichiers qui se terminent en ~.out~ (ou ~.exe~ sous Windows), tu peux
|
||||
éditer (ou créer) ton ~.gitignore~ et entrer ces lignes :
|
||||
#+BEGIN_SRC gitignore
|
||||
,*.out
|
||||
,*.exe
|
||||
#+END_SRC
|
||||
|
||||
Maintenant, si tu créés un fichier en ~.out~ ou ~.exe~, il sera
|
||||
complètement ignoré par git et ne sera pas stocké dans l’historique
|
||||
des versions. Il s’agit de ce qu’on appelle du globbing. En gros,
|
||||
l’étoile indique que tu t’en fiches de ce qu’il y a devant ~.out~ ou
|
||||
~.exe~ dans cet exemple, si quelque chose se termine par ça, c’est
|
||||
ignoré. Pour ignorer quelque chose dans un dossier, tu pourrais avoir
|
||||
quelque chose du genre ~mondossier/*~ et POUF, tous les fichiers de
|
||||
~mondossier/~ sont ignorés. En gros, le globbing va fonctionner comme le
|
||||
globbing de ton shell (Bash, Zsh, Fish,…)
|
||||
|
||||
Par exemple, [[https://labs.phundrak.com/phundrak/langue-phundrak-com/commit/f8ec1936f839e9e95a6badf4480589f5bc9d00a0][voici un dépôt]] un peu plus complexe que ce qu’on est en
|
||||
train de faire (figé lors d’un commit fixé). Tu peux voir dans mon
|
||||
~.gitignore~ qu’il y a pas mal d’extensions de fichiers qui sont
|
||||
ignorées, mais j’ai aussi ~_minted*~ et ~auto-generated*~ qui sont des
|
||||
dossiers ignorés, et pas juste leur contenu qui est ignoré (l’étoile
|
||||
est là pour ignorer tous les dossiers dont le nom commence par ce qui
|
||||
précède l’étoile). J’ai aussi ignoré le dossier ~.dart_tool/~ qui lui
|
||||
pour le coup n’a pas de globbing, ainsi que le fichier ~pubspec.lock~,
|
||||
sans globbing non plus.
|
||||
|
||||
**** On est plusieurs dessus en fait…
|
||||
Pas de panique ! Git a été créé pour ça, et il dispose d’une
|
||||
fonctionnalité de branchage permettant d’avoir plusieurs versions
|
||||
coexistantes d’un même fichier. Cela peut être très utile pour avoir
|
||||
soit plusieurs personnes travaillant sur un même projet, soit pour une
|
||||
même personne travaillant sur plusieurs fonctionnalités différentes,
|
||||
soit les deux. Ainsi, on a plusieurs version indépendantes que l’on
|
||||
pourra fusionner plus tard.
|
||||
|
||||
Par défaut une branche est créée lors de la création d’un dépôt qui
|
||||
s’appelle ~master~. Pour créer une nouvelle branche, on peut donc
|
||||
utiliser la commande ~git checkout -b nomdelanouvellebranche~.
|
||||
#+BEGIN_SRC text
|
||||
$ git checkout -b nouvelle-branche
|
||||
Switched to a new branch 'nouvelle-branche'
|
||||
#+END_SRC
|
||||
|
||||
À partir d’ici, toute modification apportée aux fichiers du dépôt
|
||||
n’affecteront que la branche courante, ~nouvelle-branche~ donc, et les
|
||||
fichiers de la branche ~master~ resteront inchangés. Si jamais tu veux
|
||||
retourner pour une quelconque raison sur la branche ~master~, il te
|
||||
suffira d’utiliser la commande ~git checkout master~.
|
||||
|
||||
Si tu souhaites avoir une liste des branches du dépôt, tu peux taper
|
||||
~git branch --list~. La branche active sera marquée d’une étoile à côté
|
||||
de son nom.
|
||||
#+BEGIN_SRC text
|
||||
$ git branch --list
|
||||
master
|
||||
,* nouvelle-branche
|
||||
#+END_SRC
|
||||
|
||||
**** J’ai accidentellement modifié des fichiers sur la mauvaise branche, mais je n’ai pas encore fait de commits.
|
||||
Tout va bien alors ! Tu vas simplement exécuter cette commande :
|
||||
#+BEGIN_SRC text
|
||||
$ git stash
|
||||
#+END_SRC
|
||||
|
||||
Ça va déplacer toutes tes modifications que tu n’as pas encore commit
|
||||
dans le stash, qui est une sorte d’emplacement temporaire, en dehors
|
||||
des branches. Normalement, ça va réinitialiser tes fichiers tels
|
||||
qu’ils étaient lors du dernier commit. Maintenant, change la branche
|
||||
sur laquelle tu travailles, par exemple tu si tu es sur la branche
|
||||
~kevin~, tu exécutes ceci :
|
||||
#+BEGIN_SRC text
|
||||
$ git checkout kevin
|
||||
#+END_SRC
|
||||
|
||||
Tes modifications sont toujours dans ton stack, et pour les restaurer,
|
||||
tu n’as plus qu’à exécuter
|
||||
#+BEGIN_SRC text
|
||||
$ git stash pop
|
||||
#+END_SRC
|
||||
|
||||
Et voilà, tu viens de déplacer tes modifications sur la bonne branche.
|
||||
Pour information, si tu as créé un nouveau fichier ou un nouveau
|
||||
dossier avec des fichiers, ils ne seront pas déplacés dans le stash,
|
||||
mais ils ne seront pas supprimés lors de la première commande. Tu
|
||||
auras juste à les commit sur ta nouvelle branche pour qu’ils cessent
|
||||
de se déplacer de branche en branche.
|
||||
|
||||
**** Du coup, Mathilde a bien avancé sur son code, et moi aussi, chacun sur notre branche. On fait comment maintenant ?
|
||||
Au bout d’un moment, tu vas sans doute vouloir fusionner deux
|
||||
branches, par exemple tu as finis de développer une nouvelle
|
||||
fonctionnalité sur la branche ~nouvelle-branche~ et tu souhaites
|
||||
l’ajouter à la version stable de ton code qui se situe sur ~master~.
|
||||
Dans ce cas, ce que tu peux faire, c’est retourner sur ta branche
|
||||
~master~, puis tu vas effectuer ce qu’on appelle un merge ; en gros,
|
||||
pour faire simple, tu vas appliquer les modifications de la branche
|
||||
que tu souhaites fusionner avec ta branche ~master~ sur cette dernière.
|
||||
#+BEGIN_SRC text
|
||||
$ git checkout master
|
||||
Switched to branch 'master'
|
||||
$ git merge nouvelle-branche
|
||||
Updating 133c5b6..2668937
|
||||
Fast-forward
|
||||
projet.txt | 1 +
|
||||
1 file changed, 1 insertion(+)
|
||||
create mode 100644 projet.txt
|
||||
#+END_SRC
|
||||
|
||||
Rappelle-toi que la commande ~merge~ ramène les commits de la branche
|
||||
spécifiée vers ta branche active, et pas forcément vers le ~master~. Du
|
||||
coup, si tu est sur une branche ~mathilde~ et que tu effectues un ~git
|
||||
merge leon~, tu vas ramener tous les commits de leon vers la branche
|
||||
mathilde. Ça peut être intéressant à faire si jamais un bug a été
|
||||
corrigé dans une autre branche ou qu’une fonctionnalité a été ajoutée
|
||||
et que tu veux en bénéficier dans ta branche active. N’oublie juste
|
||||
pas de tout bien commit avant de faire ton merge.
|
||||
|
||||
*** J’ai entendu parler de Github…
|
||||
Tu commences à me plaire Enzo ! Github est un site web sur lequel tu
|
||||
peux héberger des projets libres ou open-source (si tu ne connais pas
|
||||
la différence, voici un article pour t’aider à comprendre, et un autre
|
||||
pour la route). C’est en particulier orienté pour les projets gérés
|
||||
par git, ce qui tombe bien car c’est ce qu’on utilise. Cela a pour
|
||||
avantage de pouvoir aisément partager ton code et d’assurer qu’il est
|
||||
bien sauvegardé quelque part d’autre que ton disque dur (un ~rm -rf~ est
|
||||
si vite arrivé). Et surtout, ça peut te permettre de collaborer avec
|
||||
d’autres personnes sur le même projet sans te casser la tête.
|
||||
|
||||
#+begin_quote
|
||||
Git est à Github ce que le porn est à Pornhub.
|
||||
#+end_quote
|
||||
|
||||
J’aimerais tout de même te mettre au courant que Github n’est
|
||||
largement pas le seul site de ce genre à exister. Le concurrent le
|
||||
plus célèbre de Github est [[https://about.gitlab.com/][Gitlab]], et personnellement j’utilise [[https://gitea.io/en-us/][Gitea]].
|
||||
Ces deux derniers peuvent même être hébergés en instances
|
||||
personnelles, comme [[https://labs.phundrak.com/phundrak/langue-phundrak-com/commit/f8ec1936f839e9e95a6badf4480589f5bc9d00a0][ce que je fais avec Gitea]] (qui est beaucoup plus
|
||||
léger que Gitlab, mais avec quelques fonctionnalités en moins), et il
|
||||
existe encore [[https://labs.phundrak.com/phundrak/langue-phundrak-com/commit/f8ec1936f839e9e95a6badf4480589f5bc9d00a0][plein d’autres alternatives]], à toi de trouver les
|
||||
autres.
|
||||
|
||||
*** J’ai téléchargé un projet en zip
|
||||
Ou bien, tu peux télécharger le projet directement via git. Eh oui !
|
||||
git permet de gérer les dépôts dits distants, c’est à dire ceux qui
|
||||
sont hébergés sur un serveur en ligne, comme par exemple sur Github.
|
||||
Pour cela, il te faut te munir du lien vers le dépôt git, et le passer
|
||||
en argument de git clone. Par exemple, si tu veux télécharger de dépôt
|
||||
du petit logiciel de chat en réseau que j’ai codé durant ma L2
|
||||
d’informatique, tu peux exécuter ceci :
|
||||
#+BEGIN_SRC text
|
||||
$ git clone https://github.com/noalien/GL4Dummies.git
|
||||
Cloning into 'GL4Dummies'...
|
||||
remote: Enumerating objects: 682, done.
|
||||
remote: Counting objects: 100% (682/682), done.
|
||||
remote: Compressing objects: 100% (455/455), done.
|
||||
remote: Total 3516 (delta 354), reused 509 (delta 215), pack-reused 2834
|
||||
Receiving objects: 100% (3516/3516), 72.95 MiB | 2.13 MiB/s, done.
|
||||
Resolving deltas: 100% (2019/2019), done.
|
||||
#+END_SRC
|
||||
|
||||
Et c’est bon, tu as accès au répertoire ~GL4Dummies~ et au code source
|
||||
du projet. (Courage aux élèves de Paris 8 qui feront de la
|
||||
programmation graphique !)
|
||||
|
||||
*** Et si je veux créer mon propre dépôt sur Github
|
||||
Dans ce cas là, c’est simple Brigitte. Il faut que tu te créés un
|
||||
compte sur Github, puis tu cliques sur le bouton ~+~ et ~New Repository~.
|
||||
Tu lui donnes le nom que tu souhaites (en l’occurrence je le nomme
|
||||
~temporary-repo~ car je vais le supprimer cinq minutes après l’écriture
|
||||
de ces lignes), et tu cliques sur ~Create Repository~. Tu n’ajoutes rien
|
||||
avant, pas de description, pas de ~.gitignore~, RIEN.
|
||||
|
||||
Et là, magie ! Github indique comment ajouter le dépôt distant à ton
|
||||
dépôt local.
|
||||
#+BEGIN_SRC text
|
||||
$ git remote add origin https://github.com/Phundrak/temporary-repo.git
|
||||
#+END_SRC
|
||||
|
||||
Et voilà, ton dépôt est lié au dépôt distant. Oui, juste comme ça.
|
||||
|
||||
Sinon, si tu souhaites d’abord créer ton dépôt sur Github puis sur ta
|
||||
machine, tu peux aussi très bien le créer sur Github (logique) puis le
|
||||
cloner sur ta machine comme je te l’ai montré avant.
|
||||
|
||||
*** Et du coup, comment je met tout ça en ligne ?
|
||||
Bon ok, ce n’est pas aussi simple que ça. Une fois que tu as lié ton
|
||||
dépôt au dépôt distant, il faudra que tu mettes en ligne tes commits
|
||||
quand tu en auras l’occasion. Pour ce faire, tu n’as qu’à taper ~git
|
||||
push~ ; et la première fois, il faudra que tu indiques à ton dépôt où
|
||||
mettre en ligne précisément dans le dépôt distant, auquel cas tu
|
||||
ajoutes ~-u origin master~ pour cette première fois. Git te demandera
|
||||
donc tes identifiants Github pour pouvoir mettre tout ça en ligne.
|
||||
#+BEGIN_SRC text
|
||||
$ git push -u origin master
|
||||
Username for 'https://github.com': phundrak
|
||||
Password for 'https://phundrak@github.com':
|
||||
Enumerating objects: 10, done.
|
||||
Counting objects: 100% (10/10), done.
|
||||
Delta compression using up to 8 threads
|
||||
Compressing objects: 100% (7/7), done.
|
||||
Writing objects: 100% (10/10), 940 bytes | 313.00 KiB/s, done.
|
||||
Total 10 (delta 0), reused 0 (delta 0)
|
||||
remote:
|
||||
remote: Create a pull request for 'master' on GitHub by visiting:
|
||||
remote: https://github.com/Phundrak/temporary-repo/pull/new/master
|
||||
remote:
|
||||
To https://github.com/Phundrak/temporary-repo.git
|
||||
,* [new branch] master -> master
|
||||
Branch 'master' set up to track remote branch 'master' from 'origin'.
|
||||
#+END_SRC
|
||||
|
||||
Bon, là en nom d’utilisateur il y a le mien, faudra remplacer avec le
|
||||
tiens. Et ouais, ma vitesse de mise en ligne n’est pas fameuse, je
|
||||
suis sur une connexion 3G+ à l’heure où j’écris ces lignes, ne me juge
|
||||
pas. Bref, toujours est-il que je viens de mettre en ligne les
|
||||
fichiers du dépôt sur Github. Pas la peine de chercher le mien sur
|
||||
Github par contre, ça fera un bail que je l’aurai supprimé au moment
|
||||
où tu liras ces lignes.
|
||||
|
||||
Pour info, tu peux éviter d’avoir à taper ton identifiant et ton mot
|
||||
de passe à chaque fois que tu fais un push sur ton dépôt si tu
|
||||
indiques à Github ta clef SSH. Tu auras plus d’informations là (c’est
|
||||
à peu près la même merde pour Gitlab, Gitea et Cie).
|
||||
|
||||
*** Quelqu’un a fait des modifications depuis mon dernier commit, je récupère ça comment ?
|
||||
Pour faire un exemple, je viens de créer un ~README.md~ sur Github
|
||||
directement. Ce type de fichiers est assez standard afin de présenter
|
||||
plus ou moins en détails le dépôt et le projet qui y est lié, et son
|
||||
contenu apparaîtra formaté sur la page du dépôt sur Github s’il est au
|
||||
format ~.md~ (Markdown) ou ~.org~ (org-mode, le Markdown d’Emacs avec
|
||||
lequel est écrit ce tutoriel, et qui est clairement supérieur à
|
||||
Markdown). Mais il n’est pas présent dans mon dépôt local, du coup je
|
||||
vais devoir le récupérer. On va donc entrer git pull.
|
||||
#+BEGIN_SRC text
|
||||
$ git pull
|
||||
remote: Enumerating objects: 4, done.
|
||||
remote: Counting objects: 100% (4/4), done.
|
||||
remote: Compressing objects: 100% (3/3), done.
|
||||
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
|
||||
Unpacking objects: 100% (3/3), done.
|
||||
From https://github.com/Phundrak/temporary-repo
|
||||
4380d87..8bd4896 master -> origin/master
|
||||
Updating 4380d87..8bd4896
|
||||
Fast-forward
|
||||
README.md | 2 ++
|
||||
1 file changed, 2 insertions(+)
|
||||
create mode 100644 README.md
|
||||
#+END_SRC
|
||||
|
||||
*** Je suis en train de travailler sur le même fichier que Ginette
|
||||
Là, c’est un problème qui aurait pu être évité avec l’usage des
|
||||
branches dont je t’avais parlé plus haut, mais visiblement, vous êtes
|
||||
sur la même branche. Pas bien. Dans ce cas-là, met-toi d’accord avec
|
||||
Ginette pour savoir qui fait ses push en premier. Si le choix tombe
|
||||
sur Ginette, ou si elle a imposé sa vision des choses et a fait son
|
||||
push avant toi, Github va râler car tu n’es pas à jour. Dans ce cas ne
|
||||
panique pas, si tu n’as pas fait tes commits, lance la commande ~git
|
||||
stash~ ; ça va sauvegarder tes modifications dans un coin à part et va
|
||||
annuler tes modifications.
|
||||
|
||||
*** Github ne veut pas de mes pushs sur le dépôt de Gilberte, oskour !
|
||||
Du calme Jean-Célestin. Cela veut tout simplement dire que tu n’as
|
||||
tout simplement pas les droits d’écriture sur son dépôt. Du coup, soit
|
||||
tu peux lui demander directement à ce qu’elle te donne les droits
|
||||
d’écriture si elle a confiance en toi, soit tu peux créer un fork puis
|
||||
une pull-request sur Github depuis ton fork où tu auras fait tes
|
||||
modifications.
|
||||
|
||||
*** Fork ? Pull request ? Que font des fourchettes et des pulls dans ce tuto ?
|
||||
Ouhlà Billy, il va falloir remettre les choses au clair. Là il s’agit
|
||||
de quelque chose de spécifique à Github qu’à Git (d’où le fait qu’on
|
||||
en discute dans ce chapitre que le précédent).
|
||||
|
||||
Sur Github, il est possible de copier vers ton profil le dépôt de
|
||||
quelqu’un d’autre dans l’état où il est au moment du fork. Cela inclus
|
||||
les fichiers du ~master~, mais également de toutes les branches du
|
||||
dépôt. Tu peux y penser en terme de super-branche dont tu deviens le
|
||||
propriétaire. Tu peux ainsi travailler comme bon te semble sur le code
|
||||
source sans que son propriétaire ne vienne t’engueuler car tu es en
|
||||
train de polluer sa base de code.
|
||||
|
||||
Si jamais il y a une modification dont tu es particulièrement fier, tu
|
||||
peux la soumettre au propriétaire du dépôt original (et à ses
|
||||
modérateurs et contributeurs s’il y en a) via ce qu’on appelle une
|
||||
pull-request. Cela signifie donc que tu demandes l’autorisation
|
||||
d’ajouter des commits à la base de code, et ces commits peuvent être
|
||||
lus et commentés par le propriétaire ou les modérateurs. Il peut y
|
||||
avoir une discussion entre toi et les autres personnes qui ont leur
|
||||
mot à dire, le code peut être temporairement refusé, auquel cas tu
|
||||
peux reproposer de nouveau commits sur la même pull-request jusqu’à ce
|
||||
que ton code soit définitivement accepté ou refusé. Dans tous les cas,
|
||||
cela mènera à la fermeture de ta pull-request, et tu pourras fièrement
|
||||
annoncer que tu as participé à un projet sur Github, ou bien avouer
|
||||
avec toute la honte du monde qu’il a été refusé.
|
||||
|
||||
*** J’ai remarqué un bug ou une erreur, mais je ne peux pas corriger ça moi-même
|
||||
Eh bien dans ce cas-là, ouvre une /issue/ Bernadette ; /issue/ qui en
|
||||
français veut dire /problème/. Il s’agit d’un système de Github te
|
||||
permettant de signaler quelque chose aux propriétaires du dépôt, il
|
||||
peut s’agir d’un bug, d’une demande de fonctionnalité ou de
|
||||
proposition de modification d’autres fonctionnalités. Cela peut donner
|
||||
lieu à des discussions menant à la compréhension du bug, ou à une
|
||||
amélioration de ta proposition.
|
||||
|
||||
Si tu soumets un bug, avant d’ouvrir une nouvelle issue, assure-toi de
|
||||
bien savoir comment le bug se produit et peut se reproduire. Est-ce
|
||||
que le bug apparaît si tu utilise ou ouvre le logiciel d’une autre
|
||||
façon ? Est-ce que le bug apparaît ailleurs ? Est-tu sûr que le bug
|
||||
soit un bug ? Et si tu décides de le partager, assure-toi de partager
|
||||
un maximum d’information et tout ce que tu sais sur ce bug, en
|
||||
particulier les étapes et conditions pour le reproduire.
|
||||
|
||||
*** Les raccourcis et paramètres de Git
|
||||
Comme j’en avais parlé plus haut, il est possible de configurer git de
|
||||
façon un peu plus poussée que simplement déclarer notre nom et notre
|
||||
adresse e-mail dans notre =~/.gitconfig=. Il est par exemple possible de
|
||||
déclarer notre éditeur texte préféré, notre navigateur par défaut ou
|
||||
bien même des raccourcis qui pourront t’être bien utile. Ci dessous je
|
||||
te met une partie de mon fichier de configuration avec quelques-unes
|
||||
de mes préférences et pas mal de mes alias.
|
||||
#+BEGIN_SRC toml
|
||||
[core]
|
||||
editor = emacsclient -c
|
||||
whitespace = fix,-indent-with-non-tab,trailing-space
|
||||
[web]
|
||||
browser = firefox
|
||||
[color]
|
||||
ui = auto
|
||||
[alias]
|
||||
a = add --all
|
||||
c = commit
|
||||
cm = commit -m
|
||||
cam = commit -am
|
||||
co = checkout
|
||||
cob = checkout -b
|
||||
cl = clone
|
||||
l = log --oneline --graph --decorate
|
||||
ps = push
|
||||
pl = pull
|
||||
re = reset
|
||||
s = status
|
||||
staged = diff --cached
|
||||
st = stash
|
||||
sc = stash clear
|
||||
sp = stash pop
|
||||
sw = stash show
|
||||
#+END_SRC
|
||||
|
||||
- ~a~ :: Permet d’ajouter d’un coup tout nouveau fichier d’un dépôt en
|
||||
préparation au commit. On peut faire la même chose avec ~git add .~ si
|
||||
on est à la racine du dépôt.
|
||||
- ~c~ :: Un raccourci pour commit, ça permet d’éviter quelques frappes
|
||||
de clavier d’écrire ~git c~ plutôt que ~git commit~.
|
||||
- ~cm~ :: De même pour ~cm~ qui évite de devoir écrire ~commit -m~. On n’a
|
||||
plus qu’à écrire directement le message de commit après ~cm~.
|
||||
- ~cam~ :: Non, ce n’est pas un plan, c’est le même alias que ~cm~ mais
|
||||
qui en plus met automatiquement tous les fichiers modifiés ou
|
||||
supprimés, donc s’il n’y a pas de nouveau fichier à ajouter, même
|
||||
pas besoin de passer par un ~git a~ avant le ~git cam "j’aime les
|
||||
pâtes"~.
|
||||
- ~co~ :: Pour aller plus vite quand on veut écrire ~checkout~.
|
||||
- ~cob~ :: Et pour en plus rajouter le flag ~-b~ pour la création d’une
|
||||
nouvelle branche.
|
||||
- ~cl~ :: Pour quand tu voudras télécharger ce tutoriel en tapant ~git cl
|
||||
https://github.com/Phundrak/tutoriel-git.git~ plutôt que ~git clone
|
||||
https://github.com/Phundrak/tutoriel-git.git~.
|
||||
- ~l~ :: Te permet d’avoir le log un peu plus sympa et compact dont
|
||||
j’avais parlé plus haut.
|
||||
- ~ps~ :: Pour faire un push plus rapidement.
|
||||
- ~pl~ :: Et pour télécharger les derniers commits sur le dépôt plus
|
||||
rapidement.
|
||||
- ~re~ :: Pour réinitialiser plus rapidement.
|
||||
- ~s~ :: Pour rapidement savoir où tu en es dans ton dépôt, savoir ce
|
||||
qui a été modifié, ajouté, supprimé, déplacé, tout ça…
|
||||
- ~staged~ :: Eh oui, Git n’a pas de fonction dédiée pour lister les
|
||||
fichiers en staging, du coup la voilà.
|
||||
- ~st~ :: Pour sauvegarder tes modifications sur le stash plus
|
||||
rapidement.
|
||||
- ~sc~ :: Pour supprimer ton stash plus rapidement.
|
||||
- ~sp~ :: Pour rétablir le stash sur la branche courante plus
|
||||
rapidement.
|
||||
- ~sw~ :: Pour rapidement savoir ce qu’il y a sur le stash.
|
||||
|
||||
*** Et c’est tout ?
|
||||
C’est déjà pas mal ! Mais non, ce n’est certainement pas tout.
|
||||
Cependant, ce tutoriel n’a pour but de t’apprendre que les bases de
|
||||
Git et de Github, pas de tout t’apprendre ! Si tu souhaites aller plus
|
||||
loin, connaître plus de commandes (comme ~git blame~ ou ~git reset~), ou
|
||||
bien connaître plus d’options, je ne peux que t’inviter à aller te
|
||||
documenter par toi-même sur le site de Git qui se trouve ici, ou bien
|
||||
à consulter des pages de manuel dans ton terminal via ~man git~, ~man
|
||||
git-apply~ ou ~man git-cherry-pick~ (oui, il faut lier ~git~ et le nom de
|
||||
la commande par un tiret d’union).
|
||||
|
||||
Si jamais tu as une question, n’hésite pas à m’envoyer un mail à
|
||||
[[mailto:lucien@phundrak.com][lucien@phundrak.com]]. Si jamais tu trouves une erreur dans ce que je
|
||||
viens de dire dans ce tutoriel, ou si tu as une suggestion, c’est
|
||||
justement le moment de mettre en pratique ce que tu as lu un peu plus
|
||||
haut et d’ouvrir une issue sur Github sur le [[https://github.com/Phundrak/tutoriel-git][dépôt de ce tutoriel]].
|
||||
|
||||
** [EN] My YouTube subscriptions as an RSS feed :linux:dev:tutorial:
|
||||
** [EN] My YouTube subscriptions as an RSS feed :linux:dev:tutorial:
|
||||
:PROPERTIES:
|
||||
:EXPORT_FILE_NAME: youtube-subscriptions-rss
|
||||
:EXPORT_DATE: 2022-02-04
|
||||
|
|
@ -2105,7 +1368,7 @@ player. You lost focus.
|
|||
|
||||
*** My Solution: mpv + RSS
|
||||
Wouldn’t it be nice if it were possible to watch these videos with a
|
||||
full fledged video player over which you have complete control? Which
|
||||
full-fledged video player over which you have complete control? Which
|
||||
could be customized to your heart’s content? Which won’t secretly
|
||||
track what you watch?
|
||||
|
||||
|
|
@ -2161,8 +1424,8 @@ https://www.youtube.com/feeds/videos.xml?playlist_id=PL96C35uN7xGI15-QbtUD-wJ5-G
|
|||
#+end_src
|
||||
|
||||
*** Which RSS reader to go with?
|
||||
If you know me, you’ll know I am extremely biaised towards Emacs, so
|
||||
of course I’ll recommend Elfeed to any Emacs user ([[https://config.phundrak.com/emacs#Packages-Configuration-Applications-Elfeedoip0fl6184j0][my relevant
|
||||
If you know me, you’ll know I am extremely biased towards Emacs, so of
|
||||
course I’ll recommend Elfeed to any Emacs user ([[https://config.phundrak.com/emacs#Packages-Configuration-Applications-Elfeedoip0fl6184j0][my relevant
|
||||
configuration is here]]). I even wrote an advice around
|
||||
~elfeed-show-visit~ to ensure YouTube videos are open with mpv instead
|
||||
of my web browser.
|
||||
|
|
@ -2180,14 +1443,14 @@ really my cup of tea, but I can see why some people enjoy it.
|
|||
|
||||
*** Improving a bit the mpv tooling
|
||||
You might have heard it, but youtube-dl hasn’t been doing great
|
||||
recently. The tool is becoming slow and it lacks quite a few features
|
||||
recently. The tool is becoming slow, and it lacks quite a few features
|
||||
it could really benefit from. While it is important to acknowledge its
|
||||
historical importance, I think it is now time to move on, and its
|
||||
successor shall be [[https://github.com/yt-dlp/yt-dlp][yt-dlp]]. In my experience, this youtube-dl fork is
|
||||
much faster than youtube-dl itself on top of providing additional
|
||||
features such as [[https://github.com/yt-dlp/yt-dlp#sponsorblock-options][SponsorBlock integration]].
|
||||
|
||||
How do you replace youtube-dl with yt-dlp then? If you use ArchLinux
|
||||
How do you replace youtube-dl with yt-dlp then? If you use Arch Linux
|
||||
or one of its derivates (I hope not Manjaro though), you can simply
|
||||
install ~yt-dlp-drop-in~ from the AUR.
|
||||
#+begin_src bash
|
||||
|
|
@ -2197,5 +1460,5 @@ yay -S yt-dlp-drop-in
|
|||
# or whichever AUR helper you prefer, as long as it is NOT yaourt
|
||||
#+end_src
|
||||
|
||||
If you are not an ArchLinux user, check out [[https://www.funkyspacemonkey.com/replace-youtube-dl-with-yt-dlp-how-to-make-mpv-work-with-yt-dlp][this article]], it will help
|
||||
you.
|
||||
If you are not an Arch Linux user, check out [[https://www.funkyspacemonkey.com/replace-youtube-dl-with-yt-dlp-how-to-make-mpv-work-with-yt-dlp][this article]], it will
|
||||
help you.
|
||||
|
|
|
|||
Loading…
Reference in New Issue