Comment faire pour passer de git à ClearCase?

Voici une méthode qui évite les détournements, que notre équipe a utilisée avec beaucoup de succès pendant plus d'un an, jusqu'à ce que nous retirions ClearCase pour Subversion (Politique de L'entreprise, bien que ce soit un pas en arrière pour notre équipe - nous utilisions simplement ClearCase comme un système de fichiers muet, et fonctionnions virtuellement nativement en git, mais maintenant nous utilisons le pont git-svn qui n'est pas aussi agréable que natif git.)

nous avons utilisé deux répertoires, un pour le snapshot ClearCase et le master git repo, que nous avons partagé avec toute l'équipe et dans lequel nous n'avons jamais édité de fichiers, et un pour notre répertoire "working".

la préparation dans la vue snapshot ClearCase est:

% git init
% git add **/*.cxx **/*.h **/Makefile (and so on)
% git commit -m "initial"

puis clonez dans votre répertoire de travail:

% mkdir ~/work
% git clone /path/to/repo

travail dans l'Annuaire de travail, sur une branche:

% git checkout -b feature
% ...edit/compile...
% git add -u
% git commit

assurez-vous que le snapshot ClearCase est à jour avec vierge (qu'il a toujours été pour nous, parce que nous l'avons partagée au sein de l'équipe, et nous avons tous utilisé git).

puis fusionner la branche sur le master en la rebasant, pour éviter une commit de fusion automatique:

% git checkout master
% git pull
% git checkout feature
% git rebase master
% git checkout master
% git merge feature
% git branch -d feature

% git diff --name-status origin/master

préparer la vue ClearCase en vérifiant/mkelem/rmname tout fichier modifié / nouveau / supprimé, après la sortie de git diff --name-status . Nous avons utilisé un script roulé à la main pour le faire. N'oubliez pas de vérifier tous les répertoires qui ont ajouté ou supprimé des fichiers:

puis repousse les trucs git, et vérifie avec ClearCase:

% git push
% cd /path/to/repo
% git reset --hard
% cleartool ci `cleartool lsco -r -short -me`

il semble que beaucoup de commandes, mais cela inclut la configuration, et votre flux de travail quotidien n'utilise pas beaucoup de commandes. Vous pouvez trivialement construire un script autour de l'étape push-back-to-ClearCase, et découvrir/montrer à votre équipe tous les trucs cool supplémentaires git peu à peu que tout le monde s'habitue au flux de travail de base.

la vraie beauté de ce système est, après un certain temps quand tout le monde est compétent avec git, vous pouvez trivialement jeter ClearCase et tous les travaux de singe individuels et les frais associés. Peut-être donner au gars de ClearCase de la compagnie des vacances bien méritées et un peu de recyclage avec les économies. (Malheureusement, dans mon entreprise, les trucs de git étaient tous des skunkworks, et nous sommes passés à Subversion-forwards à partir de ClearCase mais en arrière à partir de git!)

I fortement je vous recommande d'utiliser le script pristine de ClearCase Globally, Git Locally , qui s'exécute dans la vue snapshot ClearCase et assure sa synchronisation avec git. Nous avons mis cela en place comme un travail de cron qui a fonctionné deux fois par jour, et a également exécuté manuellement chaque fois que nous étions sur le point de pousser de nouveau à git. Malheureusement, le lien vers le blog n'est plus valide. Cependant le script est toujours disponible sur GitHub .