1
Last month I began introducing the various concepts and terminology used by Git. This month we'll be taking it a step further, and running through a series of examples on actually using Git (in combination with GitHub; creating a custom Git server falls outside of the scope of this article). I will be assuming you either have a free account with GitHub, or else that you have found someone's repository you'd like to clone. For anyone who is interested, I created a public repository for this article, which can be found here: https://github.com/lswest/Command-Conquer-Examples. Note: If you don't have a GitHub account, and are using someone's repository, you will not necessarily be able to push to them. You can create your own copy of the repository by forking it (requires an account as well).
Le mois dernier, j'ai commencé à introduire les différents concepts et la terminologie utilisés par Git. Ce mois-ci, nous allons aller un peu plus loin, et parcourir une série d'exemples sur l'usage réel de Git (en combinaison avec GitHub ; la création d'un serveur Git personnalisé est hors du cadre de cet article). Je supposerai que soit vous avez un compte gratuit sur GitHub, soit que vous avez trouvé un dépôt quelconque que vous aimeriez dupliquer. Pour ceux qui sont intéressés, j'ai créé un dépôt public pour cet article, qui peut être trouvé ici: https://github.com/lswest/Command-Conquer-Examples.
Remarque: Si vous n'avez pas de compte GitHub, et que vous utilisez le dépôt d'une autre personne, vous ne serez pas nécessairement en mesure de téléverser vers lui. Vous pouvez créer votre propre copie du dépôt par bifurcation (ça nécessite aussi un compte).
Step One: Create a Repository If you would prefer to use an existing repository (or not create a GitHub account), skip this step. At the very top of the screen when logged into GitHub, you'll see your username, and next to that a plus sign. Click the plus to create a new repository. You can enter the following information: Required: • Repository Name • Owner • Public/Private (Private is available to only paying members) Optional: • Description of the repository • Initialize with a README • .gitignore settings • Choosing a license for the repository.
Première étape: créer un dépôt
Si vous préférez utiliser un dépôt existant (ou ne pas créer un compte GitHub), ignorez cette étape.
Tout en haut de l'écran lorsque vous êtes connecté à GitHub, vous verrez votre nom d'utilisateur, et à côté un signe plus. Cliquez sur le signe plus pour créer un nouveau dépôt. Vous pouvez entrer les informations suivantes:
Requis: • Nom du dépôt • Propriétaire • Public/Privé (privé est disponible seulement pour les membres payants)
Facultatif: • Description du dépôt • Initialisation avec un Lisez-moi. • Paramétrage de .gitignore • Choix d'une licence pour le dépôt.
2
Step Two: Clone the Git Repository There are some GUI Tools for Linux, but for the sake of this article, I will refer to only the actual terminal commands: • Open a terminal. • cd to any subfolder where you want the repository located. • Enter: git clone https://github.com/lswest/Command-Conquer-Examples.git • Depending on the size of the repository, it may take a moment. Once you're back at your prompt, you have successfully cloned it. You may now want to cd into the repository folder (in my case: cd Command-Conquer-Examples).
Deuxième étape: Clone du dépôt Git
Il y a quelques outils avec interface graphique pour Linux, mais, pour les besoins de cet article, je vais me référer qu'aux seules commandes du terminal : • Ouvrez un terminal. • cd vers le sous-dossier où vous voulez que le dépôt soit placé. • Entrez :
git clone https://github.com/lswest/Command-Conquer-Examples.git
• Selon la taille du dépôt, ça peut prendre quelque temps. Une fois qu'on vous rend la main, vous l'avez cloné avec succès. Vous pouvez maintenant vouloir aller dans le dossier du dépôt (dans mon cas: cd Command-Conquer-Examples).
Step Three: Making Changes For the sake of this example, I'll be editing the README.md file. Naturally, the procedure is the same with any edit: • Open the file in your favourite editor. • Make your changes. • Once the file is saved, you then need the following command: git add <file> Note: if you want to add all files, simply use a period instead of the name of the file.
Troisième étape: Faire des changements
Pour les besoins de cet exemple, je vais éditer le fichier README.md. Naturellement, la procédure est la même pour toute autre modification : • Ouvrez le fichier dans votre éditeur de texte favori. • Effectuez vos modifications. • Une fois que le fichier est enregistré, vous devez ensuite entrer la commande suivante :
git add <fichier>
Remarque: si vous voulez ajouter tous les fichiers, il suffit d'utiliser un point à la place du nom du fichier.
3
Step Four: Commit Once you've added the file you want, and are ready to commit them into the next update to your repository, you can run the following command: git commit If you run the command like this without any arguments or parameters, it will prompt you to enter a message for the commit before finishing. A couple useful options are: • -a: Automatically adds any changes files (but ignores newly added/removed files). • -m <msg>: Uses the message supplied for the commit message – i.e. -m “First commit – edited README.md”.
Quatrième étape: Confirmation (Commit)
Une fois que vous avez ajouté le fichier que vous voulez et que vous êtes prêt à le confirmer dans la prochaine mise à jour de votre dépôt, vous pouvez exécuter la commande suivante:
git commit
Si vous exécutez la commande comme ceci sans aucun argument ni paramètres, elle vous invite à saisir un message pour la confirmation avant de terminer. Deux options utiles sont : • -a : ajoute automatiquement tous les fichiers modifiés (mais ignore les fichiers nouvellement ajoutés ou supprimés). • -m <msg> : Utilise le message fourni comme message de confirmation, exemple : -m “Première confirmation - modif du README.md”.
Step Five: Push Now that you've created a commit listing all the changes you want to take over onto the remote repository, you're ready to synchronize them. In Git this is called a push. The format of the command is: git push <local> <remote> By default when using Github, the local will be origin, and the remote will be master. If you're working on a more complicated repository, you'll need to check the exact branch names. In this example, the command will most likely be: git push origin master If you haven't configured git to store your username and password for Github, you'll be prompted for those now. As is the custom in Linux, the prompt for the password will not display any characters at all, but will indeed register your keystrokes.
Cinquième étape: Poussée (Push)
Maintenant que vous avez créé une liste de confirmation de tous les changements que vous voulez envoyer sur le dépôt distant, vous êtes prêt à les synchroniser. Dans Git cela s'appelle une poussée. Le format de la commande est :
git push <local> <distant>
Par défaut lors de l'utilisation de Github, le local sera l'origine et le distant sera le maître. Si vous travaillez sur un dépôt plus compliqué, vous aurez besoin de vérifier l'exactitude des noms de branche. Dans cet exemple, la commande sera probablement:
git push origin master
Si vous n'avez pas configuré git pour stocker votre nom d'utilisateur et votre mot de passe pour Github, vous serez invité à les donner maintenant. Comme c'est la coutume dans Linux, le mot de passe ne s'affichera pas, mais enregistrera réellement vos frappes au clavier.
4
Step Six: Checking the Remote Once you've pushed your changes, you'll see the newest commit listed on the repository page. The commit message appears only on files that were affected by it. This helps to keep track of which files aren't being changed frequently. Further Possibilities Possibility One: Adding a New File In step 3, we discussed how to edit files that already exist in the repository. First create a new file using whatever method you need, and then add it to a commit with git add <file>. Once you've added it, follow steps 4-5. Possibility Two: Removing a File If you want to remove a file from the repository, simply deleting it from the filesystem isn't enough. You'd need to use the git command, git rm. Once a file is deleted with this (i.e. git rm “Adding a file.txt”), you can then commit the change and push it to the repository, by following the steps 4-5. Hopefully this article has helped to shed some light on using GitHub and Git repositories. If you have any difficulties, or want information on a specific scenario, feel free to email me with your questions. As always, I can be reached at lswest34+fcm@gmail.com. For anyone who is interested in hosting their own git servers, I would be happy to write an article on this topic too (if there is sufficient interest).
Sixième étape: Vérification du dépôt distant
Une fois que vous avez poussé vos changements, vous verrez la confirmation la plus récente affichée sur la page du dépôt. Le message de confirmation apparaît uniquement sur les fichiers qui ont été touchés par elle. Cela aide à garder la trace des fichiers qui ne sont pas changés fréquemment.
Autres possibilités
Possibilité Une: Ajout d'un nouveau fichier
Dans l'étape 3, nous avons discuté de la façon de modifier les fichiers qui existent déjà dans le dépôt. Tout d'abord créez un nouveau fichier en utilisant la méthode que vous souhaitez, puis l'ajoutez à une confirmation avec git add <fichier>. Une fois que vous l'avez ajouté, suivez les étapes 4 et 5.
Possibilité Deux: Suppression d'un fichier
Si vous souhaitez supprimer un fichier du dépôt, le supprimer simplement du système de fichiers n'est pas suffisant. Vous aurez besoin d'utiliser la commande « git rm ». Une fois qu'un fichier est supprimé de cette façon (ex: git rm “Ajout d'un fichier.txt”), vous pouvez ensuite confirmer la modification et la pousser vers le dépôt, en suivant les étapes 4 et 5.
J'espère que cet article vous a aidé à faire la lumière sur l'utilisation des dépôts Git et GitHub. Si vous avez des difficultés, ou souhaitez des informations sur un scénario spécifique, n'hésitez pas à m'envoyer un courriel avec vos questions. Comme toujours, je peux être joint à lswest34+fcm@gmail.com. Pour ceux qui voudraient héberger leurs propres serveurs git, je serais heureux d'écrire un article sur ce sujet-là aussi (s'il y a suffisamment d'intérêt).