Versionsverwaltung: zwei Branches parallel führen?

Gast #3780600
Lesenswert?
• ▲
▼
Tag zusammen,

ich habe ein AVR Projekt, dass ich mittels git verwalte. An dem Projekt 
arbeiten neben mir noch zwei andere Entwickler.
Momentan arbeiten wir alle mit einer Testhardware mit "großem" 
ATmega1284P Controller. Auf dem Board werden alle Controllerpins 
rausgeführt, außerdem ist ein LCD zum Testen angeschlossen. Die zweite 
UART wird zum Debuggen benutzt.

Nun ssteht bald der Schritt hin zur realen Hardware auf dem 
Programm.Dabei handelt es sich um eine extra angefertige Platine, auf 
der ein kleinerer Mega32 sitzt und auf dem nur die wirklich benötigten 
Pins benutzt werden. Auf einen Quarz wird verzichtet.

So, das resultiert natürlich in einer angepassten Software.
Registernamen werden sich ändern, Pinbelegungen ändern sich, 
Konfigurationen ändern sich, manche Module fliegen ganz raus (zweite 
UART, LCD).

Die Frage ist nun, wie ich diesen Vorgang in git (oder generell, in 
einer Versionsverwaltung) abbilde.
Mein erster Gedanke war, vor dem "Cut" alle offenen Branches in den 
master zurückzuführen, dass die Software erstmal komplett ist. Danach 
würde ich zwei Branches separat weiterlaufen lassen, einmal für den m128 
und einmal für den m32. Hintergrund ist, dass unsre Testhardware 
weiterhin zum Entwickeln/Bugfixing genutzt werden soll.

Allerdings bin ich mir nicht sicher ob das so passt. Ich müsste ja 
regelmäsig die Branches mergen. Dabei allerdings dann per Hand 
kontrollieren dass kein Controllerspezifisches Zeugs, wie Registernamen, 
gemergt wird. Das wird umständlich.

Wie würdet ihr das handhaben?
Was hat sich da bewährt?
#3780632
Lesenswert?
• ▲
▼
Karl schrieb:
> Die Frage ist nun, wie ich diesen Vorgang in git (oder generell, in
> einer Versionsverwaltung) abbilde.

Wie wär's mit "gar nicht"? ;-)

Sourcecode kann für unterschiedliche Zielhardware übersetzt werden, das 
ist durchaus üblich so. Für die Verwaltung der Quelltexte an sich hat 
das keine wirkliche Auswirkung. Vielleicht mal abgesehen von einer 
Konfig-Datei oder den Makefiles, die man anpassen muss. Diese liegen 
natürlich auch im Repository.
Gast #3780776
Lesenswert?
• ▲
▼
Das ist eigentlich nicht die schlechteste Idee :-)

Allerdings muss ich mir dazu wohl noch Gedanken machen, denn in einer 
#IFDEF Schlacht soll das Ganze nicht ausarten. Vor allem 
Funktionsaufrufe zu Test/Debuggfunktionen müssen aber irgendwie 
geschützt werden.
#3780792
Lesenswert?
• ▲
▼
Karl schrieb:

> Allerdings muss ich mir dazu wohl noch Gedanken machen, denn in einer
> #IFDEF Schlacht soll das Ganze nicht ausarten. Vor allem
> Funktionsaufrufe zu Test/Debuggfunktionen müssen aber irgendwie
> geschützt werden.

Dafür gibts diverse Möglichkeiten - ich beschränke z.B. die #ifdefs 
gerne auf die Headerdatei, in der dann je nach Konfiguration entweder 
die echten Funktionen deklariert oder Dummydefinitionen erzeugt werden. 
Zusätzlich sorgt das Makefile dafür, dass die zugehörige C-Datei mit den 
Funktionsdefinitionen nur eingebunden wird wenn die Konfiguration sie 
benötigt.
1
#ifdef CONFIG_UART_DEBUG
2

3
void uart_init(void);
4
void uart_putc(char c);
5

6
#else
7

8
#define uart_init()    do {} while(0)
9
#define uart_putc(x)   do {} while(0)
10

11
#endif

Statt der Leermakro-Definition könnte man auch "static inline void 
uart_init(void) {}" im Headerfile verwenden, der Compiler sollte dann 
den Aufruf der leeren Funktion komplett rausoptimieren. Welche Variante 
man für weniger böse hält hängt auch von den lokalen Code-Richtlinien 
ab, wahrscheinlich gibts da auch welche die beide davon verbieten 
würden.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren