Ok, après avoir vu ce post de PJ Hyett , j'ai décidé de sauter jusqu'au bout et d'aller avec Git .

J'ai donc besoin d'un guide pratique pour débutant sur Git. "Débutant" étant défini comme quelqu'un qui sait comment gérer son compilateur, comprend à un certain niveau ce qu'est un Makefile , et a touché le contrôle des sources sans très bien le comprendre.

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

Donc:

Installation / configuration

• Comment installer Git
• Comment configurez-vous Git? Essayez de couvrir Linux, Windows, Mac, pensez à l'état d'esprit «client / serveur».
  • Configurer GIT Server avec Msysgit sous Windows
• Comment créez-vous un nouveau projet / référentiel?
• Comment le configurez-vous pour ignorer les fichiers (.obj, .user, etc.) qui ne font pas vraiment partie de la base de code?

Travailler avec le code

• Comment obtenez-vous le dernier code?
• Comment extrayez-vous le code?
• Comment commettez-vous des changements?
• Comment voyez-vous ce qui n'est pas engagé ou l'état de votre base de code actuelle?
• Comment détruisez-vous les commits indésirables?
• Comment comparez-vous deux révisions d'un fichier, ou votre fichier actuel et une révision précédente?
• Comment voyez-vous l'historique des révisions d'un fichier?
• Comment gérez-vous les fichiers binaires (visio docs, par exemple, ou les environnements de compilation)?
• Comment fusionner des fichiers modifiés en "même temps"?
• Comment annuler (annuler ou réinitialiser) un commit?

Marquage, branchement, versions, lignes de base

• Comment «marquer» «tag» ou «publier» un ensemble particulier de révisions pour un ensemble particulier de fichiers afin de pouvoir toujours le récupérer plus tard?
• Comment tirez-vous une «version» particulière?
• Comment branchez-vous?
• Comment fusionnez-vous les succursales?
• Comment résolvez-vous les conflits et terminez la fusion?
• Comment fusionner des parties d'une branche dans une autre branche?
• Qu'est-ce que le rebasage?
• Comment suivre les branches distantes?
• Comment puis-je créer une branche sur un référentiel distant?
• Comment supprimer une branche d'un référentiel distant?
• Exemples de flux de travail Git

Autre

• Décrivez et créez un lien vers une bonne interface graphique, un plug-in IDE, etc. qui fait de Git une ressource hors ligne de commande, mais veuillez énumérer ses limites ainsi que ses avantages.
  • msysgit - Plateforme croisée, incluse avec Git
  • gitk - Visionneuse d'historique multiplateforme, incluse avec Git
  • gitnub - Mac OS X
  • gitx - Visionneuse d'historique Mac OS X
  • smartgit - Multiplateforme , commercial, bêta
  • tig - interface graphique de console pour Linux
  • qgit - GUI pour Windows, Linux
  • Git Extensions - package 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 puis-je travailler efficacement avec un référentiel Subversion défini comme ma source de contrôle de source?

Autres références pour débutants Git

• Guide Git
• Git book
• Git magic
• gitcasts
• Guides GitHub
• Tutoriel Git
• Progit - livre de Scott Chacon
• Git - SVN Crash Course
• Git de bas en haut
• Git prêt
• gitref.org
• Git cheatsheet visuel

Plonger dans Git

• Comprendre Git conceptuellement
• Git pour les informaticiens (et une autre version )

Je vais parcourir les entrées de temps en temps et les ranger afin qu'elles aient une apparence cohérente et qu'il soit facile de parcourir la liste - n'hésitez pas à suivre un simple "en-tête - brève explication - liste d'instructions - gotchas et modèle d'informations supplémentaires ". Je vais également créer un lien vers les entrées de la liste à puces ci-dessus, il est donc facile de les retrouver plus tard.

Comment créez-vous un nouveau projet / référentiel?

Un dépôt git est simplement un répertoire contenant un .gitrépertoire spécial .

Ceci est différent des systèmes de contrôle de version "centralisés" (comme subversion), où un "référentiel" est hébergé sur un serveur distant, que vous checkoutdans un répertoire "copie de travail". Avec git, votre copie de travail est le référentiel.

Exécutez simplement git initdans le répertoire qui contient les fichiers que vous souhaitez suivre.

Par exemple,

cd ~/code/project001/
git init

Cela crée un .gitdossier (caché) dans le répertoire courant.

Pour créer un nouveau projet, exécutez git initavec un argument supplémentaire (le nom du répertoire à créer):

git init project002

(This is equivalent to: mkdir project002 && cd project002 && git init)

Pour vérifier si le chemin actuel se trouve dans un référentiel git, exécutez simplement git status- s'il ne s'agit pas d'un référentiel, il signalera "fatal: Pas un référentiel git"

