Je ne sais pas dans quel langage de programmation vous écrivez, mais je suis sûr que vous utilisez Geet pendant le développement. Il existe de plus en plus d'outils pour soutenir le développement, mais même le plus petit projet de test, je commence toujours par la commande git init . Et pendant la journée de travail, je tape en moyenne 80 autres équipes, en référence à ce système de contrôle de version.
J'ai passé beaucoup de nerfs lorsque j'ai commencé à réapprendre la méthode d'impression à dix doigts. En fin de compte, c'était la meilleure décision pour améliorer votre flux de travail personnel. Parmi les prochaines optimisations les plus importantes figure le développement avancé de la Geeta.
De nombreux articles sur Gita ont été écrits sur Habr, mais ils ne vont pas au-delà de la documentation officielle, et les auteurs proposent de simplifier le travail avec des béquilles faites maison. Je suis sûr qu'il est nécessaire d'étudier le Geet sur des exemples concrets de tâches, et d'augmenter l'efficacité de travailler avec lui en utilisant des moyens standardisés.
Qui bénéficiera de cet article?
Avez-vous déjà maîtrisé l'ensemble de gentleman de Gita et êtes-vous prêt à passer à autre chose? Il y a 2 façons:
- Maîtriser les commandes abrégées - alias. Ils sont presque toujours mnémoniques et faciles à retenir. Oublier les commandes d'origine est problématique, je les tape facilement quand c'est nécessaire. De plus, je ne suis pas confus en vérifiant quelque chose dans la Gita lors de l'écriture de code.
- Découvrez les indicateurs supplémentaires pour les équipes, ainsi que leur intégration entre elles. Je comprends que quelqu'un déteste couper. Pour vous aussi, l'article contient des éléments intéressants - comment augmenter l'utilité et la commodité de la sortie de commande, ainsi que comment résoudre les problèmes les plus triviaux, mais souvent rencontrés dans la pratique .
Consacrez quelques heures aujourd'hui aux expériences décrites dans l'article et économisez par des calculs approximatifs six mois de vie professionnelle.
Bienvenue au chat!
La préparation
Parmi les développeurs, la norme pour l'alternative Bash est Zsh , un shell logiciel avancé qui prend en charge le réglage fin. Et parmi les utilisateurs de Zsh , la norme consiste à utiliser Oh My Zsh , un ensemble de paramètres prédéfinis pour Zsh . Ainsi, après avoir installé ce kit, nous sortirons de la boîte un ensemble de hacks que la communauté a collecté et développé pour nous au fil des ans.
Il est très important de noter que Zsh est pour Linux , et pour Mac , et même pour Windows .
Installez Zsh et Oh My Zsh
Installez Zsh et Oh My Zsh selon les instructions avec une seule commande:
Comme la tâche consiste à optimiser l'interaction avec le Geet , nous ajouterons quelques plug-ins à Zsh . Ouvrez le ~/.zshrc et ajoutez des plugins à la liste:
plugins=(git gitfast)
Total:
git - un ensemble d'alias et de fonctions auxiliaires;gitfast - auto-complétion améliorée pour Gita.
RĂ©glage tig
Et la touche finale est l'installation de l'utilitaire de console tig :
Nous en reparlerons plus loin.
Git en pratique
Il est préférable de traiter avec Geeta en résolvant des problèmes spécifiques. Ensuite, nous considérons les tâches de la pratique quotidienne et les options pour leur solution pratique. Pour ce faire, envisagez un certain référentiel avec des fichiers texte.
Les blocs jaunes indiquent l'alias principal pour résoudre le problème à partir de la section. Apprenez-le seulement et laissez tout le reste pour le développement général.
Vérifier l'état du répertoire de travail
Commençons par la chose la plus élémentaire. Nous avons fait un petit travail et voyons maintenant ce qui se passe dans le répertoire de travail:
$ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: e.md 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: b.md Untracked files: (use "git add <file>..." to include in what will be committed) d.md
L'état actuel de tous les fichiers est décrit en détail, des instructions supplémentaires pour l'action sont données. Il est très utile au début lors de l'utilisation de Geeta, mais il y a beaucoup de superflu pour le travail quotidien. Abaissons le niveau de bruit avec des touches supplémentaires:
$ git status -sb
Oui, nous sommes dans la branche master , avons modifié le b.md ( M-odified ) et créé deux fichiers, en ajoutant le premier à l'index Geeta ( A-dded ) et en laissant le second hors de l'index ( ?? ). Court et clair.
Il reste Ă optimiser la saisie sans fin de cette commande par l'alias " g it s tatus with b ranch" :
Afficher le statut abrégé du répertoire de travail
$ gsb
Créer un commit
Nous continuons.
Bien sûr, vous pouvez faire des commits. Mais essayons d'optimiser la solution de cette tâche simple. Ajoutez toutes les modifications à l'index avec l'alias " g it a dd a ll" :
$ gaa
Nous vérifions que l'index a exactement ce dont nous avons besoin en utilisant l'alias " g it d iff ca ched" :
$ gdca # git diff --cached diff --git a/b.md b/b.md index 698d533..cf20072 100644 --- a/b.md +++ b/b.md @@ -1,3 +1,3 @@ # Beta -Next step. +Next step really hard. diff --git a/d.md b/d.md new file mode 100644 index 0000000..9e3752e --- /dev/null +++ b/d.md @@ -0,0 +1,3 @@ +# Delta + +Body of article.
Hmm, les changements qui résolvent une seule tâche doivent tomber dans un seul commit. Ici, les modifications apportées aux deux fichiers ne sont en aucun cas liées. d.md le fichier d.md de l'index avec l'alias " g it r eset u ndo" :
$ gru d.md # git reset
Et créez un commit avec l'alias " g it c ommit" :
$ gc
Nous écrivons le nom du commit et enregistrons. Et puis nous créons un autre commit pour le fichier d.md commande plus familière en utilisant l'alias " g it c ommit m e s sa g e" :
$ gaa
Et nous pouvons ...
... valider les fichiers modifiés à partir de l'index avec une seule commande:
$ gcam "Add changes"
... voir les modifications par des mots au lieu de lignes (très utile lorsque vous travaillez avec du texte):
$ gdw
... ajouter des fichiers par parties (très utile lorsque vous devez ajouter au commit uniquement une partie des modifications du fichier):
$ gapa
... ajouter à l'index uniquement les fichiers déjà sous la supervision de la Geeta:
$ gau
Total:
Ajouter à l'index / créer un commit
$ ga
Correction du commit
Le nom du dernier commit n'explique pas les modifications que nous avons apportées. Reformulons:
$ gc!
Et dans l'éditeur de texte qui s'ouvre, nous l'appellerons plus clairement: "Add Delta article" . Je suis sûr que vous n'utilisez jamais le commutateur -v , bien que lors de la modification de la description du commit, il montre toutes les modifications apportées, ce qui aide à mieux naviguer.
Et nous pouvons ...
... apportez des modifications de fichier au commit, mais ne touchez pas Ă la description:
$ gcn!
... apportez toutes les modifications de fichier immédiatement au commit, sans ajouter d'abord à l'index:
$ gca!
... combinez les deux commandes précédentes:
$ gcan!
Eh bien, il est important de noter une fois de plus qu'au lieu de taper la git commit -v --amend régulièrement utilisée, nous n'écrivons que trois caractères:
Modifier le dernier commit
$ gc!
Prise en main d'une nouvelle fonctionnalité
Créez une nouvelle branche à partir de l'alias actuel " g it c heckout b ranch" :
$ gcb erlang
Bien que non, il vaut mieux Ă©crire un article sur une langue plus moderne par Elixir alias " g it b ranch with the key m ove" (renommer dans la Gita se fait par move ):
$ gb -m elixir
Il serait logique d'utiliser l'alias gbmv , mais malheureusement, il n'a pas encore été inventé. Une bonne option pour une contribution.
Nous apportons des modifications au référentiel et créons un commit, comme nous le savons déjà :
$ echo "# — ." > e.md $ gaa && gcmsg "Add article about Elixir"
Et rappelez-vous:
Créer une nouvelle branche
$ gcb
Fusionner les modifications
Nous ajoutons maintenant notre nouvel article sur Elixir Ă master . Commencez par passer Ă la branche principale avec l'alias " g it c heckout m aster" :
$ gcm
Non, vraiment. L'une des commandes les plus utilisées en trois caractères faciles à retenir. Maintenant, le mergim du changement d'alias est « g it m erge» :
$ gm elixir
Oups, mais quelqu'un a déjà réussi à apporter des modifications au master . Et au lieu de la belle histoire linéaire qui a été adoptée dans notre projet, j'ai créé détesté fusionner le commit.
Fusionner les branches
$ gm
Supprimer le dernier commit
Rien à craindre! Il vous suffit de supprimer le dernier commit et de réessayer de fusionner les modifications « g it r eset hh ard» :
Supprimer le dernier commit
$ grhh HEAD~
Nous résolvons les conflits
La séquence d' checkout – rebase – merge standard checkout – rebase – merge pour préparer un historique des modifications linéaires est effectuée par la séquence d'alias suivante:
gco elixir
Tous sont si souvent utilisés qu'ils s'éloignent déjà des doigts, et lorsque vous effectuez de telles opérations, il n'est pas nécessaire de penser à l'ensemble de lettres à taper. Et n'oubliez pas que dans Zsh vous pouvez compléter les noms des branches avec la touche Tab .
Faire un rebase
$ grb
Soumettre des modifications au serveur
D'abord, nous ajoutons l' origin alias " g it r emote a dd" :
$ gra origin git@github.com/...
Et puis nous envoyons les modifications directement à la branche courante du référentiel ( «gg» - g doublé au début de la commande indique l'exécution de l'action dans la branche courante):
$ ggpush
Vous pouvez aussi ...
... envoyer les modifications au serveur avec l'installation en upstream de l'alias « g it p ush s et up stream» :
$ gpsup
Soumettre les modifications au serveur
$ gp
Nous recevons des modifications du serveur
Le travail bat son plein. Nous avons réussi à ajouter un nouvel article f.md à master , et nos collègues ont modifié l'article a.md et envoyé cette modification au serveur. Cette situation est également résolue très simplement:
$ gup
Ensuite, vous pouvez envoyer des modifications en toute sécurité au serveur. Le conflit est réglé.
Obtenez les modifications du serveur
$ gl
Supprimer les branches fusionnées
Nous avons donc fusionné avec succès plusieurs branches en master , y compris la branche elixir de l'exemple précédent. Nous n'en avons plus besoin. Vous pouvez supprimer l'alias " g it b ranch d elete a nother" :
$ gbda
Équipe très belle et rusée. Habituellement, j'oublie d'effacer les branches qui ont perdu leur pertinence et cette équipe gracieuse est un vrai salut. Si vous ne souhaitez pas utiliser d'alias, copiez simplement la version complète de la commande dans vos notes et exécutez-la si nécessaire.
Créer un commit temporaire
Le travail sur un nouvel article h.md sur Haskell h.md son plein. À moitié écrit et vous devez obtenir les commentaires d'un collègue. Sans y réfléchir à deux fois , nous tapons l'alias " g it w ork i n p rogress" :
$ gwip
Et puis un commit est créé avec le nom Work in Progress , en sautant CI et en supprimant les fichiers "supplémentaires". Nous envoyons la branche au serveur, parlons de ce collègue et attendons la révision.
Ensuite, ce commit peut être annulé et les fichiers retournés à leur état d'origine:
$ gunwip
Et pour vérifier s'il y a des WIP dans votre branche, utilisez la commande:
$ work_in_progress
La commande gwip est un analogue assez fiable de stash lorsque vous devez passer Ă une branche voisine. Mais dans Zsh il existe de nombreux alias pour se stash .
Ajouter une validation temporaire / réinitialiser la validation temporaire
$ gwip $ gunwip
Masquer les modifications
Vous devez être prudent avec cette commande. Les fichiers peuvent être masqués, puis supprimés complètement avec une action imprudente, car il existe un reflog dans lequel vous pouvez essayer de trouver le travail perdu.
Cachons les fichiers sur lesquels nous travaillons avec l'alias g it st ash a ll :
$ gsta
Et puis retournez-les avec l'alias « g it st ash p op» :
$ gstp
Ou la méthode la plus sûre « g it st ash a ll a pply» :
$ gstaa
Vous pouvez aussi ...
... voyez exactement ce que nous avons caché:
gsts
... utilisez des abréviations pour les commandes associées:
gstc
Masquer les modifications / obtenir des modifications
$ gsta $ gstaa
Vous cherchez un bug
L'outil git-bisect , qui m'a sauvé à plusieurs reprises, a également ses propres alias. On commence par lancer la procédure de «recherche d'erreur binaire» avec l' alias « g it b i s ect s tart» :
$ gbss
On note que le commit actuel, dernier de la branche, contient une erreur avec l'alias " g it b i s ect b ad" :
$ gbsb
Nous marquons maintenant le commit qui nous garantit l'état opérationnel de l'application « g it b i s ect g ood» :
$ gbsg HEAD~20
Et maintenant, il reste à continuer de répondre aux questions de Gita avec les phrases gbsb ou gbsg , et après avoir trouvé le coupable, réinitialisez la procédure:
$ gbsr
Et j'écris vraiment ces abréviations lorsque j'utilise cet outil.
Erreur de recherche de validation
$ gbss
Nous recherchons l'instigateur de l'anarchie
Même avec un pourcentage élevé de couverture de code avec des tests, personne n'est à l'abri d'une situation où l'application se bloque et pointe gentiment vers une ligne spécifique avec une erreur. Ou, par exemple, dans notre cas, nous voulons savoir qui a fait une erreur dans la deuxième ligne du fichier a.md Pour ce faire, exécutez la commande:
$ gbl a.md -L 2
Vous voyez, les contributeurs d' Oh My Zsh ont créé un alias non seulement pour l'équipe git blame , mais y ont ajouté des clés qui facilitent la recherche directe de l'instigateur.
Bonus
Afficher une liste des validations
Pour afficher la liste des validations, utilisez la commande git log avec des clés de formatage de sortie supplémentaires. Habituellement, cette commande, avec les clés, est entrée dans les alias personnalisés de Gita. Nous avons plus de chance, nous avons déjà un alias prêt à l'emploi: glog . Et si vous avez installé l'utilitaire tig sur les conseils du début de l'article, vous êtes un champion absolu.
Maintenant, pour apprendre l'historique des commits dans la console d'une manière très pratique, vous devez taper le mot git vice versa:
$ tig
L'utilitaire fournit Ă©galement quelques ajouts utiles qui ne sont pas dans la Gita prĂŞte Ă l'emploi.
Tout d'abord, une commande pour parcourir le contenu d'une histoire:
$ tig grep
Deuxièmement, afficher une liste de toutes les sources, branches, tags ainsi que leur historique:
$ tig refs
Troisièmement, vous trouverez peut-être quelque chose d'intéressant pour vous:
$ tig --help
git reset --hard accidentelle de git reset --hard
Vous avez travaillé sur la branche elixir toute la journée:
$ glog * 17cb385 (HEAD -> elixir) Refine Elixir article * c14b4dc Add article about Elixir * db84d54 (master) Initial commit
Et à la fin, ils ont accidentellement tout supprimé:
$ grhh HEAD~2 HEAD is now at db84d54 Initial commit
Pas besoin de paniquer. La règle la plus importante est d'arrêter l'exécution de toute commande dans la Gita et d'exhaler . Toutes les actions avec le référentiel local sont enregistrées dans un journal spécial - reflog . De là , vous pouvez obtenir le hachage du commit souhaité et le restaurer dans l'arborescence de travail.
Regardons le reflog, mais pas de la manière habituelle via git reflog , mais plus intéressant avec une transcription détaillée:
$ glg -g
Trouvez le hachage du commit 17cb385 souhaité et restaurez-le:
Par chance, au lieu de créer un nouveau commit, j'ai apporté des modifications au précédent
Ici encore, nous arrivons au reflog de l'aide au sauvetage. Nous trouvons le hachage du commit 17cb385 origine, si nous 17cb385 le commit immédiatement, puis au lieu de chercher le hachage, nous pouvons utiliser le lien rapide vers celui-ci HEAD@{1} . Ensuite, nous effectuons une réinitialisation logicielle, tandis que l'index n'est pas réinitialisé:
La branche est trop vieille
Parfois, vous commencez à travailler sur une fonctionnalité, mais sa sortie est retardée indéfiniment. Vous vous engagez et passez à d'autres tâches. Avec l'équipe, vous apportez un tas de modifications au maître et après un certain temps, vous revenez à la branche avec des fonctionnalités. Vous essayez de rebaser, mais il propose d'analyser les conflits en une dizaine de commits. Vous pouvez essayer de les résoudre tous ou de les faciliter.
Regardons un exemple d'une branche de fonctionnalité appelée elixir :
Ainsi, au lieu d'essayer de mettre à jour la branche, nous prenons et transférons un seul commit sans aucun problème.
Suppression de données importantes du référentiel
Pour supprimer des données importantes du référentiel, j'ai enregistré l'extrait de code suivant:
$ git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch <path-to-your-file>' --prune-empty --tag-name-filter cat -- --all && git push origin --force --all
L'exécution de cette commande cassera votre stash . Avant son exécution, il est recommandé d'obtenir toutes les modifications masquées. En savoir plus sur cette technique ici .
Se référant à la branche précédente
Lors de l'exécution de certaines commandes qui s'attendent à ce qu'un nom de branche soit saisi, nous pouvons passer un trait d'union comme référence à la branche avec laquelle nous sommes venus. Il est particulièrement bon d'utiliser cette astuce de paiement:
$ gco -
Supprimer tous les fichiers marqués en .gitignore
Un autre revers courant est trop tard pour ajouter des fichiers ou répertoires indésirables à .gitignore . Afin de les nettoyer du référentiel ( et de les supprimer du disque ), il existe déjà des clés prêtes à l'emploi pour la commande git clean :
$ gclean -X
Faites attention!
Lisez la suite pour la bonne façon.
Pourquoi de nombreuses Ă©quipes ont-elles besoin du --dry-run ?
Le --dry-run nécessaire uniquement à titre de précaution lors de la désinstallation et de la mise à jour. Par exemple, la section précédente a décrit comment supprimer tout ce qui est spécifié dans le fichier .gitignore . Il vaut mieux être prudent et utiliser le --dry-run , --dry-run liste de tous les fichiers à supprimer, puis exécuter la commande sans --dry-run .
Conclusion
L'article montre un point pour optimiser le travail du programmeur. N'oubliez pas que les abréviations mnémoniques 10-20 ne sont pas difficiles, oubliez que l'équipe d'origine est presque impossible. Les alias sont standardisés, donc lorsque vous passez toute l'équipe à Zsh + Oh My Zsh , vous pouvez travailler à la même vitesse et avec le même confort, même avec la programmation par paire.
OĂą aller ensuite?
J'offre les options suivantes:
- Enfin, découvrez comment le Geet est disposé à l'intérieur . Cela aide à comprendre ce que vous faites et pourquoi ce que vous voulez faire ne fonctionne pas.
- Ne soyez pas paresseux pour regarder Ă nouveau la documentation des commandes:
git --help ou ghh . - Voir la liste complète des alias sur le lien . Essayer de se souvenir de tous est fou, mais utiliser la liste comme une collection de commandes et de clés intéressantes est une bonne idée.
Certains alias sont créés de manière non triviale, mais s'avèrent très utiles dans la pratique. Beaucoup des alias présentés ne sont pas seulement des abréviations, mais de petites fonctions qui optimisent davantage le travail. L'utilisation de Git est devenue plus agréable, la qualité des commits s'est améliorée.
J'espère que le matériel s'est avéré utile et que vous pourrez apprendre quelque chose de nouveau par vous-même. Ou peut-être ont-ils déjà commencé à introduire activement une nouvelle approche. Bonne chance