Git pour les débutants : Le guide pratique définitif

Question

Ok, après avoir vu ce message par PJ Hyett j'ai décidé d'aller jusqu'au bout et d'opter pour Git .

Donc ce dont j'ai besoin, c'est d'un guide pour débutants. pratique Guide de Git. "Débutant" étant défini comme quelqu'un qui sait comment manipuler son compilateur, comprend à un certain niveau ce qu'est une Makefile est, et a touché au contrôle de la source sans très bien le comprendre.

"Pratique" étant défini comme la personne qui ne veut pas entrer dans les détails de ce que Git fait en arrière-plan, et qui ne se soucie même pas (ou ne sait pas) qu'il est distribué. Vos réponses pourraient faire allusion aux possibilités, mais essayez de viser le débutant qui veut garder un dépôt "principal" sur un "serveur" qui est sauvegardé et sécurisé, et traiter leur dépôt local comme une simple ressource "client".

Donc :

Installation/Setup

• Comment installer Git
• Comment configurer Git ? Essayez de couvrir Linux, Windows, Mac, pensez à l'esprit "client/serveur".
  • Configurer le serveur GIT avec Msysgit sous Windows
• Comment créer un nouveau projet/dépôt ?
• Comment le configurer pour qu'il ignore les fichiers (.obj, .user, etc) qui ne font pas vraiment partie de la base de code ?

Travailler avec le code

• Comment obtenir le dernier code ?
• Comment vérifier le code ?
• Comment valider les modifications ?
• Comment voir ce qui n'est pas validé, ou l'état de votre base de code actuelle ?
• Comment détruire les commits non désirés ?
• Comment comparer deux révisions d'un fichier, ou votre fichier actuel et une révision précédente ?
• Comment voir l'historique des révisions d'un fichier ?
• Comment gérez-vous les fichiers binaires (docs visio, par exemple, ou environnements de compilateurs) ?
• Comment fusionner les fichiers modifiés "en même temps" ?
• Comment annuler (revenir en arrière ou réinitialiser) un commit ?

Étiquetage, branchement, versions, lignes de base

• Comment " marquer ", " étiqueter " ou " libérer " un ensemble particulier de révisions pour un ensemble particulier de fichiers afin de pouvoir toujours les récupérer plus tard ?
• Comment tirer un "communiqué" particulier ?
• Comment se ramifie-t-on ?
• Comment fusionner les branches ?
• Comment résoudre les conflits et mener à bien la fusion ?
• Comment fusionner des parties d'une branche dans une autre branche ?
• Qu'est-ce que le rebasement ?
• Comment puis-je suivre les succursales distantes ?
• Comment créer une branche sur un référentiel distant ?
• Comment supprimer une branche sur un référentiel distant ?
• Exemples de flux de travail Git

Autre

• Décrivez une bonne interface graphique, un plugin IDE, etc., qui fait de Git une ressource sans ligne de commande, et indiquez ses limites et ses avantages.
  • msysgit - Multiplateforme, inclus avec Git
  • gitk - Visualiseur d'historique multiplateforme, inclus avec Git
  • gitnub - Mac OS X
  • gitx - Visualisation de l'historique de Mac OS X
  • smartgit - Plate-forme croisée, commerciale, bêta
  • tig - console GUI pour Linux
  • qgit - Interface graphique pour Windows, Linux
  • Extensions Git - pour Windows, comprend une interface graphique conviviale
• Y a-t-il d'autres tâches courantes qu'un débutant devrait connaître ?
  • Git Status vous indique ce que vous venez de faire, quelle branche vous avez, et d'autres informations utiles.
• Comment travailler efficacement avec un dépôt de subversion défini comme source de contrôle des sources ?

Autres références pour les débutants de Git

• Guide Git
• Livre Git
• La magie de Git
• gitcasts
• Guides GitHub
• Tutoriel Git
• Progit - livre de Scott Chacon
• Cours accéléré Git - SVN
• Git du bas vers le haut
• Git ready
• gitref.org
• Aide-mémoire visuel Git

Se plonger dans Git

• Comprendre le concept de Git
• Git pour les informaticiens (et une autre version )

Je passerai en revue les entrées de temps en temps et les "nettoierai" pour qu'elles aient un aspect cohérent et qu'il soit facile de parcourir la liste - n'hésitez pas à suivre un modèle simple "en-tête - brève explication - liste d'instructions - problèmes et informations supplémentaires". Je vais également créer un lien vers les entrées de la liste à puces ci-dessus afin qu'il soit facile de les retrouver plus tard.

Answer 1

Ajoutez sérieusement le lien figurant dans La réponse de Tim dans l'article de Stack Overflow Configurer un serveur Git avec Msysgit sous Windows .

Il m'a parfaitement expliqué comment configurer Git sous Windows avec msysgit et est un article incroyablement détaillé.

Answer 2

Qu'est-ce que le rebasement ?

Explication du rebasement tirée du livre Guide pragmatique de Git - Travis Swicegood

Chapitre III

16 . Réécrire l'histoire en rebasant

Le repositionnement des commits est le seul concept de Git qui n'a pas d'équivalent dans le le monde traditionnel du contrôle de version. En utilisant git rebase, vous pouvez réécrire l'histoire l'histoire d'un dépôt de diverses de différentes manières. C'est l'une des commandes les plus commande la plus puissante de Git, ce qui l'une des plus dangereuses.

