Comment séparer automatiquement les commit git pour séparer les changements dans un seul fichier

Question

Je suis très à l'aise avec Git, je l'utilise depuis plus d'un an maintenant. Mieux encore, j'ai finalement convaincu un client d'y passer! Cependant, je suis simplement coincé quant à la façon d'accomplir ce que je vais décrire, ou si c'est même possible. Même si cela peut être fait, je me demande si cela pourrait nous mettre en place pour un dépôt gâché, ingérable.

J'ai mis en place deux branches de la base de code. L'un est "maître" et l'autre est "prod". Le HEAD de prod est toujours le dernier code à déployer en production, et master est la principale branche de développement.

Voici le problème: Le client convertit à partir de CVS et la plupart des développeurs s'habituent encore à git. Leur flux de travail CVS impliquait le marquage des versions de fichiers individuels pour la production, puis la mise à jour des serveurs à l'aide de la balise. Malheureusement, cela a conduit à des pratiques bâclées comme commettre ensemble des changements sans rapport, puis marquer les fichiers après le fait, et garder beaucoup de fichiers inutiles dans leur arbre de travail principal, etc ... et les développeurs veulent savoir comment ils peuvent faire les suivants:

Dans leurs repos locaux, ils piratent et s'engagent pour le plaisir de leurs coeurs, puis à la fin de la journée, être en mesure d'exécuter une commande qui prend une liste de fichiers dont les commits au cours de la journée se fusionnent leur prod locale - et seulement ces fichiers - même si ces commits combinent des changements à d'autres fichiers.

Je sais comment scinder les commits avec git rebase --interactive, mais je n'ai aucune idée de la façon dont j'automatiserais les commits de scission du tout, peu importe comment je le veux.

Je réalise que la chose la plus simple serait simplement de leur dire de changer les branches de leur prod, de récupérer les fichiers de leurs branches principales dans l'arbre de travail puis de les commettre. Mon problème avec cela est de perdre l'histoire de leurs commits au cours de la journée. Est-ce que quelqu'un d'autre là-bas a abordé cela avec un script ou quelque chose, ou dois-je juste aiguillonner les développeurs dans un meilleur comportement - et risquer de rejeter complètement Git?

---

Voici la solution que j'ai finalement préparée. C'est un simple script shell qui semble faire exactement ce que je veux, même si ce n'est pas la solution la plus élégante. J'ai seulement testé quelques scénarios, mais l'historique des changements du fichier est préservé et si les commits de la branche dev sont fusionnés plus tard en entier, git semble le faire proprement!

#!/bin/sh 
set -e 
dest_branch=$1 
file=$2 
current_branch=$(git branch | sed 's/^\* //;/^\s/d') 
( 
    set -e 
    git format-patch --stdout --full-index -M -C -B --ignore-if-in-upstream $dest_branch -- $file 
    git checkout $dest_branch 
) | git am 
git checkout $current_branch 

Answer 1

Les développeurs ont encore une approche très « file centré sur la » vision au lieu d'un « référentiel centré sur » (basée sur la révision de SVN ou Git opte pour)!
Ils doivent lire « What are the basic VCS concepts every developer should know? »;)
(il est à l'origine au sujet ClearCase, mais toujours pertinent pour les utilisateurs CVS confrontés à un DVCS)

Cela dit, une façon de combler l'écart dans le scénario particulier serait :

• à la fin de la journée de piratage informatique, créer une branche spéciale de la tête en cours
• faire une modification finale uniquement pour les bons fichiers (celui pour la prod)
  la modification pourrait être pour par exemple quelques kind of special keyword extension, juste pour les marquer comme «à fusionner pour prod».
• fusionner cette branche spéciale à leur prod locale: dans un commit, seuls les bons fichiers sont fusionnés.

Ainsi, l'historique de ces fichiers est préservé.