Comment puis-je maintenir la qualité du code sans SCM?

Question

Je travaille dans une institution gouvernementale. La technologie utilisée ici et les méthodes de développement de logiciels sont assez démodées.

Ils ont des tonnes d'espace de stockage mais pas d'espace approprié pour conserver et maintenir les applications utilisées pour automatiser la plupart des travaux ici.

L'institution ne me permettrait pas d'utiliser des logiciels SCM comme GIT ou SVN.

Quelle serait la meilleure approche pour conserver la qualité du code et pouvoir ajouter de nouvelles fonctionnalités dans les applications plus tard?

Comment puis-je me souvenir des modifications que j'ai apportées au code sans le casser?

EDIT: J'ai oublié de mentionner, ils ont des lecteurs réseau pour chacun des ordinateurs et en quelque sorte ces lecteurs réseau font ou enregistrent des sauvegardes par périodes. Cependant, si je ne crée pas mon propre plan permettant d'enregistrer mon travail et de pouvoir ajouter de nouvelles fonctionnalités sans casser le code existant, il n'y a pas de gros avantage par rapport à une solution SCM.

EDIT: Puisque beaucoup de gens ont suggéré Git portable, je dois ajouter plus d'informations. J'ai essayé d'installer le serveur Visual SVN, mais cela a échoué car je n'ai pas les privilèges d'administrateur à installer. J'ai également essayé de télécharger régulièrement Git Shell, mais le pare-feu ou les paramètres réseau ne me permettaient pas d'accéder à la page de téléchargement de Git. J'ai même essayé d'envoyer Git portable à mon email qui est Gmail. Google a détecté le fichier exe dans le package et il ne m'a pas non plus permis de télécharger la version portable de Git sur mon ordinateur de travail. Une autre chose que je dois mentionner, la politique de réseau appliquée aux ordinateurs via l'institution ne permet pas d'utiliser des périphériques de stockage USB. Vous pouvez utiliser les ports USB pour charger le smartphone ou alimenter certains gadgets comme les petits haut-parleurs. De plus, comme certaines personnes l'ont mentionné, il existe des ordinateurs sur lesquels même Internet n'est pas autorisé.

Greg Burghardt · Accepted Answer

Vous pouvez reproduire librement le rôle que joue le contrôle de code source avec trois outils simples:

Logiciel de sauvegarde (Commits/Check-ins)
Dossiers (succursales)
Effectuer une fusion de répertoires entre deux répertoires à l'aide d'un outil comme KDiff3 (fusion de branches)

Fondamentalement, votre flux de travail devient:

Créer un nouveau dossier (nouvelle branche)
Copier des fichiers dans le nouveau dossier (nouvelle branche) à partir d'un dossier existant (branche existante)
Faire une copie de sauvegarde de ce dossier (terminer la création de la nouvelle branche)
Faites un peu de travail
Faire une sauvegarde du nouveau dossier (commit)
Faire une fusion de répertoire d'un dossier à un autre (fusion)
Faire une autre sauvegarde dans l'autre dossier (valider la fusion)

Les systèmes de contrôle de source plus monolithiques, comme SVN ou TFS, font essentiellement cela pour vous dans les coulisses.

Maintenant, la réalité est que c'est comme une compagnie de bus disant à ses chauffeurs qu'ils ne peuvent pas conduire des bus qui ont une batterie, forçant les conducteurs à pousser le bus en bas de la colline, puis à ouvrir l'embrayage pour démarrer le bus ... c'est terrible et indique que la direction actuelle ne sait rien de la gestion d'un garage à bus. Mes condoléances.

Mais au moins, vous pouvez démarrer le bus.

Erdrik Ironrose · Answer

Bien que le consensus serait certainement de ne pas travailler pour cette entreprise Je ne crois pas que cela réponde vraiment à votre question.

Vous ne pouvez pas vraiment remplacer SCM.

Vous pourriez ne pas avoir besoin des cloches et des sifflets habituels d'un système complet. Par exemple, l'entreprise peut refuser une demande de serveur, mais autoriser l'utilisation d'un SCM local. Ils peuvent détester git, mais autoriser Subversion (ou un autre système de version).

