Zweigbeschreibungen in Git

Question

Gibt es in Git eine Möglichkeit, eine "Beschreibung" für Zweige zu haben?

Ich versuche zwar, beschreibende Namen zu verwenden, aber wenn ich eine Zeit lang an einem einzigen Zweig arbeite, kann ich mich manchmal nicht mehr daran erinnern, warum ich einige der anderen Themenzweige erstellt habe. Ich versuche, beschreibende Namen für die Zweige zu verwenden, aber ich denke, eine "Beschreibung" (eine kurze Notiz über den Zweck des Zweigs) wäre schön.

Answer 1

Git 1.7.9 unterstützt dies. Von der 1.7.9 Versionshinweise :

 \* "git branch --edit-description" can be used to add descriptive text
   to explain what a topic branch is about.

Sie können sehen, dass diese Funktion bereits im September 2011 eingeführt wurde, mit den Commits 6f9a332 , 739453a3 , b7200e8 :

struct branch_desc_cb {
  const char *config_name;
  const char *value;
};

--edit-description::

Öffnen Sie einen Editor und bearbeiten Sie den Text, um zu erklären, wozu die Verzweigung dient, damit sie von verschiedenen anderen Befehlen verwendet werden kann (z. B. request-pull ).

Beachten Sie, dass dies bei einem abgetrennten HEAD-Zweig nicht funktioniert.

Diese Beschreibung wird von dem Skript request-pull verwendet: siehe Übergabe c016814783 , sondern auch git merge --log .

request-pull ist ein Skript, das die Änderungen zwischen zwei Commits auf der Standardausgabe zusammenfasst und die angegebene URL in die generierte Zusammenfassung einbezieht.

[Von @AchalDave] Leider kann man keine Beschreibungen pushen, da sie in der Konfiguration gespeichert sind, was es für die Dokumentation von Zweigen in einem Team nutzlos macht.

Answer 2

Verwenden Sie git branch --edit-description um eine Zweigbeschreibung festzulegen oder zu bearbeiten.

Hier ist eine Shell-Funktion, die Verzweigungen anzeigt, ähnlich wie git branch aber mit angehängten Beschreibungen.

# Shows branches with descriptions
function gb() {
  current=$(git rev-parse --abbrev-ref HEAD)
  branches=$(git for-each-ref --format='%(refname)' refs/heads/ | sed 's|refs/heads/||')
  for branch in $branches; do
    desc=$(git config branch.$branch.description)
    if [ $branch == $current ]; then
      branch="* \033[0;32m$branch\033[0m"
     else
       branch="  $branch"
     fi
     echo -e "$branch \033[0;36m$desc\033[0m"
  done
}

Hier ist, was gb sieht aus, hier als Text, falls das Bild verrottet:

$ gb
* logging Log order details.  Waiting for clarification from business.
  master 
  sprocket Adding sprockets to the parts list.  Pending QA approval.

Und als Bild, damit Sie die Farben sehen können:

Answer 3

Wenn Sie tun am Ende die README verwenden, erstellen Sie eine Git-Alias Ändern von git checkout so dass Ihr README jedes Mal angezeigt wird, wenn Sie den Zweig wechseln.

Fügen Sie zum Beispiel Folgendes in ~/.gitconfig ein, und zwar unter [alias]

cor = !sh -c 'git checkout $1 && cat README' -

Danach können Sie Folgendes ausführen git cor <branch_name> Verzweigung zu wechseln y die README des Zweigs anzeigen, zu dem Sie wechseln.

Answer 4

El README vorgeschlagen von Chris J kann funktionieren, vorausgesetzt, es wird mit einer benutzerdefinierten Merge-Treiber, der in einem .gitattribute .
Auf diese Weise kann die . Version des README wird beim Zusammenführen immer beibehalten.

Die "Beschreibung" für Zweige wird auch als "Kommentar" bezeichnet, der mit diesen Metadaten verknüpft ist, und sie wird nicht unterstützt.

Zumindest mit einer README Datei können Sie für jeden Zweig eine:

$ git show myBranch:README

Wenn sich Ihr README im Stammverzeichnis Ihres REPO befindet, funktioniert es von jedem Pfad aus, da der Pfad, der von git show ist ein absolutes Verzeichnis aus dem obersten Verzeichnis des Repo.

Answer 5

Hier gibt es zwei beliebte Vorschläge:

1. git branch --edit-description : Wir mögen das nicht, weil man es nicht verschieben kann. Vielleicht kann ich mich noch daran erinnern, was die von mir erstellten Zweige tun, aber mein Team kann es sicher nicht.
2. README Datei pr. Zweig. Dies ist eine Qual beim Zusammenführen: Sehr anfällig für Merge-Konflikte, und wir werden in README von Zweigen, wenn wir Feature-Zweige zusammenführen. Unterschiede zwischen Zweigen sind ebenfalls ein Problem.

Wir haben beschlossen, ein Waisenhaus zu schaffen. branches-readme Branche. Verwaiste Zweige sind Zweige mit einer eigenen Historie - Sie kennen sie vielleicht von Github's gh-pages Zweige. Dieser verwaiste Zweig enthält einen einzigen README Datei. Sie hat Inhalte wie:

master:
    The default branch
mojolicious:
    Start using Mojolicious
branch-whatever:
    Description of the whatever branch

Sie ist verschiebbar und zusammenführbar. Ansicht der README aus jeder Verzweigung mit:

git show branches-readme:README

Der Nachteil ist, dass Sie den verwaisten Zweig auschecken müssen, wenn Sie die Software aktualisieren wollen. README und die README wird nicht automatisch aktualisiert, wenn Zweige umbenannt werden, kommen oder gehen. Für uns ist das aber in Ordnung.

Mach es wie:

git checkout --orphan branches-readme
# All the files from the old branch are marked for addition - skip that
git reset --hard
# There are no files yet - an empty branch
ls
vi README
# put in contents similar to above
git add README
git commit -m "Initial description of the branches we already have"
git push origin branches-readme
# get all your original files back
git checkout master

Ebenso können auch einzelne Teammitglieder ihre eigenen branches-$user verwaiste Zweigstellen, die ihre eigenen privaten Zweigstellen beschreiben, solange sie diese nicht an das Team weitergeben.

Mit weiteren Werkzeugen könnte dies auch in die Ausgabe von git branch . Zu diesem Zweck sollte vielleicht ein README.yaml Datei könnte anstelle einer einfachen README .