Vous pouvez également répertorier le .gitrépertoire et vérifier qu'il contient des fichiers / répertoires similaires à ce qui suit:

$ ls .git
HEAD         config       hooks/       objects/
branches/    description  info/        refs/

Si pour une raison quelconque, vous souhaitez "dé-git" un référentiel (vous souhaitez arrêter d'utiliser git pour suivre ce projet). Supprimez simplement le .gitrépertoire au niveau de base du référentiel.

cd ~/code/project001/
rm -rf .git/

Attention: Cela détruira tout l' historique des révisions, toutes vos balises, tout ce que git a fait. Il ne touchera pas aux fichiers "actuels" (les fichiers que vous pouvez actuellement voir), mais les modifications précédentes, les fichiers supprimés, etc. ne seront pas récupérables!

GUI pour git

Git GUI

Inclus avec git - Exécuté à git guipartir de la ligne de commande et le programme d' installation de Windows msysgit l' ajoute au menu Démarrer.

Git GUI peut faire la majorité de ce que vous devez faire avec git. Y compris les changements d'étape, configurer git et les référentiels, pousser les changements, créer / extraire / supprimer des branches, fusionner et bien d'autres choses.

Une de mes fonctionnalités préférées est les raccourcis "ligne de scène" et "morceau de scène" dans le menu contextuel, qui vous permettent de valider des parties spécifiques d'un fichier. Vous pouvez obtenir le même via git add -i, mais je trouve cela plus facile à utiliser.

Ce n'est pas la plus jolie application, mais elle fonctionne sur presque toutes les plateformes (basée sur Tcl / Tk)

Captures d'écran | un screencast

GitK

Également inclus avec git. Il s'agit d'un visualiseur d'historique git et vous permet de visualiser l'historique d'un référentiel (y compris les branches, lors de leur création et de leur fusion). Vous pouvez afficher et rechercher des validations.

Va bien avec git-gui.

Gitnub

Application Mac OS X. Principalement équivalent à git log, mais a une certaine intégration avec github (comme la "Vue réseau").

Est joli et s'adapte à Mac OS X. Vous pouvez rechercher des référentiels. La plus grande critique de Gitnub est qu'il montre l'histoire de manière linéaire (une seule branche à la fois) - il ne visualise pas la ramification et la fusion, ce qui peut être important avec git, bien qu'il s'agisse d'une amélioration prévue.

Liens de téléchargement, journal des modifications et captures d'écran | référentiel git

GitX

Destiné à être un "clone gitk pour OS X".

Il peut visualiser l'historique des branchements non linéaires, effectuer des validations, afficher et rechercher des validations, et il a d'autres fonctionnalités intéressantes comme la possibilité de "rechercher" n'importe quel fichier dans n'importe quelle révision (espace de presse dans la liste des fichiers), d'exporter n'importe quel fichier (par glisser-déposer).

Il est bien mieux intégré dans OS X que git-gui/ gitk, et est rapide et stable même avec des référentiels exceptionnellement grands.

Le répertoire d'origine de git pieter n'a pas été mis à jour récemment (plus d'un an au moment de la rédaction). Une branche plus activement maintenue est disponible chez brotherbard / gitx - elle ajoute "barre latérale, chercher, tirer, pousser, ajouter à distance, fusionner, choisir, rebaser, cloner, cloner vers"

Télécharger | Captures d'écran | référentiel git | fourche brotherbard | fourchette laullon

SmartGit

Depuis la page d'accueil:

SmartGit est un frontal pour le système de contrôle de version distribué Git et fonctionne sur Windows, Mac OS X et Linux. SmartGit est destiné aux développeurs qui préfèrent une interface utilisateur graphique à un client en ligne de commande, pour être encore plus productifs avec Git - le DVCS le plus puissant aujourd'hui.

Vous pouvez le télécharger à partir de leur site Web .

Télécharger

TortoiseGit

Version TortoiseSVN Git pour les utilisateurs de Windows.

Il transfère TortoiseSVN vers TortoiseGit La dernière version 1.2.1.0 Cette version peut effectuer des tâches régulières, telles que commit, show log, diff two version, create branch and tag, Create patch et ainsi de suite. Voir ReleaseNotes pour plus de détails. Bienvenue à contribuer à ce projet.

Télécharger

QGit

QGit est une visionneuse GUI git construite sur Qt / C ++.

Avec qgit, vous pourrez parcourir l'historique des révisions, afficher le contenu des correctifs et les fichiers modifiés, en suivant graphiquement différentes branches de développement.

Télécharger

gitg

gitg est une visionneuse de référentiel git ciblant gtk + / GNOME. L'un de ses principaux objectifs est de fournir une expérience utilisateur plus unifiée pour les frontends git sur plusieurs bureaux. Il ne s'agit pas d'écrire une application multiplateforme, mais en étroite collaboration avec des clients similaires pour d'autres systèmes d'exploitation (comme GitX pour OS X).

Caractéristiques

• Parcourir l'historique des révisions.
• Gérer les grands référentiels (charge le référentiel Linux, 17000+ révisions, moins de 1 seconde).
• Validez les modifications.
• Mettre en scène / mettre en scène des mecs individuels.
• Rétablir les changements.
• Afficher la différence colorisée des changements dans les révisions.
• Parcourir l'arborescence pour une révision donnée.
• Exportez des parties de l'arborescence d'une révision donnée.
• Fournissez toute refspec qu'une commande telle que «git log» peut comprendre pour construire l'historique.
• Afficher et basculer entre les branches dans la vue historique.

Téléchargement: versions ou source

Gitbox

Gitbox est une interface graphique Mac OS X pour le système de contrôle de version Git. Dans une seule fenêtre, vous voyez les branches, l'historique et l'état du répertoire de travail.

Les opérations quotidiennes sont faciles: mettez en scène et modifiez les changements avec une case à cocher. Validez, tirez, fusionnez et poussez en un seul clic. Double-cliquez sur une modification pour afficher un diff avec FileMerge.app.

Télécharger

Gity

Le site Web de Gity n'a pas beaucoup d'informations, mais à partir des captures d'écran, il semble être un git gui OS X open source riche en fonctionnalités.

Télécharger ou source

Meld

Meld est un outil de diff et de fusion visuel. Vous pouvez comparer deux ou trois fichiers et les éditer sur place (mise à jour dynamique des diffs). Vous pouvez comparer deux ou trois dossiers et lancer des comparaisons de fichiers. Vous pouvez parcourir et afficher une copie de travail à partir de systèmes de contrôle de version populaires tels que CVS, Subversion, Bazaar-ng et Mercurial [ et Git ].

Téléchargements

Katana

Une interface graphique Git pour OSX par Steve Dekorte.

En un coup d'œil, voyez quelles branches distantes ont des modifications à tirer et les dépôts locaux ont des modifications à pousser. Les opérations git d'ajout, de validation, de push, de pull, de tag et de reset sont prises en charge ainsi que les différences visuelles et la navigation visuelle de la hiérarchie du projet qui met en évidence les modifications et ajouts locaux.

Gratuit pour 1 référentiel, 25 $ pour plus.

Télécharger

Sprout (anciennement GitMac)

Se concentre sur la facilité d'utilisation de Git. Comprend une interface utilisateur Cocoa native (de type mac), une navigation rapide dans le référentiel, un clonage, un push / pull, une ramification / fusion, un diff visuel, des branches distantes, un accès facile au terminal, et plus encore.

En rendant les actions Git les plus couramment utilisées intuitives et faciles à exécuter, Sprout (anciennement GitMac) rend Git convivial. Compatible avec la plupart des workflows Git, Sprout est idéal pour les concepteurs et les développeurs, la collaboration en équipe et les utilisateurs avancés et novices.

Télécharger | Site Internet

La tour

Une interface graphique Git riche en fonctionnalités pour Mac OSX. Essai gratuit de 30 jours, 59 USD pour une licence mono-utilisateur.

Télécharger | Site Internet

EGit

EGit est un fournisseur Eclipse Team pour le système de contrôle de version Git. Git est un SCM distribué, ce qui signifie que chaque développeur a une copie complète de tout l'historique de chaque révision du code, ce qui rend les requêtes par rapport à l'historique très rapides et polyvalentes.

Le projet EGit implémente l'outillage Eclipse en plus de l'implémentation JGit Java de Git.

Télécharger | Site Internet

Extensions Git

Open Source pour Windows - installe tout ce dont vous avez besoin pour travailler avec Git dans un seul package, facile à utiliser.

Git Extensions est une boîte à outils pour rendre le travail avec Git sous Windows plus intuitif. L'extension shell s'intégrera dans l'Explorateur Windows et présente un menu contextuel sur les fichiers et les répertoires. Il existe également un plugin Visual Studio pour utiliser git depuis Visual Studio.

Télécharger

Un grand merci à dbr pour avoir élaboré le truc git gui.

SourceTree

SourceTree est un client Mac gratuit pour Git, Mercurial et SVN. Construit par Atlassian, les gens derrière BitBucket, il semble fonctionner aussi bien avec n'importe quel système VC, ce qui vous permet de maîtriser un seul outil à utiliser avec tous vos projets, quelle que soit leur version. Plein de fonctionnalités et GRATUIT.

Expert-Ready et riche en fonctionnalités pour les utilisateurs novices et avancés:

Passez en revue les ensembles de modifications sortants et entrants. Cerise-pick entre les branches. Gestion des correctifs, rebase, stash / shelve et bien plus encore.

Télécharger | Site Internet

Eh bien, malgré le fait que vous ayez demandé de ne pas «simplement» établir un lien avec d'autres ressources, c'est assez idiot quand il existe déjà une ressource cultivée (et croissante) communautaire qui est vraiment très bonne: le Git Community Book . Sérieusement, ces 20+ questions dans une question vont être tout sauf concises et cohérentes. Le Git Community Book est disponible en HTML et en PDF et répond à beaucoup de vos questions avec des réponses claires, bien formatées et examinées par les pairs et dans un format qui vous permet de passer directement à votre problème actuel.

Hélas, si mon message vous dérange vraiment, je le supprimerai. Dis-le.

Comment le configurer pour ignorer les fichiers:

La possibilité d'avoir git ignorer les fichiers que vous ne souhaitez pas suivre est très utile.

Pour ignorer un fichier ou un ensemble de fichiers, vous fournissez un modèle. La syntaxe du modèle pour git est assez simple, mais puissante. Il est applicable aux trois fichiers différents que je mentionnerai ci-dessous.

• Une ligne vierge n'ignore aucun fichier, elle est généralement utilisée comme séparateur.
• Les lignes commençant par # servent de commentaires.
• Le ! le préfixe est facultatif et annulera le modèle. Tout modèle annulé qui correspond remplacera les modèles de priorité inférieure.
• Prend en charge les expressions avancées et les caractères génériques
  • Ex: Le modèle: *. [Oa] ignorera tous les fichiers du référentiel se terminant par .o ou .a (fichiers objets et archives)
• Si un modèle a un répertoire se terminant par une barre oblique, git ne correspondra qu'à ce répertoire et aux chemins en dessous. Cela exclut les fichiers réguliers et les liens symboliques de la correspondance.
• Une barre oblique principale correspondra à tous les fichiers de ce nom de chemin.
  • Ex: le motif /*.c correspondra au fichier foo.c mais pas à bar / awesome.c

Excellent exemple de la page de manuel gitignore (5) :

$ git status
[...]
# Untracked files:
[...]
#       Documentation/foo.html
#       Documentation/gitignore.html
#       file.o
#       lib.a
#       src/internal.o
[...]
$ cat .git/info/exclude
  # ignore objects and archives, anywhere in the tree.
  *.[oa]
$ cat Documentation/.gitignore
# ignore generated html files,
*.html
# except foo.html which is maintained by hand
!foo.html
$ git status
[...]
# Untracked files:
[...]
#       Documentation/foo.html
[...]

En règle générale, il existe trois façons différentes d'ignorer les fichiers non suivis.

1) Ignorer pour tous les utilisateurs du référentiel:

Ajoutez un fichier nommé .gitignore à la racine de votre copie de travail.

Modifiez .gitignore pour correspondre à vos préférences pour quels fichiers doivent / ne doivent pas être ignorés.

git add .gitignore 

et engagez-vous lorsque vous avez terminé.

2) Ignorez uniquement votre copie du référentiel:

Ajouter / modifier le fichier $ GIT_DIR / info / exclude dans votre copie de travail, avec vos modèles préférés.

Ex: ma copie de travail est ~ / src / project1 donc je voudrais éditer ~ / src / project1 / .git / info / exclude

Vous avez terminé!

3) Ignorez dans toutes les situations, sur votre système:

Les modèles d'ignorance globaux pour votre système peuvent aller dans un fichier nommé comme vous le souhaitez.

Le mien s'appelle personnellement ~ / .gitglobalignore

Je peux ensuite informer git de ce fichier en modifiant mon fichier ~ / .gitconfig avec la ligne suivante:

core.excludesfile = ~/.gitglobalignore

Vous avez terminé!

Je trouve que la page de manuel de gitignore est la meilleure ressource pour plus d'informations.

Comment «étiqueter» un ensemble particulier de révisions

Comment «marquer» «tag» ou «publier» un ensemble particulier de révisions pour un ensemble particulier de fichiers afin de pouvoir toujours le récupérer plus tard?

Utilisation de la git tagcommande.

Pour simplement "baliser" la révision actuelle, il vous suffit d'exécuter ..

git tag -a thetagname
git tag -a 0.1
git tag -a 2.6.1-rc1 -m 'Released on 01/02/03'

Pour lister les balises actuelles, exécutez simplement git tagsans arguments, ou -l(en minuscule L):

$ git tag -a thetagname # and enter a message, or use -m 'My tag annotation'
$ git tag -l
thetagname

Pour supprimer une balise, vous utilisez le -ddrapeau:

$ git tag -d thetagname 
Deleted tag 'thetagname'
$ git tag
[no output]

Pour baliser un commit spécifique (précédent), il vous suffit de le faire.

git tag [tag name] [revision SHA1 hash]

Par exemple:

git tag 1.1.1 81b15a68c6c3e71f72e766931df4e6499990385b

Remarque: par défaut, git crée une balise "légère" (essentiellement une référence à une révision spécifique). La "bonne" façon est d'utiliser le -adrapeau. Cela lancera votre éditeur demandant un message de balise (identique à la demande d'un message de validation, vous pouvez également utiliser l' -mindicateur pour fournir le message de balise sur la ligne de commande). L'utilisation d'une balise annotée crée un objet avec son propre ID, date, tagueur (auteur) et éventuellement une signature GPG (en utilisant la -sbalise). Pour plus d'informations à ce sujet, consultez cet article

git tag mytagwithmsg -a -m 'This is a tag, with message'

Et pour répertorier les balises avec des annotations, utilisez l' -n1indicateur pour afficher 1 ligne de chaque message de balise ( -n245pour afficher les 245 premières lignes de chaque annotation, etc.):

$ git tag -l -n1
mytagwithmsg    This is a tag, with message

Pour plus d'informations, consultez la page de manuel git-tag (1)

Exemple de workflow avec GIT.

Git est extrêmement flexible et s'adapte bien à n'importe quel flux de travail, mais ne pas appliquer un flux de travail particulier pourrait avoir pour effet négatif de rendre difficile la compréhension de ce que vous pouvez faire avec git au-delà du flux de travail de «sauvegarde» linéaire, et de l'utilité des branchements, par exemple .

Cet article de blog explique bien un flux de travail très simple mais efficace qui est vraiment facile à configurer à l'aide de git.

citant le blog: Nous considérons l'origine / master comme la branche principale où le code source de HEAD reflète toujours un état prêt pour la production:

Le workflow est devenu suffisamment populaire pour avoir créé un projet qui implémente ce workflow: git-flow

Belle illustration d'un flux de travail simple, où vous effectuez toutes vos modifications en développement, et ne poussez pour maîtriser que lorsque le code est dans un état de production:

Supposons maintenant que vous souhaitiez travailler sur une nouvelle fonctionnalité ou sur la refactorisation d'un module. Vous pourriez créer une nouvelle branche, ce que nous pourrions appeler une branche "caractéristique", quelque chose qui prendra un certain temps et pourrait casser du code. Une fois que votre fonctionnalité est "suffisamment stable" et que vous souhaitez la rapprocher de la production, vous fusionnez votre branche de fonctionnalité en développement. Lorsque tous les bogues sont triés après la fusion et que votre code réussit tous les tests, vous transférez vos modifications dans master.

Pendant tout ce processus, vous trouvez un terrible bogue de sécurité, qui doit être corrigé immédiatement. Vous pouvez avoir une branche appelée hotfixes, qui apporte des modifications qui sont repoussées plus rapidement dans la production que la branche "develop" normale.

Ici, vous avez une illustration de l'aspect de cette fonctionnalité / correctif / développement / production (bien expliqué dans le billet de blog, et je le répète, le blog explique le processus dans son ensemble avec beaucoup plus de détails et beaucoup mieux que moi. .

Voici une copie du message de PJ Hyett, car il n'est plus disponible:

Git n'est pas difficile

23 nov. 2008

Quand nous disons aux gens pourquoi ils devraient utiliser Git sur Subversion, la ligne de référence est: "Git fait Subversion mieux que Subversion, mais il fait beaucoup plus que cela."

Le «beaucoup plus» est composé d'un tas de choses qui font vraiment briller Git, mais cela peut être assez écrasant pour ceux qui viennent d'autres SCM comme Subversion.

Cela dit, rien ne vous empêche d'utiliser Git comme vous utilisez Subversion pendant que vous effectuez la transition.

En supposant que vous avez installé le logiciel nécessaire et que vous disposez d'un référentiel distant quelque part, voici comment récupérer le code et repousser vos modifications avec Subversion:

$ svn checkout svn://foo.googlecode.com/svn/trunk foo
# make your changes
$ svn commit -m "my first commit"

Et comment le feriez-vous dans Git:

$ git clone git@github.com:pjhyett/foo.git
# make your changes
$ git commit -a -m "my first commit"
$ git push

Une commande de plus pour que cela se produise dans Git. Cette commande supplémentaire a de grandes implications, mais pour les besoins de ce post, c'est tout ce dont nous parlons, une commande supplémentaire.

Vous voyez, ce n'est vraiment pas si difficile.

Mise à jour: je m'en voudrais de ne pas mentionner également que l'équivalent de la mise à jour de votre copie locale dans Subversion par rapport à Git est svn updateet git pull, respectivement. Une seule commande dans les deux cas.

Comment installer Git

Sous Windows:

Installer msysgit

Il existe plusieurs téléchargements:

• Git: utilisez-le sauf si vous avez spécifiquement besoin de l'une des autres options ci-dessous.
• PortableGit: utilisez-le si vous souhaitez exécuter Git sur un PC sans l'installer sur ce PC (par exemple, exécuter Git à partir d'un lecteur USB)
• msysGit: utilisez-le si vous souhaitez développer Git lui-même. Si vous souhaitez simplement utiliser Git pour votre code source, mais ne souhaitez pas modifier le code source de Git , vous n'en avez pas besoin.

Cela installe également un shell bash Cygwin, vous pouvez donc utiliser le gitdans un shell plus agréable (que cmd.exe), et inclut également git-gui (accessible via la git guicommande ou leStart > All Programs > Git menu)

Mac OS X

Utilisez l' installateur git-osx , ou vous pouvez également installer à partir des sources

Via un gestionnaire de packages

Installez à l' gitaide de votre gestionnaire de packages natif. Par exemple, sur Debian (ou Ubuntu):

apt-get install git-core

Ou sous Mac OS X, via MacPorts :

sudo port install git-core+bash_completion+doc

… Ou fink:

fink install git

… Ou Homebrew :

brew install git

Sur les distributions basées sur Red Hat, telles que Fedora:

yum install git

Dans Cygwin, le paquet Git se trouve dans la section "devel"

Depuis la source (Mac OS X / Linux / BSD / etc.)

Sous Mac OS X, si les outils de développement sont installés, vous pouvez compiler Git à partir des sources très facilement. Téléchargez la dernière version de Git en tant que .tar.bzou .tar.gzdepuis http://git-scm.com/ et extrayez-la (double-cliquez dans le Finder)

Sous Linux / BSD / etc. il devrait en être de même. Par exemple, dans Debian (et Ubuntu), vous devez installer le build-essentialpaquet via apt.

Ensuite, dans un terminal, cdà l'endroit où vous avez extrait les fichiers (l'exécution cd ~/Downloads/git*/devrait fonctionner), puis exécutez ..

./configure && make && sudo make install

Cela installera Git à l'emplacement par défaut ( /usr/local- gitsera donc dans/usr/local/bin/git )

Il vous invitera à entrer votre mot de passe (pour sudo), afin qu'il puisse écrire dans le /usr/local/répertoire, qui ne peut être consulté que par l'utilisateur "root", donc sudo est requis!

Si vous souhaitez l'installer dans un endroit séparé (afin que les fichiers de Git ne soient pas mélangés avec d'autres outils), utilisez-le --prefixavec la commande configure:

