git pre commit, um sicherzustellen, HEAD vom Master-Repo auf dem neuesten Stand ist

Question

Ich ziehe mein Team über von einem alten CVS-Repository git zu verwenden. Ich habe gehofft, in einem precommit Haken hinzufügen, um sicherzustellen, bevor ein Commit lokal erfolgt (und gedrückt) jede Person, die einen auf den neuesten Stand Repo hat.

Zum Beispiel in CVS jeder tun würde, einen ‚cvs up‘ bevor Sie Änderungen vornehmen, und begehen dann. Ich will es zwingen, damit die Menschen können keine Änderungen begehen, wenn sie ein git pull origin master ersten getan haben (wir werden nicht mit zusätzlichen Zweige werden)

Gibt es eine einfache Möglichkeit, dies zu tun? für jede Hilfe cheers:)

Answer 1

Überprüfen, ob die Schas aus git ls-remote origin HEAD (remote Spitze) und git rev-parse HEAD (lokale Spitze) gleich sind?

Beachten Sie, dass dies dabei, Sie werfen einen LOT weg von Git Flexibilität - denken Sie an, ob das wirklich , was Sie tun wollen. Ein Teil der Stärke von git pull ist, dass selbst wenn Sie noch Dinge begehen, die von der Master-Kopie abwich, wenn Sie aus dem Master ziehen kopieren können Sie die Änderungen in zusammengefügt werden (und in den meisten Fällen der Prozess vollständig automatisiert ist).

Wenn Ihr Ziel ist eine lineare zu haben ist begehen Geschichte (die ihre eigene Abwägungen hat), würde ich vorschlagen, einen Blick auf die rebase Befehl nehmen, anstatt zwingen Sie Ihren Entwickler nie hinter Herkunft / Master zu begehen.

Bearbeiten

Eigentlich, wenn Sie nur git pull tun (statt Umbasierung), werden Sie nicht in der Lage sein, die Köpfe zu vergleichen, da ziehen würde Merge Commits tun. Stattdessen müssen Sie git ls-remote origin HEAD zu git merge-base origin/HEAD HEAD vergleichen.

Einige andere Kommentare

• Warum Sie verwenden Git, aber dann nicht mit zusätzlichen Niederlassungen überhaupt? Das ist ein bisschen wie ein Auto zu kaufen, aber nie den Motor mit (und stattdessen nur überall schieben). Die Zweige sind billig in Git, schnell einzurichten und fast mühelos zu verschmelzen. Sie tun sich selbst einen schlechten Dienst, wenn Sie nicht von ihnen Gebrauch machen.

• Warum interessieren Sie alle sind up-to-date bevor Sie Änderungen vornehmen? Dies ist nicht CVS, Konfliktlösung ist nicht schrecklich - Git wird automatisch lösen 95% der Konflikte für Sie, ohne dass Sie etwas zu tun haben, also, ob Sie git pull vor oder nach dem Sie Ihre Änderungen vornehmen nicht wirklich wichtig - Sie müssen nur ziehen, bevor Sie drücken und Sie werden in Ordnung sein.

• zum vorherigen Punkt Verwandte: da nicht vorspulen Schübe standardmäßig abgelehnt, brauchen Sie nicht wirklich einen Haken. Sagen Sie Ihre Entwickler „wenn Ihre Push als nicht vorspulen abgelehnt wird, kann ein git pull, dann versuchen Sie es erneut drücken“ und alles funktioniert.

Answer 2

Dies zerstört die ‚verteilt‘ Natur von git. Es macht jeden etwas global begehen. Die cvs „commit“ ist analog zu dem git „Push“ das ist, was mit dem entfernten Ende in Verbindung steht.

Wenn Sie wirklich Vorteil des verteilten Modells nehmen mögen, sollten Sie ermutigen und machen Sie Ihr Team den Punkt des lokalen Commits verstehen, anstatt macht das System die zentralen Repo traf auf jedem Commit (die aus zentralisierte gesägt).

Answer 3

Wenn Sie den Remote-Zweig verfolgen:

git fetch
git log HEAD..origin
# or:
git diff ...origin

Wie andere Antworten angedeutet, zwingt diese Art der Prüfung ist nicht immer eine gute Lösung für jeder Remote-Repo, kann aber als Warnung interessant sein.

nicht vergessen, dass ein git push standardmäßig wird abgelehnt wenn es nicht eine fastforward Änderung .
So ist die git pull wird den Weg sowieso diese Nachricht zu vermeiden.