TC3 XAE: Git Branches/Merge Erfahrungen

roboticBeet

Level-2
Beiträge
340
Reaktionspunkte
130
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,
wir nutzen für die Versionierung von TwinCAT Projekten einen Git Server und sind damit auch sehr zufrieden. Bislang nutzen wir für die SPS Entwicklung jedoch lediglich gradlinig den Hauptbranch. Um weitere Entwicklungen parallel zum Betrieb der Anlagen auch besser in Gitlab versionieren zu können, möchten wir gerne prüfen, ob sich das sinnvoll mit Branches abbilden lässt. Die Sorge ist, dass sich im Gegensatz zur klassischen C++/.NET Programmierung schnell komplexe Mergekonflikte ergeben könnten, aufgrund der Art und Weise wie TwinCAT die Bausteine in Textform in XML kodiert.

Hat da jemand Langzeiterfahrungen?
 
Für diesen Anwendungsfall eignet sich am besten das Beckhoff Tool TcProjectCompare. Man kann es als externes Diff bzw Merge Tool einsetzen.
Damit erhält man eine übersichtliche Darstellung der Änderungen zwischen zwei TwinCAT Dateien bzw. Projekten.
Das Tool wird zusammen mit der TwinCAT XAE installiert.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das Tool nutzen wir bereits, um Änderungen zu visualisieren. Mir geht es mehr darum, ob beim Mergen unterschiedlicher Branches, die ggf. längere Zeit parallel nebeneinander liefen, unlösbare Konflikte gibt, weil bspw. die Dateistruktur von TwinCAT im Hintergrund massiv geändert wurde.
 
Meine Tipps,..

.gitignore entsprechend anpassen
Code:
# gitignore template for TwinCAT3
# website: https://www.beckhoff.com/twincat3/
#
# Recommended: VisualStudio.gitignore

# Some usual suspects
*.bak
*.bin
*.zip
*.orig

# TwinCAT files
*.compiled-library
*.compileinfo
*.tmc
*.tmcRefac
*.library
*.project.~u
*.tclrs
*.tnzip
*.tpy
*.tpzip
*.tsproj.bk?
*.tszip
*.xti.bk?
LineIDs.dbg
_Boot/
_CompileInfo/
_Libraries/
_ModuleInstall/

## Ignore Visual Studio temporary files, build results, and
## files generated by popular Visual Studio add-ons.
##
## Get latest from https://github.com/github/gitignore/blob/master/VisualStudio.gitignore

# User-specific files
*.rsuser
*.suo
*.user
*.userosscache
*.sln.docstates

Bei allen IO's, auch Profinet, Profibus, usw... die Eigenschaft "Save in Own File" aktivieren
1662627597010.png

IO-Abbild, mit Option 'Save in own File' definieren
1662628097426.png

'Write product version in file' deaktivieren -> Ist auch ohne Branch von Vorteil wenn mehrere Person am gleichen Projekt arbeiten
1662627682478.png

'Sperate Line Ids' aktivieren -> Line IDs sind für Breakpoint wichtig, führen aber beim Mergen nur zu Verwirrung
1662627869781.png
 
Zuletzt bearbeitet:
Noch ein Erfahrungswert zum Branching:
Es bietet sich an, einen Branch zwischen Main-Branch und Feature-Branches für das Einmergen der verschiedenen Features zu haben. Damit werden die Features erst zusammengefügt bevor sie gemeinsam als neue Version in den Main-Branch wandern. Die potenziell blutigen merges finden also nicht auf dem main-branch statt.
 
Zurück
Oben