./configure --prefix=/usr/local/gitpath
make
sudo make install

Cela installera le gitbinaire dans /usr/local/bin/gitpath/bin/git- vous n'avez donc pas à taper cela à chaque fois que vous, vous devez ajouter dans votre $PATHen ajoutant la ligne suivante dans votre ~/.profile:

export PATH="${PATH}:/usr/local/bin/gitpath/bin/"

Si vous n'avez pas accès à sudo, vous pouvez utiliser --prefix=/Users/myusername/binet installer dans votre répertoire personnel. N'oubliez pas d'ajouter ~/bin/à$PATH

Le script x-git-update-to-latest-version automatise une grande partie de ceci:

Ce script met à jour mon clone local du dépôt git (localement sur ~/work/track/git), puis configure, installe (sur /usr/local/git- git describe) et met à jour le /usr/local/gitlien symbolique.

De cette façon, je peux avoir /usr/local/git/bindans mon PATHet j'utilise toujours la dernière version.

La dernière version de ce script installe également les pages de manuel. Vous devez modifier votre MANPATHpour inclure le /usr/local/git/share/manrépertoire.

Git Reset

Disons que vous faites un pull, fusionnez-le dans votre code et décidez que vous ne l'aimez pas. Utilisez git-log, ou tig, et trouvez le hachage de l'endroit où vous souhaitez revenir (probablement votre dernier commit avant le pull / merge) copiez le hachage, et faites:

# Revert to a previous commit by hash:
git-reset --hard <hash>

Au lieu du hachage, vous pouvez utiliser HEAD ^ comme raccourci pour le commit précédent.

# Revert to previous commit:
git-reset --hard HEAD^

Comment configurer un référentiel d'équipe partagé?

Comment configurer un référentiel normal est décrit ici - mais comment configurer un référentiel d'équipe que tout le monde peut extraire et transmettre?

Utilisation d'un système de fichiers NFS partagé

En supposant que votre équipe possède déjà, par exemple, une appartenance à un groupe partagé qui peut être utilisée.

mkdir /your/share/folder/project.git
cd /your/share/folder/project.git
newgrp yourteamgroup # if necessary
git init --bare --shared

Pour commencer à utiliser ce référentiel, la chose la plus simple à faire est de démarrer à partir d'un référentiel local que vous avez déjà utilisé:

cd your/local/workspace/project
git remote add origin /your/share/folder/project.git
git push origin master

D'autres peuvent maintenant cloner cela et commencer à travailler:

cd your/local/workspace
git clone /your/share/folder/project.git

Utilisation de SSH

Configurez un compte utilisateur sur le serveur cible. Que vous utilisiez un compte sans mot de passe, un compte avec mot de passe ou que vous utilisiez, authorized_keyscela dépend vraiment de votre niveau de sécurité requis. Jetez un œil à la configuration de Git sur SSH pour plus d'informations.

