Skip to main content
We publish frequent updates to our documentation, and translation of this page may still be in progress. For the most current information, please visit the English documentation.

Planen und Nachverfolgen von Arbeiten für dein Team oder Projekt

Die Grundlagen für die Verwendung der Planungs- und Nachverfolgungstools von GitHub zum Verwalten von Arbeiten in einem Team oder Projekt.

Einführung

Du kannst GitHub-Repositorys, -Issues, -Projektboards und andere Tools verwenden, um deine Arbeit zu planen und nachzuverfolgen, unabhängig davon, ob du an einem einzelnen Projekt oder in einem funktionsübergreifenden Team arbeitest.

In diesem Leitfaden erfährst du, wie du ein Repository für die Zusammenarbeit mit einer Gruppe von Personen erstellst und einrichtest, Issuevorlagen erstellst, Issues öffnest und Aufgabenlisten verwendest, um Arbeit aufzugliedern, und ein Projektboard zum Organisieren und Nachverfolgen von Issues einrichtest.

Repository erstellen

Beim Starten neuer Projekte, Initiativen oder Features besteht der erste Schritt darin, ein Repository zu erstellen. Repositorys enthalten alle Dateien deines Projekts und machen einen Ort verfügbar, an dem du mit anderen zusammenarbeiten und deine Arbeit verwalten kannst. Weitere Informationen findest du unter Erstellen eines neuen Repositorys.

Du kannst Repositorys für verschiedene Zwecke basierend auf deinen Anforderungen einrichten. Im Folgenden sind ein paar gängige Anwendungsfälle aufgeführt:

  • Produktrepositorys: Größere Organisationen, die Arbeit und Ziele im Zusammenhang mit bestimmten Produkten nachverfolgen, verfügen gegebenenfalls über mindestens ein Repository, das den Code und andere Dateien enthält. Diese Repositorys können auch für Dokumentation, Berichterstellung hinsichtlich der Produktintegrität oder zukünftige Pläne für das Produkt verwendet werden.
  • Projektrepositorys: Du kannst ein Repository für ein einzelnes Projekt erstellen, an dem du arbeitest, oder für ein Projekt, an dem du mit anderen zusammenarbeitest. Eine Organisation, die die Arbeit für kurzlebige Initiativen oder Projekte nachverfolgt, z. B. ein Beratungsunternehmen, muss über den Sachstand eines Projekts berichten und Projektbeteiligte basierend auf Qualifikationen und Bedürfnissen auf verschiedene Projekten verteilen. Code für das Projekt ist häufig in einem einzigen Repository enthalten.
  • Teamrepositorys: Bei einer Organisation, die Personen in Teams gruppiert und diesen Projekte zuteilt, z. B. im Fall eines Teams für Entwicklertools, kann Code auf viele Repositorys für die verschiedenen nachzuverfolgenden Arbeiten verteilt sein. Hier kann es hilfreich sein, ein teamspezifisches Repository als zentralen Ort zu nutzen, an dem alle Arbeiten nachverfolgt werden, an denen das Team beteiligt ist.
  • Persönliche Repositorys: Du kannst ein persönliches Repository erstellen, um all deine Arbeit an einem zentralen Ort nachzuverfolgen, zukünftige Aufgaben zu planen oder sogar Notizen oder Informationen hinzuzufügen, die du speichern möchtest. Du kannst auch Projektmitarbeiter hinzufügen, wenn du diese Informationen für andere Personen freigeben möchtest.

Du kannst mehrere, separate Repositorys erstellen, wenn du unterschiedliche Zugriffsberechtigungen für den Quellcode und zum Nachverfolgen von Issues und Diskussionen benötigst. Weitere Informationen findest du unter Erstellen eines Repositorys ausschließlich für Issues.

In den folgenden Beispielen in diesem Leitfaden wird ein Beispielrepository mit der Bezeichnung „Project Octocat“ verwendet.

Vermitteln von Repositoryinformationen

