Git

Introduction Je possède des comptes personnels et professionnels sur GitHub, GitLab et Bitbucket. Comment pourrais-je définir tout cela pour qu’il fonctionne correctement grâce aux clés SSH afin que mon système s’appuie sur la bonne clé SSH en fonction de l’identité qu’il doit utiliser. Pour ce post particulier, nous allons connecter une identité personnelle et professionnelle pour chaque compte. Mais vous pouvez en ajouter autant que vous le souhaitez. 😉 🔑 Génération de clés Nous allons créer des identités par défaut....

Pourquoi avoir une stratégie d’utilisation de Git ? Git est puissant mais il est généralement mal utilisé. Et un outil mal utilisé peut vite devenir contre-productif. Dans le cas de Git, cela peut se traduire par des conflits à chaque commit/merge ou presque, des pertes de données (même s’il faut vraiment en vouloir), etc… Comment fonctionne GitFlow ? GitFlow est un ensemble de règles simples qui se basent sur le fonctionnement par branche de Git....

Nous sommes tous passés par là. Qu’il s’agisse d’un calendrier serré, de corrections constantes ou simplement de la création de messages avec notre propre modèle défini; nous avons tous fait de mauvais messages de commit. Heureusement pour nous, la spécification Conventional Commits existe, et avec elle un ensemble d’outils puissants pour nous aider. Application d’une norme Pour faire respecter une norme à chaque fois que nous nous faisons un commit, nous avons husky et commitling....

Que l’on soit backend ou frontend, il y a une chose qui nous rassemble, c’est notre gestionnaire de source et son utilisation. Dans cet article, je vais vous présenter le conventional-changelog qui vous permettra de produire un historique de super qualité 🙌! Le problème Combien d’entre vous sont tombés sur des projets avec un historique qui ressemble à cela: 🤕 1e60930a9 (HEAD -> develop, origin/develop) Modification front 249ff1d07 Fix an error 359a4d13e Add log 444e2f204 Update conf 503d00e2e Types 610d42648 Lots of things....

L’une des principales différences entre git et les autres systèmes de contrôle de version est qu’il permet à l’utilisateur de réécrire l’historique. Pour ce faire, le moyen principal consiste à utiliser git rebase, généralement suivi d’un git push --force pour écraser l’historique du serveur (remote) avec l’historique local. Voici comment diviser les commits existants à l’aide de rebase, reset et commit. Supposons que vous ayez deux fichiers édités dans un commit (A et B) et que vous souhaitiez importer les modifications d’un de ces fichiers (A) dans votre branche actuelle, mais pas celles de l’autre (B)....

Une des choses les plus grandes et les pires avec git est que vous pouvez réécrire l’histoire. Voici une façon sournoise d’abuser de cela, je ne peux pas penser à une raison légitime de le faire. Comme pour tout, merci StackOverflow pour toutes les options que je peux choisir parmi Fixe la date du dernier commit à la date du jour 1GIT_COMMITTER_DATE="$(date)" git commit --amend --no-edit --date "$(date)" Fixer la date du dernier commit à une date arbitraire 1GIT_COMMITTER_DATE="2019-05-07T21:07:52" git commit --amend --no-edit --date "2019-05-07T21:07:52" 1GIT_COMMITTER_DATE="Mon 20 Aug 2018 20:19:19 BST" git commit --amend --no-edit --date "Mon 20 Aug 2018 20:19:19 BST" Définir la date d’une validation arbitraire sur une date arbitraire ou courante Rebaser avant ledit engagement et arrêter pour modification:...

Dans cet article, vous apprendrez à créer et à gérer facilement des git hooks pour vos projets Node/NPM à l’aide de Husky. Git Hooks En termes simples, les git hooks sont des scripts personnalisés, qui peuvent être exécutés automatiquement lorsque des événements spécifiques se produisent. Des crochets (hooks) côté client sont déclenchés pour des actions telles que le commit ou le merge. Les crochets côté serveur s’exécutent dans des situations telles que la réception de données (git push) du client....