Verrouillage des fichiers binaires à l'aide de système de contrôle de version git

Question

Pour un ans et demi, j'ai réussi à garder mes yeux sur le git de la communauté dans l'espoir de faire de l'interrupteur à l'écart à partir de SVN. Une question me retient est l'impossibilité de verrouiller des fichiers binaires. Tout au long de la dernière année, j'ai encore à voir les développements sur cette question. Je comprends que le verrouillage des fichiers va à l'encontre des principes fondamentaux de la source distribué de contrôle, mais je ne vois pas comment une société de développement web peut prendre avantage de git pour suivre le code source et le fichier image change quand il est possible qu'un fichier binaire conflits.

Pour atteindre les effets de verrouillage, une "centrale" référentiel doit être identifié. Quelle que soit la nature distribuée de git, la plupart des entreprises ont une "centrale" référentiel pour un projet de logiciel. Nous devrions être en mesure de marquer un fichier à l'aide d'un verrou de l'régissant le dépôt git à une adresse spécifiée. C'est peut-être rendu difficile en raison git pistes le contenu du fichier pas fichiers?

Ne l'un de vous avez de l'expérience dans les relations avec git et les fichiers binaires qui doivent être verrouillées avant de modification?

NOTE: Il semble que la Source du matériel open source de contrôle de version distribué projet, de la Véracité, de a de verrouillage comme l'un de ses objectifs.

Answer 1

Subversion a des serrures, et ils ne sont pas seulement consultatif. Ils peuvent être appliqués à l'aide de l' svn:needs-lock d'attribut (mais peut aussi être délibérément rompu si nécessaire). C'est la bonne solution pour la gestion des non fusionnables fichiers. La société où je travaille pour les magasins juste au sujet de tout dans la Subversion, et utilise svn:needs-lock pour tous les non fusionnables fichiers.

Je suis en désaccord avec "les verrous sont juste un moyen de communication". Ils sont beaucoup plus efficaces que des notifications push-tels que le téléphone ou e-mail. Subversion serrures sont auto-documentation (qui a la serrure). D'autre part, si vous avez à communiquer par d'autres traditionnel push-notification de canaux, tels que l'e-mail, qui vous le faire envoyer la notification? Vous ne savez pas à l'avance qui pourrait vouloir modifier le fichier, en particulier sur les projets open-source, sauf si vous avez une liste complète de l'ensemble de votre équipe de développement. Si ces modes de communication ne sont pas presque aussi efficace.

Un verrou central serveur, alors qu'à l'encontre des principes de DVCS, est la seule méthode viable pour les non fusionnables fichiers. Tant que les DVCS n'ont pas un centrale de la fonction de verrouillage, je pense qu'il va garder l'entreprise pour laquelle je travaille à l'aide de la Subversion.

La meilleure solution serait d'en faire un outil de fusion pour tous vos formats de fichier binaires, mais c'est un plus long terme et en cours objectif qui ne sera jamais "fini".

Voici une lecture intéressante sur le sujet.

Answer 2

En réponse à Mario de préoccupation supplémentaire, avec les changements qui s'opèrent dans plusieurs endroits sur les fichiers binaires. Si le scénario est Alice et Bob sont à la fois apporter des modifications à la même ressource binaire en même temps. Ils ont chacun leur propre repo, cloné à partir d'un emplacement central à distance.

C'est en effet un problème potentiel. Donc, Alice termine premier et pousse à la centrale d' alice/update de la branche. Normalement, lorsque cela se produit, Alice allait faire une annonce qui devrait être revu. Bob voit et revoit. Il peut soit (1) d'intégrer ces modifications lui-même dans sa version (branchement alice/update et de faire ses changements) ou (2), de publier ses propres changements d' bob/update. Encore une fois, il fait une annonce.

Maintenant, si Alice pousse à l' master au lieu de cela, Bob a un dilemme lorsqu'il retire master et tente de fusionner dans sa branche locale. Ses conflits avec Alice. Mais encore une fois, la même procédure peut s'appliquer, juste sur des branches différentes. Et même si Bob ignore toutes les mises en garde et s'engage sur Alice, il est toujours possible de sortir Alice s'engager à réparer les choses. Cela devient tout simplement un problème de communication.

Depuis (autant que je sache) de la Subversion serrures sont simplement consultatif, un e-mail ou un message instantané peut servir le même but. Mais même si vous ne le faites pas, Git vous permet de le fixer.

Non, il n'y a pas de mécanisme de verrouillage en soi. Mais un mécanisme de verrouillage a tendance à être juste un substitut à une bonne communication. Je crois que c'est pourquoi le Git les développeurs n'ont pas ajouté un mécanisme de verrouillage.