Du kannst eine README.md-Datei für dein Repository erstellen, um dein Team oder Projekt einzuführen und wichtige Informationen darüber zu vermitteln. Eine README-Datei ist häufig das erste Element, das ein Benutzer deines Repositorys sehen wird, sodass du auch Informationen darüber bereitstellen kannst, wie Benutzer oder Mitwirkende mit dem Projekt beginnen und wie du dich an das Team wenden kannst. Weitere Informationen findest du unter Informationen zu README-Dateien.

Du kannst auch eine CONTRIBUTING.md-Datei erstellen, die eigens dafür vorgesehen ist, Richtlinien vorzugeben, wie Benutzer oder Mitwirkende Arbeit zum Team oder Projekt beitragen und mit diesem interagieren können, z. B. wie sie ein Issue zur Fehlerkorrektur öffnen oder eine Verbesserung anfordern können. Weitere Informationen findest du unter Festlegen von Richtlinien für Repositorymitwirkende.

README-Beispiel

Zum Einführen des neuen Projekts – „Project Octocat“ – kann eine README.md-Datei erstellt werden.

Erstellen eines README-Beispiels

Issuevorlagen erstellen

Du kannst Issues verwenden, um die verschiedenen Arten von Arbeit nachzuverfolgen, die dein funktionsübergreifendes Team oder Projekt abdeckt, sowie Informationen von Beteiligten außerhalb deines Projekts zu sammeln. Im Folgenden findest du ein paar gängige Anwendungsfälle für Issues.

  • Releasenachverfolgung: Du kannst ein Issue verwenden, um den Fortschritt für ein Release oder die Schritte zum Abschließen eines Starttags nachzuverfolgen.
  • Große Initiativen: Du kannst ein Issue verwenden, um den Fortschritt großer Initiativen oder Projekte nachzuverfolgen und dann eine Verknüpfung zu den kleineren Issues herzustellen.
  • Featureanforderungen: Teams oder Benutzer können Issues erstellen, um eine Verbesserung deines Produkts oder Projekts anzufordern.
  • Fehler: Teams oder Benutzer können Issues erstellen, um einen Fehler zu melden.

Je nach Typ des Repositorys und Projekts, an dem du arbeitest, kannst du bestimmte Arten von Issues gegenüber anderen Arten priorisieren. Nachdem du die häufigsten Issuetypen für dein Team identifiziert hast, kannst du Issuevorlagen für dein Repository erstellen. Issuevorlagen ermöglichen es dir, eine standardisierte Liste von Vorlagen zu erstellen, die Mitwirkende auswählen können, wenn sie ein Issue in deinem Repository öffnen. Weitere Informationen findest du unter Konfigurieren von Issuevorlagen für dein Repository.

Beispiel für eine Issuevorlage

Nachfolgend wird eine Issuevorlage zum Melden eines Fehlers im Projekt „Octocat“ erstellt.

Beispiel für die Erstellung einer Issuevorlage

Nachdem du nun die Issuevorlage für den Fehlerbericht erstellt hast, kannst du diese beim Erstellen eines neuen Issues im Projekt „Octocat“ auswählen.

Beispiel für die Auswahl einer Issuevorlage

Öffnen von Issues und Verwenden von Aufgabenlisten zum Nachverfolgen der Arbeit

Du kannst deine Arbeit organisieren und nachverfolgen, indem du Issues erstellst. Weitere Informationen findest du unter Erstellen eines Issues.

Beispiel für ein Issue

Hier ist ein Beispiel für ein Issue, das für eine große Initiative, Front-End-Arbeit, im Projekt „Octocat“ erstellt wurde.

Beispiel für die Erstellung eines Issues für eine große Initiative

Beispiel für eine Aufgabenliste

Du kannst Aufgabenlisten verwenden, um größere Issues in kleinere Aufgaben aufzuteilen und Issues als Teil eines größeren Ziels nachzuverfolgen. Weitere Informationen findest du unter Informationen zu Aufgabenlisten.

Nachfolgend wurde dem Issue des Projekts „Octocat“ eine Aufgabenliste hinzugefügt, in der das Issue in kleinere Issues unterteilt wurde.

