De TFS à Git

14

Je suis un développeur .NET et j'ai utilisé TFS (Team Foundation Server) comme logiciel de contrôle de source à plusieurs reprises. Les bonnes fonctionnalités de TFS sont:

  1. Bonne intégration avec Visual Studio (donc je fais presque tout visuellement; pas de commandes console)
  2. Check-out et processus d'enregistrement faciles
  3. Fusion facile et résolution de conflits
  4. Constructions automatisées faciles
  5. Ramification

Maintenant, je veux utiliser Git comme colonne vertébrale, référentiel et contrôle de source de mes projets open source. Mes projets sont en langage C #, JavaScript ou PHP avec des bases de données MySQL ou SQL Server comme mécanisme de stockage.

Je viens d'utiliser l'aide de github.com à cet effet et j'ai créé un profil là-bas et téléchargé une interface graphique pour Git. Jusqu'à cette partie était si facile.

Mais je suis presque obligé d'aller plus loin. Je veux juste faire quelques opérations simples (vraiment simples), notamment:

  1. Créer un projet sur Git et le mapper dans un dossier sur mon ordinateur portable
  2. Extraire / archiver des fichiers et des dossiers
  3. Résolution des conflits

C'est tout ce que je dois faire maintenant. Mais il semble que l'interface graphique ne soit pas très conviviale. Je m'attends à ce que l'interface graphique ait un Connect To...ou quelque chose comme ça, puis j'attends une liste de projets à afficher, et quand j'en choisis un, je m'attends à voir la liste des fichiers et des dossiers de ce projet, tout comme l'exploration de votre projet TFS dans Visual Studio. Ensuite, je veux pouvoir cliquer avec le bouton droit sur un fichier et sélectionner check-in...ou check-outet des trucs comme ça.

J'attends beaucoup? Que dois-je faire pour utiliser facilement Git comme TFS? Qu'est-ce que j'oublie ici?

Saeed Neamati
la source
8
Je suis passé de SVN à git il y a un an, et j'en suis très content. Je ne recommanderais PAS SVN à quiconque, sauf à un haineux de ligne de commande rigide. Une fois que vous aurez appris Git, vous l'adorerez.
maaartinus
14
Pourquoi les gens de Windows sont-ils si obsédés par les interfaces graphiques?
tdammers
8
@tdammers Parce que la ligne de commande sur Windows craint comme l'enfer? Je sais, il y a PowerShell, mais l'utilisent-ils?
maaartinus
3
@Saeed, pour commencer, vous vous attendez à ce que l'archivage et le retrait de fichiers dans git. Aucun VCS utilisable n'a cela depuis des années.
Daniel Roseman du
1
Lecture recommandée: ericsink.com/entries/vcbe_print_edition_free.html Il explique les bases du contrôle de version et les différences entre centralisé et décentralisé (qui pourraient toujours utiliser un serveur central, l'esprit.)
Inca

Réponses:

19

Les avantages de git sont venus de jeter beaucoup d'anciennes hypothèses sur ce qu'un VCS devrait faire. Les inconvénients sont dus au fait de ne pas pouvoir tirer parti de l'expérience antérieure et de ne pas pouvoir faire les choses comme vous en avez l'habitude.

Si vous allez passer de quelque chose d'autre à git, essayez de démarrer tabula-rasa (bien qu'il soit impossible de le faire vraiment dans la pratique). Évaluez-le en fonction de ce qu'il fait et de la façon dont il le fait, et non de la façon dont il le fait par rapport à la façon dont vous êtes habitué à le faire. Ce n'est pas que vous attendez trop, c'est que vos attentes sont orthogonales à ce que git fournit. Si vous êtes marié avec une interface graphique, vous serez déçu. Git dispose d'outils gui, mais ils n'ajoutent pas grand-chose. Ce n'est pas un échec de les fournir autant qu'il n'y a pas grand-chose qu'un GUI puisse ajouter. GitK aide, non pas dans les opérations quotidiennes, mais plutôt dans la visualisation de la structure de la branche et l'examen ou la recherche de l'historique.

