Ich weiß, dass kommen up vorher, aber es gab wenig persönliche Erfahrungen in den Posts, die ich gesehen habe. Nur ein paar Antworten.
Ich würde gerne von Leuten hören, die git-p4 verwenden, oder habe Git "unter Deckeln" in einem Perforce Repo verwendet, oder vorzugsweise beides.
Und für jene Leute, die Git nur unter einer anderen Versionskontrolle verwenden, würde ich gerne hören, wie Sie mit der Benachrichtigung der Hauptversionskontrolle über Änderungen umgehen. Wenn Sie mit git / forcere fertig sind und bereit sind, die Änderungen auf dem Server zu übernehmen, wie gehen Sie dann vor, wenn Sie unbedingt sagen müssen, welche Änderungen vorgenommen wurden?
Ich habe Post-Commit Hooks mit Git untersucht, aber ich würde gerne andere Ideen hören.
Ich habe git-p4 bei der Arbeit benutzt. Es ist eine bidirektionale Brücke. Wenn Sie also git verwenden und dann Ihre lokalen Commits in p4 festschreiben möchten, ist das ein guter Weg. Allerdings hatte unsere Büropolitik eine Kultur mit einer kleinen Anzahl von massiven Commits statt vielen kleinen, so dass ich alle Änderungen in einen einzigen Patch umbuchen musste, bevor ich zurück in p4 ging. Ich hätte gerne die feinkörnige lokale Geschichte beibehalten, aber in einer einzigen Einstellung zurückgeholt, aber nie geschafft.
Apropos Änderung Benachrichtigung. git-p4 erstellt Patches für jeden Check-in seit dem letzten und übergibt sie als separate Changesets. Diese Art spiegelt die Geschichte des Hauptzweiges wider, an dem Sie in Ihrem git-Repository arbeiten.
Ich benutze git mit TFS und habe gewählt, mit Option 2 zu gehen: schiebe das .git-Verzeichnis und lasse es von TFS ignorieren. Ich mache das aus dem gleichen Grund wie @Noufal, wir haben hier eine Kultur von "einem großen Commit" im Vergleich zu den vielen kleinen Commits, die ich in Git mache. Da ich nur ein- oder zweimal am Tag zu TFS verpflichte, lohnt es sich für mich nicht, Post-Commit Hooks oder Rebasts oder irgendetwas anderes zu tun.
Ich schätze, es kommt wirklich auf das Layout Ihres perforce-Repositorys an - wenn Sie an einem relativ kleinen Teil davon arbeiten, würde ich wahrscheinlich einfach das .git-Verzeichnis direkt hineinlassen. Es ist der kleinste Pfad von Widerstand bei weitem und ich habe es erfolgreich bei kleineren Projekten eingesetzt.
Das heißt, ich habe mit diesem Ansatz in größeren Repositories gekämpft, wahrscheinlich genauso viel mit dem Workflow zu tun, wo ich als Verwaltungsaufwand für alles arbeite. Ich habe noch einen Blick auf git-p4 geworfen, aber es ist etwas, an dem ich mich näher erkundigen möchte.
Wie ich es mache, habe ich einen Master-Zweig und Feature-Zweige in git und benutze dann git diff --name-only master in einem Feature-Zweig, um herauszufinden, welche Dateien ich für ein bestimmtes Feature geändert habe. Ich überprüfe diese Dateien dann in einer Perforce-Änderungsliste und reiche sie ein.
... nun, mehr oder weniger ... :) In der Praxis verwenden wir Code Collaborator für Codeüberprüfungen, also prüfe ich die Dateien irgendwann zwischen dem Beginn der Arbeit an der Funktion und dem Einreichen der Dateien für die Codeüberprüfung (tut es nicht Es spielt wirklich keine Rolle, wann). Ich überprüfe dann vor dem Code-Review, dass ich alle Dateien habe, die ich mit dem obigen Git-Befehl haben sollte. (Weil ich paranoid bin, mache ich jetzt ein git clean -xdf in meinem Quellverzeichnis und führe eine Perforce "Offline Arbeit abstimmen" durch, um zu überprüfen, was ich vorschicke. Ich mache dann eine komplette Neuerstellung des Ganzen Das Brechen des Builds ist schließlich peinlich. Nachdem alle Überprüfungen abgeschlossen sind, reiche ich die Änderungsliste wie üblich ein.
Es ist ein bisschen eine Faff, wirklich, aber es ist nicht so schlecht, jetzt, wo ich mich daran gewöhnt habe - und es ist viel besser als nur Perforce mit massiven Commits zu verwenden und effektiv ohne irgendeine Art von Versionskontrolle für Tage hintereinander:)
Tags und Links git version-control perforce