Beispiel für das Hinzufügen einer Aufgabenliste zu einem Issue

Treffen von Entscheidungen als Team

Du kannst Issues und Diskussionen verwenden, um im Team zu kommunizieren und als Team Entscheidungen zu geplanten Verbesserungen oder Prioritäten für dein Projekt zu treffen. Issues sind nützlich, wenn du sie zur Diskussion bestimmter Details erstellst, z. B. für Fehler- oder Leistungsberichte, die Planung für das nächste Quartal oder das Design für eine neue Initiative. Diskussionen sind nützlich für offenes Brainstorming oder Feedback außerhalb der Codebasis und repositoryübergreifend. Weitere Informationen findest du unter Welches Diskussionstool sollte ich verwenden?

Als Team kannst du auch den aktuellen Stand täglicher Aufgaben innerhalb von Issues kommunizieren, damit jeder den Sachstand der Arbeit kennt. Du kannst z. B. ein Issue für ein großes Feature erstellen, an dem mehrere Personen arbeiten, und jedes Teammitglied kann Updates jeweils mit Status oder offenen Fragen in diesem Issue hinzufügen.

Issuebeispiel mit Projektmitarbeitern

Hier ist ein Beispiel für Projektmitarbeiter, die den aktuellen Sachstand ihrer Arbeit an dem Problem des Projekts „Octocat“ mitteilen.

Beispiel für die Zusammenarbeit an einem Issue

Verwenden von Bezeichnungen zum Hervorheben von Projektzielen und -status

Du kannst Bezeichnungen für ein Repository erstellen, um Issues, Pull Requests und Diskussionen zu kategorisieren. GitHub bietet auch Standardbezeichnungen für jedes neue Repository, die du bearbeiten oder löschen kannst. Bezeichnungen sind nützlich zum Nachverfolgen von Projektzielen, Fehlern, Arbeitstypen und Issuestatus.

Weitere Informationen findest du unter Erstellen einer Bezeichnung.

Nachdem du eine Bezeichnung in einem Repository erstellt hast, kannst du diese auf beliebige Issues, Pull Requests oder Diskussionen im Repository anwenden. Anschließend kannst du Issues und Pull Requests nach Bezeichnung filtern, um alle zugeordneten Arbeiten zu ermitteln. Suche beispielsweise nach allen Front-End-Fehlern in deinem Projekt, indem du nach Issues mit den Bezeichnungen front-end und bug filterst. Weitere Informationen findest du unter Filtern und Suchen von Issues und Pull Requests.

Beispiel für Beschriftungen

Nachfolgend findest du ein Beispiel für eine front-end-Bezeichnung, die erstellt und dem Issue hinzugefügt wurde.

Beispiel für das Hinzufügen einer Bezeichnung zu einem Issue

Hinzufügen von Issues zu einem Projektboard

Du kannst die project boards auf GitHub verwenden, um die Arbeit deines Teams zu planen und nachzuverfolgen. Projektboards bestehen aus Issues, Pull Requests und Notizen, die als Karten in Spalten deiner Wahl kategorisiert werden. Du kannst Projektboards für die Arbeit an Features, allgemeine Roadmaps oder sogar Releaseprüflisten erstellen. Weitere Informationen findest du unter Informationen zu Projektboards.

Beispiel für ein Projektboard

Nachfolgend findest du ein Projektboard für das Beispielprojekt „Octocat“ mit dem erstellten Issue und den hinzugefügten kleineren Issues, in die es untergliedert wurde.

Beispiel für ein Projektboard

Nächste Schritte

Du hast jetzt mehr über die Tools erfahren, die GitHub zum Planen und Nachverfolgen deiner Arbeit bietet. Außerdem hast du die ersten Schritte der Einrichtung deines funktionsübergreifenden Team- oder Projektrepositorys ausgeführt. Hier findest du einige hilfreiche Ressourcen, die du nutzen kannst, um das Repository weiter anzupassen und deine Arbeit zu organisieren.