Voici une analogie maladroite pour ce que je veux dire par "orthogonal". L'une des choses que vous pouvez faire avec un journal est d'envelopper du poisson ou de l'utiliser pour tapisser une cage à oiseaux. Mais ceux-ci ne sont pas essentiels au fonctionnement d'un journal, ce sont des caractéristiques accessoires du formulaire dans lequel il se présente. ", c'est un peu comme s’attendre à pouvoir envelopper du poisson ou à tapisser votre cage à oiseaux du site Web d’ un journal .

kylben
la source
Oups, j'ai oublié d'expliquer le montage. Je viens d'ajouter le dernier paragraphe après m'être levé pour plus de café et avoir l'analogie en tête.
kylben
3
J'ai adoré la métaphore à la fin. +1
Yam Marcovic
7

Avez-vous pensé au mercure? Comme git, c'est un DCVS et vous permet de faire toutes les bonnes choses que l'on peut faire avec un DCVS. Comme git, il existe un assez bon fournisseur de services cloud (bitbucket). Mais, contrairement à Git, l'histoire de Windows est assez décente, vous n'êtes pas un citoyen de 2e classe. Vous disposez de bonnes options d'outils (TortiseHG) et d'une intégration assez décente de Visual Studio (VisualHG).

Cependant, rien ne ressemblera à TFS dans Visual Studio - le monde n'est tout simplement pas câblé de cette façon.

Wyatt Barnett
la source
1
Je suis d'accord, il y a quelques années, je suis passé de VSS à Mercurial et ce fut une véritable révélation. Soudain, je pouvais faire des choses que je n'aurais jamais pensé être pratiques. Ensuite, j'ai déménagé svnet j'ai raté beaucoup de choses qui étaient tellement faciles à intégrer hg. Maintenant, je déménage gitet j'ai des sentiments mitigés. J'adore récupérer bon nombre de ces installations que j'ai manquées svn, mais la simplicité de me manque encore hgpar rapport à la complexité inutile de git. Même simplement l'installation de TortoiseGit sur Windows vous oblige à sauter à travers des cerceaux qui ne sont tout simplement pas nécessaires avec TortoiseHg .
Mark Booth,
@Mark Booth: Je suis d'accord que git n'est pas très convivial, mais quelle complexité inutile ? Les problèmes d'installation ne comptent pas, ils peuvent être attribués à TortoiseGit (qui est un programme différent) ou à Windows.
maaartinus
Ce serait mieux sur le chat, mais je ne vois absolument aucun besoin pour la zone d'index / cache / staging, à mon humble avis, la valeur par défaut devrait être de tout commettre avec l'option de validations partielles si demandé (mieux serait de mettre de côté les changements que vous don vous ne voulez pas immédiatement, relancez vos tests unitaires, validez puis décompressez). Je déteste aussi devoir créer explicitement une nouvelle branche quand j'en veux une. Avec hg, une branche sans nom est créée silencieusement chaque fois que vous vous engagez sur un non-head. Dans git, si vous vous éloignez d'une tête sans ramification, vous pouvez potentiellement la perdre et la faire ramasser!
Mark Booth,
6

Je suis passé de SVN à git il y a un an, et j'en suis très content. Cependant, je ne me fie à aucune interface graphique et si vous refusez de manière rigide la ligne de commande, cela peut être un problème.

Vous semblez vous attendre gità travailler comme d'habitude, mais ce n'est pas le cas. Ce n'est pas difficile, mais vous devriez jeter un œil à ses principes avant de continuer.

Créer un projet sur Git et le mapper dans un dossier sur mon ordinateur portable

Git est distribué, ce qui signifie que vous travaillez toujours avec votre référentiel local, qui peut être mappé à n'importe quel nombre de télécommandes, y compris zéro. Lorsque je joue avec un autre projet, j'utilise deux télécommandes: leur dépôt git ou SVN et mon propre serveur.

Je commence toujours par créer un répertoire vide, puis soit par git initou git clone SOME-REMOTE-REPOSITORY. Ce lien pourrait vous aider.

