mirror of
https://github.com/microsoft/Web-Dev-For-Beginners.git
synced 2025-08-07 23:37:23 +02:00
Merge branch 'main' of https://github.com/FranciscoImanolSuarez/Web-Dev-For-Beginners
This commit is contained in:
Francisco Imanol Suarez
GitHub
@@ -0,0 +1,318 @@
|
||||
# Introduction à GitHub
|
||||
|
||||
Cette leçon couvre les principes de base de GitHub, une plateforme permettant d’héberger et de gérer les modifications apportées à votre code.
|
||||
|
||||
|
||||
> Sketchnote par [Tomomi Imura](https://twitter.com/girlie_mac)
|
||||
|
||||
## Quiz préalable
|
||||
[Quiz préalable](https://nice-beach-0fe9e9d0f.azurestaticapps.net/quiz/3?loc=fr)
|
||||
|
||||
## Introduction
|
||||
|
||||
Dans cette leçon, nous allons couvrir :
|
||||
|
||||
- suivre le travail que vous faites sur votre machine
|
||||
- travailler sur des projets avec d’autres personnes
|
||||
- comment contribuer aux logiciels open source
|
||||
|
||||
### Prérequis
|
||||
|
||||
Avant de commencer, vous devrez vérifier si Git est installé. Dans le type de terminal :
|
||||
`git --version`
|
||||
|
||||
Si Git n’est pas installé, [télécharger Git](https://git-scm.com/downloads). Ensuite, configurez votre profil Git local dans le terminal:
|
||||
* `git config --global user.name " votre-nom"`
|
||||
* `git config --global user.email " your-email"`
|
||||
|
||||
Pour vérifier si Git est déjà configuré, vous pouvez taper :
|
||||
`git config --list`
|
||||
|
||||
Vous aurez également besoin d’un compte GitHub, d’un éditeur de code (comme Visual Studio Code), et vous devrez ouvrir votre terminal (ou : invite de commandes).
|
||||
|
||||
Accédez à [github.com](https://github.com/) et créez un compte si vous ne l’avez pas déjà fait, ou connectez-vous et remplissez votre profil.
|
||||
|
||||
✅ GitHub n’est pas le seul référentiel de code au monde; il y en a d’autres, mais GitHub est le plus connu
|
||||
|
||||
### Préparation
|
||||
|
||||
Vous aurez besoin à la fois d’un dossier avec un projet de code sur votre ordinateur local (ordinateur portable ou PC) et d’un référentiel public sur GitHub, qui servira d’exemple pour contribuer aux projets d’autres personnes.
|
||||
|
||||
---
|
||||
|
||||
## Gestion du code
|
||||
|
||||
Supposons que vous ayez un dossier localement avec un projet de code et que vous souhaitiez commencer à suivre votre progression à l’aide de git - le système de contrôle de version. Certaines personnes comparent l’utilisation de git à l’écriture d’une lettre d’amour à votre futur moi. En lisant vos messages de validation des jours, des semaines ou des mois plus tard, vous pourrez vous rappeler pourquoi vous avez pris une décision, ou " annuler " une modification - c’est-à-dire lorsque vous écrivez de bons " messages de validation ".
|
||||
|
||||
### Tâche : créer un référentiel et valider le code
|
||||
|
||||
1. **Créer un référentiel sur GitHub**. Sur GitHub.com, dans l’onglet Référentiels ou dans la barre de navigation en haut à droite, recherchez le bouton **nouveau référentiel**.
|
||||
|
||||
1. Donnez un nom à votre référentiel (dossier)
|
||||
1. Sélectionnez **créer un référentiel**.
|
||||
|
||||
1. **Accédez à votre dossier de travail**. Dans votre terminal, basculez vers le dossier (également connu sous le nom de répertoire) que vous souhaitez démarrer le suivi. Tapez :
|
||||
|
||||
```bash
|
||||
cd [nom de votre dossier]
|
||||
```
|
||||
|
||||
1. **Initialiser un dépôt git**. Dans votre type de projet :
|
||||
|
||||
```bash
|
||||
git init
|
||||
```
|
||||
|
||||
1. **Vérifier l’état**. Pour vérifier l’état de votre type de référentiel :
|
||||
|
||||
```bash
|
||||
git status
|
||||
```
|
||||
|
||||
la sortie peut ressembler à ceci :
|
||||
|
||||
```output
|
||||
Changes not staged for commit:
|
||||
(use "git add <file>..." to update what will be committed)
|
||||
(use "git checkout -- <file>..." to discard changes in working directory)
|
||||
|
||||
modified: file.txt
|
||||
modified: file2.txt
|
||||
```
|
||||
|
||||
En règle générale, une commande `git status` vous indique des choses comme quels fichiers sont prêts à être _enregistrés_ dans le référentiel ou contient des modifications que vous voudrez peut-être conserver.
|
||||
|
||||
1. **Ajouter tous les fichiers pour le suivi**
|
||||
Cela s’appelle aussi fichiers intermédiaires/ ajout de fichiers à la zone de transit.
|
||||
|
||||
```bash
|
||||
git add .
|
||||
```
|
||||
|
||||
L’argument `git add` plus `.` indique que tous vos fichiers &changes pour le suivi.
|
||||
|
||||
1. **Ajouter les fichiers sélectionnés pour le suivi**
|
||||
|
||||
```bash
|
||||
git add [nom du fichier ou du dossier]
|
||||
```
|
||||
|
||||
Cela nous aide à ajouter uniquement les fichiers sélectionnés à la zone de transit lorsque nous ne voulons pas valider tous les fichiers à la fois.
|
||||
|
||||
1. **Défaire la scène de tous les fichiers**
|
||||
|
||||
```bash
|
||||
git reset
|
||||
```
|
||||
|
||||
Cette commande nous aide à défaire tous les fichiers à la fois.
|
||||
|
||||
1. **Défaire un fichier particulier**
|
||||
|
||||
```bash
|
||||
git reset [nom du fichier ou du dossier]
|
||||
```
|
||||
|
||||
Cette commande nous aide à défaire un fichier particulier à la fois que nous ne voulons pas inclure pour le prochain commit.
|
||||
|
||||
1. **Persistance de votre travail**. À ce stade, vous avez ajouté les fichiers à un soi-disant _staging area_. Un endroit où Git suit vos fichiers. Pour rendre la modification permanente, vous devez _valider_ les fichiers. Pour ce faire, vous créez un _commit_ avec la commande `git commit`. Un _commit_ représente un point d’enregistrement dans l’historique de votre référentiel. Tapez ce qui suit pour créer un _commit_ :
|
||||
|
||||
```bash
|
||||
git commit -m " premier commit "
|
||||
```
|
||||
|
||||
Cela valide tous vos fichiers, en ajoutant le message " premier commit ". Pour les futurs messages de validation, vous voudrez être plus descriptif dans votre description pour indiquer le type de modification que vous avez apportée.
|
||||
|
||||
1. **Connectez votre référentiel Git local avec GitHub**. Un référentiel Git est bon sur votre machine, mais à un moment donné, vous voulez avoir une sauvegarde de vos fichiers quelque part et également inviter d’autres personnes à travailler avec vous sur votre dépôt. GitHub est un excellent endroit pour le faire. N’oubliez pas que nous avons déjà créé un référentiel sur GitHub, donc la seule chose que nous devons faire est de connecter notre référentiel Git local à GitHub. La commande `git remote add` fera exactement cela. Tapez la commande suivante :
|
||||
|
||||
> Remarque, avant de taper la commande, accédez à votre page de référentiel GitHub pour trouver l’URL du référentiel. Vous l’utiliserez dans la commande ci-dessous. Remplacez `repository_name` par votre URL GitHub.
|
||||
|
||||
```bash
|
||||
git remote add origin https://github.com/username/repository_name.git
|
||||
```
|
||||
|
||||
Cela crée un _remote_, ou une connexion, nommé " origin " pointant vers le référentiel GitHub que vous avez créé précédemment.
|
||||
|
||||
1. **Envoyer des fichiers locaux à GitHub**. Jusqu’à présent, vous avez créé une _connexion_ entre le référentiel local et le référentiel GitHub. Envoyons ces fichiers à GitHub avec la commande suivante `git push`, comme suit:
|
||||
|
||||
```bash
|
||||
git push -u origin main
|
||||
```
|
||||
|
||||
Cela envoie vos commits dans votre branche "main" à GitHub..
|
||||
|
||||
1. **Pour ajouter d’autres modifications**. Si vous souhaitez continuer à apporter des modifications et à les pousser vers GitHub, il vous suffit d’utiliser les trois commandes suivantes:
|
||||
|
||||
```bash
|
||||
git add .
|
||||
git commit -m " tapez votre message de validation ici "
|
||||
git push
|
||||
```
|
||||
|
||||
> Conseil, vous pouvez également adopter un fichier `.gitignore` pour empêcher les fichiers que vous ne souhaitez pas suivre d’apparaître sur GitHub - comme ce fichier de notes que vous stockez dans le même dossier mais n’a pas sa place sur un référentiel public. Vous pouvez trouver des modèles pour les fichiers `.gitignore` dans [.gitignore templates](https://github.com/github/gitignore).
|
||||
|
||||
#### Valider les messages
|
||||
|
||||
Une grande ligne d’objet de commit Git complète la phrase suivante:
|
||||
S’il est appliqué, ce commit le sera
|
||||
|
||||
Pour le sujet, utilisez l’impératif, présent: "changement" pas "changé" ni "changements".
|
||||
Comme dans le sujet, dans le corps (facultatif) utilisez également l’impératif, le présent. Le corps doit inclure la motivation du changement et contraster cela avec le comportement précédent. Vous expliquez le `pourquoi`, pas le `comment`.
|
||||
|
||||
✅ Prenez quelques minutes pour surfer sur GitHub. Pouvez-vous trouver un très bon message d’engagement? Pouvez-vous en trouver un vraiment minime? Quelles informations pensez-vous être les plus importantes et les plus utiles à transmettre dans un message de validation ?
|
||||
|
||||
### Tâche : Collaborer
|
||||
|
||||
La principale raison de mettre des choses sur GitHub était de permettre de collaborer avec d’autres développeurs.
|
||||
|
||||
## Travailler sur des projets avec d’autres
|
||||
|
||||
Dans votre référentiel, accédez à `Insights > Community ` pour voir comment votre projet se compare aux normes communautaires recommandées.
|
||||
|
||||
Voici quelques éléments qui peuvent améliorer votre référentiel GitHub :
|
||||
- **Description**. Avez-vous ajouté une description pour votre projet ?
|
||||
- **README**. Avez-vous ajouté un fichier README ? GitHub fournit des conseils pour l’écriture d’un [README](https://docs.github.com/articles/about-readmes/).
|
||||
- **Guide de contribution**. Votre projet a-t-il des [directives de contribution](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/),
|
||||
- **Code de conduite**. Un [Code de conduite](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/),
|
||||
- **Licence**. Peut-être plus important encore, une [licence](https://docs.github.com/articles/adding-a-license-to-a-repository/) ?
|
||||
|
||||
|
||||
Toutes ces ressources profiteront à l’intégration des nouveaux membres de l’équipe. Et ce sont généralement le genre de choses que les nouveaux contributeurs regardent avant même de regarder votre code, pour savoir si votre projet est le bon endroit pour qu’ils passent leur temps.
|
||||
|
||||
✅ fichiers README, bien qu’ils prennent du temps à préparer, sont souvent négligés par les mainteneurs occupés. Pouvez-vous trouver un exemple particulièrement descriptif? Remarque: il y a quelques [outils pour aider à créer de bons README](https://www.makeareadme.com/) que vous voudrez peut-être essayer.
|
||||
|
||||
### Tâche : fusionner du code
|
||||
|
||||
Les documents contributeurs aident les gens à contribuer au projet. Il explique les types de contributions que vous recherchez et comment le processus fonctionne. Les contributeurs devront passer par une série d’étapes pour pouvoir contribuer à votre référentiel sur GitHub :
|
||||
|
||||
|
||||
1. **Forker votre repo** Vous voudrez probablement que les gens _fork_ votre projet. La duplication signifie la création d’un réplica de votre référentiel sur leur profil GitHub.
|
||||
1. **Cloner**. De là, ils cloneront le projet sur leur ordinateur local.
|
||||
1. **Créer une branche**. Vous voudrez leur demander de créer une _branche_ pour leur travail.
|
||||
1. **Concentrez leur changement sur un seul domaine**. Demandez aux contributeurs de concentrer leurs contributions sur une chose à la fois - de cette façon, les chances que vous puissiez _fusionner_ dans leur travail sont plus élevées. Imaginez qu’ils écrivent un correctif de bogue, ajoutent une nouvelle fonctionnalité et mettent à jour plusieurs tests - que se passe-t-il si vous le souhaitez ou si vous ne pouvez implémenter que 2 modifications sur 3 ou 1 sur 3?
|
||||
|
||||
✅ Imaginez une situation où les branches sont particulièrement essentielles à l’écriture et à l’expédition d’un bon code. À quels cas d’utilisation pouvez-vous penser ?
|
||||
|
||||
> Remarque, soyez le changement que vous voulez voir dans le monde et créez également des branches pour votre propre travail. Tous les commits que vous faites seront effectués sur la branche que vous avez actuellement "extraite". Utilisez `git status` pour voir de quelle branche il s’agit.
|
||||
|
||||
Passons en revue un flux de travail de contributeur. Supposons que le contributeur a déjà _forked_ et _cloné_ le référentiel afin qu’il ait un référentiel Git prêt à être travaillé, sur sa machine locale :
|
||||
|
||||
1. **Créer une branche**. Utilisez la commande `git branch` pour créer une branche qui contiendra les modifications qu’ils veulent contribuer:
|
||||
|
||||
```bash
|
||||
git branch [nom_branche]
|
||||
```
|
||||
|
||||
1. **Passer à la branche de travail**. Basculez vers la branche spécifiée et mettez à jour le répertoire de travail avec `git checkout`:
|
||||
|
||||
```bash
|
||||
git checkout [nom_branche]
|
||||
```
|
||||
|
||||
1. **Travailler**. À ce stade, vous souhaitez ajouter vos modifications. N’oubliez pas d’en parler à Git avec les commandes suivantes:
|
||||
|
||||
```bash
|
||||
git add .
|
||||
git commit -m " mes modifications "
|
||||
```
|
||||
|
||||
Assurez-vous de donner à votre engagement une bonne réputation, pour votre bien ainsi que pour le mainteneur du repo que vous aidez.
|
||||
|
||||
1. **Combinez votre travail avec la branche `main`**. À un moment donné, vous avez fini de travailler et vous voulez combiner votre travail avec celui de la branche `main`. La branche `main`" a peut-être changé entre-temps, alors assurez-vous de la mettre à jour au plus tard avec les commandes suivantes:
|
||||
|
||||
```bash
|
||||
git checkout principal
|
||||
git pull
|
||||
```
|
||||
|
||||
À ce stade, vous voulez vous assurer que tous les _conflits_, les situations où Git ne peut pas facilement _combiner_ les modifications se produisent dans votre branche de travail. Par conséquent, exécutez les commandes suivantes :
|
||||
|
||||
```bash
|
||||
git checkout [branch_name]
|
||||
git merge main
|
||||
```
|
||||
|
||||
Cela apportera tous les changements de `main` dans votre branche et j’espère que vous pourrez simplement continuer. Sinon, VS Code vous dira où Git est _confus_ et vous modifiez simplement les fichiers affectés pour dire quel contenu est le plus précis.
|
||||
|
||||
1. **Envoyez votre travail à GitHub**. L’envoi de votre travail à GitHub signifie deux choses. Pousser votre succursale à votre dépôt, puis ouvrir un PR, Pull Request.
|
||||
|
||||
```bash
|
||||
git push --set-upstream origin [nom_branche]
|
||||
```
|
||||
|
||||
La commande ci-dessus crée la branche sur votre référentiel duppliqué.
|
||||
|
||||
1. **Ouvrez une PR**. Ensuite, vous souhaitez ouvrir une PR. Pour ce faire, accédez au référentiel forké sur GitHub. Vous verrez une indication sur GitHub où il vous demande si vous souhaitez créer une nouvelle PR, vous cliquez dessus et vous êtes emmené vers une interface où vous pouvez changer le titre du message de validation, lui donner une description plus appropriée. Maintenant, le mainteneur du repo que vous avez forké verra ce PR et _croisons les doigts_ qu’il apprécieront et _fusionnera_ votre PR. Vous êtes maintenant un contributeur, yay :)
|
||||
|
||||
1. **Nettoyer**. Il est considéré comme une bonne pratique de _clean up_ après avoir fusionné avec succès un PR. Vous voulez nettoyer à la fois votre branche locale et la branche que vous avez poussée vers GitHub. Commençons par le supprimer localement avec la commande suivante:
|
||||
|
||||
```bash
|
||||
git branch -d [nom_branche]
|
||||
```
|
||||
|
||||
Assurez-vous d’accéder à la page GitHub pour le référentiel duppliqué suivant et supprimez la branche distante que vous venez d’y pousser.
|
||||
|
||||
`Pull request` semble être un terme stupide parce que vous voulez vraiment pousser vos modifications au projet. Mais le responsable (propriétaire du projet) ou l’équipe principale doit prendre en compte vos modifications avant de la fusionner avec la branche " principale " du projet, vous demandez donc vraiment une décision de modification à un responsable.
|
||||
|
||||
Une pull request est l’endroit idéal pour comparer et discuter des différences introduites sur une branche avec des révisions, des commentaires, des tests intégrés, etc. Une bonne pull request suit à peu près les mêmes règles qu’un message de validation. Vous pouvez ajouter une référence à un problème dans le suivi des problèmes, lorsque votre travail, par exemple, résout un problème. Cela se fait à l’aide d’un `#` suivi du numéro de votre problème. Par exemple `#97`.
|
||||
|
||||
🤞croisons les doigts pour que toutes les vérifications réussissent et que le ou les propriétaires du projet fusionnent vos modifications dans le projet🤞
|
||||
|
||||
Mettez à jour votre branche de travail locale actuelle avec tous les nouveaux commits de la branche distante correspondante sur GitHub :
|
||||
|
||||
`git pull`
|
||||
|
||||
## Comment contribuer à l’open source
|
||||
|
||||
Tout d’abord, trouvons un référentiel (ou **repo**) sur GitHub qui vous intéresse et auquel vous souhaitez apporter une modification. Vous voudrez copier son contenu sur votre machine.
|
||||
|
||||
✅ Un bon moyen de trouver des repos " conviviaux pour les débutants " est de [rechercher par la balise 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
|
||||
|
||||
|
||||
|
||||
Il existe plusieurs façons de copier du code. Une façon consiste à " cloner " le contenu du référentiel, en utilisant HTTPS, SSH ou en utilisant l’interface de ligne de commande GitHub CLI (Interface de ligne de commande).
|
||||
|
||||
Ouvrez votre terminal et clonez le référentiel comme suit:
|
||||
`git clone https://github.com/ProjectURL`
|
||||
|
||||
Pour travailler sur le projet, basculez vers le dossier de droite :
|
||||
`cd ProjectURL`
|
||||
|
||||
Vous pouvez également ouvrir l’ensemble du projet à l’aide de [Codespaces](https://github.com/features/codespaces), de l’éditeur de code intégré / environnement de développement cloud de GitHub ou de [GitHub Desktop](https://desktop.github.com/).
|
||||
|
||||
Enfin, vous pouvez télécharger le code dans un dossier compressé.
|
||||
|
||||
### Quelques choses plus intéressantes sur GitHub
|
||||
|
||||
Vous pouvez mettre en vedette, regarder et / ou " fork " n’importe quel référentiel public sur GitHub. Vous pouvez trouver vos référentiels étoilés dans le menu déroulant en haut à droite. C’est comme le bookmarking, mais pour le code.
|
||||
|
||||
Les projets ont un suivi des problèmes, principalement sur GitHub dans l’onglet " Problèmes ", sauf indication contraire, où les gens discutent des problèmes liés au projet. Et l’onglet Pull Requests est l’endroit où les gens discutent et examinent les modifications en cours.
|
||||
|
||||
Les projets peuvent également avoir des discussions dans des forums, des listes de diffusion ou des canaux de chat tels que Slack, Discord ou IRC.
|
||||
|
||||
✅ Jetez un coup d’œil à votre nouveau référentiel GitHub et essayez quelques éléments, comme la modification des paramètres, l’ajout d’informations à votre référentiel et la création d’un projet (comme un tableau Kanban). Il y a beaucoup de choses que vous pouvez faire!
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Challenge
|
||||
|
||||
Associez-vous à un ami pour travailler sur le code de l’autre. Créez un projet en collaboration, bifurquez du code, créez des branches et fusionnez les modifications.
|
||||
|
||||
## Quiz de validation des connaissances
|
||||
[Quiz de validation des connaissances](https://nice-beach-0fe9e9d0f.azurestaticapps.net/quiz/4?loc=fr)
|
||||
|
||||
## Examen & Auto-apprentissage
|
||||
|
||||
En savoir plus sur [contribuer à un logiciel open source](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
|
||||
|
||||
[Git cheatsheet](https://training.github.com/downloads/github-git-cheat-sheet/).
|
||||
|
||||
Pratique, pratique, pratique. GitHub a d’excellents chemins d’apprentissage disponibles via [lab.github.com](https://lab.github.com/):
|
||||
|
||||
- [Première semaine sur GitHub](https://lab.github.com/githubtraining/first-week-on-github)
|
||||
|
||||
Vous trouverez également des laboratoires plus avancés.
|
||||
|
||||
## Affectation
|
||||
|
||||
Complétez [la première semaine dans le laboratoire de formation GitHub](https://lab.github.com/githubtraining/first-week-on-github)
|
||||
@@ -0,0 +1,317 @@
|
||||
# Introdução ao GitHub
|
||||
|
||||
Esta lição cobre os fundamentos do GitHub, uma plataforma para hospedar e gerenciar alterações em seu código.
|
||||
|
||||
|
||||
> Sketchnote por [Tomomi Imura](https://twitter.com/girlie_mac)
|
||||
|
||||
## Quiz Pré-Aula
|
||||
[Quiz Pré-Aula](https://nice-beach-0fe9e9d0f.azurestaticapps.net/quiz/3)
|
||||
|
||||
## Introdução
|
||||
|
||||
Nesta lição vamos falar sobre:
|
||||
|
||||
- rastreando o trabalho que você faz em sua máquina
|
||||
- trabalhando em projetos com outros
|
||||
- como contribuir com software de código aberto
|
||||
|
||||
### Pré-requisitos
|
||||
|
||||
Antes de começar, você precisará verificar se o Git está instalado. No terminal, digite:
|
||||
`git --version`
|
||||
|
||||
Se o Git não estiver instalado, [baixe o Git aqui](https://git-scm.com/downloads). Em seguida, configure seu perfil Git local no terminal:
|
||||
* `git config --global user.name "your-name"`
|
||||
* `git config --global user.email "your-email"`
|
||||
|
||||
Para verificar se o Git já está configurado, você pode digitar:
|
||||
`git config --list`
|
||||
|
||||
Você também precisará de uma conta do GitHub, um editor de código (como o Visual Studio Code) e abrir seu terminal (ou: prompt de comando).
|
||||
|
||||
Navegue para [github.com](https://github.com/) e crie uma conta, caso ainda não o tenha feito, ou faça login e preencha o seu perfil.
|
||||
|
||||
✅ O GitHub não é o único repositório de código do mundo; existem outros, mas o GitHub é o mais conhecido
|
||||
|
||||
### Preparação
|
||||
|
||||
Você precisará de uma pasta com um projeto de código em sua máquina local (laptop ou PC) e de um repositório público no GitHub, que servirá como um exemplo de como contribuir com os projetos de outras pessoas.
|
||||
|
||||
---
|
||||
|
||||
## Gerenciamento de código
|
||||
|
||||
Digamos que você tenha uma pasta localmente com algum projeto de código e deseja começar a monitorar seu progresso usando git - o sistema de controle de versão. Algumas pessoas comparam o uso do git a escrever uma carta de amor para o seu futuro eu. Lendo suas mensagens de commit dias, semanas ou meses depois, você será capaz de se lembrar por que tomou uma decisão, ou "reverter" uma mudança - isto é, quando você escreve boas "mensagens de commit".
|
||||
|
||||
### Tarefa: Faça um repositório e conmmit o código
|
||||
|
||||
1. **Crie um repositório no GitHub**. No GitHub.com, na guia de repositórios ou na barra de navegação superior direita, encontre o botão **new repo** .
|
||||
|
||||
1. Dê um nome ao seu repositório (pasta)
|
||||
1. Selecione **create repository**.
|
||||
|
||||
1. **Navegue até sua pasta de trabalho**. Em seu terminal, mude para a pasta (também conhecida como diretório) que deseja iniciar o rastreamento. Digite:
|
||||
|
||||
```bash
|
||||
cd [nome da sua pasta]
|
||||
```
|
||||
|
||||
1. **Inicialize um repositório git**. No seu projeto, digite:
|
||||
|
||||
```bash
|
||||
git init
|
||||
```
|
||||
|
||||
1. **Cheque status**. Para checar o status de seu repositório, digite:
|
||||
|
||||
```bash
|
||||
git status
|
||||
```
|
||||
|
||||
a saída pode ser parecida com esta:
|
||||
|
||||
```output
|
||||
Changes not staged for commit:
|
||||
(use "git add <file>..." to update what will be committed)
|
||||
(use "git checkout -- <file>..." to discard changes in working directory)
|
||||
|
||||
modified: file.txt
|
||||
modified: file2.txt
|
||||
```
|
||||
|
||||
Geralmente o comando `git status` diz a você coisas como quais arquivos estão prontos para serem _salvos_ para o repo ou tem alterações que você pode querer persistir.
|
||||
|
||||
1. **Adicionar todos os arquivos para rastreamento**
|
||||
Isso também é chamado de arquivos de teste / adição de arquivos à área de teste.
|
||||
|
||||
```bash
|
||||
git add .
|
||||
```
|
||||
|
||||
O argumento `git add` plus `.` indiciona todos os seus arquivos e alterações para rastreamento.
|
||||
|
||||
1. **Adicionar arquivos selecionados para rastreamento**
|
||||
|
||||
```bash
|
||||
git add [nome do arquivo ou pasta]
|
||||
```
|
||||
|
||||
Isso nos ajuda a adicionar apenas os arquivos selecionados à área de teste quando não queremos enviar todos os arquivos de uma vez.
|
||||
|
||||
1. **Unstage todos os arquivos**
|
||||
|
||||
```bash
|
||||
git reset
|
||||
```
|
||||
Este comando nos ajuda a unstage todos os arquivos de uma vez.
|
||||
|
||||
1. **Unstage um arquivo em particular**
|
||||
|
||||
```bash
|
||||
git reset [nome do arquivo ou pasta]
|
||||
```
|
||||
|
||||
Este comando nos ajuda a remover stage de apenas um arquivo específico de uma vez que não queremos incluir no próximo commit.
|
||||
|
||||
1. **Persistindo no seu trabalho**. Neste ponto, você adicionou os arquivos a um local chamado _staging area_. Um lugar onde o Git está rastreando seus arquivos. Para tornar a mudança permanente, você precisa _committar_ os arquivos. Para fazer isso, crie um _commit_ com o comando `git commit`. Um _commit_ representa um ponto na história do seu repo sendo salvo. Digite o seguinte para criar um _commit_:
|
||||
|
||||
```bash
|
||||
git commit -m "first commit"
|
||||
```
|
||||
|
||||
Isso confirma todos os seus arquivos, adicionando a mensagem "first commit" (primeiro commit). Para mensagens de commit futuras, você desejará ser mais descritiva em sua descrição para transmitir que tipo de mudança você fez.
|
||||
|
||||
1. **Conecte seu repositório Git local com GitHub**. Um repositório Git é bom em sua máquina, mas em algum momento você vai querer fazer backup de seus arquivos em algum lugar e também convidar outras pessoas para trabalhar com você em seu repositório. Um ótimo lugar para fazer isso é o GitHub. Lembre-se de que já criamos um repositório no GitHub, então a única coisa que precisamos fazer é conectar nosso repositório Git local ao GitHub. O comando `git remote add` fará exatamente isso. Digite o seguinte comando:
|
||||
|
||||
> Antes de digitar o comando, vá para a página do repositório GitHub para encontrar o URL do repositório. Você o usará no comando abaixo. Substitua `repository_name` pelo seu URL do GitHub.
|
||||
|
||||
```bash
|
||||
git remote add origin https://github.com/username/repository_name.git
|
||||
```
|
||||
|
||||
Isso cria um _remote_, ou conexão, chamada "origin" apontando para o repositório GitHub que você criou anteriormente.
|
||||
|
||||
1. **Envie arquivos locais para GitHub**. Até agora, você criou uma _conexão_ entre o repositório local e o repositório GitHub. Vamos enviar esses arquivos para o GitHub com o seguinte comando `git push`, assim:
|
||||
|
||||
```bash
|
||||
git push -u origin main
|
||||
```
|
||||
|
||||
Isso envia seus commits em seu branch "principal" para o GitHub.
|
||||
|
||||
1. **Para adicionar mais mudanças**. Se quiser continuar fazendo alterações e enviando-as para o GitHub, você só precisará usar os três comandos a seguir:
|
||||
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "digite sua mensagem de commit aqui"
|
||||
git push
|
||||
```
|
||||
|
||||
> Dica, você também pode adotar um arquivo `.gitignore` para evitar que arquivos que você não deseja rastrear apareçam no GitHub - como aquele arquivo de notas que você armazena na mesma pasta, mas não tem lugar em um repositório público. Você pode encontrar modelos para arquivos `.gitignore` em [modelos .gitignore](https://github.com/github/gitignore).
|
||||
|
||||
#### Mensagens de Commit
|
||||
|
||||
Uma ótima mensagem de Git commit completa a seguinte frase:
|
||||
Se aplicado, este commit irá <sua mensagem de commit aqui>
|
||||
|
||||
Para o assunto use o tempo presente imperativo: "mudar" e não "mudou" nem "muda".
|
||||
Assim como no sujeito, no corpo (opcional) também use o tempo presente imperativo. O corpo deve incluir a motivação para a mudança e contrastar isso com o comportamento anterior. Você está explicando o `porquê`, não o` como`.
|
||||
|
||||
✅ Reserve alguns minutos para navegar no GitHub. Você consegue encontrar uma mensagem de commit realmente ótima? Você pode encontrar uma ruim? Quais informações você acha que são as mais importantes e úteis para transmitir em uma mensagem de commit?
|
||||
|
||||
### Tarefa: Colabore
|
||||
|
||||
O principal motivo para colocar coisas no GitHub foi possibilitar a colaboração com outros desenvolvedores.
|
||||
|
||||
## Trabalhando em projetos com outras pessoas
|
||||
|
||||
Em seu repositório, navegue até `Insights> Community` para ver como seu projeto se compara aos padrões recomendados da comunidade.
|
||||
|
||||
Aqui estão algumas coisas que podem melhorar seu repositório GitHub:
|
||||
- **Descrição**. Você adicionou uma descrição para o seu projeto?
|
||||
- **README**. Você adicionou um README? O GitHub fornece orientação para escrever um [README](https://docs.github.com/articles/about-readmes/).
|
||||
- **Guia de Contribuição**. Seu projeto tem um [guia para contribuição](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/),
|
||||
- **Código de Conduta**. Um [Código de Conduta](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/),
|
||||
- **Licença**. Talvez o mais importante, a [licença](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
|
||||
|
||||
|
||||
Todos esses recursos irão beneficiar a integração de novos membros da equipe. E esses são normalmente o tipo de coisas que os novas pessoas colaboradoras olham antes mesmo de olhar para o seu código, para descobrir se o seu projeto é o lugar certo para elas passarem o tempo.
|
||||
|
||||
✅ Arquivos README, embora levem tempo para serem preparados, são freqüentemente negligenciados por pessoas mantenedores ocupadas. Você pode encontrar um exemplo particularmente descritivo? Nota: existem algumas [ferramentas para ajudar a criar bons READMEs](https://www.makeareadme.com/) que você pode querer experimentar.
|
||||
|
||||
### Tarefa: Dar merge em algum código
|
||||
|
||||
Documentos contribuintes ajudam as pessoas a contribuir para o projeto. Ele explica quais tipos de contribuições você está procurando e como funciona o processo. As pessoas colaboradoras precisarão seguir uma série de etapas para poder contribuir com seu repo no GitHub:
|
||||
|
||||
|
||||
1. **Bifurcando seu repo** Você provavelmente vai querer que as pessoas _fork_ seu projeto. Bifurcação significa criar uma réplica de seu repositório em seu perfil GitHub.
|
||||
1. **Clone**. A partir daí, elas clonarão o projeto em sua máquina local.
|
||||
1. **Crie um branch**. Você vai querer pedir a elas que criem um _branch_ para seu trabalho.
|
||||
1. **Concentre sua mudança em uma área**. Peça aos colaboradores para concentrarem suas contribuições em uma coisa de cada vez - dessa forma, as chances de você se _mergir_ no trabalho delas são maiores. Imagine que elas escrevam uma correção de bug, adicionem um novo recurso e atualizem vários testes - e se você quiser ou só puder implementar 2 de 3, ou 1 de 3 alterações?
|
||||
|
||||
✅ Imagine uma situação em que os branches são particularmente críticos para escrever e distribuir bons códigos. Em quais casos de uso você consegue pensar?
|
||||
|
||||
> Nota, seja a mudança que você deseja ver no mundo e crie ramificações para o seu próprio trabalho também. Todos os commits que você fizer serão feitos no branch em que você está atualmente “check-out”. Use `git status` para ver qual branch é.
|
||||
|
||||
Vamos analisar o fluxo de trabalho de uma pessoa colaboradora. Suponha que ela já _forked_ e _cloned_ o repo para que ela tenha um repositório Git pronto para ser trabalhado, em sua máquina local:
|
||||
|
||||
1. **Crie um brancj**. Use o comando `git branch` para criar um branch que conterá as mudanças que pretendem contribuir:
|
||||
|
||||
```bash
|
||||
git branch [branch-name]
|
||||
```
|
||||
|
||||
1. **Mudar para o branch de trabalho**. Mude para o branch especificado e atualize o diretório de trabalho com `git checkout`:
|
||||
|
||||
```bash
|
||||
git checkout [branch-name]
|
||||
```
|
||||
|
||||
1. **Trabalhe**. Neste ponto, você deseja adicionar suas alterações. Não se esqueça de contar ao Git sobre isso com os seguintes comandos:
|
||||
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "minhas mudancas"
|
||||
```
|
||||
|
||||
Certifique-se de dar ao seu commit um bom nome, para seu bem e também para os mantenedores do repo no qual você está ajudando.
|
||||
|
||||
1. **Combine seu trabalho com o branch `main`**. Em algum ponto, você concluiu o trabalho e deseja combinar seu trabalho com o do branch `principal`. O branch `main` pode ter mudado enquanto isso, certifique-se de primeiro atualizá-lo para o mais recente com os seguintes comandos:
|
||||
|
||||
```bash
|
||||
git checkout main
|
||||
git pull
|
||||
```
|
||||
|
||||
Neste ponto, você quer ter certeza de que quaisquer _conflitos_, situações em que o Git não pode _combinar_ facilmente as mudanças aconteçam em seu branch de trabalho. Portanto, execute os seguintes comandos:
|
||||
|
||||
```bash
|
||||
git checkout [branch_name]
|
||||
git merge main
|
||||
```
|
||||
|
||||
Isso trará todas as mudanças de `main` em seu branch e esperançosamente você pode simplesmente continuar. Caso contrário, o VS Code dirá onde o Git está _confundido_ e você apenas alterará os arquivos afetados para dizer qual conteúdo é o mais preciso.
|
||||
|
||||
1. **Envie seu trabalho para o GitHub**. Enviar seu trabalho para o GitHub significa duas coisas. Enviando seu branch para o repo e, em seguida, abra um PR, Pull Request.
|
||||
|
||||
```bash
|
||||
git push --set-upstream origin [branch-name]
|
||||
```
|
||||
|
||||
O comando acima cria o branch em seu repositório bifurcado.
|
||||
|
||||
1. **Abra um PR**. Em seguida, você deseja abrir um PR. Você faz isso navegando até o repositório bifurcado no GitHub. Você verá uma indicação no GitHub onde pergunta se você deseja criar um novo PR, você clica nele e é levado a uma interface onde pode alterar o título da mensagem de commit, dê-lhe uma descrição mais adequada. Agora, a mantenedora do repo que você bifurcou verá este PR e _dedos cruzados_, eles apreciarão e _mergirão_ seu PR. Agora você é uma pessoa contribuidora, eba :)
|
||||
|
||||
1. **Limpeza**. É considerado uma boa prática _limpar_ após mesclar com sucesso um PR. Você deseja limpar seu branch local e o branch que você enviou para o GitHub. Primeiro, vamos excluí-lo localmente com o seguinte comando:
|
||||
|
||||
```bash
|
||||
git branch -d [branch-name]
|
||||
```
|
||||
|
||||
Em seguida, vá para a página GitHub do repositório bifurcado e remova o branch remoto que você acabou de enviar para ele.
|
||||
|
||||
`Pull request` parece um termo bobo porque na verdade você deseja enviar suas alterações para o projeto. Mas a pessoa mantendo o repo ou equipe central precisa considerar suas mudanças antes de fundi-las com o branch "principal" do projeto, então você está realmente solicitando uma decisão de mudança de uma pessoa mantenedora.
|
||||
|
||||
Uma PR é o lugar para comparar e discutir as diferenças introduzidas em um branch com revisões, comentários, testes integrados e muito mais. Uma boa PR segue aproximadamente as mesmas regras de uma mensagem de commit. Você pode adicionar uma referência a um problema no rastreador de problemas, quando seu trabalho, por exemplo, corrige um problema. Isso é feito usando um `#` seguido pelo número do seu problema. Por exemplo `# 97`.
|
||||
|
||||
🤞 Dedos cruzados para que todas as verificações sejam aprovadas e as pessoas proprietárias do projeto deem merge nas suas alterações no projeto🤞
|
||||
|
||||
Atualize seu branch de trabalho local atual com todos os novos commits do branch remoto correspondente no GitHub:
|
||||
|
||||
`git pull`
|
||||
|
||||
## Como contribuir com Open Source
|
||||
|
||||
Primeiramente, vamos encontrar um repositório (ou **repo**) no GitHub de interesse para você e para o qual você gostaria de contribuir. Você vai querer copiar o conteúdo para desse repo parasua máquina.
|
||||
|
||||
✅ Uma boa maneira de encontrar repos 'iniciantes' é [buscar usando a tag 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
|
||||
|
||||
|
||||
|
||||
Existem várias maneiras de copiar códigos. Uma maneira é "clonar" o conteúdo do repositório, usando HTTPS, SSH ou usando o GitHub CLI (Command Line Interface).
|
||||
|
||||
Abra seu terminal e clone o repositório assim:
|
||||
`git clone https://github.com/ProjectURL`
|
||||
|
||||
Para trabalhar no projeto, mude para a pasta certa:
|
||||
`cd ProjectURL`
|
||||
|
||||
Você também pode abrir todo o projeto usando [Codespaces](https://github.com/features/codespaces), O editor de código incorporado do GitHub/ ambiente de desenvolvimento em nuvem, ou o [GitHub Desktop](https://desktop.github.com/).
|
||||
|
||||
Por último, você pode baixar o código em uma pasta com zíper.
|
||||
|
||||
### Mais algumas coisas interessantes sobre o GitHub
|
||||
|
||||
Você pode dar uma strela, assistir e/ou "bifurcação" em qualquer repositório público no GitHub. Você pode encontrar seus repositórios estrelados no menu suspenso de cima para a direita. É como marcar, mas para código.
|
||||
|
||||
Os projetos têm um rastreador de problemas, no GitHub na aba "Problemas", a menos que indicado o contrário, onde as pessoas discutem questões relacionadas ao projeto. E a aba de Pull Requests é onde as pessoas discutem e analisam as mudanças que estão em andamento.
|
||||
|
||||
Os projetos também podem ter discussão em fóruns, listas de discussão ou canais de bate-papo como Slack, Discord ou IRC.
|
||||
|
||||
✅ Dê uma olhada no seu novo GitHub repo e experimente algumas coisas, como editar configurações, adicionar informações ao seu repo e criar um projeto (como uma placa Kanban). Há muita coisa que você pode fazer!
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Desafio
|
||||
|
||||
Parear com uma amiga para trabalhar no código uma da outra. Crie um projeto de forma colaborativa, de fork no código, crie branches e de merge mudanças.
|
||||
|
||||
## Quiz pós-aula
|
||||
[Quiz pós-aula](https://nice-beach-0fe9e9d0f.azurestaticapps.net/quiz/4)
|
||||
|
||||
## Revisão & Auto estudo
|
||||
|
||||
Leia mais sobre [contribuindo para o software de código aberto](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
|
||||
|
||||
[Git cheatsheet](https://training.github.com/downloads/github-git-cheat-sheet/).
|
||||
|
||||
Pratique, pratique, pratique. GitHub tem ótimos caminhos de aprendizagem disponíveis via [lab.github.com](https://lab.github.com/):
|
||||
|
||||
- [Primeira semana no GitHub](https://lab.github.com/githubtraining/first-week-on-github)
|
||||
|
||||
Você também encontrará laboratórios mais avançados.
|
||||
|
||||
## Lição de casa
|
||||
|
||||
Complete [o lab a Primeira Semana gitHub](https://lab.github.com/githubtraining/first-week-on-github)
|
||||
Reference in New Issue
Block a user