Machen das nicht alle so? Shortcuts für die wichtigsten git Befehle erstellen

Wieder einmal ist mir aufgefallen, dass es wohl je nach Mensch einen unterschiedlichen Grad an persönlicher Faulheit gibt 🙂 Ich selbst bin zugegebenermaßen dann sehr faul, wenn es um stupide und sich wiederholende Tätigkeiten geht. Da schwindet meine Motivation dermaßen, dass ich meist sehr schnell eine Möglichkeit finde, diese Aufgaben so weit wie möglich zu automatisieren oder zu vereinfachen.

Eine solche Tätigkeit ist der Umgang mit dem Sourcecode Verwaltungsoftware – bei mir meist git. V.a. in einem agilen Umfeld (heute wird ja meist mit Scrum o.ä.) gearbeitet, wird häufig committed, gepushed oder mal die History angesehen. Da ich gerne an der Shell arbeite, gibt es in meiner .bashrc neben diversen anderen Shortcuts eine ganze Reihe an Git Befehlen die ich häufig verwende:

  • alias gs=’git status‘
  • alias gc=’git checkout‘
  • alias gl=’git log –stat‘
  • alias gd=’git diff‘
  • ….

Das kann ich jedem nur empfehlen, zumindest wenn nicht mit einem graphischen Tool gearbeitet wird. Wobei aus meiner Sicht, für viele Aufgaben die gitbash o.ä. sogar schneller zu bedienen ist und einen höheren Grad an Kontrolle als die meisten Tools bietet. V.a. dann wenn man sie auf die oben beschriebene Art an die persönlichen Vorlieben anpasst.

 

Veröffentlicht unter Uncategorized | Hinterlasse einen Kommentar

Debugging – machen das nicht alle so?

Als ich in meinem aktuellen Projekt einen Fehler nicht beheben konnte und mir leider auch die Rechte fehlten um auf das entsprechende Apache Logfile zuzugreifen war ich nach einer kurzen Diskussion, wie man das Problem angeht, verwundert. Ich dachte ja, das alle Entwickler so etwas ähnlich angehen:

  1. Versuchen Zugriff auf alle Logfiles zu bekommen und sinnvolle Logmeldungen einbauen bzw. einen Debugger zu nutzen –
    Das hat in diesem Fall ja leider nicht geklappt 🙁
  2. Dann eben „Old-School“ Debugging:
    1. Ich suche mir eine Stelle vermutlich nahe genug am Fehler liegt, aber noch erreicht wird sollte das Programm sich , wie in diesem Fall, mit einem HTTP 500 Fehler verabschieden
    2. Je nach Programmiersprache ein exit, throw Exception, die um einen 500er Fehler auszulösen. Und eine irgendwie hilfreiche Ausgabe zu erzeugen
    3. Je nachdem ob die Stelle erreicht wird die meine Debugzeile sinnvoll vor oder zurückschieben
    4. Als ich dann die Stelle eingegrenzt hatte, konnte ich die Ursache recht schnell mit der Ausgabe einiger Variablen feststellen und beheben.
  3. Eine weitere Methode die ich gerne anwende, wenn kein vernünftiges Debugging Tool verfügbar ist bzw. um die Fehlerstelle schnell und einfach einzugrenzen:
    1. Großzügig Sourcecode (ca. die Hälfte, wie bei einer Binärsuche 🙂 ) entfernen und testen, ob der Fehler noch auftritt.
    2. Falls ja, mehr Sourcecode entfernen
    3. Falls nein, etwas weniger bzw einen Teil des entfernten Codes wiederherstellen

Mit den beiden Methoden komme ich meist recht schnell zum Ziel, wenn es keine „normale“ Debugging Möglichkeit gibt.

Veröffentlicht unter Uncategorized | Hinterlasse einen Kommentar

git log im svn style

Nachdem in einer Schulung die Frage gestellt wurde und ich die git History selbst gerne so anzeigen lassen:

Für alle die gerne die git log ähnlich wie svn log -v inkl. der geänderten Dateien ansehen möchten, ist das der richtige Befehl

  • git log –stat
Veröffentlicht unter Uncategorized | Hinterlasse einen Kommentar