Si tous les développeurs utilisent le même compte pour accéder à ce référentiel partagé, vous n'avez pas besoin d'utiliser l' --sharedoption comme ci-dessus.

Après avoir lancé le référentiel de la même manière que ci-dessus, vous effectuez le push initial comme ceci:

cd your/local/workspace/project
git remote add origin user@server:/path/to/project.git
git push origin master

Voir la similitude avec ce qui précède? La seule chose qui pourrait arriver en plus est que SSH demande un mot de passe si le compte a un mot de passe. Si vous obtenez cette invite sur un compte sans mot de passe, le serveur SSH est probablement désactivé PermitEmptyPasswords.

Le clonage ressemble maintenant à ceci:

cd your/local/workspace
git clone user@server:/path/to/project.git

git statusest votre ami, utilisez-le souvent. Bon pour répondre à des questions comme:

• Qu'est-ce que cette commande vient de faire?
• Sur quelle branche suis-je?
• Quels changements vais-je m'engager et ai-je oublié quelque chose?
• Étais-je au milieu de quelque chose la dernière fois que j'ai travaillé sur ce projet (jours, semaines ou peut-être des mois)?

Contrairement à, disons svn status, git statusfonctionne presque instantanément, même sur de grands projets. Je l'ai souvent trouvé rassurant en apprenant à utiliser Git fréquemment, pour m'assurer que mon modèle mental de ce qui se passait était exact. Maintenant, je l'utilise principalement pour me rappeler ce que j'ai changé depuis mon dernier commit.