rebase prend une série de commits (normalement une branche) et les rejoue au-dessus d'un autre commit (normalement le dernier commit d'une autre branche). Le commit parent parent change donc tous les ID de IDs de commit sont recalculés. Cela peut causer des problèmes pour les autres développeurs qui ont votre code car les IDs ne correspondent pas.

Il y a une règle simple à suivre avec git rebase : utilisez-le autant que vous voulez que vous le souhaitez sur les commits locaux. Une fois que vous avez partagé des changements avec un autre développeur le mal de tête ne vaut généralement pas la peine.

Answer 3

Ressources : A vérifier absolument Les Gitcasts de Scott Chacon , notamment la conférence Railsconf .

Github est génial et a aussi des guides utiles .

Answer 4

En ce qui concerne les bonnes interfaces graphiques/frontales, vous pouvez également consulter les sites suivants qgit qui est un visualiseur de dépôt multiplateforme (Linux/Win32) pour Git et peut également être utilisé comme frontal de haut niveau pour les opérations Git les plus courantes, en fait, il peut être facilement amélioré par ce qu'on appelle des "actions personnalisées" afin que les utilisateurs puissent fournir des actions personnalisées.

Answer 5

Un autre élément qui, selon moi, devrait figurer dans cette liste, probablement très utile pour les débutants :

Ne paniquez pas

Que faire si j'ai fait quelques commits et que j'ai ensuite fait quelque chose d'effrayant, comme par exemple un rebasement, et que maintenant quelque chose - ou même tout - semble être perdu ? (Le rebasement semble être celui qui touche le plus de personnes du premier coup, c'est pourquoi je me concentre sur lui. Alors que git rebase --abort aide beaucoup, parfois vous découvrirez que vous avez bâclé un montage lors d'un rebasement interactif, par exemple, et que vous avez laissé le rebasement se terminer et que maintenant vous voulez récupérer vos anciens éléments. Et puis il y a des choses comme filter-branch ...)

Un principe clé de git est qu'il ne supprime jamais réellement ce que vous avez commis. ("Quoi, jamais ?" "Non, jamais !" "Quoi, jamais ?" "Eh bien, presque jamais !") Si vous n'avez pas exécuté git gc , c'est toujours là . Il faudra peut-être creuser un peu pour trouver vos travaux antérieurs, mais si vous avez réussi à git commit s plus tôt, alors, par exemple, même votre série de commits apparemment détruite par une erreur tragique de rebasement est toujours là, normalement pour au moins un mois (techniquement, jusqu'à ce que les "reflogs" expirent).

Il est important de garder à l'esprit que chaque nom de branche étiquette - ou pointe vers - un "commit-ID". Ce sont les chiffres amusants comme 7cc5272 . Beaucoup de choses que vous faites, comme ajouter un nouveau commit à une branche, font que le nom de la branche pointe vers un nouveau, différent commit-ID. Chaque ID de commit a un lien qui pointe vers un ou plusieurs ID de commit précédents, et c'est ce qui constitue réellement une "branche" pleine de commits.

L'entrée rebase parle de "réécrire l'histoire", et des commandes comme git filter-branch réécrivent également l'histoire, mais ils ne le font pas en détruisant l'histoire précédente, mais plutôt en ajoutant une nouvelle histoire. Une fois que le nouvel historique est en place, git va "déplacer les étiquettes" de façon à ce qu'il soit ressemble à L'histoire a changé. Si vous êtes sur votre fix-nasty-bug et faire une git rebase et réussissent à tout casser, l'étiquette fix-nasty-bug fait maintenant référence à l'épave, mais les versions originales sont toujours là. Rebase en particulier fait une étiquette temporaire (non-mobile, non-branchée) épelée ORIG_HEAD qui vous permet de les trouver. Le site filter-branch sauvegarde également tous les noms originaux. Dans certains cas, il peut ne pas y avoir de nom évident, mais les commits peuvent toujours être trouvés. Si nécessaire, trouvez-vous un "git guru" et expliquez-lui ce que vous avez fait qui a mené au naufrage.

(La commande git reflog show peut également aider à trouver les ID de commit).

Si vous avez trouvé ce que vous pensez être une partie ou la totalité de votre travail précédent, essayez :

git log <commit-ID>   # ORIG_HEAD after a bad rebase, for instance
git show <commit-ID>  # or some long SHA1 value you can still see in a window

Si cela semble juste ou utile, mettez un nom dessus :

git branch recover-my-stuff ORIG_HEAD

et tout est de retour ! En fait, maintenant, votre mauvaise rebase et votre travail original sont tous deux dans votre dépôt git "pour toujours" (ou du moins, jusqu'à ce que vous supprimiez les noms des branches). y laisser passer quelques mois, puis les mettre à la poubelle). Vous pouvez mettre autant de noms sur autant de commits récupérés que vous le souhaitez. (Les noms de branches sont virtuellement gratuits, sauf qu'ils encombrent votre fichier git branch et, bien sûr, ils empêchent également les commits d'être collectés. Vous pouvez également, ou à la place, mettre des balises sur des commit-IDs spécifiques, si vous préférez cela).