Anleitung: Mit Branches in Access arbeiten
Die Arbeit anderer pullen, zu einem anderen Branch wechseln oder einen neuen beginnen, während die Datenbank in Access geöffnet bleibt und kein Code verloren geht.
Kontext / Problemstellung
Code, den Sie in Access ändern, liegt in der Datenbank. git sieht ihn erst, wenn ein Export ihn in die Quellen
geschrieben hat. Ein git switch oder git pull im Terminal arbeitet deshalb mit Quellen, die älter sein können als die
Datenbank: Ein in Access geändertes Modul bleibt auf dem alten Branch zurück, oder der nächste Export überschreibt, was
der Pull gebracht hat.
Lösungsübersicht
Das SDK führt die Branch-Schritte über dieselbe Prüfung aus wie wkl-office changes:
| Schritt | Was das SDK vorher und nachher tut |
|---|---|
| Pull | Merget den Remote-Branch in die Quellen (immer ein Merge, nie ein Rebase) und importiert die hinzugekommenen Objekte in die geöffnete Datenbank. Ein Objekt, das Sie auch in Access geändert haben, wird nicht importiert: Es wartet in Änderungen auf Ihre Entscheidung. Eine Datei, die git nicht mergen konnte, wartet als Mergekonflikt. |
| Pull und Push | Wie Pull, danach Push des Branches, wenn nichts auf eine Entscheidung wartet. |
| Fetch | Holt den Stand des Remotes, damit der Branch zeigt, wie viele Commits es zu pullen gibt. Ändert nichts an den Quellen. |
| Wechseln zu einem Branch | Exportiert zuerst, was Sie in Access geändert haben, und fragt vorher nach; lehnt ab, solange etwas auf eine Entscheidung wartet. Nach dem Wechsel bietet es an, die Objekte mit anderen Quellen zu importieren oder die Datenbank neu zu erstellen. |
| Neuer Branch | Legt einen Branch aus dem aktuellen Stand an und wechselt zu ihm; Quellen und Datenbank bleiben, wie sie sind, deshalb wird nichts geprüft oder exportiert. |
Im Add-In stehen die Schritte im Menü Branch der Gruppe Projekt auf der Registerkarte WKL SDK und auf der
Symbolleiste WKL SDK des VBA-Editors. Die Beschriftung des Menüs ist der aktuelle Branch, gefolgt von ↑ mit der Zahl
der Commits für Push und ↓ mit der Zahl der Commits für Pull, nach dem Stand des letzten Fetch oder Pull (main ↑2 ↓1).
In der Befehlszeile sind es wkl-office pull und wkl-office switch.
Umsetzung
In Access oder im VBA-Editor:
- Branch öffnen und Pull wählen. Das Ergebnis steht in der Registerkarte Ausgabe. Wartet etwas auf eine Entscheidung, öffnet sich die Registerkarte Änderungen.
- Zum Wechseln Branch öffnen und unter Wechseln zu einen Branch wählen. Ein Branch, den es nur auf dem Remote gibt, ist entsprechend gekennzeichnet; der Wechsel legt einen lokalen Branch an, der ihm folgt.
- Enthält der VBA-Editor nicht gespeicherten Code oder Access nicht exportierte Änderungen, fragt das Add-In Die in Access gemachten Änderungen exportieren und zu Branch wechseln? Exportieren und wechseln wählen. Der Code wird gespeichert, die Änderungen werden exportiert, dann wird der Branch gewechselt.
- Nach dem Wechsel holt n Objekt(e) importieren die geänderten Objekte in die geöffnete Datenbank; Neu erstellen und öffnen baut sie aus den Quellen des Branches neu. Unterscheiden sich Tabellen, Verweise oder Daten, ist ein Neuerstellen nötig; die Frage sagt das.
- Neuer Branch… fragt nach dem Namen. Einen Namen, den git nicht annimmt oder den schon ein Branch trägt, können Sie nicht bestätigen.
In der Befehlszeile:
wkl-office pull Customers.acproj wkl-office pull Customers.acproj --push wkl-office switch Customers.acproj feature/phone --create --export wkl-office switch Customers.acproj main --import
Einen Konflikt nach einem Pull entscheiden. Die Registerkarte Änderungen listet auf, was wartet:
- Ein in Access und durch den Pull geändertes Objekt steht auf Beide geändert. Access behalten behält Ihre Fassung, Quelle behalten übernimmt die Fassung des Pulls; in der Befehlszeile ist das
wkl-office sync <object> --keep access|source. - Eine Datei, die git nicht mergen konnte, steht auf Mergekonflikt lösen. Wählen Sie sie aus und klicken Sie auf Merge lösen: Meine behalten behält die Fassung Ihres Branches, Ihre übernehmen die Fassung des Pulls. Um beide von Hand zusammenzuführen, doppelklicken Sie die Zeile: Die Datei öffnet sich in Visual Studio Code. Entfernen Sie die Konfliktmarkierungen, speichern Sie und wählen Sie erneut Merge lösen, dann Als zusammengeführt markieren. Die zuletzt gelöste Datei schließt den Merge mit einem Commit ab, der die Meldung von git trägt. Importieren Sie danach die zusammengeführten Quellen mit Änderungen importieren.
Hinweise
- Ein Wechsel verliert keinen Code: Was nur in Access liegt, wird nach Ihrer Zustimmung zuerst exportiert. git nimmt die geänderten Quelldateien dann auf den anderen Branch mit oder lehnt den Wechsel ab, wenn jener Branch eine andere Fassung derselben Datei hat. Dann ändert sich nichts, und Sie können den Export zuerst committen.
- Der Pull importiert nur, was er gebracht hat. Ein Import, der schon vor dem Pull ausstand, bleibt ausstehend.
- Ein Pull wird abgelehnt, solange ein Mergekonflikt eines früheren Pulls nicht gelöst ist.
- Der Import braucht die Datenbank des Projekts in Access geöffnet. In der Befehlszeile ohne geöffnete Datenbank listet
switchdie Objekte auf; importieren Sie sie später mitwkl-office import --changedoder erstellen Sie neu. - Das SDK startet git ohne Konsole. Eine Frage, die git auf der Konsole stellen würde, scheitert sofort. Die Anmeldung über einen Credential Helper wie Git Credential Manager öffnet weiterhin ihr eigenes Fenster.
- Nur git. In einer Subversion-Arbeitskopie lautet das Branch-Menü Das Projekt liegt in keiner git-Arbeitskopie, und
pullundswitchlehnen ab.