Typos and spellings for chapter 1

[Mo-Gul]

• Vereinheitlichungen/allgemeine Korrekturen
  • Begriffe (wie "Versionsverwaltungssystem")
  • ev. --> evtl.
  • Repositories --> Repositorys
  • die Branch --> der Branch
• Kapitel 1

[max123kl]

Wow, es gibt doch mehr "Schreibfehler" als ich erwartet habe.

Falls du deine ToDo-Liste allein abarbeiten willst, wird das bestimmt eine ganze Weile dauern.
Wie könnten wir die Aufgabe auf mehrere "Schultern" verteilen?

Damit die Änderungen schneller ins Buch übernommen werden, schlage ich vor, dass du deinen PR in ein Issue wandelst und fertige Abschnitte in einem PR referenzierst.
Wie das technisch umzusetzen ist, habe ich selbst leider keine Erfahrung. (Im Repo zur Core-Übersetzung von Joomla wird lt. "contributing guidelines" etwas Ähnliches praktiziert.)

Im englischen Repo ist derzeit außerdem gerade eine PR-Diskussion im Gange, die sich u.a. um das Entfernen der abschließenden Punkte bei Bildunterschriften dreht. Man könnte deshalb folgende Aufgabe noch in die Task-Liste aufnehmen:

• Entfernen der abschließenden Punkte (bei Bildunterschriften)

@pastatopf , @saxc , @cbachhuber – wie ist eure Meinung?

[cbachhuber]

Super Arbeit @Mo-Gul, vielen Dank!

Zu @max123kl's Vorschlägen: die vorgeschlagenen Veränderungen in einem Issue zu tracken, ist der richtige Weg. Andernfalls wird dieser PR irgendwann unmöglich zu reviewen 😅
Zur Vorgehensweise: ich würde diesen PR mergen, und dann die Arbeitsbeschreibung in einen neuen Issue kopieren. Diesen kann man dann von diesem und zukünftigen PRs referenzieren, einfach via e.g. #110. Man sieht dann ja auch im Issue, welche PRs ihn referenzieren.

Das Entfernen der Punkte bei Bildunterschriften kann man in den Issue mit aufnehmen oder separat behandeln, finde beides ok.

[Mo-Gul]

Dieser PR war ein Test, ob/wie euch meine Änderungen gefallen und ich habe auf genau solches Feedback wie die Erstellung eines Issues etc. gehofft. Den Vorschlag nehme ich natürlich gerne an. Werde ihn gleich umsetzen.

Erledigt, siehe issue #111.

[Mo-Gul]

Bezüglich des Entfernens der abschließenden Punkte (bei Bildunterschriften) schlage ich vor, dass dies ein separates Issue wird, weil dies eine Stil-Entscheidung ist und nichts mit Rechtschreibkorrekturen etc. zu tun hat.

[Mo-Gul]

Falls du deine ToDo-Liste allein abarbeiten willst, wird das bestimmt eine ganze Weile dauern.
Wie könnten wir die Aufgabe auf mehrere "Schultern" verteilen?

Wie in meinem Kommentar zum neuen Issue (#111 (comment)) geschrieben, lese ich das Buch, um Git zu lernen. Mal sehen, bis wohin ich komme und wann ich denke, dass ich nur noch Bahnhof verstehe oder ich mir ziemlich sicher bin, dass ich die beschriebenen Dinge einfach nicht brauchen werde. Dann macht es natürlich auch keinen Sinn (für mich) die Kapitel weiter zu lesen.

Gerne können aber natürlich weitere Leute ebenfalls "Korrekturlesen".

[max123kl]

Wie in meinem Kommentar zum neuen Issue (#111 (comment)) geschrieben, lese ich das Buch, um Git zu lernen.

@Mo-Gul
das war genau mein Grund, mich mit dem Buch zu beschäftigen. Da mein "technisches" Wissen leider begrenzt ist, hoffe ich auf die Expertise der anderen Mitautoren.

[Mo-Gul]

Danke fürs Mergen.

Jetzt habe ich noch eine Frage, wie weiter verfahren werden soll: Soll ich die weiteren Änderungen in einem neuen Branch erstellen oder weiter den Typos-and-Spellings-Branch verwenden?

Falls letzteres: Wie bekomme ich denn die schon angenommenen Änderungen in den Branch? Mir wurde schon einmal mitgeteilt, dass ich per

git fetch upstream
git rebase upstream/master
git push origin --force

die Änderungen von dem Haupt-Repository in den Master-Branch meines Forks bekommen kann (werde das gleich mal ausprobieren, falls ihr keinen besseren Vorschlag habt). Aber wie bekomme ich sie von dort -- ohne etwas kaputt zu machen -- in den Branch?

Vielen Dank für den Input.

[cbachhuber]

Üblicherweise lebt ein Branch nur für einen Pull Request. Mein Ablauf sieht wie folgt aus:

# when on master branch with latest changes
git checkout -b my-awesome-branch-with-an-expressive-name
# work on the branch, commit and push. Open PR, get it merged to upstream/master.
git checkout master
git pull upstream master  # assuming upstream is set as the remote repo you forked from
# You're now on master, including latest changes from my-awesome-branch-with-an-expressive-name
git checkout -b new-branch-for-next-work-item
# Repeat until end of time

git pull führt fetch & merge aus. Das muss auf master reichen, ein rebase ist nicht notwendig.

[max123kl]

Ich arbeite vorwiegend mit der GUI "GitHub Desktop" und dem Atom-Editor.
Um das lokale Repo zu aktualisieren habe ich für die Konsole eine ähnliche Befehlskette, wobei bei mir ist:
upstream = <progit/progit2-de> und origin = <mein_geforktes_GithubRepo>

git status -v   # um den Arbeitsbereich zu prüfen
git pull upstream master  
git push origin master

Die "checkouts" erledigt der GitHub Desktop im Hintergrund

Ich habe mir auch (leider) angewöhnt manche Branches (z.B. der Branch, um die englischen Commit zu includen) länger zu behalten und wiederzuverwenden.
Dann ist es aber wichtig, dass dieser Branch auf dem gleichen Versionsstand wie master ist, bevor man neue Arbeiten dort anfängt.
Ich nutze dafür die GUI um master in den <vorhandenen_Branch> zu mergen.
Mit der GUI und Atom komme ich besser zurecht, falls Konflikte auftauchen.