Source code management/de: Difference between revisions
(Created page with "* FreeCAD mit GitKraken entwickeln, eine Anleitung zur Verwendung einer grafischen Oberfläche mit Git. * [https://wiki.spheredev.org/...") |
No edit summary |
||
(111 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
<languages/> |
<languages/> |
||
{{TOCright}} |
|||
Das wichtigste Quellcode Verwaltungswerkzeug für das FreeCAD Projekt ist [http://en.wikipedia.org/wiki/Git_%28software%29 Git], das in den meisten Betriebssystemen einfach über einen Paketmanager oder direkt von der Website von [https://git-scm.com/ Git] installiert werden kann. Es wird empfohlen, sich mit Git vertraut zu machen, bevor du direkt mit dem FreeCAD Quellcode arbeitest. Besuche die Seite [https://git-scm.com/doc Git-Dokumentation] für das Referenzhandbuch sowie das [https://git-scm.com/book/en/v2 Pro Git-Buch], um zu lernen, das System allgemein zu nutzen. Das vorliegende Dokument konzentriert sich auf die Verwendung von Git für die FreeCAD Entwicklung. Die Kompilierung von FreeCAD ist unter [[Compiling/de|Kompilieren]] beschrieben. |
|||
<span id="Introduction"></span> |
|||
Obwohl Git in erster Linie eine Terminalanwendung ist, gibt es viele grafische Anwendungen, die die Arbeit mit Zweigen, das Anwenden von Patches und das Senden von Pull Anfragen an einen Master Zweig erleichtern. Beispiele sind [https://git-scm.com/docs/gitk gitk] (die erste entwickelte grafische Benutzeroberfläche),[https://wiki.gnome.org/Apps/Gitg/ gitg] (Gnome),[https://github.com/tibirna/qgit qgit] (Qt), [https://jonas.github.io/tig/ tig] (Ncurses), [http://github.com/git-cola/git-cola git-cola] und [https://www.gitkraken.com/ GitKraken] (proprietär). Eine kurze Einführung in dieses Werkzeug findest Du unter [[Developing FreeCAD with GitKraken/de|Entwicklung von FreeCAD mit GitKraken]]. |
|||
== Einführung == |
|||
Das Hauptwerkzeug zur Quellcodeverwaltung für das FreeCAD-Projekt ist [http://en.wikipedia.org/wiki/Git_%28software%29 Git], das in den meisten Betriebssystemen einfach über einen Paketmanager oder direkt von der Website von [https://git-scm.com/ Git] installiert werden kann. Es wird empfohlen, sich mit Git vertraut zu machen, bevor man direkt mit dem FreeCAD-Quellcode arbeitet. Auf der Seite [https://git-scm.com/doc Git Dokumentation] findet man das Referenzhandbuch sowie das [https://git-scm.com/book/en/v2 Pro Git Book] (beide engl.), um zu lernen, wie das System im Allgemeinen genutzt wird. Das vorliegende Dokument konzentriert sich auf die Verwendung von Git für die FreeCAD-Entwicklung. Die Zusammenstellung von FreeCAD ist unter [[Compiling/de|Kompilieren]] beschrieben. |
|||
Während Git in erster Linie eine Terminalanwendung ist, gibt es viele grafische Anwendungen, die die Arbeit mit Zweigen, das Anwenden von Patches und das Senden von Pull-Anfragen an einen Master-Zweig erleichtern. Beispiele sind [https://git-scm.com/docs/gitk gitk] (die erste entwickelte grafische Benutzeroberfläche),[https://wiki.gnome.org/Apps/Gitg/ gitg] (Gnome),[https://github.com/tibirna/qgit qgit] (Qt), [https://jonas.github.io/tig/ tig] (Ncurses), [http://github.com/git-cola/git-cola git-cola] und [https://www.gitkraken.com/ GitKraken] (proprietär). Eine kurze Einführung in dieses Werkzeug findet man unter [[Developing FreeCAD with GitKraken/de|Entwicklung von FreeCAD mit GitKraken]]. |
|||
Hinweis: Wenn dir davon schwindelig wird, gibt es eine sehr gute nicht-technische Serie über die Verwendung von Git und Github mit dem Titel '[https://youtu.be/BCQHnlnPusY Git und Github für Dichter]'. |
|||
<span id="Source_code_access"></span> |
|||
== Quellcodezugang== |
== Quellcodezugang== |
||
Jeder kann auf den FreeCAD |
Jeder kann auf den FreeCAD-Quellcode zugreifen und eine Kopie davon bekommen, aber nur die FreeCAD-Projektmanager haben Schreibzugriff darauf. Du kannst eine Kopie des Codes erhalten, ihn studieren und nach Belieben ändern, aber wenn du möchtest, dass deine Änderungen in den offiziellen Quellcode aufgenommen werden, musst du eine "Pull-Anfrage" gegen das Haupt-Repositorium durchführen, damit deine Änderungen von den Verwaltern überprüft werden können. Diese Art der Entwicklung ist bekannt als der [https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows Dictator and Lieutenants Workflow], da die Kern-Entwickler (Diktatoren) und betrauten Entwickler (Leutnante) den Code filtern, der von unabhängigen Entwicklern und Benutzern eingereicht wird. |
||
Wenn deine Quellcode-Änderungen signifikant sind, empfehlen wir dir, sie im Pull-Request Abschnitt des [http://forum.freecadweb.org/viewforum.php?f=17 FreeCAD-Forum] zu erklären. |
|||
[[File:FreeCAD_git_workflow.svg|600px]] {{Caption|Typischer Arbeitsablauf zur Entwicklung von Code für FreeCAD; jeder kann den Code aus dem Haupt-Repositorium beziehen, aber die Hauptentwickler haben das exklusive Recht, Eingaben anderer Entwickler zu überprüfen und zusammenzuführen.}} |
|||
<span id="Official_GitHub_repository"></span> |
|||
===Offizieller GitHub-Ablageordner (Repository)=== |
|||
Der FreeCAD-Quellcode wird in Github bereitgestellt, {{URL|https://github.com/FreeCAD/FreeCAD}} |
|||
Wenn deine Quellcode Änderungen signifikant sind, empfehlen wir dir, sie im Pull Request Abschnitt des [http://forum.freecadweb.org/viewforum.php?f=17 FreeCAD-Forum] zu erklären. |
|||
Um Code beitragen zu können, wird ein [https://github.com/join GitHub-Konto] benötigt. |
|||
[[File:FreeCAD_git_workflow.svg|600px]] {{Caption|Typischer Arbeitsablauf zur Entwicklung von Code für FreeCAD; jeder kann den Code aus dem Haupt Repositorium beziehen, aber die Hauptentwickler haben das exklusive Recht, Eingaben anderer Entwickler zu überprüfen und zusammenzuführen.}} |
|||
In der Vergangenheit wurde der Quellcode in einem SVN-Repositorium bereitgestellt, {{URL|https://free-cad.svn.sourceforge.net/svnroot/free-cad}}. Dieser wurde am 10. Oktober 2011 mit [https://github.com/FreeCAD/FreeCAD/commit/120ca87015 commit 120ca87015] nach GitHub verschoben. |
|||
=== Offizielles GitHub Repository ===== |
|||
Der FreeCAD Quellcode wird in Github bereitgestellt, {{URL|https://github.com/FreeCAD/FreeCAD}} |
|||
:Daher gibt es viele Änderungen, die vor dieser Zeit vorgenommen wurden, die nicht in der modernen Git-Commit-Geschichte aufgezeichnet sind. Lies mehr dazu auf der Seite [[History/de|Geschichte]]. |
|||
Um Code beitragen zu können, benötigst Du ein [https://github.com/join GitHub Konto]. |
|||
=== Setzen des Git |
=== Setzen des Git-Benutzernamens === |
||
Entwickler sollten Code in ihr persönliches Projektarchiv mit ihrem GitHub |
Entwickler sollten Code in ihr persönliches Projektarchiv mit ihrem GitHub-Benutzernamen eintragen. Wenn dieser nicht bereits global gesetzt ist, kann er lokal für das aktuelle Git-Projektarchiv wie folgt gesetzt werden: |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git config user.name "YOUR_NAME" |
git config user.name "YOUR_NAME" |
||
git config user.email GITHUB_USERNAME@users.noreply.github.com |
git config user.email GITHUB_USERNAME@users.noreply.github.com |
||
}} |
}} |
||
Wobei {{incode|"YOUR_NAME"}} deinen vollständigen Namen oder Spitznamen darstellt, der zur Identifizierung des Autors eines bestimmten |
Wobei {{incode|"YOUR_NAME"}} deinen vollständigen Namen oder Spitznamen darstellt, der zur Identifizierung des Autors eines bestimmten Beitrags verwendet wird, und {{incode|GITHUB_USERNAME}} den Namen deines Accounts auf GitHub angibt. |
||
<span id="Remote_repositories"></span> |
|||
=== Entfernte Repositorien === |
|||
===Ferne Projektarchive (Remote repositories)=== |
|||
Bitte lese [https://stackoverflow.com/questions/9257533/what-is-the-difference-between-origin-and-upstream-on-github#9257901 Was ist der Unterschied zwischen Ursprung und Upstream auf GitHub?] (Stackoverflow) um den Unterschied zwischen {{incode|origin}} und {{incode|upstream}} im Kontext von Git zu verstehen. Dieser Abschnitt erklärt, wie man die richtigen Repositorien für die Entwicklung festlegt. |
|||
Bitte lies [https://stackoverflow.com/questions/9257533/what-is-the-difference-between-origin-and-upstream-on-github#9257901 Was ist der Unterschied zwischen Ursprung und Upstream auf GitHub?] (Stackoverflow) um den Unterschied zwischen {{incode|origin}} und {{incode|upstream}} im Kontext von Git zu verstehen. Dieser Abschnitt erklärt, wie man die richtigen Ablageorte/Projektarchive für die Entwicklung festlegt. |
|||
Im Wesentlichen: |
Im Wesentlichen: |
||
* {{incode|origin}} ist deine persönliche |
* {{incode|origin}} ist deine persönliche Abzweigung des offiziellen FreeCAD-Projektarchivs, also {{URL|https://github.com/GITHUB_USERNAME/FreeCAD}} |
||
* {{incode|upstream}} ist |
* {{incode|upstream}} ist der offizielle FreeCAD-Ablageort, d.h. {{URL|https://github.com/FreeCAD/FreeCAD}} |
||
Diese Unterscheidung ist wichtig, da du zuerst Code in deine eigene Kopie des |
Diese Unterscheidung ist wichtig, da du zuerst Code in deine eigene Kopie des Projektarchivs schreiben solltest, bevor du diese Änderungen in das offizielle Projektarchiv schreibst. |
||
Basierend auf dem oben genannten, gibt es zwei Möglichkeiten, deine Git |
Basierend auf dem oben genannten, gibt es zwei Möglichkeiten, deine Git-Entwicklungsumgebung einzurichten: |
||
* 1. Methode: |
* 1. Methode: Auf GitHub verzweigen und den eigenen Zweig lokal klonen. |
||
* 2. Methode: |
* 2. Methode: FreeCAD direkt auf den eigenen lokalen Rechner klonen und die fernen Server anpassen. |
||
Wir empfehlen die 1. Methode, weil sie einen Schritt schneller ist. |
Wir empfehlen die 1. Methode, weil sie einen Schritt schneller ist. |
||
Line 43: | Line 59: | ||
<div class="mw-collapsible mw-collapsed toccolours"> |
<div class="mw-collapsible mw-collapsed toccolours"> |
||
<span id="1st_Method:_Fork_on_GitHub_and_clone_your_fork_locally"></span> |
|||
==== 1. Methode: Verzweigung auf GitHub und klone deine Abspaltung lokal ===== |
|||
====1. Methode: Auf GitHub verzweigen und den eigenen Zweig lokal klonen==== |
|||
<div class="mw-collapsible-content"> |
<div class="mw-collapsible-content"> |
||
Line 53: | Line 70: | ||
* Klone auf deinem Rechner deine neu erstellte FreeCAD Fork. Er wird in einem Verzeichnis {{incode|freecad-source}} erstellt. |
* Klone auf deinem Rechner deine neu erstellte FreeCAD Fork. Er wird in einem Verzeichnis {{incode|freecad-source}} erstellt. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git clone https://github.com/GITHUB_USERNAME/FreeCAD.git freecad-source |
git clone https://github.com/GITHUB_USERNAME/FreeCAD.git freecad-source |
||
}} |
}} |
||
Line 59: | Line 76: | ||
* Sobald der Download abgeschlossen ist, gib das neue Quellverzeichnis ein und lege das {{incode|upstream}} Repositorium fest. |
* Sobald der Download abgeschlossen ist, gib das neue Quellverzeichnis ein und lege das {{incode|upstream}} Repositorium fest. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
cd freecad-source |
cd freecad-source |
||
git remote add upstream https://github.com/FreeCAD/FreeCAD.git |
git remote add upstream https://github.com/FreeCAD/FreeCAD.git |
||
}} |
}} |
||
* |
* Bestätige deine Fernrepositorien mit {{incode|git remote -v}}; die Ausgabe sollte ähnlich wie diese sein |
||
{{Code|code= |
{{Code|lang=text|code= |
||
origin https://github.com/GITHUB_USERNAME/FreeCAD.git (fetch) |
origin https://github.com/GITHUB_USERNAME/FreeCAD.git (fetch) |
||
origin https://github.com/GITHUB_USERNAME/FreeCAD.git (push) |
origin https://github.com/GITHUB_USERNAME/FreeCAD.git (push) |
||
Line 80: | Line 97: | ||
<div class="mw-collapsible mw-collapsed toccolours"> |
<div class="mw-collapsible mw-collapsed toccolours"> |
||
<span id="2nd_Method:_Clone_FreeCAD_directly_to_your_local_machine"></span> |
|||
==== 2. Methode: FreeCAD direkt auf deinen lokalen Rechner klonen ==== |
|||
====2. Methode: FreeCAD direkt auf den eigenen lokalen Rechner klonen==== |
|||
<div class="mw-collapsible-content"> |
<div class="mw-collapsible-content"> |
||
Zuerst wirst du das FreeCAD Repositorium in GitHub abspalten (engl.:fork ‚Gabel‘), jedoch wirst du das ursprüngliche FreeCAD Repositorium auf deinen lokalen Rechner klonen und dann deine Fernbedienungen über das Terminal ändern. |
|||
* [https://github.com/join |
* [https://github.com/join Anmelden] auf dein GitHub Konto. |
||
* |
* Gehe zum offiziellen FreeCAD Repositorium: {{URL|https://github.com/FreeCAD/FreeCAD}} |
||
* |
* Klicke oben rechts auf der Seite auf die "Fork" Schaltfläche. Dadurch wird eine persönliche Kopie des FreeCAD Repositoriums unter deinem GitHub Benutzernamen erstellt: {{URLn|https://github.com/GITHUB_USERNAME/FreeCAD}} |
||
* |
* Klone das ursprüngliche FreeCAD Repositorium. Es wird in einem Verzeichnis {{incode|freecad-source}} erstellt. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git clone https://github.com/FreeCAD/FreeCAD.git freecad-source |
git clone https://github.com/FreeCAD/FreeCAD.git freecad-source |
||
}} |
}} |
||
* Sobald das Herunterladen abgeschlossen ist, gib das neue Quellverzeichnis ein und lege das {{incode|Ursprung}}s Repositorium fest. |
|||
* Once the download is complete, enter the new source directory and set the {{incode|origin}} repository. |
|||
{{Code|code= |
{{Code|lang=text|code= |
||
cd freecad-source |
cd freecad-source |
||
git remote add origin https://github.com/GITHUB_USERNAME/FreeCAD.git |
git remote add origin https://github.com/GITHUB_USERNAME/FreeCAD.git |
||
}} |
}} |
||
* |
* Richte dann das {{incode|upstream}} Repositorium ein. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git remote add upstream https://github.com/FreeCAD/FreeCAD.git |
git remote add upstream https://github.com/FreeCAD/FreeCAD.git |
||
}} |
}} |
||
* |
* Bestätige deine Fernrepositorien mit {{incode|git remote -v}}; die Ausgabe sollte ähnlich wie diese sein |
||
{{Code|code= |
{{Code|lang=text|code= |
||
origin https://github.com/GITHUB_USERNAME/FreeCAD.git (fetch) |
origin https://github.com/GITHUB_USERNAME/FreeCAD.git (fetch) |
||
origin https://github.com/GITHUB_USERNAME/FreeCAD.git (push) |
origin https://github.com/GITHUB_USERNAME/FreeCAD.git (push) |
||
Line 116: | Line 134: | ||
}} |
}} |
||
* Jetzt kann die Entwicklung beginnen. |
|||
* Now development can begin. |
|||
</div> |
</div> |
||
</div> |
</div> |
||
Wenn die Fernrepositorien aus irgendeinem Grund zwar existieren, aber auf die falsche Adresse verweisen, kannst du die Situation durch Umbenennen des Namens des entfernten Repositoriums beheben. Beispielsweise sollte {{incode|Ursprung}} auf deine persönliche Abspaltung zeigen; wenn er auf das ursprüngliche FreeCAD Repositorium zeigt, ändere den Namen dieses Fernrepositoriums in {{incode|upstream}} und füge das {{incode|Ursprung}}s Repositorium manuell hinzu. |
|||
If for some reason the remote repositories exist but point to the wrong address, you can remedy the situation by renaming the remote repository's name. For example, {{incode|origin}} should point to your personal fork; if it is pointing to the original FreeCAD repository, change the name of this remote to {{incode|upstream}}, and manually add the {{incode|origin}} repository. |
|||
{{Code|code= |
{{Code|lang=text|code= |
||
git remote rename origin upstream |
git remote rename origin upstream |
||
git remote add origin https://github.com/GITHUB_USERNAME/FreeCAD.git |
git remote add origin https://github.com/GITHUB_USERNAME/FreeCAD.git |
||
Line 129: | Line 147: | ||
}} |
}} |
||
Du kannst auch weitere Informationen mit dem Schlüsselwort {{incode|anzeigen}} anzeigen. |
|||
{{Code|code= |
{{Code|lang=text|code= |
||
git remote show origin |
git remote show origin |
||
git remote show upstream |
git remote show upstream |
||
}} |
}} |
||
<span id="Git_development_process"></span> |
|||
== Git development process == |
|||
==Git-Entwicklungsprozess== |
|||
{{VeryImportantMessage|Never develop on your local ''master'' branch. Instead, create a local branch for development, and then merge this local branch to the upstream master branch through a pull request. Please read [https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell Git Branching], [https://book.git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging Basic Branching and Merging], and [https://git-scm.com/book/en/v2/GitHub-Contributing-to-a-Project GitHub - Contributing to a project] to learn more.}} |
|||
{{VeryImportantMessage|Niemals auf dem eigenen lokalen ''Master''-Zweig entwickeln. Erstelle stattdessen einen lokalen Zweig für die Entwicklung, und führe diesen lokalen Zweig dann über eine Pull-Anforderung mit dem vorgeschalteten Master-Zweig zusammen. Lies bitte [https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell Git-Verzweigung], [https://book.git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging Grundlegende Verzweigung und Zusammenführung] und [https://git-scm.com/book/en/v2/GitHub-Contributing-to-a-Project GitHub - An einem Projekt mitwirken], um mehr zu erfahren.}} |
|||
[[File:FreeCAD_git_branches_workflow.svg|800px]] |
[[File:FreeCAD_git_branches_workflow.svg|800px]] |
||
{{Caption| |
{{Caption|Generischer Arbeitsablauf zur Entwicklung von Code für FreeCAD unter Verwendung von {{incode|git}}; das Haupt Repositorium wird online gespalten und auf einen Offline Rechner geklont (0); neue Zweige (1) werden verwendet, um lokale Änderungen und Ergänzungen des Codes zu übergeben (2); die Zweige werden auf den neuesten Online Code zurückgeführt (3), und dann zum entfernten Repositorium geschoben (4); dann wird eine Pull Anfrage erstellt, um den Code in das Haupt Repositorium einzufügen (5). Dann wird der persönliche Klon mit dem neuen Mastercode aktualisiert (a); dieser aktualisierte Mastercode wird ebenfalls an das Fernrepositorium (b) geschickt, um denselben Code sowohl online als auch offline zu haben.}} |
||
= |
<span id="Branching"></span> |
||
=== Verzweigung === |
|||
Anstatt an der Masterversion des Codes zu arbeiten, empfiehlt die bewährte Methode mit Git die Erstellung eines neuen Zweiges, wann immer du an einer neuen Funktion arbeiten willst. Zweige sind kostengünstig, sie kopieren nicht den gesamten Quellcode Baum, sondern erzeugen lediglich einen Zeitpunkt, an dem Sie Code schreiben werden; daher helfen Zweige dabei, die laufende Arbeit vom Hauptcode getrennt zu halten. |
|||
Instead of working on the master version of the code, best practices with Git recommend creating a new branch whenever you want to work on a new feature. Branches are inexpensive, they don't copy the entire source tree, but merely create a point in time on top of which you will write code; thus branches help keep work in progress separate from the main code. |
|||
Die Verwendung eines neuen Zweigs erfolgt in zwei Schritten: Zuerst erstellest du den Zweig, und dann wechselst du zu ihm: |
|||
Using a new branch is done in two steps, first your create the branch, and then you switch to it: |
|||
{{Code|code= |
{{Code|lang=text|code= |
||
git branch myNewBranch |
git branch myNewBranch |
||
git checkout myNewBranch |
git checkout myNewBranch |
||
}} |
}} |
||
Führe alternativ beide Schritte mit einer einzigen Anweisung aus: |
|||
Alternatively, perform both steps with a single instruction: |
|||
{{Code|code= |
{{Code|lang=text|code= |
||
git checkout -b myNewBranch |
git checkout -b myNewBranch |
||
}} |
}} |
||
Jetzt kannst du Zweige mit {{incode|checkout}} ändern, wann immer du daran arbeiten musst. Um die Zweige in deinem Projekt und dem aktuellen Zweig zu sehen, verwende die Operation {{incode|branch}} allein oder füge {{incode|-v}} oder {{incode|-vv}} für weitere Informationen hinzu: |
|||
{{Code|code= |
{{Code|lang=text|code= |
||
git branch |
git branch |
||
git branch -vv |
git branch -vv |
||
}} |
}} |
||
Nachdem du Änderungen vorgenommen und diese Änderungen übertragen hast, verwende die Operation {{incode|log}} mit den folgenden Optionen, um die Zweige zu visualisieren |
|||
After you've made changes and committed those changes use the {{incode|log}} operation with the following options to visualize the branches |
|||
{{Code|code= |
{{Code|lang=text|code= |
||
git log --oneline --decorate --graph --all |
git log --oneline --decorate --graph --all |
||
}} |
}} |
||
= |
<span id="Committing"></span> |
||
=== Übergeben === |
|||
Sobald du dich in einem neuen Zweig befindest, bearbeite die gewünschten Quelldateien mit einem Texteditor. Um zu sehen, welche Dateien geändert wurden, verwende die Operationen {{incode|status}} und {{incode|diff}}; wenn du mit den Änderungen zufrieden bist, speichere die Änderungen mit der Operation {{incode|commit}}: |
|||
{{Code|code= |
{{Code|lang=text|code= |
||
git status |
git status |
||
git diff |
git diff |
||
Line 182: | Line 204: | ||
}} |
}} |
||
Anders als bei SVN muss man ausdrücklich angeben, welche Dateien übergeben werden; mit der Option {{incode|-a}} werden alle geänderten Dateien gespeichert. Der voreingestellte Texteditor, z.B. {{incode|nano}} oder {{incode|vim}}, wird zum Verfassen einer Überabemitteilung geöffnet. |
|||
Alternativ fügt man die Mitteilung der Übergabeanweisung hinzu: |
|||
Alternatively add the message in the commit itself: |
|||
{{Code|code= |
{{Code|lang=text|code= |
||
git commit -a -m "Fix the bug in the clone function." |
git commit -a -m "Fix the bug in the clone function." |
||
}} |
}} |
||
Werden neue Dateien oder Verzeichnisse erstellt, muss zuerst die Aktion {{incode|add}} ausgeführt werden, die sie zum lokalen Projektarchiv hinzufügt, bevor die Änderungen übergeben werden. |
|||
If you create new files or directories, you must use the {{incode|add}} operation first to add them to the local repository before committing the changes. |
|||
{{Code|code= |
{{Code|lang=text|code= |
||
git add path |
git add path |
||
git commit -a |
git commit -a |
||
}} |
}} |
||
Wobei {{incode|path}} eine beliebige Datei oder ein beliebiges Verzeichnis sein kann. |
|||
<span id="Writing_good_commit_messages"></span> |
|||
===Gute Übergabemitteilungen schreiben=== |
|||
=== Writing good commit messages === |
|||
You should try to work in small steps, that is, commit often, after a small addition in your code. If you cannot summarize your changes in one sentence, then it has probably been too long since you made a commit. |
You should try to work in small steps, that is, commit often, after a small addition in your code. If you cannot summarize your changes in one sentence, then it has probably been too long since you made a commit. |
||
For big changes, it is important that you have helpful and useful descriptions of your work. FreeCAD has adopted a format mentioned in the [https://git-scm.com/book/en/v2 Pro Git] book, which consists of a short message, and then a larger descriptive paragraph. |
For big changes, it is important that you have helpful and useful descriptions of your work. FreeCAD has adopted a format mentioned in the [https://git-scm.com/book/en/v2 Pro Git] book, which consists of a short message, and then a larger descriptive paragraph. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
Short (50 chars or less) summary of changes |
Short (50 chars or less) summary of changes |
||
Line 224: | Line 248: | ||
If you are doing a lot of related work in a branch, you should make many small commits (see a [https://forum.freecadweb.org/viewtopic.php?f=10&t=2062&p=14887#p14886 forum post]). When you want to merge those changes into the master branch, you should issue |
If you are doing a lot of related work in a branch, you should make many small commits (see a [https://forum.freecadweb.org/viewtopic.php?f=10&t=2062&p=14887#p14886 forum post]). When you want to merge those changes into the master branch, you should issue |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git log master..myNewBranch |
git log master..myNewBranch |
||
}} |
}} |
||
um die einzelnen Übergabe Meldungen zu sehen. Dann kannst du eine Nachricht von hoher Qualität schreiben, wenn eine Zusammenführung durchgeführt wird. |
|||
to see the individual commit messages. Then you can write a high quality message when performing a merge. |
|||
When you merge to master use the {{incode|--squash}} option and commit with your quality commit message. This will allow you to be very liberal with your commits and help to provide a good level of detail in commit messages without so many distinct descriptions. |
When you merge to master use the {{incode|--squash}} option and commit with your quality commit message. This will allow you to be very liberal with your commits and help to provide a good level of detail in commit messages without so many distinct descriptions. |
||
Line 238: | Line 262: | ||
With {{incode|git log --oneline}} you can see many commits in sequence, with the newest commit on top. In this example, starting from "feature A" many commits are made to implement "feature B"; we would like to squash all commits belonging to "feature B" into one. |
With {{incode|git log --oneline}} you can see many commits in sequence, with the newest commit on top. In this example, starting from "feature A" many commits are made to implement "feature B"; we would like to squash all commits belonging to "feature B" into one. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
871adb OK, feature B is fully implemented |
871adb OK, feature B is fully implemented |
||
1c3317 Whoops, it is not ready yet... |
1c3317 Whoops, it is not ready yet... |
||
Line 249: | Line 273: | ||
}} |
}} |
||
Use the {{incode|rebase}} operation with the {{incode|--interactive}} option to select various commits and squash them. Use the hash of the commit just before the first one that you want to squash, in this case the one corresponding to "feature A". |
Use the {{incode|rebase}} operation with the {{incode|--interactive}} or {{incode|-i}} option to select various commits and squash them. Use the hash of the commit just before the first one that you want to squash, in this case the one corresponding to "feature A". |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git rebase - |
git rebase -i 6394da |
||
}} |
}} |
||
(TIP: If you know how many commits you want to edit, you can use {{incode|git rebase -i HEAD~n}} to work on the last {{incode|n}} commits) |
|||
The command line editor, like {{incode|nano}} or {{incode|vim}}, will open to show you the commits again, now with the older commit on top. Before each commit, the word {{incode|pick}} will be shown. Delete the word {{incode|pick}}, and write the word {{incode|squash}} or just the letter {{incode|s}} instead, with the exception of the first entry; this commit is the oldest one, so all future commits will be squashed into it. |
The command line editor, like {{incode|nano}} or {{incode|vim}}, will open to show you the commits again, now with the older commit on top. Before each commit, the word {{incode|pick}} will be shown. Delete the word {{incode|pick}}, and write the word {{incode|squash}} or just the letter {{incode|s}} instead, with the exception of the first entry; this commit is the oldest one, so all future commits will be squashed into it. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
pick d94e78 Prepare the module for feature B |
pick d94e78 Prepare the module for feature B |
||
s 4e9baa Good implementation |
s 4e9baa Good implementation |
||
Line 273: | Line 299: | ||
You can use {{incode|git log --oneline}} again to observe the new commit history. In this case only a single commit for "feature B" will appear, on top of the unmodified commit for "feature A". |
You can use {{incode|git log --oneline}} again to observe the new commit history. In this case only a single commit for "feature B" will appear, on top of the unmodified commit for "feature A". |
||
{{Code|code= |
{{Code|lang=text|code= |
||
c83d67 OK, feature B is fully implemented now, with proper module setup, and clean code. |
c83d67 OK, feature B is fully implemented now, with proper module setup, and clean code. |
||
6394da Feature A |
6394da Feature A |
||
}} |
}} |
||
When coding for FreeCAD, we ask that you begin each commit message with the module that it affects. For example, a commit message for a change to sketcher might be: |
|||
<pre> |
|||
Sketcher: make straight lines curve a bit |
|||
Straight lines are sort of ugly, so this commit adds a little bit of curvature to them, so |
|||
they are more visually pleasing. They also sparkle some, and change colors over time. |
|||
Fixes bug #1234. |
|||
</pre> |
|||
Your PR will be easier to review, and faster to be merged, if you are careful to use rebase to structure and describe your commits before submitting. |
|||
=== Pushing your work to your GitHub repository === |
=== Pushing your work to your GitHub repository === |
||
Line 284: | Line 322: | ||
For FreeCAD, you should push your local branch to the {{incode|origin}} remote repository, that is, {{URLn|https://github.com/GITHUB_USERNAME/FreeCAD}}. You need to enter your username and password every time you push, unless you have set up [https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage#_credential_caching Credential caching]. Please read [https://help.github.com/articles/pushing-to-a-remote/ Pushing commits to a remote repository] for more information. |
For FreeCAD, you should push your local branch to the {{incode|origin}} remote repository, that is, {{URLn|https://github.com/GITHUB_USERNAME/FreeCAD}}. You need to enter your username and password every time you push, unless you have set up [https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage#_credential_caching Credential caching]. Please read [https://help.github.com/articles/pushing-to-a-remote/ Pushing commits to a remote repository] for more information. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git push origin myNewBranch |
git push origin myNewBranch |
||
}} |
}} |
||
When you work with a single branch, you may need to interactively rebase, squash, and fix commits many times. In this case, your branch history will not be simple, and you will not be able to push it to the remote repository. You may get a message like the following, saying that it is not possible to do a "fast-forward" push. |
|||
The regular developer doesn't have write access to the {{incode|upstream}} repository {{URL|https://github.com/FreeCAD/FreeCAD}}, therefore, you shouldn't push code to this remote server. |
|||
{{Code|lang=text|code= |
|||
error: failed to push some refs to 'https://github.com/USER/FreeCAD.git' |
|||
hint: Updates were rejected because a pushed branch tip is behind its remote |
|||
hint: counterpart. Check out this branch and integrate the remote changes |
|||
hint: (e.g. 'git pull ...') before pushing again. |
|||
hint: See the 'Note about fast-forwards' in 'git push --help' for details. |
|||
}} |
|||
In order to finally push your branch to the remote repository you need to "force push" it. This will completely overwrite your remote branch with the actual branch that you have offline. |
|||
{{Code|lang=text|code= |
|||
git push -f origin myNewBranch |
|||
}} |
|||
The regular developer doesn't have write access to the {{incode|upstream}} repository {{URL|https://github.com/FreeCAD/FreeCAD}}, therefore, you should never push code to this remote server. |
|||
=== Rebasing from upstream === |
=== Rebasing from upstream === |
||
Line 303: | Line 357: | ||
Therefore, when you are ready to merge your branch to the main FreeCAD repository, you must "rebase" your own copy of the repository, so that it is as close as possible to the official repository. See [https://git-scm.com/book/en/v2/Git-Branching-Rebasing Git Branching - Rebasing] for more information. |
Therefore, when you are ready to merge your branch to the main FreeCAD repository, you must "rebase" your own copy of the repository, so that it is as close as possible to the official repository. See [https://git-scm.com/book/en/v2/Git-Branching-Rebasing Git Branching - Rebasing] for more information. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git checkout myNewBranch |
git checkout myNewBranch |
||
git pull --rebase upstream master |
git pull --rebase upstream master |
||
Line 319: | Line 373: | ||
To summarize, you need to be in the appropriate branch, rebase the upstream code, and then proceed with the push. |
To summarize, you need to be in the appropriate branch, rebase the upstream code, and then proceed with the push. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git checkout myNewBranch |
git checkout myNewBranch |
||
git pull --rebase upstream master |
git pull --rebase upstream master |
||
Line 327: | Line 381: | ||
The {{incode|pull}} operation is equivalent to a {{incode|fetch}} followed by a {{incode|merge}}. When the {{incode|--rebase}} option is used, instead of doing a simple {{incode|merge}}, it runs the {{incode|rebase}} operation. |
The {{incode|pull}} operation is equivalent to a {{incode|fetch}} followed by a {{incode|merge}}. When the {{incode|--rebase}} option is used, instead of doing a simple {{incode|merge}}, it runs the {{incode|rebase}} operation. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git pull upstream |
git pull upstream |
||
Line 334: | Line 388: | ||
}} |
}} |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git pull --rebase upstream master |
git pull --rebase upstream master |
||
Line 345: | Line 399: | ||
Once you have committed your changes locally, rebased your branch from the upstream repository, and pushed your branch online, you can initiate a "pull request". A [https://help.github.com/articles/about-pull-requests/ pull request] tells the administrators of the official FreeCAD repository that you want to merge the new code in your branch with the official code. |
Once you have committed your changes locally, rebased your branch from the upstream repository, and pushed your branch online, you can initiate a "pull request". A [https://help.github.com/articles/about-pull-requests/ pull request] tells the administrators of the official FreeCAD repository that you want to merge the new code in your branch with the official code. |
||
To recap, the development process looks like this: |
|||
As soon as you push the code to your {{incode|origin}} repository {{URLn|https://github.com/GITHUB_USERNAME/FreeCAD}}, GitHub will give you the option of comparing and creating a pull request against the {{incode|upstream}} repository. By pressing {{Button|Compare & pull request}} you will open an interface that will allow you to pick which repository is the "base", target of the merge, and which is the "head", your additional code. A quick check will be done by the system telling you if there are no conflicts with the files that you modified; if you worked on files that nobody has touched, your branch will be able to merge cleanly. In addition, it will show you a text editor so you can write a message documenting your changes; it will also display the number of commits in your branch, the number of files that were modified, and a view showing you the differences between the "base" and the "head" so that everybody can immediately see your intended modifications. |
|||
# Fork FreeCAD and get a local copy of that fork. |
|||
# Create a branch on your fork and change to that branch. |
|||
# Code! Commit and much or as little as you like, writing good commit messages to keep track of what you are doing. |
|||
# When you are satisfied with your work, use {{incode|git rebase -i HEAD~n}} (where n is the total number of commits you've made) to collapse your commits into a logical set with good commit messages (each message should begin with the name of the module it affects, e.g. "Sketcher: make straight lines curve a bit"). |
|||
# Use GitHub to submit your code as a "Pull Request (PR)" as described below. |
|||
As soon as you push the code to your {{incode|origin}} repository {{URLn|https://github.com/GITHUB_USERNAME/FreeCAD}}, GitHub will give you the option of comparing and creating a pull request against the {{incode|upstream}} repository. By pressing {{Button|Compare & pull request}} you will open an interface that will allow you to pick which repository is the "base", target of the merge, and which is the "head", your additional code. A quick check will be done by the system telling you if there are no conflicts with the files that you modified; if you worked on files that nobody has touched, your branch will be able to merge cleanly. |
|||
{{Code|code= |
|||
GitHub will show you a text editor so you can write a message documenting your changes: this editor will be pre-filled with a welcome message (that you can delete), a checklist (that you should go through), and a reminder to document your change on the wiki when it's accepted. To use the checklist, go through each item in turn and change the {{incode|[ ]}} to {{incode|[X]}} to indicate that you've done that step. GitHub will also display the number of commits in your branch, the number of files that were modified, and a view showing you the differences between the "base" and the "head" so that everybody can immediately see your intended modifications. Double-check these for things like stray blank lines you didn't mean to add, or huge formatting changes that your IDE decided to make behind your back. |
|||
{{Code|lang=text|code= |
|||
base repository: FreeCAD/FreeCAD base: master <---- head repository: GITHUB_USERNAME/FreeCAD compare: myNewBranch |
base repository: FreeCAD/FreeCAD base: master <---- head repository: GITHUB_USERNAME/FreeCAD compare: myNewBranch |
||
Line 376: | Line 439: | ||
Now you must wait for the administrators to merge your branch; you will be notified when this happens. |
Now you must wait for the administrators to merge your branch; you will be notified when this happens. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
Pull request successfully merged and closed |
Pull request successfully merged and closed |
||
Line 385: | Line 448: | ||
If you wish, you may delete the branch that was just merged, or even your entire FreeCAD fork, as your own code is already included at the end of the master branch. |
If you wish, you may delete the branch that was just merged, or even your entire FreeCAD fork, as your own code is already included at the end of the master branch. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
-----o-----------Z----A' FreeCAD upstream/master |
-----o-----------Z----A' FreeCAD upstream/master |
||
}} |
}} |
||
Line 393: | Line 456: | ||
The pull request interface can be used whenever you want to submit code from your own repositories to another repository in GitHub. You can use it to merge code in the opposite direction as well, from other people's branches to your own, or even between your own branches. In the last case, since you own the branches, the merges can be approved by yourself immediately. |
The pull request interface can be used whenever you want to submit code from your own repositories to another repository in GitHub. You can use it to merge code in the opposite direction as well, from other people's branches to your own, or even between your own branches. In the last case, since you own the branches, the merges can be approved by yourself immediately. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
base repository: SomeProject/Some_Software base: master <---- head repository: GITHUB_USERNAME/Some_Software compare: add_new_functions |
base repository: SomeProject/Some_Software base: master <---- head repository: GITHUB_USERNAME/Some_Software compare: add_new_functions |
||
base repository: GITHUB_USERNAME/FreeCAD base: myNewBranch <---- head repository: FreeCAD/FreeCAD compare: master |
base repository: GITHUB_USERNAME/FreeCAD base: myNewBranch <---- head repository: FreeCAD/FreeCAD compare: master |
||
Line 399: | Line 462: | ||
}} |
}} |
||
<span id="Keeping_the_GitHub_repository_up_to_date"></span> |
|||
=== Keeping the GitHub repository up to date === |
|||
=== Das GitHub Repositorium auf dem neuesten Stand halten === |
|||
Once you've forked FreeCAD, your personal repository exists independently from the original. When the original repository has new commits, GitHub will inform you that your personal repository is behind in number of commits: |
Once you've forked FreeCAD, your personal repository exists independently from the original. When the original repository has new commits, GitHub will inform you that your personal repository is behind in number of commits: |
||
{{Code|code= |
{{Code|lang=text|code= |
||
This branch is 5 commits behind FreeCAD:master. |
This branch is 5 commits behind FreeCAD:master. |
||
}} |
}} |
||
Line 409: | Line 473: | ||
In similar way, if you created a development branch with new code, GitHub will inform you that this branch is ahead in number of commits; that is, this branch has changes that haven't been merged into the official FreeCAD repository: |
In similar way, if you created a development branch with new code, GitHub will inform you that this branch is ahead in number of commits; that is, this branch has changes that haven't been merged into the official FreeCAD repository: |
||
{{Code|code= |
{{Code|lang=text|code= |
||
This branch is 3 commits ahead of FreeCAD:master. |
This branch is 3 commits ahead of FreeCAD:master. |
||
}} |
}} |
||
Line 415: | Line 479: | ||
While developing, both cases are possible, as your own branch may lack commits made by other developers, but include new commits by you: |
While developing, both cases are possible, as your own branch may lack commits made by other developers, but include new commits by you: |
||
{{Code|code= |
{{Code|lang=text|code= |
||
This branch is 2 commits ahead, 14 commits behind FreeCAD:master. |
This branch is 2 commits ahead, 14 commits behind FreeCAD:master. |
||
}} |
}} |
||
Line 423: | Line 487: | ||
As for your original {{incode|master}} branch, it will never be automatically updated by GitHub; this is something that you must do yourself. Switch to the {{incode|master}} branch, then {{incode|pull}} from {{incode|upstream}} (which performs a {{incode|fetch}} and {{incode|merge}}), and then push this updated {{incode|master}} branch to your remote {{incode|origin}} repository. |
As for your original {{incode|master}} branch, it will never be automatically updated by GitHub; this is something that you must do yourself. Switch to the {{incode|master}} branch, then {{incode|pull}} from {{incode|upstream}} (which performs a {{incode|fetch}} and {{incode|merge}}), and then push this updated {{incode|master}} branch to your remote {{incode|origin}} repository. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git checkout master |
git checkout master |
||
git pull upstream master |
git pull upstream master |
||
Line 431: | Line 495: | ||
After this is done, GitHub will let you know that your are synchronized with the {{incode|upstream}} repository. |
After this is done, GitHub will let you know that your are synchronized with the {{incode|upstream}} repository. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
This branch is even with FreeCAD:master. |
This branch is even with FreeCAD:master. |
||
}} |
}} |
||
Line 437: | Line 501: | ||
Now that your {{incode|master}} is up to date, you may decide to switch to it, and delete the other branch that you used previously to develop a feature. |
Now that your {{incode|master}} is up to date, you may decide to switch to it, and delete the other branch that you used previously to develop a feature. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git checkout master |
git checkout master |
||
git branch -d myNewBranch |
git branch -d myNewBranch |
||
Line 444: | Line 508: | ||
To delete the branch in the {{incode|origin}} remote repository, you can use the {{incode|push}} operation. Normally, you push a local branch; this creates a remote branch with the same name as your local branch. |
To delete the branch in the {{incode|origin}} remote repository, you can use the {{incode|push}} operation. Normally, you push a local branch; this creates a remote branch with the same name as your local branch. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git push origin myNewBranch |
git push origin myNewBranch |
||
}} |
}} |
||
Line 450: | Line 514: | ||
However, if you use the notation {{incode|local_name:remote_name}}, the local branch is created in the remote repository under a different name: |
However, if you use the notation {{incode|local_name:remote_name}}, the local branch is created in the remote repository under a different name: |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git push origin myNewBranch:someRemoteBranch |
git push origin myNewBranch:someRemoteBranch |
||
}} |
}} |
||
Daher kannst du den entfernte Fernzweig löschen, indem du einen leeren lokale Zweig schiebst: |
|||
Therefore, you can delete the remote branch by pushing an empty local branch: |
|||
{{Code|code= |
{{Code|lang=text|code= |
||
git push origin :myNewBranch |
git push origin :myNewBranch |
||
git push origin :someRemoteBranch |
git push origin :someRemoteBranch |
||
Line 463: | Line 527: | ||
Now that you only have an up-to-date {{incode|master}}, you can create a new branch, and repeat the steps of changing files, committing, pushing, submitting a pull request, merging, and updating. |
Now that you only have an up-to-date {{incode|master}}, you can create a new branch, and repeat the steps of changing files, committing, pushing, submitting a pull request, merging, and updating. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git checkout master |
git checkout master |
||
git checkout -b anotherBranch |
git checkout -b anotherBranch |
||
Line 470: | Line 534: | ||
If you don't want to delete your already custom branch, you may force updating it to be equal to the updated {{incode|master}}; then you can do whatever you want with it, including adding more commits and pushing it to the remote {{incode|origin}} repository. |
If you don't want to delete your already custom branch, you may force updating it to be equal to the updated {{incode|master}}; then you can do whatever you want with it, including adding more commits and pushing it to the remote {{incode|origin}} repository. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git checkout myNewBranch |
git checkout myNewBranch |
||
git reset --hard master |
git reset --hard master |
||
Line 478: | Line 542: | ||
Hard resetting a branch like this is usually not needed. In most cases, you want to follow the sequence of creating a new branch, committing changes, pushing those changes, merging the branch, and then deleting the branch. |
Hard resetting a branch like this is usually not needed. In most cases, you want to follow the sequence of creating a new branch, committing changes, pushing those changes, merging the branch, and then deleting the branch. |
||
<span id="Advanced_Git_operations"></span> |
|||
== Advanced Git operations == |
|||
== Erweiterte Git Operationen == |
|||
<span id="Searching"></span> |
|||
=== Resolving merge conflicts === |
|||
=== Suchen === |
|||
Some handy tools to help you find what you're looking for: |
|||
<span id="Search_filenames"></span> |
|||
==== Dateinamen suchen ==== |
|||
Use {{incode|git ls-files}} to search the repository for file that contains a certain string in a filename. The example below will return all instances of the files that contain the 'dxf' in their filenames. |
|||
{{Code|lang=text|code= |
|||
git ls-files *dxf* |
|||
}} |
|||
<span id="Search_for_a_string"></span> |
|||
==== Suche nach einer Zeichenkette ==== |
|||
Use {{incode|git grep}} to search the repository for file that contains a certain string with the files themselves. The example below will return all instances of the files that contain the 'dxf' within each and every file. |
|||
{{Code|lang=text|code= |
|||
git grep dxf |
|||
}} |
|||
<span id="Resolving_merge_conflicts"></span> |
|||
=== Auflösen von Zusammenführungskonflikten === |
|||
Merging branches with {{incode|git merge}}, or rebasing your branch with {{incode|git rebase}}, will occasionally present conflicts, as files may have been modified by another author at the same time. If this happens you should see the changes of both sides, the other author's, and your own, and then make a decision on how to include both sets of changes in the best way possible. This is normally a manual process that cannot be automated; the programmer must understand the code, and decide what code to move, re-write, or drop to solve the conflict. |
Merging branches with {{incode|git merge}}, or rebasing your branch with {{incode|git rebase}}, will occasionally present conflicts, as files may have been modified by another author at the same time. If this happens you should see the changes of both sides, the other author's, and your own, and then make a decision on how to include both sets of changes in the best way possible. This is normally a manual process that cannot be automated; the programmer must understand the code, and decide what code to move, re-write, or drop to solve the conflict. |
||
Sobald ein Konflikt auftritt, kann eine Meldung wie diese erscheinen. |
|||
Once a conflict occurs, a message like this may appear. |
|||
{{Code|code= |
{{Code|lang=text|code= |
||
CONFLICT (content): Merge conflict in src/Mod/source_code.py |
CONFLICT (content): Merge conflict in src/Mod/source_code.py |
||
error: Failed to merge in the changes. |
error: Failed to merge in the changes. |
||
Line 494: | Line 585: | ||
If a specialized diff tool is installed and configured for Git, for example, Gnome's [https://wiki.gnome.org/Apps/Meld Meld], the conflict can be examined and solved by using the {{incode|mergetool}} operation. |
If a specialized diff tool is installed and configured for Git, for example, Gnome's [https://wiki.gnome.org/Apps/Meld Meld], the conflict can be examined and solved by using the {{incode|mergetool}} operation. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git mergetool |
git mergetool |
||
}} |
}} |
||
Line 500: | Line 591: | ||
The Meld tool normally displays three columns; the two columns on the sides display the two conflicting files, while the column on the middle displays the new code that will be saved and committed finally. Therefore, this central column should be edited in a way that it integrates the code of both side columns. Once the conflict is solved and the new source code (the central column) is saved, the Meld tool can be closed. Then the {{incode|merge}} or {{incode|rebase}} operation can continue. |
The Meld tool normally displays three columns; the two columns on the sides display the two conflicting files, while the column on the middle displays the new code that will be saved and committed finally. Therefore, this central column should be edited in a way that it integrates the code of both side columns. Once the conflict is solved and the new source code (the central column) is saved, the Meld tool can be closed. Then the {{incode|merge}} or {{incode|rebase}} operation can continue. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git merge --continue |
git merge --continue |
||
git rebase --continue |
git rebase --continue |
||
Line 511: | Line 602: | ||
* [https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#_external_merge_tools External merge and diff tools] to use when you encounter a Git conflict. |
* [https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#_external_merge_tools External merge and diff tools] to use when you encounter a Git conflict. |
||
<span id="Inspect_changes"></span> |
|||
=== Inspect changes === |
|||
=== Änderungen untersuchen === |
|||
Inspect the history of a single file through various commits with the {{incode|log}} operation: |
Inspect the history of a single file through various commits with the {{incode|log}} operation: |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git log --patch path |
git log --patch path |
||
}} |
}} |
||
Line 521: | Line 613: | ||
Where {{incode|path}} can be any directory or file. Instead of {{incode|--patch}}, also the shorthands {{incode|-p}} or {{incode|-u}} can be used. |
Where {{incode|path}} can be any directory or file. Instead of {{incode|--patch}}, also the shorthands {{incode|-p}} or {{incode|-u}} can be used. |
||
<span id="Inspect_changes_between_two_branches"></span> |
|||
=== Inspect changes between two branches === |
|||
=== Änderungen zwischen zwei Zweigen untersuchen === |
|||
Inspect the changes between two branches with the {{incode|log}} and {{incode|diff}} operations with the names of the branches: |
Inspect the changes between two branches with the {{incode|log}} and {{incode|diff}} operations with the names of the branches: |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git log master..myBranch |
git log master..myBranch |
||
git diff master..myBranch |
git diff master..myBranch |
||
Line 532: | Line 625: | ||
The {{incode|log}} operation shows the commits, while {{incode|diff}} shows the actual changes in the files. |
The {{incode|log}} operation shows the commits, while {{incode|diff}} shows the actual changes in the files. |
||
<span id="Reset_files_and_directories"></span> |
|||
=== Reset files and directories === |
|||
=== Dateien und Verzeichnisse zurücksetzen === |
|||
If you accidentally made modifications to a file or directory, you may want to completely revert these changes, to get the previous state of the source code. |
If you accidentally made modifications to a file or directory, you may want to completely revert these changes, to get the previous state of the source code. |
||
Line 538: | Line 632: | ||
This can be done quickly using the {{incode|checkout}} operation: |
This can be done quickly using the {{incode|checkout}} operation: |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git checkout path |
git checkout path |
||
git checkout . |
git checkout . |
||
Line 547: | Line 641: | ||
If you have accidentally added files and directories you can use the {{incode|clean}} operation: |
If you have accidentally added files and directories you can use the {{incode|clean}} operation: |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git clean -df |
git clean -df |
||
}} |
}} |
||
Line 555: | Line 649: | ||
To completely reset the repository, losing all uncommitted modifications, use the {{incode|reset}} operation: |
To completely reset the repository, losing all uncommitted modifications, use the {{incode|reset}} operation: |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git fetch |
git fetch |
||
git reset --hard FETCH_HEAD |
git reset --hard FETCH_HEAD |
||
Line 564: | Line 658: | ||
The {{incode|revert}} operation also reverts changes. However, this command does this by adding another commit to the history; in many cases this is not desired. |
The {{incode|revert}} operation also reverts changes. However, this command does this by adding another commit to the history; in many cases this is not desired. |
||
<span id="Pruning_old_branches"></span> |
|||
=== Pruning old branches === |
|||
=== Beschneiden alter Zweige === |
|||
If you have committed many branches to the {{incode|upstream}} repository, you may wish to remove these branches from your local system as they have already been merged. The branch in the {{incode|origin}} repository online can be deleted immediately after merging. Then you can remove the local references to that branch, using the {{incode|--prune}} or {{incode|prune}} options to the {{incode|fetch}} and {{incode|remote}} operations. |
If you have committed many branches to the {{incode|upstream}} repository, you may wish to remove these branches from your local system as they have already been merged. The branch in the {{incode|origin}} repository online can be deleted immediately after merging. Then you can remove the local references to that branch, using the {{incode|--prune}} or {{incode|prune}} options to the {{incode|fetch}} and {{incode|remote}} operations. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git fetch --prune origin |
git fetch --prune origin |
||
git remote prune origin |
git remote prune origin |
||
}} |
}} |
||
Schließlich kannst du die Zweige lokal löschen |
|||
Finally you can delete the branches locally |
|||
{{Code|code= |
{{Code|lang=text|code= |
||
git branch -D myBranch |
git branch -D myBranch |
||
}} |
}} |
||
Line 581: | Line 676: | ||
It is also a good practice to do garbage collection after a while, by using the {{incode|gc}} operation. This will cleanup unnecessary files, and compress local file revisions, in order to optimize local disk usage of the repository. |
It is also a good practice to do garbage collection after a while, by using the {{incode|gc}} operation. This will cleanup unnecessary files, and compress local file revisions, in order to optimize local disk usage of the repository. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git gc |
git gc |
||
}} |
}} |
||
<span id="Working_with_patches"></span> |
|||
=== Working with patches === |
|||
=== Arbeiten mit Patches === |
|||
Obwohl Git Ihnen dir erlaubt, verschiedene Code Zweige mit {{incode|git merge}} zusammenzuführen (in deinem Computer) oder einer Pull Anfrage (Fernrepositorium) gibt es Zeiten, in denen es wünschenswert sein kann, einen traditionellen "Patch" zu erstellen, der als Anhang per Email verschickt werden kann. Der folgende Arbeitsablauf erklärt, wie dies zu tun ist. |
|||
Although Git allows you to merge different branches of code with {{incode|git merge}} (in your computer) or a pull request (remote repository), there are times when it may be desirable to create a traditional "patch", which can be sent as an attachment through email. The following workflow explains how to do this. |
|||
<span id="Creating_patches"></span> |
|||
==== Creating patches ==== |
|||
==== Patches erstellen ==== |
|||
* You should be developing your new code in a secondary branch of your repository, and not in the master branch. So the first step is to make sure you are in the correct branch. |
* You should be developing your new code in a secondary branch of your repository, and not in the master branch. So the first step is to make sure you are in the correct branch. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git branch -v |
git branch -v |
||
git checkout myBranch |
git checkout myBranch |
||
Line 600: | Line 697: | ||
* Now use {{incode|git format-patch}} against the master branch, and use the {{incode|--stdout}} option to redirect the result to standard output; then redirect the standard output to a file, which for convenience is created above the source code directory. |
* Now use {{incode|git format-patch}} against the master branch, and use the {{incode|--stdout}} option to redirect the result to standard output; then redirect the standard output to a file, which for convenience is created above the source code directory. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git format-patch master --stdout > ../myCode.patch |
git format-patch master --stdout > ../myCode.patch |
||
}} |
}} |
||
* Eine andere Methode ist |
|||
* Another method is |
|||
{{Code|code= |
{{Code|lang=text|code= |
||
git format-patch HEAD^ |
git format-patch HEAD^ |
||
git format-patch HEAD~1 |
git format-patch HEAD~1 |
||
Line 613: | Line 710: | ||
The number of circumflex carets {{incode|^}} or the number {{incode|1}} indicate the number of commits that should be considered, that is, {{incode|^^^}} or {{incode|~3}} will create three patches for three commits. |
The number of circumflex carets {{incode|^}} or the number {{incode|1}} indicate the number of commits that should be considered, that is, {{incode|^^^}} or {{incode|~3}} will create three patches for three commits. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git format-patch HEAD^ |
git format-patch HEAD^ |
||
}} |
}} |
||
Line 619: | Line 716: | ||
This will create a patch or series of patches with the following naming convention |
This will create a patch or series of patches with the following naming convention |
||
{{Code|code= |
{{Code|lang=text|code= |
||
XXXX-commit-message.patch |
XXXX-commit-message.patch |
||
}} |
}} |
||
Line 625: | Line 722: | ||
where {{incode|XXXX}} is a number from {{incode|0000}} to {{incode|9999}}, and the commit message forms the majority of the file name, for example, |
where {{incode|XXXX}} is a number from {{incode|0000}} to {{incode|9999}}, and the commit message forms the majority of the file name, for example, |
||
{{Code|code= |
{{Code|lang=text|code= |
||
0001-fix-ViewProjMatrix-getProjectionMatrix.patch |
0001-fix-ViewProjMatrix-getProjectionMatrix.patch |
||
}} |
}} |
||
<span id="Applying_patches"></span> |
|||
==== Applying patches ==== |
|||
==== Patches anwenden ==== |
|||
Git can merge patches or diffs. To know more about this process read [https://www.drupal.org/node/1399218 Applying patches with Git]. |
Git can merge patches or diffs. To know more about this process read [https://www.drupal.org/node/1399218 Applying patches with Git]. |
||
Wenn du die Patch Datei bereits in deinem System hast, wende sie einfach an. |
|||
If you already have the patch file in your system, just apply it. |
|||
{{Code|code= |
{{Code|lang=text|code= |
||
git apply myCode.patch |
git apply myCode.patch |
||
}} |
}} |
||
Line 641: | Line 739: | ||
You can use {{incode|curl}} to download a patch from a website, and then apply it through {{incode|git}}. |
You can use {{incode|curl}} to download a patch from a website, and then apply it through {{incode|git}}. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
curl -O https://some.website.org/code/myCode.patch |
curl -O https://some.website.org/code/myCode.patch |
||
git apply myCode.patch |
git apply myCode.patch |
||
Line 657: | Line 755: | ||
</pre> |
</pre> |
||
<span id="Reversing_a_patch"></span> |
|||
==== Reversing a patch ==== |
|||
==== Einen Patch rückgängig machen ==== |
|||
When you apply a patch you modify some files. However, these modifications aren't permanent until you commit the changes. Therefore, if you want to revert a patch use the following instructions. |
When you apply a patch you modify some files. However, these modifications aren't permanent until you commit the changes. Therefore, if you want to revert a patch use the following instructions. |
||
Line 663: | Line 762: | ||
This will revert the changes applied, if you still have access to the original patch file. |
This will revert the changes applied, if you still have access to the original patch file. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git apply -R myCode.patch |
git apply -R myCode.patch |
||
}} |
}} |
||
Line 669: | Line 768: | ||
Alternatively, this will remove non-committed changes to the branch. |
Alternatively, this will remove non-committed changes to the branch. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git checkout -f |
git checkout -f |
||
}} |
}} |
||
Line 677: | Line 776: | ||
Say that you're working on a branch and you find yourself making some modifications to the source that are out of the scope of your current branch; in other words, those changes would be better in another branch instead of the current one. The {{incode|git stash}} command can be used to temporarily store those uncommitted local changes. |
Say that you're working on a branch and you find yourself making some modifications to the source that are out of the scope of your current branch; in other words, those changes would be better in another branch instead of the current one. The {{incode|git stash}} command can be used to temporarily store those uncommitted local changes. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git stash |
git stash |
||
git stash push |
|||
}} |
}} |
||
If in the future you want to use those commits, you can pop the commits out of the stash, and into your working branch. |
If in the future you want to use those commits, you can "pop" the commits out of the stash, and into your working branch. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git stash pop |
git stash pop |
||
}} |
}} |
||
Line 690: | Line 788: | ||
Or if you decide that you don't like those saved commits anymore, you may drop the commits from the stash entirely. |
Or if you decide that you don't like those saved commits anymore, you may drop the commits from the stash entirely. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git stash drop |
git stash drop |
||
}} |
}} |
||
Line 696: | Line 794: | ||
You can list multiple stash commits with |
You can list multiple stash commits with |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git stash list |
git stash list |
||
}} |
}} |
||
Line 702: | Line 800: | ||
To learn more, read [https://medium.freecodecamp.org/useful-tricks-you-might-not-know-about-git-stash-e8a9490f0a1a Useful tricks you might not know about Git stash]. |
To learn more, read [https://medium.freecodecamp.org/useful-tricks-you-might-not-know-about-git-stash-e8a9490f0a1a Useful tricks you might not know about Git stash]. |
||
<span id="Check_out_GitHub_requests_locally"></span> |
|||
=== Check out GitHub requests locally === |
|||
=== GitHub Anfragen lokal herausfinden === |
|||
[https://gist.github.com/piscisaureus/3342247 Checkout GitHub pull requests locally] |
[https://gist.github.com/piscisaureus/3342247 Checkout GitHub pull requests locally] |
||
== FreeCAD revision number == |
|||
=== Blaming === |
|||
{{VeryImportantMessage|Section TBD}} |
|||
Add content from https://forum.freecadweb.org/viewtopic.php?f=23&t=55943&p=481483#p481287 |
|||
=== Bisect === |
|||
{{incode|git bisect}} is a method to find the specific commit that introduced a bug. |
|||
You need to find 2 commits: |
|||
* A good commit (for example {{incode|abcd}}) before the system broke. |
|||
* A bad commit (for example {{incode|efgh}}) after the system broke. |
|||
Then enter this from the terminal: |
|||
{{Code|lang=text|code= |
|||
git bisect start |
|||
git bisect good abcd |
|||
git bisect bad efgh |
|||
}} |
|||
Result: {{incode|git}} will check out the mid point between the two commits. |
|||
The next step is to build and test the code. If the system works, continue the process by typing: |
|||
{{Code|lang=text|code= |
|||
git bisect good |
|||
}} |
|||
Repeat the previous step of building the code and testing it. |
|||
If the system is broken, type: |
|||
{{Code|lang=text|code= |
|||
git bisect bad |
|||
}} |
|||
Repeat the previous steps applying {{incode|good}} or {{incode|bad}} depending on the outcome of your tests. |
|||
Eventually, {{incode|git}} will tell you that {{incode|wxyz}} is the first bad commit. |
|||
Finally, to exit the bisect process, type: |
|||
{{Code|lang=text|code= |
|||
git bisect reset |
|||
}} |
|||
Note: {{incode|git bisect}} takes a long time if good and bad are far apart. |
|||
<span id="FreeCAD_revision_number"></span> |
|||
== FreeCAD Revisionsnummer == |
|||
In contrast to subversion, which uses a consecutive number for its revisions, Git produces [https://en.wikipedia.org/wiki/SHA-1 SHA-1 hash values] with every commit. A hash value is a long alphanumeric string that looks like this |
In contrast to subversion, which uses a consecutive number for its revisions, Git produces [https://en.wikipedia.org/wiki/SHA-1 SHA-1 hash values] with every commit. A hash value is a long alphanumeric string that looks like this |
||
{{Code|code= |
{{Code|lang=text|code= |
||
9b3ffef570596e184006287434fba54a4b03ccc3 |
9b3ffef570596e184006287434fba54a4b03ccc3 |
||
}} |
}} |
||
<span id="Latest_revision_number"></span> |
|||
=== Latest revision number === |
|||
=== Letzte Revisionsnummer === |
|||
To find the latest revision number of a particular branch use the {{incode|rev-list}} operation with the {{incode|--count}} option. Give the name of the branch, remote repository, tag, or a special pointer like {{incode|HEAD}}, to indicate the last commit in that particular object. |
To find the latest revision number of a particular branch use the {{incode|rev-list}} operation with the {{incode|--count}} option. Give the name of the branch, remote repository, tag, or a special pointer like {{incode|HEAD}}, to indicate the last commit in that particular object. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git rev-list --count master |
git rev-list --count master |
||
git rev-list --count HEAD |
git rev-list --count HEAD |
||
Line 726: | Line 878: | ||
Or browse [https://github.com/FreeCAD/FreeCAD the repository on GitHub], and read the amount of commits reported in the particular branch. |
Or browse [https://github.com/FreeCAD/FreeCAD the repository on GitHub], and read the amount of commits reported in the particular branch. |
||
<span id="Revision_number_of_a_specific_commit_hash"></span> |
|||
=== Revision number of a specific commit hash === |
|||
=== Revisionsnummer eines bestimmten Commit Hashes === |
|||
Since the hash is an alphanumeric string it is not very useful to decide if a certain commit is older or newer than another hash. To find the revision number of a particular hash, again use the {{incode|rev-list}} operation; the input can be the full hash, or a partial hash that is unique, usually the first 7 digits are enough. |
Since the hash is an alphanumeric string it is not very useful to decide if a certain commit is older or newer than another hash. To find the revision number of a particular hash, again use the {{incode|rev-list}} operation; the input can be the full hash, or a partial hash that is unique, usually the first 7 digits are enough. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git rev-list --count ab1520b872821414c6ce4a15fb85d471ac2a2b03 |
git rev-list --count ab1520b872821414c6ce4a15fb85d471ac2a2b03 |
||
git rev-list --count 9948ee4 |
git rev-list --count 9948ee4 |
||
}} |
}} |
||
<span id="Revision_hash_of_a_specific_commit_number"></span> |
|||
=== Revision hash of a specific commit number === |
|||
=== Revisions Hash einer bestimmten Commit Nummer === |
|||
If we have the commit number, say, 15000, and we want to find the corresponding hash, we need to calculate the number of commits since this point until the last commit ({{incode|HEAD}}). First, get the latest commit number. |
If we have the commit number, say, 15000, and we want to find the corresponding hash, we need to calculate the number of commits since this point until the last commit ({{incode|HEAD}}). First, get the latest commit number. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git rev-list --count HEAD |
git rev-list --count HEAD |
||
17465 |
17465 |
||
Line 746: | Line 900: | ||
Then subtract the commit that we want. |
Then subtract the commit that we want. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
17465 - 15000 = 2465 |
17465 - 15000 = 2465 |
||
}} |
}} |
||
Line 752: | Line 906: | ||
Then use the {{incode|log}} operation to show all commits and hashes. The {{incode|--skip}} option jumps the difference in commits that we calculated so that we go directly to the hash that we are looking for. |
Then use the {{incode|log}} operation to show all commits and hashes. The {{incode|--skip}} option jumps the difference in commits that we calculated so that we go directly to the hash that we are looking for. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git log --skip=2465 |
git log --skip=2465 |
||
commit 44c2f19e380e76b567d114a6360519d66f7a9e24 |
commit 44c2f19e380e76b567d114a6360519d66f7a9e24 |
||
Line 759: | Line 913: | ||
Since the log may show you two close commits, confirm it's the right commit number. If it's off by one, just pick the next commit in the sequence (before or after) and check again. |
Since the log may show you two close commits, confirm it's the right commit number. If it's off by one, just pick the next commit in the sequence (before or after) and check again. |
||
{{Code|code= |
{{Code|lang=text|code= |
||
git rev-list --count 44c2f19e38 |
git rev-list --count 44c2f19e38 |
||
15000 |
15000 |
||
Line 769: | Line 923: | ||
* [https://forum.freecadweb.org/viewtopic.php?f=10&t=31118 Finding the corresponding hash value to a particular commit number] |
* [https://forum.freecadweb.org/viewtopic.php?f=10&t=31118 Finding the corresponding hash value to a particular commit number] |
||
<span id="Revision_number_in_FreeCAD's_interface"></span> |
|||
=== Revision number in FreeCAD's interface === |
|||
=== Revisionsnummer in der FreeCAD Oberfläche === |
|||
Die Versionsnummer, die mit dem [[Std_About/de|Std Über]] Werkzeug angezeigt wird, ist in {{incode|src/Build/Version.h}} definiert, was zur Kompilierzeit erstellt wird, wenn das Werkzeug {{incode|cmake}} ausgeführt wird. Lies [https://forum.freecadweb.org/viewtopic.php?f=4&t=3025 Versionsnummer aus der Git Quelle extrahieren] für weitere Informationen. |
|||
<span id="Adding_other_repositories_(remotes)"></span> |
|||
== Adding other repositories (remotes) == |
|||
== Hinzufügen weiterer (Fern) Repositorien == |
|||
Mehrere Mitarbeiter des FreeCAD Projekts haben ihre eigenen Git Repositorien, in denen sie ihre Arbeit aufbauen oder neue Ideen ausprobieren, bevor sie bereit sind, in den offiziellen Quellcode aufgenommen zu werden. Vielleicht möchtest du ihre Quellen bekommen, um ihren Code selbst zu testen, wenn sie eine Pull Anfrage stellen. |
|||
Several collaborators of the FreeCAD project have their own Git repositories where they build up their work or where they experiment new ideas before they are ready to be included in the official source code. In certain cases you might want to clone your FreeCAD sources from these other repositories to test their code. |
|||
Verwende den Befehl {{incode|git fern}} Befehl, um diese anderen Repositorien hinzuzufügen, so dass du deren Code {{incode|holen}} und {{incode|abrufen}} kannst. |
|||
{{Code|code= |
{{Code|lang=text|code= |
||
git checkout master |
|||
git remote add other_user other_user_repo_url |
|||
git remote add OTHER_USER OTHER_URL |
|||
git fetch other_user |
|||
git fetch OTHER_USER |
|||
git checkout -b other_user_branch other_user/branch |
|||
git checkout -b OTHER_BRANCH OTHER_USER/OTHER_BRANCH |
|||
}} |
}} |
||
Lass uns zum Beispiel Bernds Fernrepositorium hinzufügen: |
|||
Head to the development section of the [https://forum.freecadweb.org/viewforum.php?f=6 FreeCAD forum] to discuss more about development of new features. See also [[Compiling|Compiling]] for instructions on compiling FreeCAD. |
|||
{{Code|lang=text|code= |
|||
git remote add bernd http://github.com/berndhahnebach/FreeCAD_bhb |
|||
}} |
|||
Der {{incode|git holen}} Befehl lädt die Referenzen von diesem Fernrepositorium herunter. |
|||
{{Code|lang=text|code= |
|||
git fetch bernd |
|||
}} |
|||
Liste alle Zweige in deinem eigenen Repositorium und die von deinen hinzugefügten Fernen auf. Bernds Zweige werden als {{incode|Fern/bernd/<Zweigname>}} angezeigt. |
|||
{{Code|lang=text|code= |
|||
git branch -a |
|||
}} |
|||
Lass uns nun eine zusammenfassende Liste der letzten 10 Commits von bernds {{incode|femdev}} Zweig ansehen. |
|||
{{Code|lang=text|code= |
|||
git log -10 --oneline remotes/bernd/femdev |
|||
}} |
|||
Jetzt können wir den gewünschte Zweig zur Inspektion herausfinden. |
|||
{{Code|lang=text|code= |
|||
git checkout remotes/bernd/femdev |
|||
}} |
|||
Dann können wir einen lokalen Zweig erstellen, der auf dem entfernten Zweig basiert. Diesen lokalen Zweig können wir modifizieren und unseren eigenen Code hinzufügen. |
|||
{{Code|lang=text|code= |
|||
git checkout -b local_branch_name /remotes/bernd/femdev |
|||
}} |
|||
Du kannst den {{incode|git rebase}} des neu erhaltenen Zweigs auf den {{incode|upstream/master}} Zweig umstellen, um sicherzustellen, dass er den neuesten Code verwendet. Wenn es Konflikte gibt, müssen diese an diesem Punkt gelöst werden. |
|||
{{Code|lang=text|code= |
|||
git pull --rebase upstream master |
|||
}} |
|||
Der neue Zweig ist bereit, modifiziert und kompiliert zu werden, wie in [[Compiling/de|Kompilieren]] beschrieben. |
|||
Besuche die Entwicklungsabteilung des [https://forum.freecadweb.org/viewforum.php?f=6 FreeCAD Forum]s, um mehr über die Entwicklung zu erfahren. |
|||
<span id="Further_reading"></span> |
|||
== Weiterführende Literatur == |
== Weiterführende Literatur == |
||
<div class="mw-translate-fuzzy"> |
|||
* [[Developing FreeCAD with GitKraken/de|FreeCAD mit GitKraken entwickeln]], eine Anleitung zur Verwendung einer grafischen Oberfläche mit Git. |
* [[Developing FreeCAD with GitKraken/de|FreeCAD mit GitKraken entwickeln]], eine Anleitung zur Verwendung einer grafischen Oberfläche mit Git. |
||
* [https://wiki.spheredev.org/index.php/Git_for_the_lazy Git für die Faulpelze], eine sehr prägnante Anleitung zu den wichtigsten Befehlen von {incode|git |
* [https://wiki.spheredev.org/index.php/Git_for_the_lazy Git für die Faulpelze], eine sehr prägnante Anleitung zu den wichtigsten Befehlen von {{incode|git}}. |
||
* Das [https://git-scm.com/book Pro Git Buch], ein quelloffenes Buch, das dich über Git lehrt; es ist in elektronischer und gedruckter Version erhältlich. |
* Das [https://git-scm.com/book Pro Git Buch], ein quelloffenes Buch, das dich über Git lehrt; es ist in elektronischer und gedruckter Version erhältlich. |
||
* Der [https://marklodato.github.io/visual-git-guide Visual Git Leitfaden], eine Referenz mit Diagrammen, die die häufigsten Operationen mit Git erklären. |
|||
</div> |
|||
* [https://www.youtube.com/watch?v=HVsySz-h9r4 Git Tutorium für Anfänger: Kommandozeilen Grundlagen], Video von Corey Schafer. |
|||
* [https://www.youtube.com/watch?v=uR6G2v_WsRA Einführung in Git - Kernkonzepte], Video von David Mahler. |
|||
[[Category:Hubs/de]] |
|||
[[Category:Developer Documentation/de]] |
|||
[[Category:Developer Documentation{{#translation:}}]] |
|||
{{clear}} |
{{clear}} |
Latest revision as of 10:50, 13 January 2023
Einführung
Das Hauptwerkzeug zur Quellcodeverwaltung für das FreeCAD-Projekt ist Git, das in den meisten Betriebssystemen einfach über einen Paketmanager oder direkt von der Website von Git installiert werden kann. Es wird empfohlen, sich mit Git vertraut zu machen, bevor man direkt mit dem FreeCAD-Quellcode arbeitet. Auf der Seite Git Dokumentation findet man das Referenzhandbuch sowie das Pro Git Book (beide engl.), um zu lernen, wie das System im Allgemeinen genutzt wird. Das vorliegende Dokument konzentriert sich auf die Verwendung von Git für die FreeCAD-Entwicklung. Die Zusammenstellung von FreeCAD ist unter Kompilieren beschrieben.
Während Git in erster Linie eine Terminalanwendung ist, gibt es viele grafische Anwendungen, die die Arbeit mit Zweigen, das Anwenden von Patches und das Senden von Pull-Anfragen an einen Master-Zweig erleichtern. Beispiele sind gitk (die erste entwickelte grafische Benutzeroberfläche),gitg (Gnome),qgit (Qt), tig (Ncurses), git-cola und GitKraken (proprietär). Eine kurze Einführung in dieses Werkzeug findet man unter Entwicklung von FreeCAD mit GitKraken.
Hinweis: Wenn dir davon schwindelig wird, gibt es eine sehr gute nicht-technische Serie über die Verwendung von Git und Github mit dem Titel 'Git und Github für Dichter'.
Quellcodezugang
Jeder kann auf den FreeCAD-Quellcode zugreifen und eine Kopie davon bekommen, aber nur die FreeCAD-Projektmanager haben Schreibzugriff darauf. Du kannst eine Kopie des Codes erhalten, ihn studieren und nach Belieben ändern, aber wenn du möchtest, dass deine Änderungen in den offiziellen Quellcode aufgenommen werden, musst du eine "Pull-Anfrage" gegen das Haupt-Repositorium durchführen, damit deine Änderungen von den Verwaltern überprüft werden können. Diese Art der Entwicklung ist bekannt als der Dictator and Lieutenants Workflow, da die Kern-Entwickler (Diktatoren) und betrauten Entwickler (Leutnante) den Code filtern, der von unabhängigen Entwicklern und Benutzern eingereicht wird.
Wenn deine Quellcode-Änderungen signifikant sind, empfehlen wir dir, sie im Pull-Request Abschnitt des FreeCAD-Forum zu erklären.
Typischer Arbeitsablauf zur Entwicklung von Code für FreeCAD; jeder kann den Code aus dem Haupt-Repositorium beziehen, aber die Hauptentwickler haben das exklusive Recht, Eingaben anderer Entwickler zu überprüfen und zusammenzuführen.
Offizieller GitHub-Ablageordner (Repository)
Der FreeCAD-Quellcode wird in Github bereitgestellt, https://github.com/FreeCAD/FreeCAD
Um Code beitragen zu können, wird ein GitHub-Konto benötigt.
In der Vergangenheit wurde der Quellcode in einem SVN-Repositorium bereitgestellt, https://free-cad.svn.sourceforge.net/svnroot/free-cad
. Dieser wurde am 10. Oktober 2011 mit commit 120ca87015 nach GitHub verschoben.
- Daher gibt es viele Änderungen, die vor dieser Zeit vorgenommen wurden, die nicht in der modernen Git-Commit-Geschichte aufgezeichnet sind. Lies mehr dazu auf der Seite Geschichte.
Setzen des Git-Benutzernamens
Entwickler sollten Code in ihr persönliches Projektarchiv mit ihrem GitHub-Benutzernamen eintragen. Wenn dieser nicht bereits global gesetzt ist, kann er lokal für das aktuelle Git-Projektarchiv wie folgt gesetzt werden:
git config user.name "YOUR_NAME"
git config user.email GITHUB_USERNAME@users.noreply.github.com
Wobei "YOUR_NAME"
deinen vollständigen Namen oder Spitznamen darstellt, der zur Identifizierung des Autors eines bestimmten Beitrags verwendet wird, und GITHUB_USERNAME
den Namen deines Accounts auf GitHub angibt.
Ferne Projektarchive (Remote repositories)
Bitte lies Was ist der Unterschied zwischen Ursprung und Upstream auf GitHub? (Stackoverflow) um den Unterschied zwischen origin
und upstream
im Kontext von Git zu verstehen. Dieser Abschnitt erklärt, wie man die richtigen Ablageorte/Projektarchive für die Entwicklung festlegt.
Im Wesentlichen:
origin
ist deine persönliche Abzweigung des offiziellen FreeCAD-Projektarchivs, alsohttps://github.com/GITHUB_USERNAME/FreeCAD
upstream
ist der offizielle FreeCAD-Ablageort, d.h.https://github.com/FreeCAD/FreeCAD
Diese Unterscheidung ist wichtig, da du zuerst Code in deine eigene Kopie des Projektarchivs schreiben solltest, bevor du diese Änderungen in das offizielle Projektarchiv schreibst.
Basierend auf dem oben genannten, gibt es zwei Möglichkeiten, deine Git-Entwicklungsumgebung einzurichten:
- 1. Methode: Auf GitHub verzweigen und den eigenen Zweig lokal klonen.
- 2. Methode: FreeCAD direkt auf den eigenen lokalen Rechner klonen und die fernen Server anpassen.
Wir empfehlen die 1. Methode, weil sie einen Schritt schneller ist.
1. Methode: Auf GitHub verzweigen und den eigenen Zweig lokal klonen
Zuerst teile das FreeCAD Repositorium in GitHub ab, dann klone diese persönliche Abspaltung auf deinen Computer, und schließlich lege das upstream
Repositorium fest.
- Anmelden auf dein GitHub Konto.
- Gehe zum offiziellen FreeCAD Repositorium:
https://github.com/FreeCAD/FreeCAD
- Drücke oben rechts auf der Seite die Taste "Fork". Dadurch wird eine persönliche Kopie des FreeCAD Repositoriums unter deinem GitHub Benutzernamen erstellt:
https://github.com/GITHUB_USERNAME/FreeCAD
- Klone auf deinem Rechner deine neu erstellte FreeCAD Fork. Er wird in einem Verzeichnis
freecad-source
erstellt.
git clone https://github.com/GITHUB_USERNAME/FreeCAD.git freecad-source
- Sobald der Download abgeschlossen ist, gib das neue Quellverzeichnis ein und lege das
upstream
Repositorium fest.
cd freecad-source
git remote add upstream https://github.com/FreeCAD/FreeCAD.git
- Bestätige deine Fernrepositorien mit
git remote -v
; die Ausgabe sollte ähnlich wie diese sein
origin https://github.com/GITHUB_USERNAME/FreeCAD.git (fetch)
origin https://github.com/GITHUB_USERNAME/FreeCAD.git (push)
upstream https://github.com/FreeCAD/FreeCAD.git (fetch)
upstream https://github.com/FreeCAD/FreeCAD.git (push)
- Jetzt kann die Entwicklung beginnen.
2. Methode: FreeCAD direkt auf den eigenen lokalen Rechner klonen
Zuerst wirst du das FreeCAD Repositorium in GitHub abspalten (engl.:fork ‚Gabel‘), jedoch wirst du das ursprüngliche FreeCAD Repositorium auf deinen lokalen Rechner klonen und dann deine Fernbedienungen über das Terminal ändern.
- Anmelden auf dein GitHub Konto.
- Gehe zum offiziellen FreeCAD Repositorium:
https://github.com/FreeCAD/FreeCAD
- Klicke oben rechts auf der Seite auf die "Fork" Schaltfläche. Dadurch wird eine persönliche Kopie des FreeCAD Repositoriums unter deinem GitHub Benutzernamen erstellt:
https://github.com/GITHUB_USERNAME/FreeCAD
- Klone das ursprüngliche FreeCAD Repositorium. Es wird in einem Verzeichnis
freecad-source
erstellt.
git clone https://github.com/FreeCAD/FreeCAD.git freecad-source
- Sobald das Herunterladen abgeschlossen ist, gib das neue Quellverzeichnis ein und lege das
Ursprung
s Repositorium fest.
cd freecad-source
git remote add origin https://github.com/GITHUB_USERNAME/FreeCAD.git
- Richte dann das
upstream
Repositorium ein.
git remote add upstream https://github.com/FreeCAD/FreeCAD.git
- Bestätige deine Fernrepositorien mit
git remote -v
; die Ausgabe sollte ähnlich wie diese sein
origin https://github.com/GITHUB_USERNAME/FreeCAD.git (fetch)
origin https://github.com/GITHUB_USERNAME/FreeCAD.git (push)
upstream https://github.com/FreeCAD/FreeCAD.git (fetch)
upstream https://github.com/FreeCAD/FreeCAD.git (push)
- Jetzt kann die Entwicklung beginnen.
Wenn die Fernrepositorien aus irgendeinem Grund zwar existieren, aber auf die falsche Adresse verweisen, kannst du die Situation durch Umbenennen des Namens des entfernten Repositoriums beheben. Beispielsweise sollte Ursprung
auf deine persönliche Abspaltung zeigen; wenn er auf das ursprüngliche FreeCAD Repositorium zeigt, ändere den Namen dieses Fernrepositoriums in upstream
und füge das Ursprung
s Repositorium manuell hinzu.
git remote rename origin upstream
git remote add origin https://github.com/GITHUB_USERNAME/FreeCAD.git
git remote -v
Du kannst auch weitere Informationen mit dem Schlüsselwort anzeigen
anzeigen.
git remote show origin
git remote show upstream
Git-Entwicklungsprozess
Generischer Arbeitsablauf zur Entwicklung von Code für FreeCAD unter Verwendung von git
; das Haupt Repositorium wird online gespalten und auf einen Offline Rechner geklont (0); neue Zweige (1) werden verwendet, um lokale Änderungen und Ergänzungen des Codes zu übergeben (2); die Zweige werden auf den neuesten Online Code zurückgeführt (3), und dann zum entfernten Repositorium geschoben (4); dann wird eine Pull Anfrage erstellt, um den Code in das Haupt Repositorium einzufügen (5). Dann wird der persönliche Klon mit dem neuen Mastercode aktualisiert (a); dieser aktualisierte Mastercode wird ebenfalls an das Fernrepositorium (b) geschickt, um denselben Code sowohl online als auch offline zu haben.
Verzweigung
Anstatt an der Masterversion des Codes zu arbeiten, empfiehlt die bewährte Methode mit Git die Erstellung eines neuen Zweiges, wann immer du an einer neuen Funktion arbeiten willst. Zweige sind kostengünstig, sie kopieren nicht den gesamten Quellcode Baum, sondern erzeugen lediglich einen Zeitpunkt, an dem Sie Code schreiben werden; daher helfen Zweige dabei, die laufende Arbeit vom Hauptcode getrennt zu halten.
Die Verwendung eines neuen Zweigs erfolgt in zwei Schritten: Zuerst erstellest du den Zweig, und dann wechselst du zu ihm:
git branch myNewBranch
git checkout myNewBranch
Führe alternativ beide Schritte mit einer einzigen Anweisung aus:
git checkout -b myNewBranch
Jetzt kannst du Zweige mit checkout
ändern, wann immer du daran arbeiten musst. Um die Zweige in deinem Projekt und dem aktuellen Zweig zu sehen, verwende die Operation branch
allein oder füge -v
oder -vv
für weitere Informationen hinzu:
git branch
git branch -vv
Nachdem du Änderungen vorgenommen und diese Änderungen übertragen hast, verwende die Operation log
mit den folgenden Optionen, um die Zweige zu visualisieren
git log --oneline --decorate --graph --all
Übergeben
Sobald du dich in einem neuen Zweig befindest, bearbeite die gewünschten Quelldateien mit einem Texteditor. Um zu sehen, welche Dateien geändert wurden, verwende die Operationen status
und diff
; wenn du mit den Änderungen zufrieden bist, speichere die Änderungen mit der Operation commit
:
git status
git diff
git commit -a
Anders als bei SVN muss man ausdrücklich angeben, welche Dateien übergeben werden; mit der Option -a
werden alle geänderten Dateien gespeichert. Der voreingestellte Texteditor, z.B. nano
oder vim
, wird zum Verfassen einer Überabemitteilung geöffnet.
Alternativ fügt man die Mitteilung der Übergabeanweisung hinzu:
git commit -a -m "Fix the bug in the clone function."
Werden neue Dateien oder Verzeichnisse erstellt, muss zuerst die Aktion add
ausgeführt werden, die sie zum lokalen Projektarchiv hinzufügt, bevor die Änderungen übergeben werden.
git add path
git commit -a
Wobei path
eine beliebige Datei oder ein beliebiges Verzeichnis sein kann.
Gute Übergabemitteilungen schreiben
You should try to work in small steps, that is, commit often, after a small addition in your code. If you cannot summarize your changes in one sentence, then it has probably been too long since you made a commit.
For big changes, it is important that you have helpful and useful descriptions of your work. FreeCAD has adopted a format mentioned in the Pro Git book, which consists of a short message, and then a larger descriptive paragraph.
Short (50 chars or less) summary of changes
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded by a
single space, with blank lines in between, but conventions vary here
If you are doing a lot of related work in a branch, you should make many small commits (see a forum post). When you want to merge those changes into the master branch, you should issue
git log master..myNewBranch
um die einzelnen Übergabe Meldungen zu sehen. Dann kannst du eine Nachricht von hoher Qualität schreiben, wenn eine Zusammenführung durchgeführt wird.
When you merge to master use the --squash
option and commit with your quality commit message. This will allow you to be very liberal with your commits and help to provide a good level of detail in commit messages without so many distinct descriptions.
Squashing commits
Squashing refers to the process of combining various consecutive commits into one. This may be desirable if you made many small commits that you want to present as a single commit, for example, when changing a single variable, correcting spelling mistakes, and adjusting the spacing of the code. You should squash only small commits to a single file; big changes to the code across multiple files should contain the full commit history.
With git log --oneline
you can see many commits in sequence, with the newest commit on top. In this example, starting from "feature A" many commits are made to implement "feature B"; we would like to squash all commits belonging to "feature B" into one.
871adb OK, feature B is fully implemented
1c3317 Whoops, it is not ready yet...
87871a I'm almost ready!
643d0e Code cleanup
af2581 Fix this and that
4e9baa Good implementation
d94e78 Prepare the module for feature B
6394da Feature A
Use the rebase
operation with the --interactive
or -i
option to select various commits and squash them. Use the hash of the commit just before the first one that you want to squash, in this case the one corresponding to "feature A".
git rebase -i 6394da
(TIP: If you know how many commits you want to edit, you can use git rebase -i HEAD~n
to work on the last n
commits)
The command line editor, like nano
or vim
, will open to show you the commits again, now with the older commit on top. Before each commit, the word pick
will be shown. Delete the word pick
, and write the word squash
or just the letter s
instead, with the exception of the first entry; this commit is the oldest one, so all future commits will be squashed into it.
pick d94e78 Prepare the module for feature B
s 4e9baa Good implementation
s af2581 Fix this and that
s 643d0e Code cleanup
s 87871a I'm almost ready!
s 1c3317 Whoops, it is not ready yet...
s 871adb OK, feature B is fully implemented
Save the file and close the editor.
The editor will open up again. Now you can add a longer message that describes all changes as if they were a single commit. Save the file and close the editor once more. This will finish combining those commits into one, with the new commit message that you wrote.
You can use git log --oneline
again to observe the new commit history. In this case only a single commit for "feature B" will appear, on top of the unmodified commit for "feature A".
c83d67 OK, feature B is fully implemented now, with proper module setup, and clean code.
6394da Feature A
When coding for FreeCAD, we ask that you begin each commit message with the module that it affects. For example, a commit message for a change to sketcher might be:
Sketcher: make straight lines curve a bit Straight lines are sort of ugly, so this commit adds a little bit of curvature to them, so they are more visually pleasing. They also sparkle some, and change colors over time. Fixes bug #1234.
Your PR will be easier to review, and faster to be merged, if you are careful to use rebase to structure and describe your commits before submitting.
Pushing your work to your GitHub repository
The local branches in your computer aren't automatically synchronized with the remote servers that you have specified as origin
or upstream
(see Remote repositories); you have to explicitly push the branches to the remote servers, for which you must have write access. Once you do this, the branches become public, and available for review by other developers.
For FreeCAD, you should push your local branch to the origin
remote repository, that is, https://github.com/GITHUB_USERNAME/FreeCAD
. You need to enter your username and password every time you push, unless you have set up Credential caching. Please read Pushing commits to a remote repository for more information.
git push origin myNewBranch
When you work with a single branch, you may need to interactively rebase, squash, and fix commits many times. In this case, your branch history will not be simple, and you will not be able to push it to the remote repository. You may get a message like the following, saying that it is not possible to do a "fast-forward" push.
error: failed to push some refs to 'https://github.com/USER/FreeCAD.git'
hint: Updates were rejected because a pushed branch tip is behind its remote
hint: counterpart. Check out this branch and integrate the remote changes
hint: (e.g. 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
In order to finally push your branch to the remote repository you need to "force push" it. This will completely overwrite your remote branch with the actual branch that you have offline.
git push -f origin myNewBranch
The regular developer doesn't have write access to the upstream
repository https://github.com/FreeCAD/FreeCAD
, therefore, you should never push code to this remote server.
Rebasing from upstream
While you work on your own branch, the official FreeCAD code keeps "moving forward" with commits from other developers, and thus starts diverging from the code that you have in your personal fork.
.-----A origin/myNewBranch / -----o-----------Z FreeCAD upstream/master
Therefore, when you are ready to merge your branch to the main FreeCAD repository, you must "rebase" your own copy of the repository, so that it is as close as possible to the official repository. See Git Branching - Rebasing for more information.
git checkout myNewBranch
git pull --rebase upstream master
This will download the code from the master
branch of the upstream
repository (the official FreeCAD source), and will merge it with your current branch (myNewBranch
), so that your changes will appear on top of the latest official code. If nobody modified the same files that you did, then the merge will succeed without problems. If some files were changed at the same time by different people, there may be a conflict that needs to be resolved.
.-----A' origin/myNewBranch / -----o-----------Z FreeCAD upstream/master
To summarize, you need to be in the appropriate branch, rebase the upstream code, and then proceed with the push.
git checkout myNewBranch
git pull --rebase upstream master
git push origin myNewBranch
The pull
operation is equivalent to a fetch
followed by a merge
. When the --rebase
option is used, instead of doing a simple merge
, it runs the rebase
operation.
git pull upstream
git fetch upstream
git merge FETCH_HEAD
git pull --rebase upstream master
git fetch upstream
git rebase master
Merging the branch (pull request)
Once you have committed your changes locally, rebased your branch from the upstream repository, and pushed your branch online, you can initiate a "pull request". A pull request tells the administrators of the official FreeCAD repository that you want to merge the new code in your branch with the official code.
To recap, the development process looks like this:
- Fork FreeCAD and get a local copy of that fork.
- Create a branch on your fork and change to that branch.
- Code! Commit and much or as little as you like, writing good commit messages to keep track of what you are doing.
- When you are satisfied with your work, use
git rebase -i HEAD~n
(where n is the total number of commits you've made) to collapse your commits into a logical set with good commit messages (each message should begin with the name of the module it affects, e.g. "Sketcher: make straight lines curve a bit"). - Use GitHub to submit your code as a "Pull Request (PR)" as described below.
As soon as you push the code to your origin
repository https://github.com/GITHUB_USERNAME/FreeCAD
, GitHub will give you the option of comparing and creating a pull request against the upstream
repository. By pressing Compare & pull request you will open an interface that will allow you to pick which repository is the "base", target of the merge, and which is the "head", your additional code. A quick check will be done by the system telling you if there are no conflicts with the files that you modified; if you worked on files that nobody has touched, your branch will be able to merge cleanly.
GitHub will show you a text editor so you can write a message documenting your changes: this editor will be pre-filled with a welcome message (that you can delete), a checklist (that you should go through), and a reminder to document your change on the wiki when it's accepted. To use the checklist, go through each item in turn and change the [ ]
to [X]
to indicate that you've done that step. GitHub will also display the number of commits in your branch, the number of files that were modified, and a view showing you the differences between the "base" and the "head" so that everybody can immediately see your intended modifications. Double-check these for things like stray blank lines you didn't mean to add, or huge formatting changes that your IDE decided to make behind your back.
base repository: FreeCAD/FreeCAD base: master <---- head repository: GITHUB_USERNAME/FreeCAD compare: myNewBranch
Able to merge. These branches can be automatically merged.
Click Create pull request to proceed. A message will appear indicating that some checks need to be done on the code. This is a system that compiles FreeCAD automatically and runs the unit tests. If the tests pass, the pull request will have a better chance of being merged into the main code, otherwise a report will be made indicating the errors encountered. See FreeCAD pull requests.
Some checks haven’t completed yet * continuous-integration/travis-ci/pr Pending — The Travis CI build is in progress |Required|
If the tests succeed, you will see a message such as the following
All checks have passed
* continuous-integration/travis-ci/pr — The Travis CI build passed |Required|
This branch has no conflicts with the base branch Only those with write access to this repository can merge pull requests.
Now you must wait for the administrators to merge your branch; you will be notified when this happens.
Pull request successfully merged and closed
You’re all set — the GITHUB_USERNAME:myNewBranch branch can be safely deleted.
If you wish, you can also delete your fork of FreeCAD/FreeCAD.
If you wish, you may delete the branch that was just merged, or even your entire FreeCAD fork, as your own code is already included at the end of the master branch.
-----o-----------Z----A' FreeCAD upstream/master
Note: you may continue working (git commit -a
) on the same branch while you wait for merge approval; if you git push
again, a second merge commit will be queued in the same pull request, and another automated test will be done. That is, while your merges aren't yet approved by the administrators, you may keep pushing changes to your origin
repository, and this will queue those commits in the same pull request to the upstream
repository. Using a single pull request to queue many individual commits is often desirable for small changes. For big additions to the source code, you should create another branch, develop your features there, and then submit a separate pull request for this branch.
The pull request interface can be used whenever you want to submit code from your own repositories to another repository in GitHub. You can use it to merge code in the opposite direction as well, from other people's branches to your own, or even between your own branches. In the last case, since you own the branches, the merges can be approved by yourself immediately.
base repository: SomeProject/Some_Software base: master <---- head repository: GITHUB_USERNAME/Some_Software compare: add_new_functions
base repository: GITHUB_USERNAME/FreeCAD base: myNewBranch <---- head repository: FreeCAD/FreeCAD compare: master
base repository: GITHUB_USERNAME/FreeCAD base: myNewBranch <---- head repository: GITHUB_USERNAME/FreeCAD compare: fix-many-bugs-branch
Das GitHub Repositorium auf dem neuesten Stand halten
Once you've forked FreeCAD, your personal repository exists independently from the original. When the original repository has new commits, GitHub will inform you that your personal repository is behind in number of commits:
This branch is 5 commits behind FreeCAD:master.
In similar way, if you created a development branch with new code, GitHub will inform you that this branch is ahead in number of commits; that is, this branch has changes that haven't been merged into the official FreeCAD repository:
This branch is 3 commits ahead of FreeCAD:master.
While developing, both cases are possible, as your own branch may lack commits made by other developers, but include new commits by you:
This branch is 2 commits ahead, 14 commits behind FreeCAD:master.
When developing code it is recommended that you rebase the branch in which you are currently working, as that will put your branch always ahead of the FreeCAD master code.
As for your original master
branch, it will never be automatically updated by GitHub; this is something that you must do yourself. Switch to the master
branch, then pull
from upstream
(which performs a fetch
and merge
), and then push this updated master
branch to your remote origin
repository.
git checkout master
git pull upstream master
git push origin master
After this is done, GitHub will let you know that your are synchronized with the upstream
repository.
This branch is even with FreeCAD:master.
Now that your master
is up to date, you may decide to switch to it, and delete the other branch that you used previously to develop a feature.
git checkout master
git branch -d myNewBranch
To delete the branch in the origin
remote repository, you can use the push
operation. Normally, you push a local branch; this creates a remote branch with the same name as your local branch.
git push origin myNewBranch
However, if you use the notation local_name:remote_name
, the local branch is created in the remote repository under a different name:
git push origin myNewBranch:someRemoteBranch
Daher kannst du den entfernte Fernzweig löschen, indem du einen leeren lokale Zweig schiebst:
git push origin :myNewBranch
git push origin :someRemoteBranch
Now that you only have an up-to-date master
, you can create a new branch, and repeat the steps of changing files, committing, pushing, submitting a pull request, merging, and updating.
git checkout master
git checkout -b anotherBranch
If you don't want to delete your already custom branch, you may force updating it to be equal to the updated master
; then you can do whatever you want with it, including adding more commits and pushing it to the remote origin
repository.
git checkout myNewBranch
git reset --hard master
git push -f origin myNewBranch
Hard resetting a branch like this is usually not needed. In most cases, you want to follow the sequence of creating a new branch, committing changes, pushing those changes, merging the branch, and then deleting the branch.
Erweiterte Git Operationen
Suchen
Some handy tools to help you find what you're looking for:
Dateinamen suchen
Use git ls-files
to search the repository for file that contains a certain string in a filename. The example below will return all instances of the files that contain the 'dxf' in their filenames.
git ls-files *dxf*
Suche nach einer Zeichenkette
Use git grep
to search the repository for file that contains a certain string with the files themselves. The example below will return all instances of the files that contain the 'dxf' within each and every file.
git grep dxf
Auflösen von Zusammenführungskonflikten
Merging branches with git merge
, or rebasing your branch with git rebase
, will occasionally present conflicts, as files may have been modified by another author at the same time. If this happens you should see the changes of both sides, the other author's, and your own, and then make a decision on how to include both sets of changes in the best way possible. This is normally a manual process that cannot be automated; the programmer must understand the code, and decide what code to move, re-write, or drop to solve the conflict.
Sobald ein Konflikt auftritt, kann eine Meldung wie diese erscheinen.
CONFLICT (content): Merge conflict in src/Mod/source_code.py
error: Failed to merge in the changes.
Patch failed at 1234 Some commit message when editing source_code.py
If a specialized diff tool is installed and configured for Git, for example, Gnome's Meld, the conflict can be examined and solved by using the mergetool
operation.
git mergetool
The Meld tool normally displays three columns; the two columns on the sides display the two conflicting files, while the column on the middle displays the new code that will be saved and committed finally. Therefore, this central column should be edited in a way that it integrates the code of both side columns. Once the conflict is solved and the new source code (the central column) is saved, the Meld tool can be closed. Then the merge
or rebase
operation can continue.
git merge --continue
git rebase --continue
For more information on merging and solving conflicts see:
- How merge conflicts are presented with
git merge
. - Basic merge conflicts and Git Tools - Advanced Merging.
- Resolving a merge conflict using the command line.
- External merge and diff tools to use when you encounter a Git conflict.
Änderungen untersuchen
Inspect the history of a single file through various commits with the log
operation:
git log --patch path
Where path
can be any directory or file. Instead of --patch
, also the shorthands -p
or -u
can be used.
Änderungen zwischen zwei Zweigen untersuchen
Inspect the changes between two branches with the log
and diff
operations with the names of the branches:
git log master..myBranch
git diff master..myBranch
The log
operation shows the commits, while diff
shows the actual changes in the files.
Dateien und Verzeichnisse zurücksetzen
If you accidentally made modifications to a file or directory, you may want to completely revert these changes, to get the previous state of the source code.
This can be done quickly using the checkout
operation:
git checkout path
git checkout .
This will restore the path
(a file or a directory) to the state it is at the tip of the branch, discarding changes that haven't been committed. If path
is the single dot .
, it will restore all files in the current directory.
If you have accidentally added files and directories you can use the clean
operation:
git clean -df
This will forcefully delete all files and directories (-df
) that are not being tracked by the repository, that is, those that have not been included previously with the add
operation.
To completely reset the repository, losing all uncommitted modifications, use the reset
operation:
git fetch
git reset --hard FETCH_HEAD
Where FETCH_HEAD
is the the tip of the upstream
repository. Another commit can also be used.
The revert
operation also reverts changes. However, this command does this by adding another commit to the history; in many cases this is not desired.
Beschneiden alter Zweige
If you have committed many branches to the upstream
repository, you may wish to remove these branches from your local system as they have already been merged. The branch in the origin
repository online can be deleted immediately after merging. Then you can remove the local references to that branch, using the --prune
or prune
options to the fetch
and remote
operations.
git fetch --prune origin
git remote prune origin
Schließlich kannst du die Zweige lokal löschen
git branch -D myBranch
It is also a good practice to do garbage collection after a while, by using the gc
operation. This will cleanup unnecessary files, and compress local file revisions, in order to optimize local disk usage of the repository.
git gc
Arbeiten mit Patches
Obwohl Git Ihnen dir erlaubt, verschiedene Code Zweige mit git merge
zusammenzuführen (in deinem Computer) oder einer Pull Anfrage (Fernrepositorium) gibt es Zeiten, in denen es wünschenswert sein kann, einen traditionellen "Patch" zu erstellen, der als Anhang per Email verschickt werden kann. Der folgende Arbeitsablauf erklärt, wie dies zu tun ist.
Patches erstellen
- You should be developing your new code in a secondary branch of your repository, and not in the master branch. So the first step is to make sure you are in the correct branch.
git branch -v
git checkout myBranch
- Now use
git format-patch
against the master branch, and use the--stdout
option to redirect the result to standard output; then redirect the standard output to a file, which for convenience is created above the source code directory.
git format-patch master --stdout > ../myCode.patch
- Eine andere Methode ist
git format-patch HEAD^
git format-patch HEAD~1
The number of circumflex carets ^
or the number 1
indicate the number of commits that should be considered, that is, ^^^
or ~3
will create three patches for three commits.
git format-patch HEAD^
This will create a patch or series of patches with the following naming convention
XXXX-commit-message.patch
where XXXX
is a number from 0000
to 9999
, and the commit message forms the majority of the file name, for example,
0001-fix-ViewProjMatrix-getProjectionMatrix.patch
Patches anwenden
Git can merge patches or diffs. To know more about this process read Applying patches with Git.
Wenn du die Patch Datei bereits in deinem System hast, wende sie einfach an.
git apply myCode.patch
You can use curl
to download a patch from a website, and then apply it through git
.
curl -O https://some.website.org/code/myCode.patch
git apply myCode.patch
Add .diff
or .patch
at the end of the URL of a GitHub commit, pull request, or compare view so that the website shows you the plain text view of that page.
- Regular commit page:
https://github.com/FreeCAD/FreeCAD/commit/c476589652a0f67b544735740e20ff702e8d0621
- Diff page:
https://github.com/FreeCAD/FreeCAD/commit/c476589652a0f67b544735740e20ff702e8d0621.diff
- Patch page:
https://github.com/FreeCAD/FreeCAD/commit/c476589652a0f67b544735740e20ff702e8d0621.patch
You can point curl
to a particular commit patch in the repository, and pipe it directly to git
to apply the patch.
curl https://github.com/FreeCAD/FreeCAD/commit/c476589652a0f67b544735740e20ff702e8d0621.patch | git apply -
Einen Patch rückgängig machen
When you apply a patch you modify some files. However, these modifications aren't permanent until you commit the changes. Therefore, if you want to revert a patch use the following instructions.
This will revert the changes applied, if you still have access to the original patch file.
git apply -R myCode.patch
Alternatively, this will remove non-committed changes to the branch.
git checkout -f
Stashing git commits
Say that you're working on a branch and you find yourself making some modifications to the source that are out of the scope of your current branch; in other words, those changes would be better in another branch instead of the current one. The git stash
command can be used to temporarily store those uncommitted local changes.
git stash
If in the future you want to use those commits, you can "pop" the commits out of the stash, and into your working branch.
git stash pop
Or if you decide that you don't like those saved commits anymore, you may drop the commits from the stash entirely.
git stash drop
You can list multiple stash commits with
git stash list
To learn more, read Useful tricks you might not know about Git stash.
GitHub Anfragen lokal herausfinden
Checkout GitHub pull requests locally
Blaming
Add content from https://forum.freecadweb.org/viewtopic.php?f=23&t=55943&p=481483#p481287
Bisect
git bisect
is a method to find the specific commit that introduced a bug.
You need to find 2 commits:
- A good commit (for example
abcd
) before the system broke. - A bad commit (for example
efgh
) after the system broke.
Then enter this from the terminal:
git bisect start
git bisect good abcd
git bisect bad efgh
Result: git
will check out the mid point between the two commits.
The next step is to build and test the code. If the system works, continue the process by typing:
git bisect good
Repeat the previous step of building the code and testing it.
If the system is broken, type:
git bisect bad
Repeat the previous steps applying good
or bad
depending on the outcome of your tests.
Eventually, git
will tell you that wxyz
is the first bad commit.
Finally, to exit the bisect process, type:
git bisect reset
Note: git bisect
takes a long time if good and bad are far apart.
FreeCAD Revisionsnummer
In contrast to subversion, which uses a consecutive number for its revisions, Git produces SHA-1 hash values with every commit. A hash value is a long alphanumeric string that looks like this
9b3ffef570596e184006287434fba54a4b03ccc3
Letzte Revisionsnummer
To find the latest revision number of a particular branch use the rev-list
operation with the --count
option. Give the name of the branch, remote repository, tag, or a special pointer like HEAD
, to indicate the last commit in that particular object.
git rev-list --count master
git rev-list --count HEAD
git rev-list --count origin
Or browse the repository on GitHub, and read the amount of commits reported in the particular branch.
Revisionsnummer eines bestimmten Commit Hashes
Since the hash is an alphanumeric string it is not very useful to decide if a certain commit is older or newer than another hash. To find the revision number of a particular hash, again use the rev-list
operation; the input can be the full hash, or a partial hash that is unique, usually the first 7 digits are enough.
git rev-list --count ab1520b872821414c6ce4a15fb85d471ac2a2b03
git rev-list --count 9948ee4
Revisions Hash einer bestimmten Commit Nummer
If we have the commit number, say, 15000, and we want to find the corresponding hash, we need to calculate the number of commits since this point until the last commit (HEAD
). First, get the latest commit number.
git rev-list --count HEAD
17465
Then subtract the commit that we want.
17465 - 15000 = 2465
Then use the log
operation to show all commits and hashes. The --skip
option jumps the difference in commits that we calculated so that we go directly to the hash that we are looking for.
git log --skip=2465
commit 44c2f19e380e76b567d114a6360519d66f7a9e24
Since the log may show you two close commits, confirm it's the right commit number. If it's off by one, just pick the next commit in the sequence (before or after) and check again.
git rev-list --count 44c2f19e38
15000
- Show the commits immediately before a particular commit in GitHub: in the address bar of the browser, change the word
commit
tocommits
to show a list. - Finding the revision number of the commit
- Finding the revision number of the commit
- Finding the corresponding hash value to a particular commit number
Revisionsnummer in der FreeCAD Oberfläche
Die Versionsnummer, die mit dem Std Über Werkzeug angezeigt wird, ist in src/Build/Version.h
definiert, was zur Kompilierzeit erstellt wird, wenn das Werkzeug cmake
ausgeführt wird. Lies Versionsnummer aus der Git Quelle extrahieren für weitere Informationen.
Hinzufügen weiterer (Fern) Repositorien
Mehrere Mitarbeiter des FreeCAD Projekts haben ihre eigenen Git Repositorien, in denen sie ihre Arbeit aufbauen oder neue Ideen ausprobieren, bevor sie bereit sind, in den offiziellen Quellcode aufgenommen zu werden. Vielleicht möchtest du ihre Quellen bekommen, um ihren Code selbst zu testen, wenn sie eine Pull Anfrage stellen.
Verwende den Befehl git fern
Befehl, um diese anderen Repositorien hinzuzufügen, so dass du deren Code holen
und abrufen
kannst.
git checkout master
git remote add OTHER_USER OTHER_URL
git fetch OTHER_USER
git checkout -b OTHER_BRANCH OTHER_USER/OTHER_BRANCH
Lass uns zum Beispiel Bernds Fernrepositorium hinzufügen:
git remote add bernd http://github.com/berndhahnebach/FreeCAD_bhb
Der git holen
Befehl lädt die Referenzen von diesem Fernrepositorium herunter.
git fetch bernd
Liste alle Zweige in deinem eigenen Repositorium und die von deinen hinzugefügten Fernen auf. Bernds Zweige werden als Fern/bernd/<Zweigname>
angezeigt.
git branch -a
Lass uns nun eine zusammenfassende Liste der letzten 10 Commits von bernds femdev
Zweig ansehen.
git log -10 --oneline remotes/bernd/femdev
Jetzt können wir den gewünschte Zweig zur Inspektion herausfinden.
git checkout remotes/bernd/femdev
Dann können wir einen lokalen Zweig erstellen, der auf dem entfernten Zweig basiert. Diesen lokalen Zweig können wir modifizieren und unseren eigenen Code hinzufügen.
git checkout -b local_branch_name /remotes/bernd/femdev
Du kannst den git rebase
des neu erhaltenen Zweigs auf den upstream/master
Zweig umstellen, um sicherzustellen, dass er den neuesten Code verwendet. Wenn es Konflikte gibt, müssen diese an diesem Punkt gelöst werden.
git pull --rebase upstream master
Der neue Zweig ist bereit, modifiziert und kompiliert zu werden, wie in Kompilieren beschrieben.
Besuche die Entwicklungsabteilung des FreeCAD Forums, um mehr über die Entwicklung zu erfahren.
Weiterführende Literatur
- FreeCAD mit GitKraken entwickeln, eine Anleitung zur Verwendung einer grafischen Oberfläche mit Git.
- Git für die Faulpelze, eine sehr prägnante Anleitung zu den wichtigsten Befehlen von
git
. - Das Pro Git Buch, ein quelloffenes Buch, das dich über Git lehrt; es ist in elektronischer und gedruckter Version erhältlich.
- Der Visual Git Leitfaden, eine Referenz mit Diagrammen, die die häufigsten Operationen mit Git erklären.
- Git Tutorium für Anfänger: Kommandozeilen Grundlagen, Video von Corey Schafer.
- Einführung in Git - Kernkonzepte, Video von David Mahler.