Extraire / archiver des fichiers et des dossiers

Vous avez manqué d'écrire l'interface graphique que vous utilisez. Les deux TortoiseGitet git-guipeut certainement le faire.

Résolution des conflits

Pour cela, j'utilise git-guiou mon éditeur de texte préféré.

Je m'attends à ce que l'interface graphique ait une connexion à ... ou quelque chose comme ça

Connectez-vous à quoi, quand il peut y avoir 0 à N télécommandes? Git ne reste pas connecté à un serveur distant, il crée la connexion uniquement temporairement et uniquement pour les quelques commandes travaillant avec le référentiel distant. La plupart du travail se fait localement.

alors j'attends une liste de projets

Je suppose par projectsvous dire repositories.

J'ai bien peur que ça n'existe pas. Git sur un serveur distant fonctionne strictement avec un seul référentiel. La liste de tous les référentiels équivaut à répertorier tous les répertoires contenant le sous-répertoire .git. Je suis sûr qu'il y a quelque chose comme ça GitHub.

J'en choisis un, je m'attends à voir la liste des fichiers et dossiers de ce projet, tout comme l'exploration

Encore une fois, je crains que cela n'existe pas, car il gittravaille localement. Et encore une fois, ce ne serait pas d'une grande utilité. Clonez simplement le référentiel et explorez-le sur votre ordinateur. Bien que le clonage d'énormes référentiels prenne un certain temps, toutes les opérations suivantes sont beaucoup plus rapides et vous pouvez consulter n'importe quelle validation ou branche.

Ensuite, je veux pouvoir cliquer avec le bouton droit sur un fichier et sélectionner l'archivage ... ou l'extraction et des trucs comme ça.

Encore une fois, gitfonctionne localement. Cela n'a donc aucun sens de s'enregistrer ou de se retirer dans un dépôt à distance. Travailler de cette façon est une perte de temps, même sur un réseau local rapide. Obtenez le référentiel sur votre ordinateur, travaillez avec lui et git pushles modifications apportées à la télécommande. Pensez-y, comme publier vos modifications et également effectuer une sauvegarde. Vous devez vous engager localement très souvent .

Avant de commencer votre travail, git fetchou git pullles modifications de la télécommande au cas où quelqu'un d'autre aurait pu travailler avec elle.

J'attends beaucoup?

Oui et non. Vous attendez quelque chose de différent de ce qu'il offre. Vous pouvez obtenir quelque chose de beaucoup mieux, gitêtre puissant, flexible, sûr, rapide comme l'enfer et faire tout ce dont vous avez besoin, mais il ne peut pas imiter exactement ce que fait un VCS centralisé.

maaartinus
la source
5

J'ai rendu le journal de la source visuelle sûr au tfs au svn au git.

Passer de vss à tfs a été une expérience agréable. Passer de tfs à svn a été une expérience agréable. Passer de svn à git a été une sorte de bataille interne.

Souvent, je me trouve assez conservateur et j'essaye de m'accrocher à ce qui fonctionne. Un bon gui est pour moi préférable à la ligne de commande et je me suis retrouvé à chercher un gui qui me permettrait de jouer avec les enfants cool avec qui je travaille. Ils ont tous utilisé exclusivement git avec la ligne de commande.

Le moment eureka pour moi est venu une fois que j'ai abandonné la recherche d'un gui argenté et que j'ai commencé à essayer git bash (j'apprends toujours).

J'ai quelques guis installés et ils complètent git depuis la ligne de commande. Extensions Git, fournisseur de contrôle de source Git pour Visual Studio et Tortoise Git. Mais je dis se familiariser avec git bash. Les commandes peuvent être un peu énigmatiques mais une fois que vous les apprenez, elles sont tellement plus rapides que l'interface graphique.