Évidemment, c'est beaucoup plus utile si votre .gitignore est correctement configuré.

Valider les modifications

Une fois que vous avez modifié un fichier, vous devez valider vos modifications dans git. Lorsque vous exécutez cette commande, il demandera un message de validation - qui est juste un simple morceau de texte qui indique à tout le monde ce que vous avez modifié.

$ git commit source/main.c

Validera le fichier main.c dans le répertoire ./source/

$ git commit -a # the -a flag pulls in all modified files

va valider tous les fichiers modifiés (mais pas les nouveaux fichiers, ceux-ci doivent être ajoutés à l'index avec git-add). Si vous ne souhaitez valider que certains fichiers, vous devrez d'abord les mettre en scène avec git-add, puis valider sans l'indicateur -a.

La validation ne modifie que votre référentiel local mais pas les référentiels distants. Si vous souhaitez envoyer les validations au référentiel distant, vous devrez faire un push.

$ git push <remote> <branch> # push new commits to the <branch> on the <remote> repository

Pour quelqu'un venant de CVS ou SVN, c'est un changement puisque la validation dans le référentiel central nécessite désormais deux étapes.

Comment branchez-vous?

La branche par défaut dans un référentiel git est appelée master.

Pour créer une nouvelle branche, utilisez

git branch <branch-name>

Pour afficher une liste de toutes les branches du type de référentiel actuel

git branch

Si vous souhaitez passer à une autre branche, vous pouvez utiliser

git checkout <branch-name>

Pour créer une nouvelle branche et y basculer en une seule étape

git checkout -b <branch-name>

Pour supprimer une branche, utilisez

git branch -d <branch-name>

Pour créer une branche avec les modifications de la branche actuelle, faites

git stash
git stash branch <branch-name>

Obtenir le dernier code

$ git pull <remote> <branch> # fetches the code and merges it into 
                             # your working directory
$ git fetch <remote> <branch> # fetches the code but does not merge
                              # it into your working directory

$ git pull --tag <remote> <branch> # same as above but fetch tags as well
$ git fetch --tag <remote> <branch> # you get the idea

Cela couvre à peu près tous les cas pour obtenir la dernière copie du code à partir du référentiel distant.

Le livre gratuit Pro Git est définitivement mon préféré, surtout pour les débutants.

Git Magic est tout ce dont vous aurez besoin. Garanti ou remboursé!

Comment fusionnez-vous les succursales?

Si vous souhaitez fusionner une branche (par exemple mastervers release), assurez-vous que votre branche actuelle est la branche cible dans laquelle vous souhaitez fusionner (utilisez git branchou git statuspour voir votre branche actuelle).

Ensuite, utilisez

git merge master

(où masterest le nom de la branche que vous souhaitez fusionner avec la branche actuelle).

En cas de conflit, vous pouvez utiliser

git diff

pour voir les conflits en attente, vous devez les résoudre.

J'ai également trouvé que Git Internals était très utile. Il est écrit par Scott Chacon (auteur de Pro Git et mainteneur du Git Community Book). Ce que j'aime chez Git Internals, c'est qu'il se concentre d'abord sur les concepts, puis sur les commandes , et étant donné qu'il fait ~ 100 petites pages, il est rapidement digeste.

Comment voyez-vous l'historique des révisions d'un fichier?

git log -- filename

Comment suivre les succursales distantes

En supposant qu'il existe un référentiel distant à partir duquel vous avez cloné votre référentiel local et en supposant également qu'il existe une branche nommée 'some_branch' sur ce référentiel distant, voici comment le suivre localement:

# list remote branches
git branch -r

# start tracking one remote branch
git branch --track some_branch origin/some_branch

# change to the branch locally
git checkout some_branch

# make changes and commit them locally
....

# push your changes to the remote repository:
git push

Un très bon article pour comprendre comment fonctionne Git est la parabole Git . Très recommandé!

Comment comparez-vous deux révisions d'un fichier, ou votre fichier actuel et une révision précédente?

La commande de comparaison est git diff.

Pour comparer 2 révisions d'un fichier:

$ git diff <commit1> <commit2> <file_name>

Cela diffère commit1 contre commit2; si vous changez l'ordre, les fichiers sont différés dans l'autre sens, ce qui n'est peut-être pas ce que vous attendez ...

Pour comparer le fichier intermédiaire en cours avec le référentiel:

$ git diff --staged <file_name>

Pour comparer le fichier non organisé actuel avec le référentiel:

$ git diff <file_name>

Pourquoi encore un autre howto? Il y en a vraiment de bons sur le net, comme le git guide qui est parfait pour commencer. Il a de bons liens, y compris le git book auquel on peut contribuer (hébergé sur git hub) et qui est parfait pour cette tâche collective.

Sur stackoverflow, je préférerais vraiment voir vos astuces préférées!

La mienne, que je n'ai découverte que récemment, est git stash, expliquée ici , qui vous permet de sauvegarder votre emploi actuel et d'aller dans une autre branche

EDIT: comme le post précédent, si vous préférez vraiment le format stackoverlow avec des messages en tant que wiki, je supprimerai cette réponse

Interface utilisateur de la console - Tig

Installation:

apt-get install tig

Usage

À l'intérieur d'un dépôt git, tapez 'tig', pour afficher un journal interactif, appuyez sur 'entrer' sur n'importe quel journal pour voir plus d'informations à ce sujet. h pour obtenir de l'aide, qui répertorie les fonctionnalités de base.

Trivia

"Tig" est "Git" à l'envers.

Comment puis-je créer une branche sur un référentiel distant?

En supposant que vous avez cloné votre référentiel distant à partir d'un référentiel distant unique.

# create a new branch locally
git branch name_of_branch
git checkout name_of_branch
# edit/add/remove files    
# ... 
# Commit your changes locally
git add fileName
git commit -m Message
# push changes and new branch to remote repository:
git push origin name_of_branch:name_of_branch

J'ai commencé avec le tutoriel officiel de Git . Je pense que c'est assez pratique pour les débutants (j'étais et je suis toujours un débutant, selon votre définition! Je saisis à peine les makefiles, je n'ai que peu joué avec Apache Subversion, etc.).

Comment supprimer une branche d'un référentiel distant?

Effectuer un push dans votre télécommande en utilisant :avant le nom de la branche

git push origin :mybranchname

étant originle nom de votre télécommande etmybranchname le nom de la branche sur le point d'être supprimée

http://help.github.com/remotes/

Modifications push et pull

De manière simplifiée, il suffit de faire git pushet git pull. Les modifications sont fusionnées et s'il y a un conflit, git vous le fera savoir et vous pourrez le résoudre manuellement.

Lorsque vous accédez pour la première fois à un référentiel distant, vous devez effectuer un git push origin master(master étant la branche master). À partir de là, il vous suffit de faire le git push.

Poussez les balises avec git push --tags.

Extraire le code

Allez d'abord dans un répertoire vide, utilisez "git init" pour en faire un référentiel, puis clonez le dépôt distant dans le vôtre.

git clone user@host.com:/dir/to/repo

Partout où vous clonez initialement, c'est d'où "git pull" tirera par défaut.

Gity: http://macendeavor.com/gity