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

Eine eigene Frage? Dieser Thread ist über 12 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.