Relacje między rodzicami a dziećmi
Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Narzędzie Google Issue Tracker obsługuje relacje nadrzędne i podrzędne. Relacja nadrzędna–podrzędna jest zwykle używana do reprezentowania podziału pracy w ramach danego projektu. Element nadrzędny może mieć wiele elementów podrzędnych, a element podrzędny może mieć wielu rodziców.
Relacja wydawcy nadrzędnego i podrzędnego ma te cechy:
Cecha |
Szczegóły |
Relacja |
N:N |
Zamawianie |
Obsługiwane jest sortowanie podrzędnych profili w ramach profilu nadrzędnego. |
Wykrywanie cyklu |
System zapobiega tworzeniu pętli zależności. |
Maks. liczba bezpośrednich podkatalogów |
500 |
Maksymalna liczba przodków |
1000 |
Przykłady
Grafika poniżej przedstawia przykładowe relacje nadrzędne i podrzędne.

Relacje między kontami nadrzędnymi i podrzędnymi oraz blokowanie
Istniejące relacje Blokowanie i Zablokowane przez są nadal obsługiwane, gdy używasz relacji nadrzędnych i podrzędnych. Gdy łączysz relacje rodzic-dziecko z blokowaniem:
- Użyj relacji rodzic-dziecko, aby podzielić zadanie na mniejsze jednostki.
- Użyj blokowania i blokowania przez, gdy czas i kolejność są krytyczne, a Ty chcesz wyraźnie wskazać w interfejsie, że należy przekazać pracę, która została przerwana lub nie została rozpoczęta.
Grafika poniżej przedstawia przykłady podziału pracy na zadania nadrzędne i podrzędne oraz blokujące.

Wszelkie prawa zastrzeżone. Java jest zastrzeżonym znakiem towarowym firmy Oracle lub jej podmiotów stowarzyszonych.
Ostatnia aktualizacja: 2025-07-25 UTC.
[null,null,["Ostatnia aktualizacja: 2025-07-25 UTC."],[[["\u003cp\u003eGoogle Issue Tracker enables the creation of parent-child relationships to represent the hierarchical breakdown of work within a project.\u003c/p\u003e\n"],["\u003cp\u003eIssues can have multiple parents and children, but the system prevents circular dependencies and limits the number of direct children to 500 and total ancestors to 1000.\u003c/p\u003e\n"],["\u003cp\u003eWhile parent-child relationships are ideal for structuring tasks, "Blocking" and "Blocked by" relationships should be used to indicate critical timing and sequencing dependencies.\u003c/p\u003e\n"],["\u003cp\u003eUsers are encouraged to leverage both relationship types to manage work effectively, using parent-child for work breakdown and blocking for highlighting time-sensitive dependencies.\u003c/p\u003e\n"]]],[],null,["# Parent-Child Relationships\n\nGoogle Issue Tracker supports parent-child relationships. A parent-child\nrelationship is typically used to represent the breakdown of work within a given\neffort. A parent can have multiple children, and a child can have multiple\nparents.\n\nThe parent-child relationship has the following characteristics:\n\n| Characteristic | Details |\n|-------------------------|----------------------------------------------------|\n| **Relationship** | N:N |\n| **Ordering** | Ordering of children within a parent is supported. |\n| **Cycle detection** | Cyclic dependencies are prevented by the system. |\n| **Max direct children** | 500 |\n| **Max ancestors** | 1000 |\n\nExamples\n--------\n\nThe following graphic shows some sample parent-child relationships.\n\nParent-child relationships and blocking\n---------------------------------------\n\nThe existing **Blocking** and **Blocked by** relationships are still supported\nwhen you use parent-child relationships. When you're combining parent-child\nrelationships with blocking:\n\n- Use **parent-child** relationships to break down work into smaller units.\n- Use **blocking** and **blocked by** when timing and sequence are critical, and you want to provide clear indications in the UI to escalate stopped or not started work.\n\nThe following graphic shows examples of parent-child and blocking work\nbreakdowns."]]