indiquer à git pour utiliser le nôtre, de fusion, d'une stratégie sur les fichiers spécifiques

J'ai la structure de répertoire suivante:

/.git
/.git/info/attributes
/MyProject
/MyProject/pom.xml
/MyProject/MyCode.java

J'ai de la branche master et de correction. Sur les deux branches pom.xml et MyCode.java ont été modifiés.
je voudrais fusionner les changements de correction pour le maître que pour MyCode.java et garder la version de base de pom.xml fichier.

J'ai donc ajouté "/.git/info/attributs" parce que je ne veux pas commettre .gitattributes avec le projet

$cat .git/info/attributes
pom.xml merge=ours
$git status
# On branch master
nothing to commit (working directory clean)
$git check-attr -a pom.xml
pom.xml: merge: ours

Enfin le problème:

Quand je fais:

$git merge bugfix
Auto-merging MyProject/pom.xml
CONFLICT (content): Merge conflict in MyProject/pom.xml
Automatic merge failed; fix conflicts and then commit the result.

Git, c'est ignorer les attributs de réglage. Ce qui me manque ici?

Je préfère ne pas définir "keepMine.sh" par cette post

ce post est ce dont j'ai besoin, mais je préfère ne pas aller de fichier par fichier si j'ai un modèle simple

merci!

  • double possible de .gitattributes & les de fusion de la stratégie pour un fichier
  • bien que vous avez raison et je n'ai pas trouvé l'autre question, lors de l'ouverture de cette une, réponse ici est beaucoup mieux, c'est court, clair et travaille, en faisant un meilleur service pour le lecteur..
  • Je suis d'accord. Mais c'est mieux si nous nous concentrons toutes les bonnes réponses dans un seul endroit. Si vous vous sentez l'autre question pourrait avoir une meilleure réponse, une option est de donner une prime. Et même si c'est marqué comme un doublon, il peut encore aider les gens. Étant marqués comme une dup ne signifie pas qu'une question n'est pas utile, j'ai même upvoted vous =)
InformationsquelleAutor Barak1731475 | 2012-12-30
  1. 28
    $ git config merge.ours.driver true

    ou même 

    $ git config --global merge.ours.driver true

    'nôtre' n'est pas l'un de l'intégré dans la fusion des pilotes, même si c'est parfaitement clair pour vous et moi ce qu'il doit faire, et il semble que git n'a pas d'erreur quand une coutume de fusion pilote n'est pas défini.

    (true ci-dessus est juste unix true de commande, ses succès, dit-il pris la version locale de regarder à droite, dans ce cas, en ne faisant rien pour elle.)

    • donc, fondamentalement, git livre attributs exemple pour fusionner les stratégies [git-scm.com/book/ch7-2.html] est uniquement les attributs de l'exemple et de ne pas travailler sans explicitement tournant sur le même préemballés, mais pas de fusion par défaut des pilotes.. il a obtenu, merci!
    InformationsquelleAutor jthill
  2. 15

    De mes tests avec git version 1.7.1 je trouve que si il y a une exigence de fusion, pas de fusion pilote execute (indépendamment de ce que vous avez mis dans la config, et indépendamment de toute git attributs).

    Si vous branche de le "maître" de votre propre branche locale "correction", puis modifier un tas de trucs dans votre propre branche, s'engager à ce que. Par la suite vous la caisse le "maître" de la branche de nouveau, puis faire quelque chose comme:

    git merge bugfix

    Vous pourriez vous attendre de la "fusion=nôtre" attribut pour vous protéger dans cette situation. Il ne le fera pas! Direction de la "correction" va piétiner sur la branche "master" s'il n'y a pas eu de modifications sur ce fichier en particulier au sein de la branche principale, depuis l'époque de "correction" ramifiés loin de maître. Aucune modification n'implique pas besoin de fusionner ce qui implique de ne pas exécuter une fusion pilote. Ce est un problème commun qui git doit avoir un attribut particulier de la pré-définis de manière à donner un fichier local absolu de la protection de l'étranger se confond, dans TOUTES les situations.

    FWIW, j'ai lu les opinions des autres que des fichiers de configuration doit être locale et privée et n'est pas vérifié dans le dépôt git à tous. Je pense que c'est le genre de bollox: bien sûr, je ne veux suivre les changements dans mon fichier de config. Bien sûr, l'idée d'un outil collaboratif, c'est que je veux être en mesure de comparer ma config à l'encontre de ce que d'autres personnes dans mon équipe sont en cours d'exécution, ou de comparer le développement de config à la production de config. L'idée d'un outil est qu'il vous aide à faire votre travail.

    Comme encombrants solution, la meilleure que j'ai est un répertoire config avec chaque fichier de configuration ayant un nom différent (c'est à dire de config/production config de test/config/devel_joe config/devel_bill et ainsi de suite), et tous ces éléments vont dans le dépôt git. Puis au déploiement de l'environnement de travail config fichier est copié de cette config. Je pense que c'est une approche laide parce que c'est un pas en arrière loin de l'idée que les branches nommées, mais au moins c'est sûr.

    InformationsquelleAutor Tel