diff --git a/docs/books/web_services/052-load-balancer-proxies-varnish.uk.md b/docs/books/web_services/052-load-balancer-proxies-varnish.uk.md index a609076f03..826a27c76e 100644 --- a/docs/books/web_services/052-load-balancer-proxies-varnish.uk.md +++ b/docs/books/web_services/052-load-balancer-proxies-varnish.uk.md @@ -327,7 +327,7 @@ sub vcl_backend_response { #### Розповсюдження запитів на різні бекенди -Якщо розміщено кілька сайтів, наприклад сервер документів (\) і вікі (\), можна розподіляти запити на правильну серверну частину. +Якщо розміщено кілька сайтів, наприклад сервер документів () і вікі (), можна розподіляти запити на правильну серверну частину. Оголошення бекендів: @@ -438,7 +438,7 @@ site.front02 probe Healthy 5/5 varnishadm backend.set_health site.front01 auto ``` -Оголошення серверних модулів виконується наступним чином: https://github.com/mattiasgeniar/varnish-6.0-configuration-templates. +Оголошення серверних модулів виконується наступним чином: . ### Журнали Apache diff --git a/docs/desktop/gnome/rdp-server.fr.md b/docs/desktop/gnome/rdp-server.fr.md index a2a2aa4cff..e78952fc03 100644 --- a/docs/desktop/gnome/rdp-server.fr.md +++ b/docs/desktop/gnome/rdp-server.fr.md @@ -12,7 +12,9 @@ Pour les débutants, vous allez utiliser RDP. RDP signifie Remote Desktop Protoc !!! note "Remarque" -Par défaut, Rocky Linux vous permet de partager votre desktop via un autre protocole VNC. VNC est assez pratique, mais RDP offre généralement une expérience beaucoup plus fluide et peut gérer des résolutions de moniteur inhabituelles. +``` +Par défaut, Rocky Linux vous permet de partager votre bureau via un autre protocole VNC. VNC est assez pratique, mais RDP offre généralement une expérience beaucoup plus fluide et peut gérer des résolutions d'écran inhabituelles. +``` ## Prérequis diff --git a/docs/gemstones/git/02_github_web_edit_pr_title.fr.md b/docs/gemstones/git/02_github_web_edit_pr_title.fr.md new file mode 100644 index 0000000000..547683088d --- /dev/null +++ b/docs/gemstones/git/02_github_web_edit_pr_title.fr.md @@ -0,0 +1,44 @@ +--- +title: Changement du titre d'une demande de Pull Request via github.com +author: Wale Soyinka +contributors: Ganna Zhyrnova +tags: + - GitHub + - Pull Request + - Documentation +--- + +## Introduction + +Ce guide explique comment modifier ou changer le titre d'une demande de Pull Request (PR) active dans un référentiel GitHub à l'aide de l'interface Web GitHub. + +## Description du Problème + +Parfois, il peut être nécessaire de modifier le titre d'une requête PR après sa création pour mieux refléter les changements ou les discussions en cours. + +## Prérequis + +- Une pull request GitHub en cours de traitement. +- Accès à l'interface Web GitHub ou CLI avec les autorisations nécessaires. + +## Procédure + +### Utilisation de l'interface Web de GitHub + +1. **Accéder à la requète Pull Request**: + - Accédez au référentiel où se trouve la requête PR. + - Cliquez sur `Pull requests` et sélectionnez la requête PR que vous souhaitez modifier. + +2. **Édition du Titre de PR**: + - Cliquez sur le titre de la Pull Request. + - Une boîte de texte modifiable apparaîtra. + - Modifiez le titre, appuyez sur ++enter++ ou cliquez en dehors de la zone de texte pour enregistrer les modifications. + +## Informations Supplémentaires (facultatif) + +- La modification d'un titre de PR n'affectera pas son fil de discussion ni les modifications de code. +- Il est considéré comme une bonne pratique d'informer les collaborateurs si des modifications significatives sont apportées au titre d'un PR. + +## Conclusion + +En suivant ces étapes, vous pouvez facilement modifier le titre d’une demande Pull Request active dans un référentiel GitHub via l’interface Web. diff --git a/docs/gemstones/git/feature_branch_workflow.fr.md b/docs/gemstones/git/feature_branch_workflow.fr.md new file mode 100644 index 0000000000..8c22c26373 --- /dev/null +++ b/docs/gemstones/git/feature_branch_workflow.fr.md @@ -0,0 +1,99 @@ +--- +title: Feature Branch Workflow avec Git +author: Wale Soyinka +contributors: Ganna Zhyrnova +tags: + - git + - Workflow de branche de fonctionnalités + - GitHub + - gh + - git fetch + - git add + - git pull + - git checkout +--- + +## Workflow de branche de fonctionnalités + +Ce workflow git répandu implique la création de nouvelles branches pour chaque nouvelle fonctionnalité ou correctif directement dans le référentiel principal. +Il est généralement utilisé dans les projets où les contributeurs ont un accès direct au référentiel. + +Ce Gemstone décrit le processus de configuration d'un référentiel local sur lequel travailler et contribuer au projet `rocky-linux/documentation` à l'aide du workflow Git Feature Branch. + +L'utilisateur "rockstar" a créé un fork de ce référentiel et nous utiliserons `https://github.com/rockstar/documentation` comme origine. + +## Prérequis + +- Un compte GitHub et un fork du projet (par exemple, `https://github.com/rockstar/documentation`). +- L'installation de `git` et `GitHub CLI (gh)`. + +## Procédure + +1. Si besoin est, clonez votre fork : + + ```bash + git clone https://github.com/rockstar/documentation.git + cd documentation + ``` + +2. Ajoutez `upstream remote` : + + ```bash + git remote add upstream https://github.com/rocky-linux/documentation.git + ``` + +3. Récupérer les modifications en amont : + + ```bash + git fetch upstream + ``` + +4. Créer une nouvelle branche, Feature Branch : + + ```bash + git checkout -b feature-branch-name + ``` + +5. Apportez des modifications, ajoutez de nouveaux fichiers et validez-les avec `commit` : + + ```bash + git add . + git commit -m "Implementing feature X" + ``` + +6. Maintenir votre Branche à Jour. Fusionnez régulièrement les modifications en amont avec `pull` pour éviter les conflits : + + ```bash + git pull upstream main --rebase + ``` + +7. Transmettez vers votre fork en tapant : + + ```bash + git push origin feature-branch-name + ``` + +8. Créer un Pull Request : + + ```bash + gh pr create --base main --head rockstar:feature-branch-name --title "New Feature X" --body "Long Description of the feature" + ``` + +## Conclusion + +Le workflow Feature Branch est une technique de collaboration courante, permettant aux équipes de travailler simultanément sur divers aspects d'un projet tout en conservant une base de code principale stable. + +Les étapes principales sont les suivantes : + +1. Cloner le référentiel principal : clonez directement le référentiel principal du projet sur votre machine locale. +2. Créer une branche de fonctionnalités : pour chaque nouvelle tâche, créez une nouvelle branche de la branche principale avec un nom descriptif. +3. Valider les modifications : travaillez sur la fonctionnalité ou le correctif dans votre branche et validez les modifications avec `commit`. +4. Maintenir la branche à jour : fusionnez avec `pull` ou rebasez régulièrement avec la branche principale pour rester synchrone avec d'éventuelles modifications. +5. Ouvrez une Pull Request : envoyez la branche au référentiel principal avec `push` et ouvrez une PR pour examen une fois que votre fonctionnalité est prête à vérifier. +6. Révision et fusion du code : la branche est fusionnée dans la branche principale avec `merge` après vérification et approbation. + +_Avantages :_ + +- Simplifie les contributions pour les contributeurs réguliers avec un accès direct au référentiel. +- Assure que chaque fonctionnalité est examinée et vérifiée avant d'être intégrée à la base de code principale. +- Permet de maintenir un historique de projet propre et linéaire. diff --git a/docs/gemstones/git/fork_and_branch_workflow.fr.md b/docs/gemstones/git/fork_and_branch_workflow.fr.md new file mode 100644 index 0000000000..442f0dc50f --- /dev/null +++ b/docs/gemstones/git/fork_and_branch_workflow.fr.md @@ -0,0 +1,115 @@ +--- +title: Fork et Branche – Git workflow +author: Wale Soyinka +contributors: Ganna Zhyrnova +tags: + - GitHub + - git + - gh + - git fetch + - git add + - git pull + - git checkout + - gh repo +--- + +## Fork et Branch Workflow + +Dans ce type de workflow, les contributeurs transfèrent le référentiel principal vers un fork dans leur propre compte GitHub, créent des branches de fonctionnalités pour leur travail, puis soumettent des contributions via des Pull Requests depuis ces branches. + +Ce Gemstone explique comment configurer un référentiel local pour contribuer à un projet GitHub. Cela commence par le fork initial du projet, la configuration d'un référentiel local et distant, la validation des modifications et la création d'une pull request (PR) pour soumettre vos contributions. + +## Prérequis + +- Un compte GitHub. +- Installation de `git` et `GitHub CLI (gh)` sur votre système. +- Un fork individuel du projet sur GitHub. + +## Procédure + +1. S'il n'existe pas déjà, créez un fork du projet en utilisant l'utilitaire `gh`. Entrer la commande suivante : + + ```bash + gh repo fork rocky-linux/documentation --clone=true --remote=true + ``` + + Les options utilisées dans cette commande _gh repo fork_ sont les suivantes : + + - `--clone=true` : Clone le référentiel forké sur votre machine locale. + - `--remote=true` : ajoute le référentiel d'origine en tant que référentiel distant, vous permettant de synchroniser les futures mises à jour. + +2. Accédez au répertoire du dépôt local. Entrer la commande suivante : + + ```bash + cd documentation + ``` + +3. Vérifiez que tous les dépôts distants pertinents ont été correctement configurés dans votre dépôt local, tapez : + + ```bash + git remote -vv + ``` + +4. Récupérez les dernières modifications avec `fetch` depuis le dépôt distant en amont : + + ```bash + git fetch upstream + ``` + +5. Créez et extrayez avec `checkout` une nouvelle branche de fonctionnalités nommée your-feature-branch : + + ```bash + git checkout -b your-feature-branch + ``` + +6. Apportez des modifications, ajoutez de nouveaux fichiers et validez vos modifications dans votre dépôt local avec `commit` : + + ```bash + git add . + git commit -m "Your commit message" + ``` + +7. Synchronisez avec la branche principale du dépôt distant nommée « upstream » : + + ```bash + git pull upstream main + ``` + +8. Transmission des modifications au Fork : + + ```bash + git push origin your-feature-branch + ``` + +9. Enfin, créez une Pull Request (PR) à l'aide de l'application CLI `gh` : + + ```bash + gh pr create --base main --head your-feature-branch --title "Your PR Title" --body "Description of your changes" + ``` + + Les options utilisées dans cette commande _gh pr create_ sont les suivantes : + + `--base` main : spécifie la branche de base dans le référentiel upstream où les modifications seront fusionnées avec `merge`. + `--head` your-feature-branch : indique la branche principale de votre fork qui contient les modifications. + `--title` "Votre titre PR" : définit le titre de la demande de Pull Request. + `--body` "Description de vos modifications" : Fournit une description détaillée des modifications dans la pull request. + +## Conclusion + +Le workflow `Fork and Branch` est une autre technique de collaboration courante. +Les étapes principales sont les suivantes : + +1. Fork Repository : créez une copie individuelle du référentiel du projet sur votre compte GitHub. +2. Clone du fork : clonez votre fork sur votre machine locale pour les travaux de développement. +3. Définir le site distant en amont : pour rester à jour avec ses modifications, ajoutez le référentiel du projet d'origine en tant que site distant `upstream remote`. +4. Création d'une Feature Branch : créez une nouvelle branche à partir de la branche principale mise à jour pour chaque nouvelle fonctionnalité ou correctif. Les noms de branche doivent décrire succinctement la fonctionnalité ou le correctif. +5. Commit des modifications : effectuez vos modifications et validez-les – `commit` – avec des messages de validation clairs et concis. +6. Synchronisation avec Upstream : synchronisez régulièrement votre fork et votre branche de fonctionnalité avec la branche principale en amont – `Upstream` – pour intégrer les nouvelles modifications et réduire les conflits de fusion – `merge` – . +7. Création d'une Pull Request (PR) : envoyez votre branche de fonctionnalité à votre fork sur GitHub avec `push` et ouvrez une PR sur le projet principal. Votre PR doit décrire clairement les changements et établir un lien vers tout problème pertinent et toute demande d'amélioration ou de nouvelle fonctionnalité. +8. Répondre aux commentaires : collaborer sur les commentaires de révision jusqu'à ce que la PR soit fusionnée – `merge` – ou fermée. + +Avantages : + +- Isole le travail de développement dans des branches spécifiques, tout en gardant la branche principale propre. +- Cela facilite la révision et l’intégration des modifications. +- Réduit le risque de conflits avec la base de code évolutive du projet principal. diff --git a/docs/gemstones/git/git_pull_vs_git_fetch.fr.md b/docs/gemstones/git/git_pull_vs_git_fetch.fr.md new file mode 100644 index 0000000000..fbb7821c00 --- /dev/null +++ b/docs/gemstones/git/git_pull_vs_git_fetch.fr.md @@ -0,0 +1,70 @@ +--- +title: Utilisation de `git pull` et `git fetch` +author: Wale Soyinka +contributors: Ganna Zhyrnova +tags: + - Git + - git pull + - git fetch +--- + +## Introduction + +Ce Gemstone explique les différences entre les commandes `git pull` et `git fetch`. Il indique également quand utiliser chaque commande de manière appropriée. + +## Git Fetch vs Git Pull + +### Git Fetch + +`git fetch` télécharge les modifications à partir d'un référentiel distant mais ne les intègre pas dans votre branche locale. + +Il est bénéfique de voir ce que les autres ont apporté avec commit sans fusionner ces modifications dans votre branche locale. + +1. Lister la branche actuellement extraite + + ```bash + git branch + ``` + +2. Récupérer les modifications avec `fetch` depuis la branche principale d'un référentiel distant nommé origin. Entrer la commande suivante : + + ```bash + git fetch origin main + ``` + +3. Comparez les modifications entre le HEAD de votre dépôt local et le dépôt `origin/main` distant. + + ```bash + git log HEAD..origin/main + ``` + +### Git Pull + +Git Pull télécharge les modifications et les fusionne dans votre branche actuelle. +Il est utile pour mettre à jour rapidement votre branche locale avec les modifications du référentiel distant. + +1. **Extraire et fusionner les modifications** : + + ```bash + git pull origin main + ``` + +2. **Vérifiez les modifications fusionnées** : + + ```bash + git log + ``` + +## Remarques Complémentaires + +- **Utilisez `git fetch`** : + \-- Lorsque vous devez vérifier les modifications avant la fusion. + \-- Éviter des changements indésirables ou des conflits dans votre branche locale. + +- **Utilisez `git pull`** : + \-- Lorsque vous souhaitez mettre à jour votre branche locale avec les derniers commits. + \-- Pour des mises à jour rapides et simples sans avoir à vérifier les modifications au préalable. + +## Conclusion + +Comprendre les distinctions entre `git fetch` et `git pull` est essentiel pour une gestion efficace du workflow Git. Choisir la bonne commande en fonction de vos besoins est important lorsque vous travaillez ou collaborez via des systèmes de contrôle de version comme GitHub, GitLab, Gitea, etc. diff --git a/docs/gemstones/git/git_remote_add.fr.md b/docs/gemstones/git/git_remote_add.fr.md new file mode 100644 index 0000000000..16809febff --- /dev/null +++ b/docs/gemstones/git/git_remote_add.fr.md @@ -0,0 +1,78 @@ +--- +title: Ajout d'un dépôt distant à l'aide de git CLI +author: Wale Soyinka +contributors: Ganna Zhyrnova +tags: + - GitHub + - git + - git remote + - git fetch +--- + +## Introduction + +Ce Gemstone illustre comment ajouter un référentiel distant spécifique à un clone local existant d'un projet FOSS à l'aide de l'interface de ligne de commande Git. +Nous utiliserons le référentiel du projet de documentation Rocky Linux comme exemple de projet FOSS - + +## Prérequis + +- Un compte GitHub. +- Installation de `git` sur le système. +- Un clone local d'un dépôt de projet FOSS. + +## Procédure + +1. Ouvrez un terminal et changez votre répertoire de travail vers le dossier contenant votre clone local du projet. + Par exemple, si vous avez cloné le dépôt github dans ~/path/to/your/rl-documentation-clone, tapez + + ```bash + cd ~/path/to/your/rl-documentation-clone + ``` + +2. Avant d’effectuer des modifications, répertoriez les `remote`s que vous avez configurées. Entrer la commande suivante : + + ```bash + git remote -vv + ``` + + S'il s'agit d'un dépôt fraîchement cloné, vous verrez probablement une seule branche remote nommée `origin` dans votre affichage de sortie. + +3. Ajoutez le référentiel de documentation Rocky Linux (`https://github.com/rocky-linux/documentation.git`) en tant que nouveau référentiel distant – `remote` – à votre référentiel local. Ici, nous allons attribuer `upstream` comme nom à cette `remote` particulière. Entrer la commande suivante : + + ```bash + git remote add upstream https://github.com/rocky-linux/documentation.git + ``` + +4. Pour souligner davantage que les noms attribués aux référentiels distants sont arbitraires, créez un autre référentiel distant nommé rocky-docs qui pointe vers le même référentiel en exécutant la commande suivante : + + ```bash + git remote add rocky-docs https://github.com/rocky-linux/documentation.git + ``` + +5. Vérifiez que le nouveau dépôt distant a été ajouté avec succès : + + ```bash + git remote -v + ``` + + Vous devriez voir `upstream` répertorié avec son URL. + +6. Facultativement, avant de commencer à apporter des modifications à votre dépôt local, vous pouvez récupérer des données à partir de la branche nouvellement ajoutée. + Récupérez les branches et les commits de la `remote` nouvellement ajoutée en exécutant : + + ```bash + git fetch upstream + ``` + +## Remarques Complémentaires + +- _Origin_ : il s'agit du nom par défaut que Git donne au référentiel distant à partir duquel vous avez cloné. C'est comme un surnom pour l'URL du dépôt. Lorsque vous clonez un dépôt, ce référentiel distant est automatiquement défini comme `origine` dans votre configuration Git locale. Le nom est arbitraire mais une convention. + +- _Upstream_ : cela fait souvent référence au référentiel d'origine lorsque vous avez créé un fork d'un projet. + Dans les projets open-source, si vous dupliquez un référentiel pour apporter des modifications, le référentiel dupliqué est votre `origin` et le référentiel d'origine est généralement appelé `upstream`. Le nom est arbitraire mais une convention. + + Cette distinction subtile entre usages/affectation de `remote` et `origin` est cruciale pour contribuer au projet original via des pull request. + +## Conclusion + +L'utilitaire Git CLI permet d'utiliser facilement un nom descriptif et d'ajouter un référentiel distant spécifique à un clone local d'un projet FOSS. Cela vous permet de vous synchroniser et de contribuer efficacement à divers dépôts. diff --git a/docs/gemstones/git/tracking_and_nontracking_branch.fr.md b/docs/gemstones/git/tracking_and_nontracking_branch.fr.md new file mode 100644 index 0000000000..01182b5000 --- /dev/null +++ b/docs/gemstones/git/tracking_and_nontracking_branch.fr.md @@ -0,0 +1,73 @@ +--- +title: Tracking vs Non-Tracking Branch avec Git +author: Wale Soyinka +contributors: null +tags: + - git + - git branch + - Tracking Branch + - Branche sans suivi +--- + +## Introduction + +Ce Gemstone explore les branches de suivi et de non-suivi dans Git. Il comprend également des étapes pour vérifier et convertir entre les types de branches. + +## Tracking Branch + +Une branche de suivi est une branche liée à une branche distante. + +1. Créez une nouvelle branche en la nommant my-local-branch. Faites en sorte que la nouvelle branche locale suive la branche principale du référentiel distant nommé `origin`. Entrer la commande suivante : + + ```bash + git checkout -b my-local-branch origin/main + ``` + +2. Utilisez la commande `git branch -vv` pour vérifier que la branche est une branche de suivi – Tracking –. Entrer la commande suivante : + + ```bash + git branch -vv + ``` + + Recherchez les branches avec `[origin/main]` indiquant qu'elles suivent `origin/main`. + +## Branche sans suivi + +Une branche sans suivi – `Non-Tracking` – est une branche qui fonctionne indépendamment des branches distantes. + +1. Créez une nouvelle branche locale sans suivi nommée my-feature-branch. Entrer la commande suivante : + + ```bash + git checkout -b my-feature-branch + ``` + +2. Les branches sans suivi n’afficheront pas de branche distante à côté d’elles dans la sortie du résultat de la commande `git branch -vv`. Vérifiez si my-feature-branch est une branche sans suivi. + +## Conversion de Non-Tracking à Tracking + +1. Si vous le souhaitez, assurez-vous d’abord que les dernières modifications de la branche principale sont fusionnées dans la branche cible. Entrer la commande suivante : + + ```bash + git checkout my-feature-branch + git merge main + ``` + +2. Configurer le suivi – tracking – vers une branche distante : + + ```bash + git branch --set-upstream-to=origin/main my-feature-branch + ``` + + Résultat : `Branch 'my-feature-branch' set up to track remote branch 'main' from 'origin'.` + +3. Vérifier les modifications. Entrer la commande suivante : + + ```bash + git branch -vv + ``` + + Maintenant, `my-feature-branch` devrait afficher `[origin/main]` indiquant qu'elle est en cours de suivi – tracking –. + +## Conclusion + +Comprendre les nuances entre les branches de suivi et celles sans suivi est essentiel dans Git. Ce Gemstone clarifie ces concepts et montre également comment identifier et convertir entre ces types de branches pour une gestion optimale du workflow git.