Answer 3

Je suis d'accord que le verrouillage des fichiers binaires est un élément nécessaire pour certains environnements. J'ai juste eu une pensée sur la façon de le mettre en œuvre, si:

• Avoir un moyen de marquage d'un fichier en tant que "needs-lock" (comme le "svn:needs-lock" de la propriété).
• À la caisse, git marque d'un tel fichier en lecture seule.
• Une nouvelle commande git-lock contact d'un verrou central serveur exécutant quelque part pour lui demander la permission de verrouillage.
• Si le verrouillage de serveur autorise, marque le fichier en lecture-écriture.
• git-add d'éclairer le verrouillage du serveur du contenu de hachage du fichier verrouillé.
• La serrure serveur regarder pour que le contenu de hachage pour apparaître dans un commit sur le référentiel maître.
• Lorsque la valeur de hachage apparaît, relâchez le verrou.

C'est très bien d'un demi-cuite idée et il y a du potentiel des trous partout. Il va également à l'encontre de l'esprit de git, mais il peut certainement être utile dans certains contextes.

Au sein d'une organisation donnée, ce genre de chose pourrait peut-être être construit en utilisant une combinaison appropriée de script wrappers et de commettre des crochets.

Answer 4

Nous avons récemment commencé à utiliser Git (à utiliser Subversion auparavant) et j'ai trouvé un changement de flux de travail qui peut vous aider avec votre problème, sans la nécessité pour les serrures. Il faut profiter de la façon dont git est conçu et comment il est facile branches.

En gros, ça se résume à pousser à un non-branche master, faisant un examen de cette branche, puis en les fusionnant dans la branche master (ou quelle que soit la cible de la branche est).

La manière dont git est "destiné" à être utilisé, chaque développeur publie leur propre dépôt public, laquelle ils demandent à d'autres de tirer de. J'ai trouvé que la Subversion des utilisateurs ont de la difficulté avec ça. Donc, au lieu de cela, nous pousser à la branche des arbres dans le référentiel central, avec à chaque utilisateur d'avoir leur propre branche de l'arbre. Par exemple, une hiérarchie, comme cela peut fonctionner:

users/a/feature1
users/a/feature2
users/b/feature3
teams/d/featurey

N'hésitez pas à utiliser votre propre structure. Remarque, je suis également en montrant sujet branches, une autre commune git idiome.

Puis, dans un local repo pour un utilisateur:

feature1
feature2

Et pour l'obtenir à un serveur central (origine):

git push origin feature1:users/a/feature1

(ce qui peut probablement être simplifié, avec les modifications de la configuration)

De toute façon, une fois feature1 est passé en revue, qui est responsable (dans notre cas, c'est le développeur de la fonctionnalité, vous pourriez avoir un seul utilisateur responsable de l'fusionne à maîtriser), effectue les opérations suivantes:

git checkout master
git pull
git merge users/name/feature1
git push

Le pull fait un fetch (en tirant sur tout nouveau maître des modifications et de la branche) et les mises à jour du maître de ce que le référentiel central. Si l'utilisateur a bien fait leur travail et de suivi master correctement, il ne devrait y avoir aucun problème avec la fusion.

Tout cela signifie que, même si un utilisateur ou à distance de l'équipe apporte une modification à une ressource binaire, il est examiné avant il est incorporé dans la branche master. Et il y a une délimitation claire (basé sur les processus) quand quelque chose se passe dans la branche master.

Vous pouvez de la même manière, de faire respecter les aspects de ce à l'aide de git crochets, mais encore une fois, je n'ai pas travaillé avec eux encore, ne peut donc pas parler d'eux.

Answer 5

Quand j'ai été en utilisant Subversion, je religieusement définir l' svn:needs-lock de propriété sur tous les binaires et même le dur-à-éditer des fichiers texte. J'ai jamais réellement été victimes de tous les conflits.

Maintenant, dans Git, je ne vous inquiétez pas au sujet de telles choses. Rappelez-vous: les verrous dans la Subversion ne sont pas réellement obligatoire verrous, ils ne sont que des outils de communication. Et devinez quoi: je n'ai pas besoin de Subversion pour communiquer, je peux gérer très bien avec E-Mail, numéro de Téléphone et la messagerie instantanée.

Une autre chose que j'ai fait, c'est de remplacer de nombreux formats binaires avec les formats texte brut. J'utilise reStructuredText ou LaT_ΕΧ au lieu de Word, CSV au lieu d'Excel, ASCII-Art à la place de Visio, YAML à la place de bases de données, SVG au lieu de OO Tirage, abc au lieu de MIDI, et ainsi de suite.