5 ідей для вдосконаленого робочого процесу GitHub
Залежно від вашої історії з робочим джерелом керування, спосіб, у який ви працюєте з кодовою базою, робите коміти тощо, змінюється.
Крім того, залежно від того, чи використовуєте ви Git, Subversion, Mercurial тощо, ви також визначаєте, як ви керуєте своїм кодом.
Але якщо ви працюєте з Git (я знаю, що багато людей у WordPress починають використовувати все більше й більше майже щодня), я рекомендую зробити деякі дрібниці, щоб допомогти вносити зміни, особливо разом із командою більш керованим.
Поради щодо розширеного робочого процесу GitHub
1 Не зобов’язуйтеся Майстру
Master слід використовувати спеціально для коду, готового до виробництва та розгортання. Це не ваша робоча гілка, це не ваша робоча гілка.
Взагалі кажучи, тут об’єднуються всі запити на отримання.
2 Намагайтеся завжди створювати гілки
Щоразу, коли у вас є колекція завдань, проблем або етапів, створіть гілку та переконайтеся, що все, над чим ви працюєте, пов’язане. Наприклад, ви не хочете працювати з базою даних і працювати з JavaScript у своїх запитах на отримання.
3 Групуйте свою роботу
Навіть якщо ви працюєте виключно над зовнішньою роботою, можливо, вам доведеться розділити її на менші гілки. Це полегшує перевірку коду та покращує запити на підключення .
4 Створюйте невеликі PR
Це дуже схоже на попередній заголовок, але ідея створення невеликих PR набагато продуктивніша, ніж створення більш довгих запитів на підключення.
- Це допомагає, коли вам потрібно надіслати запит на перевірку коду, оскільки це дає вашим товаришам по команді легший спосіб розглядати код і надавати відгуки.
- Це зберігає журнал змін щадним і допомагає надати детальний звіт про те, що робить конкретна партія коду.
Але що таке хороший PR?
5 Додайте хороші деталі у своєму PR
Наскільки я розумію, хороший запит на витягування зробить невеликий набір речей:
- Деталізуйте лише одним-двома реченнями те, що має очікувати особа, яка переглядає ваші зміни.
- Пов’яжіть PR із тикетом, карткою управління проектом (або як це називають у вашій системі),
- Перерахуйте коротші версії повідомлень комітів, щоб якомога легше було рецензенту.
Тим не менш, ймовірно, ви можете робити більше речей, але це ті речі, які я вважаю найбільш корисними (і я не можу сказати, що деяких із цих речей я не навчився від своєї команди ).
Є ще речі?
Завжди.
Але це кілька речей, які я вважаю дедалі кориснішими, особливо під час відстеження змін, співпраці з іншими та обробки запитів на отримання (як від тих, з ким я працюю, так і від тих, хто бере участь у проектах з відкритим кодом).
Нарешті, жодна з цих речей не є обов’язковою. Існує крива навчання (говорячи з досвіду), але я рекомендую спробувати кілька з них, якщо не з іншої причини, а щоб побачити, чи не покращить це ваш робочий процес.
Навіть якщо це зовсім небагато.