Le branchement avec git est tout simplement génial par rapport aux autres. Créez des branches et passez d'une branche à l'autre presque instantanément. Vous pouvez faire des choses que vous ne prendriez pas la peine de faire avec svn parce que svn copie fondamentalement votre copie de travail (du moins comme je l'ai fait).

Je trouve que Git a une courbe d'apprentissage plus abrupte que svn. Mais une fois que vous avez "compris" avec git, vous ne voulez plus y retourner.

Git tout le chemin.

tomasat
la source
5

Vous avez l'habitude d'avoir un serveur qui stocke vos fichiers et en est le propriétaire omnipotent. Pour modifier un fichier, vous devez demander l'autorisation au serveur.

Git n'est pas comme ça. Pensez à git de cette façon: vous avez votre référentiel local. Git vous permet de valider des modifications, des validations inverses, des branchements simples et rapides, etc. Lorsque vous souhaitez sauvegarder votre historique de contrôle de source, vous transférez vos modifications vers un autre référentiel, qui "se trouve être" un serveur, comme GitHub.com.

Flux de travail:

  1. Cloner (Télécharger) / Créer un référentiel
  2. Apportez quelques modifications. Poursuivez le développement sans vous soucier des autres.
  3. Poussez vers un autre référentiel (peut être un serveur comme GitHub).
  4. Lorsque vous passez à un référentiel, le propriétaire de cet autre référentiel est informé de la transmission en attente et doit décider d'accepter ces validations, de les refuser ou de n'en prendre qu'un sous-ensemble.
  5. Le cycle continue.

C'est tout.

Yam Marcovic
la source
1

Que voulez-vous dire, "le" git gui? Il y en a des millions, y compris un plugin pour l'intégration de Visual Studio, si je me souviens bien. Si une interface graphique ne fonctionne pas pour vous, essayez-en plus jusqu'à ce que vous en trouviez une qui fonctionne. J'utilise personnellement différentes GUI pour différentes tâches (et la CLI pour les autres).

Cependant, git est plus un framework de contrôle de version qu'un système fixe. Vous devrez toujours apprendre quelques notions de base pour en tirer le meilleur parti.

Karl Bielefeldt
la source
-2

J'attends beaucoup?

Oui

Que dois-je faire pour utiliser facilement Git comme TFS?

Rien. Git est centré sur CLI et n'a pas de bonne interface (je connais TortoiseGit, qui n'est pas une réponse, comparé aux autres Tortoise *). Vous pouvez essayer d'utiliser SmartGit (méfiez-vous de Java)

Blaireau paresseux
la source
1
-1: L'archivage / extraction de fichiers et la résolution de conflits n'attendent pas grand-chose du contrôle de code source.
Steven Evers
2
+1 Les vérifier directement à partir d'un serveur distant n'a tout simplement aucun sens. C'est juste pour ralentir, même sur LAN. Faire de telles choses est une fonction FTP, pas VCS.
maaartinus
1
«Archiver / extraire» des fichiers n'est pas une opération fondamentale pour un VCS. C'est une fonctionnalité d'implémentation commune à la plupart des VCS, et qui a des effets secondaires subtils mais malheureux.
kylben
2
@kylben: l'archivage / le retrait est une façon d'examiner le contrôle de version; l'édition et la fusion est une autre façon. Certains VCS utilisent l'ancienne approche, vous offrant des verrous exclusifs et la possibilité d'extraire des fichiers individuels; d'autres prennent ce dernier, et avec ceux-ci, vous téléchargez l'intégralité du référentiel, apportez vos modifications locales, puis les repoussez sur la télécommande; le VCS s'occupe de gérer les changements conflictuels, en demandant votre avis en cas de doute. Aucune des deux approches n'est meilleure, mais vous ne pouvez généralement pas plier un VCS dans celui pour lequel il n'a pas été conçu.
tdammers
1
En `` archivant / sortant '', je parlais en fait de la façon dont les VCS basés sur les verrous implémentent les choses, pas de la façon dont vous pouvez télécharger les fichiers source pour les éditer (ce qui est en effet quelque chose que chaque VCS doit être capable de faire). Le fait que de nombreux VCS se réfèrent au simple processus de téléchargement d'un fichier comme `` extraction '' est un peu un IMO impropre - rien n'est vérifié, et le référentiel ne se souvient pas qui a le fichier.
tdammers