Il y a bien sûr une question: qu'utilisent vos collègues ou des employés précédents? Si vous êtes le premier développeur de logiciels dont ils disposent, alors il est temps de pousser très fort pour les ressources dont vous avez besoin.

En fin de compte, si votre entreprise ne respecte pas votre rôle et votre expérience et ne vous permet pas d'avoir les outils dont vous avez besoin, vous allez rencontrer des problèmes encore pires (et plus stressants) qu'un manque de contrôle des sources.

Basile Starynkevitch · Answer

Fondamentalement, il y a un problème de gestion (votre organisation ne comprend pas les bases de processus de développement logiciel , par exemple modèle V ) se condensant en une incapacité apparente à utiliser un minimum -un flux de travail, méthodologie et outils. Ceci est courant (en savoir plus sur principe de Peter ).

^{BTW, je suppose que les récents incident ferroviaire SNCF à Paris fin 2017 ont une cause similaire (absence totale de culture logicielle à haut niveau de gestion, donc blocage d'une grande gare parisienne pendant plus d'une journée ; il y a bien sûr des équipes informatiques très compétentes à la SNCF, mais elles ne sont pas consultées sur les décisions importantes). Je peux nommer plusieurs industries européennes avec un manque total de culture logicielle et je suis sûr de pouvoir trouver des choses similaires même aux États-Unis.}

Le problème principal est: travaillez-vous seul sur votre base de code, ou travaillez-vous avec des collègues?

Si vous travaillez seul, vous pouvez utiliser git localement sur votre ordinateur et sauvegarder votre code (et probablement même votre .git référentiel) périodiquement (vers cet espace de stockage externe). Assurez-vous de ne jamais perdre plus d'une demi-journée de travail (sauvegardez donc vos données régulièrement et de manière fiable).

