github projects teams
Цей підручник з GitHub пояснює такі поняття, як проекти GitHub, організація та команди, розгалуження сховища, проблеми та етапи проекту, GitHub Wiki тощо:
У попередньому навчальному посібнику з серії підручників на GitHub ми побачили, як розробник може використовувати платформу для зберігання пов'язаних з проектом артефактів та контролю версій. Ми також бачили концепції навколо запитів Pull, об’єднання, розгалуження та захисту гілок.
Ну, це ще не все. У цьому підручнику ми розберемося глибше і з’ясуємо, що ще GitHub може зробити для розробників.
=> Ознайомтесь з Ідеальним навчальним посібником GitHub тут.
Ось на чому ми зупинимось.
- Створіть організацію та команди
- Розкрийте сховище
- Створюйте випуски та етапи проекту
- Створіть дошку проекту
- Створення вікі GitHub
Що ви дізнаєтесь:
- Створіть організацію та команди
- Форк GitHub
- Проблеми GitHub та етапи проекту
- Правління проекту GitHub
- GitHub Wiki для документації
- Висновок
- Рекомендована література
Створіть організацію та команди
Як попередній курсор до цього розділу, GitHub пропонує наступні 3 типи облікових записів.
- Особисті облікові записи користувачів де ви можете створювати необмежену кількість публічних та приватних сховищ, а також запрошувати співавторів.
- Рахунки організації що є насамперед концепцією спільних облікових записів, і ми побачимо більше в цьому розділі.
- Обліковий запис підприємства який використовується компаніями, які внутрішньо керують політиками для користувачів, що використовують GitHub. Зазвичай це використовується в локальній версії GitHub Enterprise.
У першій частині ми побачили, як було створено сховище з використанням одного єдиного особистого облікового запису, де цей користувач був єдиним власником сховища. Це підходить для невеликих скрут-команд, де у вас від 3 до 9 людей або, можливо, ще кілька людей, або створити сховище для одного проекту - це нормально.
Але що, якщо для виконання існують великі проекти Github, які потребують декількох сховищ і декількох команд для того самого доступу? Тут нам потрібно розглянути, як GitHub Organization допомагає у групуванні декількох сховищ для одного великого проекту. Таким чином, також буде декілька власників, оскільки залучено кілька сховищ / команд.
Щоб розпочати створення нової організації, натисніть на + угорі праворуч і виберіть Нова організація.
Відповідно виберіть план. На даний момент ми будемо використовувати безкоштовний план, який є Команда з відкритим кодом.
Введіть деталі про Організацію, а потім натисніть Далі.
Додайте учасників до організації та натисніть на Завершіть налаштування.
Наступним кроком є початок створення сховищ відповідно до потреб проекту та додавання команд до них.
Ви також можете натиснути на Запросіть когось додати учасників до щойно створеної організації. У міру додавання учасників роль також може бути призначена як учасник або власник. Для цього перейдіть до Люди Вкладку та виберіть Зміна ролі для цього члена.
Ну, наразі ми збережемо 1 користувача як Власника, а іншого як члена. Таким чином, Власник може створити кілька сховищ і призначити команди відповідним сховищам.
Перш ніж створювати сховища, давайте спочатку створимо команди. Перейдіть до Команди та натисніть на Нова команда.
Ми створимо 2 команди, тобто команду інтерфейсу користувача та команду проміжного програмного забезпечення.
Натисніть на Створити команду. Після створення команди ви можете додати членів до команди, як показано нижче.
Подібним чином створіть іншу команду та додайте до неї членів. Тепер ви бачите, що є 2 команди.
Приступимо до створення сховищ. Отже, як сценарій, зараз ми створимо 2 сховища тобто один для зберігання коду, пов’язаного з користувацьким інтерфейсом, а інший для зберігання коду проміжного програмного забезпечення. Команди будуть розподілені відповідно.
Перейдіть до Сховища та створіть файл Нове сховище .
Клацніть на Створити сховище кнопку. Далі - забезпечити доступ команди інтерфейсу до сховища.
Перейдіть до Команди вкладку. Клацніть на Команда інтерфейсу користувача і перейдіть до Сховища вкладку. Клацніть на кожну команду та знову додайте сховища з Сховища вкладку.
Додайте сховище, ввівши ім’я сховища.
Також переконайтесь Напишіть дозвіл для членів команди до цього сховища, тобто члени команди можуть читати, клонувати та натискати на це сховище.
Аналогічним чином виконайте наведені вище дії, щоб додати сховище Middleware до іншої команди. Таким чином, зараз у нас є Організація з репозиторіями всередині неї та командами також. Члени команди можуть клонувати сховище, до якого вони мають доступ, і працювати над ним.
Форк GitHub
Розкрийте сховище та синхронізуйте його з оригінальним сховищем.
У попередніх розділах та попередньому підручнику ми бачили, як створюються сховища та додається до них вихідний код. А що, якби команди хотіли протестувати деякі зміни коду, коли оригінальному сховищу не місце це робити.
Потрібно створити копію, щоб експериментувати з будь-якими змінами в коді, зберігаючи непорушним оригінальне сховище. Це називається GitHub Виделка . Щоб створити Fork, перейдіть до сховища, яке було створено в особистому кабінеті, а не в організації. Натисніть на Виделка вгорі праворуч.
Виберіть обліковий запис, для якого потрібно розгалужити вихідне сховище. У цьому випадку виберіть обліковий запис організації, де сховище буде розгалужено.
Зараз сховище роздвоєне як Demo-Proj-Org / Demo_Project_Repo_VN . Отже, будь-які експерименти з кодом можна проводити у розгалуженому сховищі, а не в оригінальному сховищі.
Якщо в оригінальному сховищі були внесені будь-які зміни, то роздвоєне сховище має бути в синхронізація . Параметри командного рядка можуть бути використані для синхронізації розгалуженого сховища, але створення запиту на витяг - простіший варіант.
Якщо припустити, що у файлі зроблено зміни у вихідному сховищі, перейдіть до створення запиту на витягування.
Клацніть на посилання порівняти по вилках.
Виберіть головку як оригінальне сховище, а основу - як розгалужене сховище, як показано і натисніть на Створити запит на витягування.
Натисніть на Запит на злиття та підтвердження об’єднання.
Зміни з’являються у розгалуженому сховищі та синхронізуються із вихідним сховищем.
Проблеми GitHub та етапи проекту
Зазвичай у кожному проекті потрібно відстежувати завдання, дефекти, вдосконалення тощо як частину прогресу. Ви можете використовувати проблеми у GitHub, щоб відстежувати всі вищезазначені разом із дошками проектів.
Що стосується проблем, ви можете пов’язати те саме із запитами на витягування, щоб його можна було автоматично закрити при об’єднанні запиту на витягування. Крім того, якщо є відкриті проблеми, їх також можна перенести в інші сховища. У цьому розділі ми побачимо набагато більше про те, як можна використовувати проблеми.
Створення випусків та етапів
Перейдіть на головну сторінку сховища та перейдіть до Проблеми Вкладка. Натисніть на Новий випуск.
Призначте його співавтору, над яким слід працювати, додайте Label, щоб виділити як покращення. Хорошою практикою є також згадування про Віха відстежувати хід порушених питань.
Натисніть на Подайте новий випуск.
Відображається підсумок випуску. Зверніть увагу, що номер випуску № 11, на який буде посилатися пізніше.
Випуск також можна перенести до іншого сховища. Можливість зробити це внизу ‘Проблема передачі’.
Додайте a термін до етапу - R1. На головній сторінці сховища перейдіть до Проблеми Вкладку та натисніть на Віхи .
Редагувати деталі Milestone R1 та додайте термін виконання. Збережіть внесені зміни.
Зараз Milestone R1 має 2 відкритих випуски, і також можна побачити відсоток завершення.
Клацніть на Milestone R1, щоб ознайомитися з проблемами, які потрібно поставити для цього етапу. Випуски також можна переорієнтувати на пріоритети, переміщуючи їх вгору та вниз.
Фільтрувати проблеми
Припускаючи, що існує кілька проблем, які перебувають у стані відкриття / закриття та призначені для кількох співавторів. Дуже важливо шукати ті питання, які базуються на певних критеріях.
Наприклад, всі завдання, призначені вам, усі проблеми у відкритому стані тощо. GitHub надає можливість пошуку, щоб фільтрувати проблеми і навіть тягнути запити.
Перейдіть на вкладку Проблеми і у полі фільтра введіть критерії наступним чином.
Наприклад, усі відкриті проблеми у відкритому стані та призначені співавтору.
тип: стан випуску: відкритий правонаступник: vniranjan2512 етап: етикетка R1: вдосконалення
Асоційовані питання для отримання запиту
Коли на запит на витягування посилається конкретне ключове слово та номер проблеми та після об’єднання проблема автоматично закривається. Навіть якщо на коміт посилається ключове слово та номер проблеми, проблема закрита.
Ключове слово може бути будь-яким, тобто закрити, закрити, виправити, виправити, вирішити, вирішити.
Наприклад, у повідомленні про запит на витягування або повідомлення про фіксацію закривається No11.
Створіть запит на витягування та згадайте ключове слово та номер посилання, як показано в повідомленні. Натисніть на Створіть запит на витягування та об’єднайте.
Питання автоматично закривається при об’єднанні запиту на витягування. Біт автоматизації, безумовно, потрібен.
Створення або відкриття нових випусків із вихідного коду
Для будь-яких змін коду можна відкрити нове видання. При цьому до випуску додається URL-адреса рядка зміни коду. У нередагованому режимі коду клацніть на 3 крапки (...) поруч із рядком коду та виберіть Довідка в новому випуску .
Деталі випуску оновлені.
Випуск PIN-коду
Ви можете закріпити проблему, щоб полегшити пошук проблем, а також уникнути дублікатів створюється.
Відкрийте випуск і в правому нижньому куті випуску натисніть на Випуск PIN-коду.
Тепер випуск додано над списком випусків.
Примітка: Будь-який час можна закріпити максимум 3 випуски.
Правління проекту GitHub
Дошка проектів у GitHub забезпечує простий спосіб візуалізації проблем. Ви можете переглянути перебіг проекту та подивитися, які питання ще не розпочато, що виконуються та завершені випуски.
Дошку проектів у GitHub можна створити на основі шаблонів Kanban, яка має заздалегідь визначений робочий процес, а також може бути налаштована. Приклад продемонструє дошку, створену на основі облікового запису користувача.
На головній сторінці сховища перейдіть до Проекти та створіть файл Новий проект.
Як ви можете бачити зверху, плата проекту допомагає:
- Сортувати завдання
- Сплануйте свій проект
- Автоматизуйте робочий процес
- Відстежуйте прогрес
- Поділитися статусом
- Закрити проект
Нова дошка проектів з основним шаблоном Kanban.
Дошка створюється з робочим процесом. Також можна додати додаткові стовпці робочого циклу, натиснувши на + Додати стовпець.
Процес роботи також може бути автоматизований. Наприклад, якщо створюється новий випуск, його можна безпосередньо додати до Статус справ. Виберіть Керуйте автоматизацією варіант для цього статусу.
Установіть прапорець Нещодавно додані і натисніть Автоматизація оновлення. Отже, при створенні нового випуску проект, вибраний для випуску, буде автоматично доданий до Статус справ. Ви також можете перетягнути існуючу проблему до стану та перейти від одного стану до іншого.
До стовпця ви також можете додати примітки, які гарантуватимуть, що ви подаєте важливу інформацію про проблеми у цій колонці. Клацніть на + підпишіть і додайте примітку.
unix знайти різницю між двома файлами
Натисніть на Додати.
GitHub Wiki для документації
Одним з дуже важливих заходів у будь-якому проекті є створення та підтримка документації для вашого сховища для використання всією командою. Репозиторій GitHub постачається з підтримкою для створення такої документації за допомогою GitHub Wiki. Отже, всю інформацію про ваш проект та його використання можна зафіксувати у вікі.
Вікі доступні для загальнодоступних сховищ у GitHub безкоштовно. Вікі використовують бібліотеку розмітки з відкритим кодом. Ми побачимо, як користуватися цією бібліотекою під час написання вікі.
Увімкнення підтримки Wiki для сховища
На головній сторінці сховища натисніть на Налаштування та переконайтеся, що Вікі опція вибрана під Особливості розділ.
Створіть GitHub Wiki
На головній сторінці сховища перейдіть до Вікі вкладку. Натисніть на Створіть першу сторінку.
Введіть заголовок та додайте текст до Вікі. Крім того, ви можете скористатися опцією форматування за допомогою підтримки Markdown. Клацніть на Зберегти сторінку колись зроблено.
Примітка у наведеному вище вмісті # призначений для заголовка1, ## - для заголовка2, ### - для заголовка3. * використовується для впорядкованого списку. Попередній перегляд буде таким, як показано нижче.
На Вікі натисніть вкладку + Додайте власний колонтитул.
Додайте вміст та збережіть сторінку.
Відкрийте будь-яку збережену Вікі, і ви побачите нижній колонтитул.
Додати бічну панель
На вікі-вкладці натисніть + Додайте власну бічну панель.
Додайте вміст для бічної панелі та збережіть сторінку.
Відкрийте будь-яку вікі, і ви побачите бічну панель.
Переглянути історію Вікі
В історії ви можете подивитися, хто вніс зміни, повідомити про повідомлення та дату, коли була внесена зміна.
Відкрийте Wiki і відредагуйте сторінку. Натисніть на Історія сторінки, з правого боку.
Клацніть на Хеш, щоб переглянути зміни. Виберіть редакції, щоб порівняти зміни та скасувати зміни новішої редакції. Натисніть на Скасувати зміни.
Зміни повернуто до попередньої версії.
Примітка : Ви можете скасувати зміни на основі дозволу редагувати Wiki.
Висновок
У частинах 1 та 2 серії GitHub ми бачили про діяльність з управління версіями, створення сховищ, запити на витягування, гілки, огляди кодів, організації та команди, розгалуження сховища, мітки, етапи, проблеми, проекти GitHub, вікі.
У нашому майбутньому уроці ми розглянемо створення випусків, інтеграцію з Jira та кількома іншими Команди Git це допоможе розробникам до того, як вони внесуть зміни до сховища GitHub.
Ми сподіваємось, що всі розробники знайдуть цей практичний підхід до GitHub корисним у своїх проектах.
=> Завітайте сюди, щоб ознайомитись із ексклюзивними навчальними посібниками GitHub.
Рекомендована література
- Види ризиків у програмних проектах
- Підручник для розробників GitHub | Як користуватися GitHub
- Як використовувати Microsoft TFS для проектів JAVA з Eclipse у DevOps
- Підручник JIRA Agile: Як ефективно використовувати JIRA для управління гнучкими проектами
- Чим відрізняється планування тестів для проектів, що проводяться вручну та автоматизації?
- Приклади твердження селену - практичне застосування в проектах
- На місці - офшорна модель проектів тестування програмного забезпечення (і як змусити це працювати для вас)
- Git проти GitHub: Вивчіть відмінності на прикладах