Tri d'un désordre Git

Question

Je viens d'hériter d'un projet maintenu à l'aide de Git. À un moment donné, le code a été déployé sur 3 systèmes distincts et chaque système conservait son propre référentiel Git décentralisé.

Chacun des 3 systèmes a étendu le système de base d’origine dans 3 directions différentes. Aucun des 3 systèmes n'a été synchronisé l'un avec l'autre. Certains changements concernent la branche principale, d’autres sur de nouvelles branches.

Comment puis-je réunir les 3 sources différentes pour pouvoir:

1. trouver une base commune avec laquelle travailler;
2. Découvrez quelles modifications sont des corrections de bugs qui devraient être appliquées sur les 3 systèmes; et
3. maintenir les 3 systèmes de manière saine, de sorte qu’il n’y ait qu’une seule branche commune et séparer les personnalisations requises pour les 3 systèmes différents?

Answer 1

Je commencerais probablement par pousser tous les référentiels vers des branches distinctes dans un référentiel central, à partir duquel je peux facilement me baser, fusionner, etc. entre les branches.

Un bon outil de visualisation tel que git-age , gitnub , gitx , glousser peut faire des merveilles, mais votre tâche sera probablement fastidieuse à moins que vous ne le puissiez trouvez les points de branchement. Si des correctifs similaires sont appliqués à toutes les branches, vous pouvez utiliser (interactif) rebase pour réorganiser vos commits tels qu'ils sont dans le même ordre. Ensuite, vous pouvez commencer à «zipper» vos branches, en déplaçant le point de branche vers le haut en plaçant les commits dans master. Vous trouverez une description intéressante sur la façon de réorganiser les commits à l'aide de rebase ici .

Les actions à entreprendre sont décrites dans les liens fournis par Index Git Howto . Un bon aide-mémoire est toujours agréable à portée de main. De plus, je soupçonne le suivi de l'article d'Eric Sinks & DVCS et DAG, première partie " contiendra quelque chose d’utile (ce n’était pas le cas, mais c’était une lecture intéressante, néanmoins).

D'autres liens utiles sont: Git Magic , Git Ready et Guide Git SourceMage

J'espère que tous les dépôts comportaient de bons messages de commit qui vous expliquent le but de chaque patch, c'est ce que dit le code:)

En ce qui concerne la gestion des personnalisations, nous avons eu de la chance avec les éléments suivants:

Nous avons commencé par séparer (ou en séparant) le code personnalisé du code générique. Ensuite, nous avons essayé deux approches. les deux qui ont bien fonctionné:

1. Tous les déploiements ont leur propre référentiel dans lequel la personnalisation a été conservée.
2. Tous les déploiements ont leur propre branche dans un référentiel de "personnalisation".

Après le premier déploiement et le fait que le second était un fait, nous avons passé un certain temps à essayer de prévoir les points de personnalisation / découpe futurs afin de réduire les duplications entre les pensions personnalisées (alt. 1, qui est l'approche que nous utilisons actuellement) et dans les repo base / core.

Et oui, nous essayons de refactoriser impitoyablement chaque fois que nous remarquons le glissement du noyau / personnalisation:)

Answer 2

OK Après un gros effort, j'ai réussi à le faire. Pour quiconque entreprendra une tâche similaire, cela impliquera beaucoup de:

git rebase

commandes et quand les choses se gâtent:

git reflog

suivi de

git reset --hard HEAD@{ref}