- Premièrement : Qu'est-ce que Git ?
- Deuxièmement : quelle est la principale différence entre SVN et Git ?
- 3. Comment installer Git sur Windows ?
- Quatre : Comment fonctionner ?
- Quatre : Git annule les opérations de modification et de suppression de fichiers
- Cinq : entrepôt distant
- Six : Créer et fusionner des branches
- Sept : branche de bug
- Huit : collaboration à plusieurs personnes
Premièrement : Qu'est-ce que Git ?
Git est actuellement le système de contrôle de version distribué le plus avancé au monde.
Principe/processus de fonctionnement :
- Espace de travail : Espace de travail
- Index / Scène : zone de stockage temporaire
- Dépôt : zone d'entrepôt (ou entrepôt local)
- À distance : entrepôt distant
Deuxièmement : quelle est la principale différence entre SVN et Git ?
SVN est un système de contrôle de version centralisé. La bibliothèque de versions est centralisée sur le serveur central. Lorsque vous travaillez, vous utilisez votre propre ordinateur, vous devez donc d'abord obtenir la dernière version du serveur central, puis travailler. Enfin, vous devez pousser le travail que vous avez effectué sur le serveur central. Le système de contrôle de version centralisé doit être connecté à Internet pour fonctionner. Si tout fonctionne correctement sur le réseau local, la bande passante est suffisamment grande et la vitesse est suffisamment rapide. S'il est sous Internet, si la vitesse du réseau est lente , ce sera déroutant.
Git est un système de contrôle de versions distribué, il n'a donc pas de serveur central. L'ordinateur de chacun est une bibliothèque de versions complète. De cette façon, il n'est pas nécessaire de se connecter à Internet pour travailler, car les versions sont toutes sur leur propre ordinateur. . Puisque l’ordinateur de chacun dispose d’un référentiel complet, comment plusieurs personnes peuvent-elles collaborer ? Par exemple, si vous modifiez le fichier A sur votre ordinateur et que quelqu'un d'autre modifie le fichier A sur votre ordinateur, à ce stade, vous n'avez qu'à transmettre vos modifications l'un à l'autre, puis vous pourrez voir les modifications de chacun.
3. Comment installer Git sur Windows ?
msysgit est la version Windows de Git, comme suit :
Vous devez en télécharger un sur Internet, puis l'installer par défaut. Une fois l'installation terminée, recherchez « Git --> Git Bash » dans le menu Démarrer, comme suit :
Une fenêtre de commande similaire apparaîtra, indiquant que Git est installé avec succès. comme suit:
Une fois l'installation terminée, la dernière étape consiste à configurer, entrez ce qui suit sur la ligne de commande :
Git étant un système de contrôle de version distribué, vous devez renseigner le nom d'utilisateur et l'adresse e-mail comme identifiant.
Remarque : le paramètre git config --global, avec ce paramètre, signifie que tous les entrepôts Git de votre machine utiliseront cette configuration. Bien sûr, vous pouvez également spécifier un nom d'utilisateur et une adresse e-mail différents pour un certain entrepôt.
Quatre : Comment fonctionner ?
Un : créez un référentiel.
Qu'est-ce qu'un référentiel ? La bibliothèque de versions est également connue sous le nom d'entrepôt, et le nom anglais est référentiel. Vous pouvez simplement comprendre un répertoire. Tous les fichiers de ce répertoire peuvent être gérés par Git. Git peut suivre la modification et la suppression de chaque fichier, afin qu'il peut être suivi à tout moment dans l'historique, ou à un moment donné dans le futur, le fichier peut être « rétabli ».
Donc créer une bibliothèque de versions est également très simple, comme suit, je suis le lecteur D -> créer une nouvelle bibliothèque de versions testgit sous le répertoire www.
La commande pwd permet d'afficher le répertoire courant.
Utilisez la commande git init pour transformer ce répertoire en un entrepôt que git peut gérer, comme suit :
À ce stade, il y aura un répertoire .git sous votre répertoire testgit actuel. Ce répertoire est utilisé par Git pour suivre et gérer la version. Ne modifiez pas manuellement les fichiers dans ce répertoire, sinon l'entrepôt git sera détruit. comme suit:
Jetons un coup d'œil à la démo comme suit :
J'ai créé un nouveau fichier bloc-notes readme.txt dans le répertoire testgit de la bibliothèque de versions avec le contenu suivant : 11111111
Étape 1 : Utilisez la commande git add readme.txt pour ajouter à la zone de stockage temporaire. comme suit:
S'il s'agit de la même chose que ci-dessus, aucune invite n'apparaît indiquant qu'il a été ajouté avec succès.
Étape 2 : utilisez la commande git commit pour indiquer à Git de soumettre le fichier à l'entrepôt.
Maintenant que nous avons soumis un fichier readme.txt, nous pouvons utiliser la commande git status pour vérifier s'il existe des fichiers non soumis, comme suit :
Cela signifie qu'il n'y a aucun fichier non soumis, mais je continuerai à modifier le contenu du fichier readme.txt. Par exemple, j'ajoute une ligne de 2222222222 ci-dessous et je continue d'utiliser git status pour afficher les résultats, comme suit :
La commande ci-dessus nous indique que le fichier readme.txt a été modifié, mais que la modification n'a pas été validée.
Ajoutez le fichier au référentiel.
Tout d'abord, il doit être clair que tous les systèmes de contrôle de version ne peuvent suivre que les modifications apportées aux fichiers texte, tels que les fichiers txt, les pages Web, les codes de tous les programmes, etc. Git ne fait pas exception. Le système de contrôle de version peut vous indiquer chaque changement, mais l'image, les fichiers binaires vidéo, bien qu'ils puissent également être gérés par le système de contrôle de version, mais il n'y a aucun moyen de suivre les modifications des fichiers. Nous ne pouvons qu'enchaîner chaque modification des fichiers binaires, c'est-à-dire , nous savons que l'image est passée de 1 Ko à 2 Ko, mais qu'est-ce qui a changé ? , le contrôle de version ne le sait pas non plus.
Ensuite, je veux voir ce qui a été modifié dans le fichier readme.txt, comment le vérifier ? Vous pouvez utiliser les commandes suivantes :
git diff readme.txt est le suivant :
Comme on peut le voir ci-dessus, le contenu du fichier readme.txt a été modifié d'une ligne 11111111 à deux lignes et une ligne 22222222 a été ajoutée.
Après avoir connu quelles modifications ont été apportées au fichier readme.txt, nous pouvons le soumettre à l'entrepôt en toute confiance. Soumettre la modification revient à soumettre le fichier en 2 étapes (la première étape est git add et la deuxième étape est : git commit).
comme suit:
Deux : restauration de la version :
Comme ci-dessus, nous avons appris à modifier le fichier, maintenant je continue à modifier le fichier readme.txt, et j'ajoute une autre ligne
Le contenu est 33333333333333. Continuez à exécuter la commande comme suit :
Maintenant, j'ai modifié le fichier readme.txt trois fois, je souhaite donc vérifier l'historique, comment le vérifier ? Nous pouvons maintenant démontrer l'utilisation de la commande git log comme suit :
La commande git log affiche les journaux d'affichage du plus proche au plus éloigné. Nous pouvons voir les trois dernières soumissions. La dernière fois est l'ajout de 333333. La dernière fois était l'ajout de 222222, et la première valeur par défaut est 111111. Si le affichage ci-dessus S'il y a trop d'informations, nous pouvons utiliser la commande git log –pretty=oneline pour démontrer ce qui suit :
Maintenant, je souhaite utiliser l'opération de restauration de version. Je souhaite restaurer la version actuelle vers la version précédente. Quelle commande dois-je utiliser ? Vous pouvez utiliser les deux commandes suivantes, la première est : git reset --hard HEAD^ Ensuite, si vous souhaitez revenir à la version précédente, remplacez simplement HEAD^ par HEAD^^ et ainsi de suite. Si vous souhaitez revenir aux 100 premières versions, il n'est certainement pas pratique d'utiliser la méthode ci-dessus.Nous pouvons utiliser la commande simple suivante pour fonctionner : git reset --hard HEAD~100. Le contenu du fichier readme.txt avant la restauration est le suivant :
Si vous souhaitez revenir à la version précédente, la commande est la suivante :
Vérifions le contenu du fichier readme.txt comme suit : Afficher par commande cat readme.txt
Comme vous pouvez le constater, le contenu est revenu à la version précédente. Nous pouvons continuer à utiliser git log pour afficher les informations de l'historique, comme suit :
Nous avons vu que le contenu de 333333 a été ajouté et nous ne l'avons pas vu, mais maintenant je souhaite revenir à la dernière version, comme par exemple : comment restaurer le contenu de 333333 ? Nous pouvons restaurer le numéro de version en utilisant la méthode de commande suivante :
git reset --hard numéro de version, mais le problème maintenant est que si j'ai désactivé la ligne de commande une fois ou le numéro de version du contenu 333, je ne le connais pas ? Comment connaître le numéro de version pour ajouter du contenu 3333 ? Le numéro de version peut être obtenu grâce à la commande suivante : git reflog La démonstration est la suivante :
À partir de l'affichage ci-dessus, nous pouvons savoir que le numéro de version du contenu ajouté 3333 est 6fcfc89. Nous pouvons maintenant commander
git reset --hard 6fcfc89 à restaurer. La démonstration est la suivante :
Vous pouvez voir qu'il s'agit de la dernière version.
Troisièmement : Comprendre la différence entre la zone de travail et la zone de stockage temporaire ?
- Espace de travail : il s'agit du répertoire que vous voyez sur votre ordinateur, comme les fichiers dans testgit sous le répertoire (à l'exception du référentiel de répertoires cachés .git). Ou les fichiers de répertoire qui devront être créés à l'avenir, etc. appartiennent tous à la catégorie de la zone de travail.
- Référentiel : L'espace de travail a un répertoire caché .git, qui n'appartient pas à l'espace de travail, mais il s'agit du référentiel. Il y a beaucoup de choses stockées dans la bibliothèque de versions, dont la plus importante est la scène (zone de stockage temporaire), et Git a automatiquement créé la première branche master pour nous, ainsi qu'un pointeur HEAD pointant vers le maître.
Nous avons dit plus tôt que l'utilisation de Git pour soumettre des fichiers au référentiel comportait deux étapes :
- Il s'agit d'utiliser git add pour ajouter des fichiers, ce qui consiste en fait à ajouter des fichiers à la zone de stockage temporaire.
- Utiliser git commit pour soumettre des modifications revient en fait à soumettre tout le contenu de la zone de stockage temporaire à la branche actuelle.
Continuons à utiliser la démo pour démontrer :
Nous ajoutons une autre ligne au readme.txt avec le contenu 4444444, puis créons un nouveau fichier dans le répertoire nommé test.txt avec le contenu de test. Nous utilisons d'abord la commande git status pour vérifier l'état, comme suit :
Nous utilisons maintenant la commande git add pour ajouter les deux fichiers à la zone de stockage temporaire, puis utilisons git status pour afficher l'état, comme suit :
Ensuite, nous pouvons utiliser git commit pour soumettre à la branche en une seule fois, comme suit :
Quatre : Git annule les opérations de modification et de suppression de fichiers
Un : Annuler la modification :
Par exemple, j'ajoute maintenant une ligne de 555555555555 dans le fichier readme.txt, vérifions-la via la commande comme suit :
Avant de soumettre, j'ai trouvé que le contenu de l'ajout de 5555555555555 était erroné, j'ai donc dû restaurer la version précédente immédiatement, et je peux maintenant apporter des modifications des manières suivantes :
- Si je sais que je souhaite supprimer ce contenu, je peux directement modifier et supprimer manuellement les fichiers requis, puis les ajouter à la zone de stockage temporaire et enfin les valider.
- Je peux revenir directement à la version précédente comme avant. Utilisez git reset --hard HEAD^
Mais maintenant, je ne veux pas utiliser les deux méthodes ci-dessus, je veux utiliser directement la commande d'annulation, comment faire ? Tout d’abord, avant d’annuler, nous pouvons utiliser git status pour vérifier l’état actuel. Comme suit:
On peut constater que Git vous dira que git checkout -- file peut ignorer la modification de l'espace de travail, comme suit :
git checkout -- readme.txt, comme suit :
La commande git checkout --readme.txt signifie annuler toutes les modifications apportées dans l'espace de travail au fichier readme.txt. Il y a ici deux situations, les suivantes :
- Une fois le fichier readme.txt automatiquement modifié, il n'a pas été placé dans la zone de stockage temporaire et il reviendra au même état que la bibliothèque de versions après avoir utilisé la modification d'annulation.
- L'autre est que readme.txt a été placé dans la zone de stockage temporaire, puis modifié, et la modification reviendra à l'état après l'ajout de la zone de stockage temporaire.
Pour le deuxième cas, je pense qu'on va continuer à faire la démo pour voir, si j'ajoute une ligne de contenu 6666666666666 au readme. Elle revient à l'état après la zone de staging. Comme suit:
Remarque : La commande git checkout -- -- dans readme.txt est très importante, s'il n'y a pas de --, alors la commande devient pour créer une branche.
Deux : supprimez le fichier
Si j'ajoute maintenant un fichier b.txt au répertoire testgit du référentiel et que je le soumets. comme suit:
Comme ci-dessus : En général, vous pouvez supprimer le fichier directement dans le répertoire de fichiers, ou utiliser la commande rm ci-dessus : rm b.txt, si je souhaite supprimer complètement ce fichier du référentiel, je peux exécuter la commande commit pour le soumettre , maintenant le répertoire ressemble à ceci,
Tant qu'il n'y a pas de commit auparavant, que dois-je faire si je souhaite restaurer ce fichier dans le référentiel ?
Vous pouvez utiliser la commande git checkout -- b.txt comme suit :
Jetons un coup d'œil à notre répertoire testgit et ajoutons 3 fichiers. Comme suit:
Cinq : entrepôt distant
Avant de comprendre, enregistrez d'abord un compte github. Puisque la transmission entre votre entrepôt Git local et l'entrepôt github est cryptée par SSH, un petit paramétrage est requis :
Étape 1 : Créez une clé SSH. Dans le répertoire personnel de l'utilisateur, vérifiez s'il existe un répertoire .ssh. Si c'est le cas, vérifiez s'il y a deux fichiers id_rsa et id_rsa.pub dans ce répertoire. Si oui, ignorez directement la commande suivante. Sinon, ouvrez la ligne de commande, et entrez la commande suivante :
ssh-keygen -t rsa –C « [email protected] », car je l'ai déjà exécuté localement, donc je l'ai localement, comme indiqué ci-dessous :
id_rsa est la clé privée, qui ne peut pas être divulguée, et id_rsa.pub est la clé publique, qui peut être communiquée à toute personne en toute confiance.
Étape 2 : Connectez-vous à github, ouvrez la page Clés SSH dans « Paramètres », puis cliquez sur « Ajouter une clé SSH », remplissez n'importe quel titre et collez le contenu du fichier id_rsa.pub dans la zone de texte Clé.
Cliquez sur Ajouter une clé et vous devriez voir la clé ajoutée.
Comment ajouter une bibliothèque distante ?
La situation actuelle est la suivante : après avoir créé un entrepôt Git localement, nous voulons créer un entrepôt Git dans github, et espérons que les deux entrepôts pourront être synchronisés à distance, afin que l'entrepôt github puisse être utilisé comme sauvegarde, et d'autres personnes peut passer par l’entrepôt pour collaborer.
Tout d'abord, connectez-vous à github, puis recherchez « créer un nouveau dépôt » dans le coin supérieur droit pour créer un nouvel entrepôt. comme suit:
Remplissez testgit dans le nom du référentiel, conservez les paramètres par défaut et cliquez sur le bouton « Créer un référentiel » pour créer avec succès un nouveau référentiel Git :
À l'heure actuelle, l'entrepôt testgit sur GitHub est toujours vide. GitHub nous dit que nous pouvons cloner un nouvel entrepôt à partir de cet entrepôt, ou lui associer un entrepôt local existant, puis transférer le contenu de l'entrepôt local vers GitHub.
Maintenant, nous exécutons la commande sous l'entrepôt testgit local selon l'invite de GitHub :
git remote add origin https://github.com/tugenhua0707/testgit.git
Tout comme suit :
Pour pousser le contenu de la bibliothèque locale vers la télécommande, utilisez la commande git push pour pousser le maître de branche actuel vers la télécommande.
Puisque la bibliothèque distante est vide, lorsque nous poussons la branche master pour la première fois, nous ajoutons le paramètre –u, Git poussera non seulement le contenu de la branche master locale vers la nouvelle branche master distante, mais poussera également la branche master locale. branche et la branche distante La branche maître peut être associée pour simplifier la commande lors d'une poussée ou d'une traction ultérieure. Une fois le push réussi, vous pouvez immédiatement voir sur la page github que le contenu de la bibliothèque distante est exactement le même que celui de la bibliothèque locale. Le nom d'utilisateur et le mot de passe pour accéder à github sont les suivants :
Désormais, tant que le commit est effectué localement, vous pouvez passer la commande suivante :
git push origin master
Poussez la dernière modification de la branche principale locale vers github, et vous disposez désormais d'une véritable bibliothèque de versions distribuées.
Comment cloner depuis un référentiel distant ?
Ci-dessus, nous avons appris comment associer une bibliothèque distante lorsqu'il existe d'abord une bibliothèque locale puis une bibliothèque distante.
Nous réfléchissons maintenant : si la bibliothèque distante a un nouveau contenu, comment puis-je la cloner localement si je souhaite la cloner ?
Tout d’abord, connectez-vous à github et créez un nouvel entrepôt nommé testgit2 comme suit :
Comme suit, nous voyons :
Maintenant que le référentiel distant est prêt, l'étape suivante consiste à cloner un référentiel local à l'aide de la commande git clone. Comme suit:
Ensuite, le répertoire testgit2 est généré dans mon répertoire local, comme suit :
Six : Créer et fusionner des branches
Dans le remplissage de version, vous savez déjà que pour chaque commit, Git les enchaîne dans une chronologie, et cette chronologie est une branche. Pour l’instant, il n’existe qu’une seule timeline : dans Git, cette branche est appelée la branche principale, la branche master. À proprement parler, HEAD ne pointe pas vers la soumission, mais vers le maître, et le maître pointe vers la soumission. Par conséquent, HEAD pointe vers la branche actuelle.
Commençons par créer une branche dev, puis passons à la branche dev. Procédez comme suit :
La commande git checkout plus le paramètre –b signifie créer et changer, ce qui équivaut aux deux commandes suivantes
- développeur de branche git
- développeur de paiement git
git branch Afficher les branches, toutes les branches seront répertoriées et un astérisque sera ajouté devant la branche actuelle. Ensuite on continue à faire la démo sur la branche dev, par exemple, on ajoute maintenant une autre ligne 7777777777777 dans readme.txt
Tout d'abord, vérifions le contenu du fichier readme.txt, puis ajoutons le contenu 77777777, comme suit :
Maintenant que le travail de la branche de développement est terminé, nous passons maintenant au maître de la branche principale et continuons à afficher le contenu du fichier readme.txt comme suit :
Nous pouvons maintenant fusionner le contenu de la branche dev dans la branche master. Sur la branche master, utilisez la commande suivante git merge dev comme indiqué ci-dessous :
La commande git merge est utilisée pour fusionner la branche spécifiée avec la branche actuelle. Après la fusion, vérifiez le contenu du fichier readme.txt. Vous pouvez voir qu'il est exactement le même que la dernière soumission de la branche dev.
En remarquant les informations d'avance rapide ci-dessus, Git nous a dit que cette fusion était en "mode avance rapide", c'est-à-dire que le maître est directement pointé vers le commit actuel du développeur, donc la vitesse de fusion est très rapide.
Une fois la fusion terminée, nous pouvons alors supprimer la branche dev, comme suit :
Résumez les commandes de création et de fusion de branches comme suit :
- Afficher la branche : branche git
- Créer une branche : nom de la branche git
- Changer de branche : nom de la caisse git
- Créer + changer de branche : git checkout –b nom
- Fusionner une branche dans la branche actuelle : git merge name
- Supprimer la branche : git branch –d nom
Comment résoudre les conflits ?
Ensuite, procédons étape par étape, créons d'abord une nouvelle branche, par exemple, le nom est fenzhi1, ajoutons une ligne de contenu 8888888 dans readme.txt, puis soumettez-la, comme indiqué ci-dessous :
De même, nous passons maintenant à la branche master et ajoutons du contenu à la dernière ligne, qui est 99999999, comme indiqué ci-dessous :
Nous devons maintenant fusionner fenzhi1 sur la branche master, comme suit :
Git utilise <<<<<<<, =======, >>>>>>> pour marquer le contenu des différentes branches, où <<<HEAD fait référence au contenu modifié par la branche principale, >> >>> fenzhi1 fait référence au contenu modifié sur fenzhi1, on peut le modifier comme suit et le sauvegarder :
Si je veux vérifier la situation de fusion de branches, je dois utiliser la commande git log. La démonstration en ligne de commande est la suivante :
stratégie de gestion de succursale
Habituellement, lors de la fusion de branches, git utilise généralement le mode "Avance rapide". Dans ce mode, après la suppression de la branche, les informations de la branche seront perdues. Nous utilisons maintenant le paramètre --no-ff pour désactiver le mode "Avance rapide". . Tout d’abord, faisons une démonstration :
- Créez une branche de développement.
- Modifiez le contenu du fichier readme.txt.
- ajouté à la zone de préparation.
- Revenez à la branche principale (maître).
- Pour fusionner la branche dev, utilisez la commande git merge –no-ff -m "comment" dev
- voir l'historique
Capture d'écran ci-dessous :
Stratégie de branchement : Tout d'abord, la branche principale de master doit être très stable, c'est-à-dire qu'elle est utilisée pour publier de nouvelles versions. En général, il n'est pas autorisé de travailler dessus. En général, le travail est effectué sur la branche nouvellement créée. branche de développement. Une fois le travail terminé, par exemple Pour être publié, ou le code de la branche de développement peut être fusionné dans la branche principale principale une fois qu'il est stable.
Sept : branche de bug
En développement, vous rencontrerez souvent des bugs, donc si vous avez un bug, vous devez le corriger. Dans Git, les branches sont très puissantes. Chaque bug peut être corrigé via une branche temporaire. Une fois le correctif terminé, fusionnez le branche, puis La branche temporaire est supprimée.
Par exemple, lorsque je reçois un bug 404 pendant le développement, nous pouvons créer une branche 404 pour le corriger, mais le travail sur la branche de développement actuelle n'a pas encore été soumis. Par exemple comme suit :
Ce n'est pas que je ne veux pas soumettre, mais à mi-chemin du travail, nous ne pouvons toujours pas soumettre. Par exemple, mon bug de branche doit être terminé dans 2 jours, mais mon bug issue-404 doit être terminé dans 5 jours. heures. Comment faire? Heureusement, Git fournit également une fonction de cache, qui peut « masquer » le site de travail actuel et continuer à travailler après avoir restauré le site ultérieurement. comme suit:
Alors maintenant, je peux corriger les bugs en branchant le numéro 404.
Tout d'abord, nous devons déterminer sur quelle branche corriger le bug. Par exemple, je le corrige sur la branche principale principale. Maintenant, je souhaite créer une branche temporaire sur la branche principale. La démonstration est la suivante :
Une fois la réparation terminée, passez à la branche principale, terminez la fusion et enfin supprimez la branche issue-404. La démonstration est la suivante :
Maintenant, nous retournons travailler sur la branche dev.
La zone de travail est propre, alors où allons-nous sur le chantier ? Nous pouvons utiliser la commande git stash list pour le visualiser. comme suit:
Le site de travail est toujours là. Git a stocké le contenu du cache quelque part, mais il doit être restauré. Vous pouvez utiliser les deux méthodes suivantes :
- git stash apply recovery, après récupération, le contenu du stash n'est pas supprimé, vous devez utiliser la commande git stash drop pour supprimer.
- Une autre façon consiste à utiliser git stash pop pour supprimer le contenu du cache lors de la restauration.
La démonstration est la suivante
Huit : collaboration à plusieurs personnes
Lorsque vous clonez à partir d'un référentiel distant, Git associe automatiquement la branche principale locale à la branche principale distante, et le nom par défaut du référentiel distant est origin.
- Pour afficher les informations de la bibliothèque distante, utilisez git remote
- Pour afficher les détails du référentiel distant, utilisez git remote –v
Démontré comme suit :
Un : pousser la branche :
Pusher une branche consiste à soumettre tous les fichiers locaux de la branche à la bibliothèque distante. Lors du push, vous devez spécifier la branche locale, afin que Git pousse la branche vers la branche distante correspondant à la bibliothèque distante : Utilisez la commande git push maître d'origine
Par exemple, le code readme.txt sur mon github actuel est le suivant :
Le code readme.txt local est le suivant :
Maintenant, je souhaite transmettre le code readme.txt mis à jour localement vers la bibliothèque distante, à l'aide de la commande suivante :
Nous pouvons voir ce qui précède, le push est réussi, nous pouvons continuer à capturer le contenu readme.txt sur github comme suit :
Vous pouvez voir que le push est réussi. Si nous voulons pousser vers d'autres branches, comme la branche dev, nous avons toujours la commande git push origin dev
Alors de manière générale, quelles branches faut-il pousser ?
La branche principale est la branche principale, elle doit donc être synchronisée avec la télécommande à tout moment.
Certaines branches de correction de bugs n'ont pas besoin d'être poussées vers la branche distante, elles peuvent d'abord être fusionnées dans la branche principale, puis la branche principale principale est poussée vers la branche distante.
Deux : prenez la branche :
Lorsque plusieurs personnes collaborent, chacune apportera ses propres modifications à la branche principale. Maintenant on peut simuler un autre collègue, qui pourra être cloné sur un autre ordinateur (attention à bien ajouter la clé SSH à github) ou un autre répertoire sur le même ordinateur, et créer un nouveau répertoire nommé testgit2
Mais d'abord, je veux également pousser la branche dev vers la télécommande, comme suit
Entrez ensuite dans le répertoire testgit2 et clonez la bibliothèque distante vers la bibliothèque locale, comme suit :
Maintenant, le répertoire est généré comme suit :
Maintenant, si nos amis veulent développer sur la branche dev, ils doivent amener la branche dev de l'origine distante vers la branche locale, afin de pouvoir utiliser la commande pour créer une branche dev locale :
git checkout –b dev origin/dev
Désormais, les amis peuvent faire du développement sur la branche dev, et lorsque le développement est terminé, pousser la branche dev vers la bibliothèque distante.
comme suit:
Les amis ont poussé la soumission vers la branche origin/dev, et j'ai également modifié le même fichier au même endroit dans mon fichier répertoire, et quand j'essaye de le pousser vers la bibliothèque distante, c'est comme suit :
D'après ce qui précède, nous pouvons voir que le push a échoué parce que la dernière soumission de mon ami était en conflit avec ce que j'ai essayé de pousser. La solution est également très simple. Ce qui précède nous a rappelé d'utiliser git pull pour récupérer d'abord la dernière soumission d'origine/dev. Ensuite, fusionnez localement, résolvez les conflits et poussez.
Le git pull a également échoué car le lien entre la branche dev locale et la branche origin/dev distante n'a pas été spécifié. Selon l'invite, définissez le lien entre dev et origin/dev : comme suit :
Cette fois, le git pull réussit, mais il y a un conflit dans la fusion, qui doit être résolu manuellement. La solution est exactement la même que la résolution des conflits dans la gestion des branches. Après avoir résolu, soumettez et appuyez à nouveau :
Nous pouvons d’abord jeter un œil au contenu du fichier readme.txt.
Maintenant que le manuel a été résolu, je dois le soumettre à nouveau, puis le transférer vers la bibliothèque distante. Comme suit:
Ainsi : le mode de travail collaboratif à plusieurs ressemble généralement à ceci :
- Tout d’abord, essayez de pousser vos propres modifications avec git push origin branch-name .
- Si le push échoue, car la branche distante est antérieure à votre mise à jour locale, vous devez d'abord utiliser git pull pour essayer de fusionner.
- Si la fusion présente des conflits, vous devez résoudre les conflits et valider localement. Utilisez ensuite git push origin branch-name pour pousser.
Réimpression : https://zhuanlan.zhihu.com/p/135183491