^{(Je suppose que vous connaissez au moins git et svn et que vous connaissez la supériorité technique de git; si vous n'êtes même pas autorisé à installer un outil comme git sur votre ordinateur de travail, vous devez avoir une conversation sérieuse avec votre patron à ce sujet: vous avez besoin de la capacité et de l'autorisation d'installer des outils open source externes (et cela va de pair avec votre responsabilité les choisir, les configurer et les installer judicieusement & soigneusement et sans connu vulnérabilités )}

Si vous travaillez avec plusieurs collègues (je suppose que moins d'une douzaine d'entre eux), vous devez les convaincre tous pour utiliser un système de contrôle de version, et vous devrez probablement en parler à votre patron immédiat (et commun). Il pourrait (probablement) décider (ou simplement accepter implicitement) qu'une machine (peut-être même un ancien bureau, peut-être même votre propre bureau) est utilisée comme serveur git. Vous devez absolument configurer ce serveur afin que le référentiel git soit sauvegardé au moins toutes les heures; vous ne pouvez pas vous permettre (et vous devez en parler à votre patron) de perdre plus d'une heure de travail de votre équipe.

^{BTW, j'aime Linux, et je recommanderais d'installer Linux sur la machine agissant comme un serveur git; l'installation de git et la configuration de sauvegardes périodiques (avec un travail crontab) est très facile; notez qu'un serveur git peut exécuter Linux avec des clients Windows l'utilisant. Je vous suggère même de passer votre machine de développement à Linux si vous le pouvez. Il est "moins cher" et beaucoup plus convivial pour les développeurs}

Mais vous devez utiliser un SCM. Vous pourriez poser une question différente à votre patron: votre équipe devrait-elle utiliser un SCM existant ou devrait-elle réinventer la roue et créer votre propre SCM? Les patrons sont généralement contre l'idée de réinventer la roue. Si vous êtes autorisé à réinventer la roue, dites à votre patron que c'est un travail à temps plein pendant au moins un an (cela fera probablement pleurer votre patron, puis accepter la manière évidente) et amusez-vous à créer votre propre SCM. Dans ce cas peu probable, assurez-vous d'étudier les systèmes SCM existants, et demandez à faire de votre système SCM un outil logiciel gratuit (à utiliser et à améliorer par d'autres équipes).

Vous devrez peut-être préparer (pendant plusieurs jours) a précis et = spécifique argumentation pour le besoin d'un SCM : d'abord pour vos collègues, puis pour votre patron immédiat. Assurez-vous également de suggérer des solutions concrètes (comme exécuter un serveur git sur un ordinateur de bureau ou un "ancien" serveur, et le sauvegarder toutes les heures via un travail crontab)

N'installez aucun logiciel (de l'extérieur, même open-source) sur votre ordinateur de travail sans autorisation (dans la plupart des pays, en particulier pour les travaux informatiques sensibles pour l'État, l'installation d'un logiciel sans autorisation est légalement un crime, et vous pourriez perdre votre emploi ou aller en prison si vous le faites .... alors assurez-vous d'être autorisé à le faire; peut-être couvrir votre cul en demandant une autorisation par écrit, ou au moins par e-mail).

^{(soit vous devrez demander au cas par cas, soit vous aurez besoin de la confiance de votre organisation pour être autorisé à installer tout légal logiciel -presque open source ou logiciel gratuit- sur votre ordinateur de travail).}

PS. Comment construire, configurer, installer techniquement puis utiliser git (à partir de son code source de logiciel libre) -ou la plupart des autres logiciels libres VCS- sur une machine (même sans autorisation administrateur) est une très différente question (à demander ailleurs). Et il est possible d'installer puis d'utiliser git sans aucune autorisation administrateur, à condition d'avoir suffisamment de ressources (temps, espace disque, un compilateur C, etc ...) pour cela.

J'ai essayé d'installer le serveur Visual SVN, mais cela a échoué car je n'ai pas les privilèges d'administrateur à installer.

Ceci peut être résolu par une configuration et une compilation spécifiques de votre git ou svn à partir du logiciel libre code source de git ou Subversion -pas juste un paquet binaire et aussi --- (code source de dépendances ); comment le faire techniquement est une différente question (mais ces questions techniques devraient aller à quelque autre place). Bien sûr, vous devez demander la permission (à votre patron) de compiler le code source de git avant de le faire. Il vous dira, ou vous discuterez avec lui, des détails pratiques (s'il accepte une telle solution) concernant le transfert de ce code source de l'extérieur sur votre ordinateur de travail.

Berin Loritsch · Answer

La première chose que je ferais serait d'identifier spécifiquement ce à quoi l'agence gouvernementale (vraisemblablement le service informatique) s'oppose. S'ils ont de l'espace de stockage, mais aucun moyen d'héberger des machines virtuelles pour les serveurs, le problème peut être que le service informatique dit non au SVN ou au GIT serveur et c'est une grande distinction. Si le problème est le pays d'origine - c'est-à-dire. nous ne faisons pas confiance aux outils créés par des entités étrangères - c'est un problème différent.

Vous pouvez exécuter GIT complètement dans le système de fichiers, ce que j'ai fait sur des projets infantiles avant d'être prêt à faire quoi que ce soit avec eux. GIT ne nécessite pas non plus de privilèges administratifs pour l'installation.

Si vous ne pouvez absolument pas utiliser Git pour quelque raison que ce soit, vous disposez de quelques options:

Éduquer: En n'autorisant pas le contrôle de version, ils introduisent un risque important. Vous devez pouvoir vous retirer des changements qui s'avèrent plus problématiques. Vous devez pouvoir économiser du temps et de l'argent au gouvernement, et SCM le fait. Vous devez être en mesure d'expliquer clairement comment. Vous devez aussi probablement faire une analyse des alternatives pour vraiment ramener le clou.
- Une alternative serait hébergée Git
- Un autre système de fichiers Git
- Choisissez au moins un, mais pas plus de deux autres outils SCM alternatifs
- et enfin ce que c'est que de travailler sans contrôle de version
Développement de l'ère Go 70s: Il y a une raison pour laquelle patch et diff ont été créés il y a si longtemps (80s). Ce sont les technologies habilitantes qui ont rendu possible le contrôle des versions.

À quoi ressemble le développement de l'ère des années 70? Ce n'est pas joli, mais c'est comme ça que nous avons commencé. Les demandes étaient beaucoup plus petites. Essentiellement, ils avaient des choses communes:

Il y avait le concept de l'étalon-or . C'était le code source principal qui avait des fonctionnalités complètes.
Il y avait une équipe de gestion de la configuration (CM). Leur responsabilité était de faire passer correctement le développement du standard à l'étalon-or. C'est là que vous avez besoin de patch et diff pour remplacer l'équipe.
Vous avez travaillé à partir d'une copie locale du code source. Vous terminez une fonctionnalité dans son intégralité et la soumettez à l'équipe CM pour qu'ils l'intègrent. Habituellement, il y a un document d'accompagnement pour que les nouveaux fichiers soient créés et les fichiers obsolètes supprimés, etc.
Ensuite, vous corrigez les erreurs du processus d'intégration.
Avant de pouvoir profiter d'une autre fonctionnalité ou d'une correction de bogue, vous obtenez une nouvelle copie de l'étalon-or.

Essentiellement, c'est un processus sujet aux erreurs avec beaucoup de potentiel pour que les choses tournent mal. L'idée de "ramification" est facile à mettre en œuvre, mais un cauchemar à gérer. Le problème majeur est que lorsque vous avez trop de copies du code source, il est difficile de comprendre quelle est la ligne de base correcte pour la production. Pour des raisons pratiques, vous devez devenir un filetage unique.

C'est ce que vous devez inclure dans votre analyse des alternatives.

Ogre Psalm33 · Answer

Compte tenu des contraintes que vous mentionnez dans les commentaires (par exemple: impossible d'accéder à la page de téléchargement de Git, à la plate-forme Windows et à l'utilisation de Visual Studio 2005), je peux voir 2 options, que j'ai déjà utilisées dans une situation similaire:

Utilisez Visual SourceSafe comme Emerson le suggère dans un commentaire. J'ai travaillé avec une équipe utilisant VS 2005 il y a quelques années, alors que la plupart du reste de l'entreprise utilisait le contrôle de version standard sous Linux/Unix, et ils utilisaient avec plaisir Visual SourceSafe pour leur CM. C'est assez démodé à ce stade, mais mieux que rien.
En parlant de mieux que de rien, je suis moi-même dans une situation similaire. Si vous ne pouvez même pas utiliser VSS (peut-être que le plugin n'est pas installé?), Et comme vous dites qu'il y a beaucoup d'espace de stockage disponible, j'espère que vous êtes autorisé à en utiliser une partie. J'ai implémenté un protocole de contrôle de version manuel basé sur des fichiers. À la fin de chaque journée de travail, je copiais ma base de code dans un nouveau répertoire horodaté. Si je devais me référer à un travail précédent (ou revenir en arrière), je regarderais les répertoires datés précédents pour trouver la modification dont j'avais besoin. Étant donné que Visual Studio est disponible, en quelques heures, vous pourriez probablement utiliser VS 2005 pour écrire un outil simple pour vous aider à automatiser la création de répertoire et la copie de fichiers.

Timothy Truckle · Answer

Ils ont des tonnes d'espace de stockage

Êtes-vous autorisé à l'utiliser à votre décision?

Si c'est le cas, vous pouvez créer un système de fichiers référentiel distant qui vaut mieux que rien. L'inconvénient est que la poussée devient lente pendant que le projet se développe car git doit télécharger le référentiel entier pour rechercher les changements ...

jusqu'à présent, les ordinateurs se comportent comme des utilisateurs ordinaires, m'interdisant d'installer des logiciels tiers.

git se présente également sous la forme application portable afin que vous puissiez l'installer dans votre chemin $ HOME ou% USERPROFILE%.

En conclusion: je ne les laisserais pas m'interdire d'utiliser un SCM¹. Je l'utiliserais "en privé". Après tout, personne ne peut dire si votre code a été développé avec ou sans enregistrement quelque part ...

¹) lorsque j'ai commencé à utiliser git il y a quelques années, mon client a préféré un SCM différent qui était assez lent et peu fiable (qui est en quelque sorte un NOGO pour un SCM (o;). J'ai utilisé git "en privé" au-dessus de l'autre SCM avec une télécommande "basée sur des fichiers" sur un partage réseau et enregistré uniquement dans leur SCM après la sortie d'une nouvelle version du produit.

AnoE · Answer

Votre environnement

Tout d'abord, je ne serais pas aussi pessimiste comme le montrent de nombreux commentaires et réponses. Oui, c'est "l'âge de pierre", mais il y a beaucoup des circonstances pires. Si votre environnement de travail global (collègues, emplacement, salaire, travail de programmation intéressant, etc.) est bon et à votre goût, alors restez-y. Concernant l'informatique, c'est ce que c'est. Cela ne se produit pas seulement dans les agences gouvernementales, mais aussi dans les banques, les assurances ou partout où l'accent est mis sur la sécurité ou les structures très anciennes.

L'insertion d'une clé USB et l'exécution de certains fichiers .exe à partir de là seraient une cause immédiate de résiliation dans d'autres endroits, donc je ne vous suggérerais pas d'essayer de contourner quoi que ce soit.

Réessayez git

Maintenant sur votre choix. Je recommanderais fortement git au lieu de svn pour vous. Si vous faites des projets à une personne de toute façon, alors git est juste un répertoire local .git à l'intérieur de la racine de votre application, rien d'autre.

Ne demandez pas à votre patron/informatique un "SCM", mais demandez-lui spécifiquement d'installer git sur votre machine afin de pouvoir développer plus rapidement et avec une meilleure qualité. Expliquez-leur que vous voulez pas souhaiter pousser votre code ailleurs, que vous avez pas besoin d'un serveur fonctionnant quelque part, et qu'il pas utilise beaucoup d'espace ou de temps de maintenance.

Git augmentera la vitesse et la qualité pour vous simplement parce que vous pouvez travailler avec plus de confiance (car vous pouvez annuler les modifications que vous avez apportées) et vous permettre de travailler sur plusieurs branches en même temps. C'est-à-dire que si vous travaillez sur une tâche importante et que quelque chose arrive qui nécessite votre attention immédiate, vous pouvez simplement basculer vers une nouvelle branche, corriger rapidement cela, puis revenir à la tâche de longue durée.

Le faire manuellement

Si cela n'est tout simplement pas possible, vous pouvez bien sûr faire un contrôle manuel des sources. Créez des "balises" manuelles en copiant votre code vous-même (peut-être créez un nouveau répertoire avec la date/heure et une brève description de ce qui a changé). Gardez un journal des modifications avec des listes détaillées non seulement de vos modifications, mais aussi des fichiers que vous avez modifiés, et peut-être encore plus de détails.

Créez des "branches" en, encore une fois, en copiant votre travail, et quand il est temps de fusionner, faire preuve de créativité en utilisant des outils arbitraires "diff" ou "diff3" - je ne sais pas si vous en avez, vous devrez trouver.

Si tout cela vous coûte beaucoup de temps, regardez attentivement si cela vaut vraiment la peine d'émuler un SCM. Si vous trouvez que cela est en vaut la peine, alors parlez à nouveau avec votre patron. Montrez-lui les avantages de votre SCM manuel (pas seulement "J'ai une copie de tout mon ancien travail" mais "quand le bug XYZ s'est produit, j'ai pu immédiatement en trouver la raison, il y a 5 versions"). Dites-leur ensuite combien cela serait plus rapide avec git.

Évidemment, si cela vous rend fou, la recherche d'un emploi est toujours une option.

Matt Piechota · Answer

Je pense que beaucoup de gens ici n'ont pas "l'institution fédérale" de cette question. Certains réseaux gouvernementaux ont des réglementations très strictes sur les logiciels qui leur sont autorisés, et enfreindre ces règles est une infraction, voire même criminelle. Je pousserais à travers la gestion pour voir si vous pouvez obtenir un mouvement APPROUVÉ lors de l'installation du logiciel. Je n'irais pas cow-boy et installer des trucs moi-même. Si vous utilisez Linux/UNIX, vérifiez si RCS (commandes ci/co) ou SCCS (commande sccs) sont installés. Ce sont de vieux outils SCM qui étaient assez standard. Ce n'est pas joli mais meilleur que ce que je vais écrire ci-dessous. :)

Puisque vous avez "beaucoup" d'espace disque, créez une arborescence source. Quelles sont les bases du SCM à petite échelle? Pouvoir enregistrer les modifications, regarder ce qui a changé, étiqueter des éléments et revenir aux anciennes versions si nécessaire. Un niveau au-dessus de l'arborescence source, créez un Makefile ou des scripts, en fonction de ce que vous avez à disposition, qui fait ce qui suit (ce sont de type Linux/UNIX, les commandes Windows seraient différentes)

make checkin - cp -a source-tree source-tree-date (au moins à la minute, sinon la seconde, comme source-tree-20171205115433)

make status - diff -R source-tree source-tree-date | moins (il y aurait un peu de logique ici, par défaut la sauvegarde la plus récente ou donner un argument pour différencier une version

make tag - ln -s source-tree-date release1.0 (faire un lien vers une version particulière)

faire revenir - rm -r source-tree && cp -a source-tree-date source-tree

jpmc26 · Answer

Vendez-leur

Vous avez laissé ce commentaire :

Ils ont un lecteur réseau que je ne sais pas mais qui crée des sauvegardes par périodes. Oui. Je l'utilise et j'y stocke mes applications.

Allez voir votre supérieur et dites quelque chose dans ce sens:

Boss, j'ai remarqué que nous avons un système où nous mettons des applications sur le lecteur réseau et une sorte de service fait des sauvegardes et garde une trace de l'historique. Il me semble que nous mettons simplement en œuvre notre propre système de contrôle des sources en procédant ainsi. Nous pourrions probablement libérer beaucoup d'espace et simplifier l'ensemble du système en passant à un système de gestion de contrôle de source dédié, comme SVN ou git. Nous aurions de nombreux avantages: des sauvegardes plus simples des versions historiques, des outils pour comprendre quelles modifications ont été apportées aux fichiers au fil du temps (informations très utiles pour le débogage), des moyens plus faciles d'annuler les erreurs et des moyens plus simples de combiner les modifications de différentes personnes.

J'ai déjà utilisé ces types de systèmes, et ils sont très bons dans la tâche que notre configuration personnalisée effectue. Il est beaucoup plus difficile de se tromper avec eux que notre système actuel. Ce sont également des technologies très matures et largement utilisées; ces outils sont largement utilisés depuis plus de 20 ans. Et en plus de cela, nous pouvons utiliser les logiciels les plus populaires sans payer un centime de licence.

Je serais heureux de vous aider à choisir un client et un serveur et à les configurer. Je suppose que cela ne prendrait que [insert estimate here] heures pour l'installer si je peux obtenir une machine. N'importe quelle machine ferait l'affaire, même un ancien bureau sur le point d'être retiré, tant que nous pouvons y accéder via le réseau.

Le résumé de haut niveau ici est que vous devez le formuler en termes qu'ils peuvent comprendre et qui sont susceptibles de penser que cela en vaut la peine:

Libérer des ressources (matériel et personnel) à d'autres fins
Risque plus faible (erreur humaine, technologie stable)
Productivité accrue
Petit coût de mise en œuvre

Vos supérieurs ne sont pas des techniciens et ils ne se soucient pas des problèmes techniques. Mais si vous pouvez définir le problème en termes d'argent et de choses qui coûtent de l'argent, leurs oreilles pourraient se dresser un peu.

Joshua · Answer

Vous n'avez plus de solutions techniques. Seules des solutions politiques subsistent.

1) Syndiquer les développeurs. S'il y a déjà un syndicat, contester leur position comme ne représentant pas équitablement la catégorie d'employés qui est un développeur. Si la formation d'une union de développeurs ne parvient pas à obtenir le soutien de la moitié des développeurs, GO. Tu es une mauvaise personne.

2) Annonce dans les journaux. Si votre gouvernement ne garantit pas la liberté d'expression en tant que question de droit reconnue, cela vous fera virer.

Emerson Cardoso · Answer

Eh bien, après avoir lu votre question et beaucoup de commentaires, j'ai compris que vous avez les contraintes/scénario suivants:

1 personne par projet;
vous ne pouvez tout simplement pas utiliser des outils externes autres que Visual Studio 2005 pour votre projet; vous ne pouvez pas utiliser GIT ou tout autre SCM;
tout en travaillant localement, vous ne pouvez pas laisser le projet dans un état cassé, car vous avez des sauvegardes automatiques de temps en temps, et vous devez le faire fonctionner tout le temps;
vous avez besoin d'un historique pour suivre les changements;

Si vous ne pouvez pas utiliser Visual Source Safe (qui a un plugin pour fonctionner avec VS 2005), vous pouvez utiliser une autre approche.

Sur la base des éléments ci-dessus, je vous suggère d'organiser vos dossiers de projet comme ci-dessous:

trunk //last functional version of the app. IMPORTANT: YOU DON'T WORK WITH THIS FOLDER UnitTests //important: create unitary tests in order to guarantee stuff is working after changes MyClassLibrary1 MyClassLibrary2 MyApplication Docs readme.md YouProject.sln temp //your working folder; has structure similar to trunk; changes will be commited to trunk; UnitTests //important: create unitary tests in order to guarantee stuff is working after changes MyClassLibrary1 MyClassLibrary2 MyApplication Docs readme.md YouProject.sln build .history //folder to contain changes in files and your comment (like commits in git) build.bat //calls MSBuild to build temp\YourProject.sln, and run all unit tests save_on_trunk.bat //if build is working, saves info from "diff.bat" in folder within ".history" with timestamp, and also overrides "trunk" with content from "temp" diff.bat //compares files from "temp" and "trunk", using "dir" and "fc" commands history.bat //outputs content from .history folder (contains file changes and comments)

Règles de base à suivre ici:

votre contrôle de code sera effectué dans le dossier du projet;
vous ne travaillez jamais en "tronc";
vous travaillez dans "temp", implémentez tests unitaires, appelez build.bat, puis save_on_trunk.bat;
IMPORTANT: implémentez des tests unitaires qui s'exécutent dans une isolation totale; vous en avez besoin pour garantir que le nouveau code ne cassera pas le tronc;
puisque vous avez des sauvegardes automatiques, les chances de perdre du code seront moindres; par conséquent, il vous suffit de faire en sorte que le code "trunk" soit en état de fonctionnement tout le temps.

Rob · Answer

Exécutez simplement git sur un répertoire nu, sans aucun serveur impliqué. Peu importe que personne d'autre n'utilise le contrôle de version, car vous pouvez contrôler la version de votre répertoire. Git a été conçu exactement pour ce scénario d'introduction SCM voyous, et cela fonctionne bien.

Vous deviendrez un héros lorsque la deuxième personne commencera à l'utiliser, même si vous devez attendre qu'un dinosaure frappe le seau pour qu'il se propage. Il est incompétent de gérer de grandes bases de code sans SCM maintenant. C'est comme gérer une entreprise sans rien auditer, en fait.

Graham · Answer

Git pour Windows a une version "portable" . Vous pouvez le copier sur votre PC ou le conserver sur une clé USB sans avoir à installer quoi que ce soit. Si le problème est simplement l'installation, ce serait une solution de contournement.

Notez que s'ils sont catégoriquement opposés au SCM, vous voudrez peut-être poser des questions précises sur ISO-9001, DO-178B ou d'autres normes de développement logiciel pertinentes.