Чи використання Git Stash в якості робочого процесу є антипаттерном?

Нещодавно я дивився на те, як я та моя команда використовують Git та як працюють наші робочі процеси. Зараз ми використовуємо робочий процес із галузевими функціями, який, здається, працює добре.

Я також бачив, як деякі люди в нашій команді використовують робочий процес на основі git stash . Робочий процес йде приблизно так:

• Робота над головною галуззю (як master)
• Зробіть зобов’язання під час поїздки
• Якщо вам потрібно отримати зміни або переключити гілки, висуньте свої непомічені зміни на сховище
• Після того як ваше оновлення буде зроблено, вискочіть зміни зі сховища.

Я мушу зазначити, що цей робочий процес використовується замість функції функціональної гілки. Замість того, щоб брати гілку і працювати над нею, розробники тут лише коли-небудь працюють над однією гілкою і штовхають / вискакують стек, як вважають за потрібне.

Я насправді не думаю, що це чудовий робочий процес, і розгалуження було б більш доцільним, ніж використання git stash таким чином. Я бачу цінність git stash як екстреної операції, але не для її використання в щоденному регулярному робочому процесі.

Чи регулярно використання git stash вважатиметься антидієграмою? Якщо так, то які конкретні проблеми можуть виникнути? Якщо ні, то які переваги?

З книги Git SCM :

Часто, коли ви працюєте над частиною свого проекту, речі перебувають у безладному стані, і ви хочете трохи переключити гілки, щоб працювати над чимось іншим. Проблема полягає в тому, що ви не хочете робити зобов’язання за виконану наполовину роботу, щоб пізніше повернутися до цього питання. Відповідь на це питання - команда git stash.

Stashing приймає брудний стан вашого робочого каталогу - тобто ваші змінені відслідковувані файли та поетапні зміни - і зберігає їх у степі незавершених змін, які ви можете будь-коли повторно застосувати.

Враховуючи цей опис, я б сказав, що це анти-візерунок. Надмірно спрощеним поясненням Git Stash було б те, що це "Вирізати та вставити" управління джерелами. Ви берете купу змінених файлів, «зберігаєте» їх у тримаючої ручці поза нормальним робочим процесом розгалуження Git, а потім пізніше застосовуєте ці зміни до іншої гілки.

Повернувшись трохи далі, зобов'язання освоїти - це анти-модель . Використовуйте гілки. Саме для цього вони були розроблені.

Це дійсно зводиться до цього:

Ви можете забити гвинт у стіну, і він буде тримати малюнок, але використання викрутки - це те, що вам слід зробити. Не використовуйте молоток, коли викрутка сидить поруч.

Про вчинення "зламаного" коду

Хоча наступна думка, я прийшов до цієї думки з досвіду.

Робіть зобов’язання рано і виконайте часто. Введіть скільки завгодно зламаного коду. Переглядайте свою локальну історію фіксації як "збереження очок", коли ви щось зловживаєте. Після того, як ви виконали логічний твір, зробіть зобов’язання. Звичайно, це може зламати все, але це не має значення до тих пір, поки ви не підкажете цих зобов'язань. Перш ніж натискати, перезавантажте та зменшіть свої зобов'язання.

1. Створіть нову філію
2. Рубати рубати
3. Вчинити порушений код
4. Поліруйте код і змусьте його працювати
5. Ввести робочий код
6. База і сквош
7. Тест
8. Натисніть, коли проходять тести

Для ОП цей ланцюжок повідомлень ядра Linux може представляти інтерес, оскільки він звучить так, ніби деякі члени команди ОП використовують Git подібним чином.

@RibaldEddie сказав у коментарі нижче:

Перш за все, сховище не знаходиться поза "розгалуженим робочим процесом", оскільки під кришкою сховище - це ще одна гілка.

(ризикуючи викликати гнів багатьох людей)

Лінус сказав:

За допомогою "git stash" ви також можете мати кілька різних прихованих речей, але вони не стоять на черзі один на одного - це просто випадкові незалежні патчі, які ви приховали, бо в якийсь момент вони були незручними.

Я думаю, що @RibaldEddie намагається сказати, що ви можете використовувати git stashв робочому процесі функції гілки - і це правда. Не в тому використання git stashцього. Це поєднання зобов'язань освоїти та використовувати git stash. Це анти візерунок.

Уточнююча git rebase

З коментаря @ RibaldEddie:

Повторне видання набагато більше схоже на вставку копій і ще гірше модифікує довірену історію.

(Наголос мій)

Змінення історії фіксації не є поганою справою, доки це місцева історія фіксації . Якщо ви перезавантажуєте зобов’язання, які ви вже натиснули, ви, по суті, осиротіли когось іншого, хто використовує вашу філію. Це погано.

А тепер скажіть, що ви зробили кілька комісій протягом дня. Деякі коміти були хорошими. Деякі ... не дуже добре. git rebaseКоманда в поєднанні з давлячи ваші коммітов це хороший спосіб , щоб очистити вашу місцеву історію фіксації. Приємно об'єднатись в один комітет для публічних відділень, тому що він зберігає чисту історію спільних філій вашої команди. Після повторного випуску ви хочете протестувати ще раз, але якщо тести пройдуть, ви можете натиснути одну чисту комісію замість кількох брудних.

Є ще одна цікава нитка ядра Linux з чистої історії фіксування .

Знову від Лінуса:

Я хочу чистої історії, але це насправді означає (а) чисту і (б) історію.

Люди можуть (і, мабуть, повинні) відновити свої приватні дерева (власну роботу). Це очищення . Але ніколи інші коди не кодують. Це "знищити історію"

Тож частина історії досить проста. Є лише одне головне правило та одне незначне уточнення:

• Ви ніколи не повинні знищувати історію інших народів. Ви не повинні перезавантажувати зобов'язання інших людей. В основному, якщо на ній не вказано ваш вихід, він вийшов за межі: ви не можете його переосмислити, оскільки це не ваше.

  Зауважте, що мова йде про історію інших народів , а не про код інших народів . Якщо вони надіслали вам матеріал як патч електронної пошти, а ви застосували його за допомогою "git am -s", то це їх код, але це ваша історія.

  Таким чином, ви можете дивитися на "git rebase" річ на ньому, навіть якщо ви не написали код, якщо сама комісія є вашою приватною.

• Незначні роз’яснення до правила: після того як ви опублікували свою історію на якомусь загальнодоступному веб-сайті, інші люди можуть використовувати її, і тепер явно вже не ваша приватна історія.

  Отже, незначне уточнення насправді полягає в тому, що справа не лише в тому, що ви "займаєтеся", це також про те, щоб він був приватним для вашого дерева, і ви ще не висунули його і не оголосили.

...

Тепер "чиста" частина трохи тонкіша, хоча перші правила є досить очевидними та простими:

• Тримайте читати власну історію

  Деякі люди роблять це, просто спочатку опрацьовуючи речі в голові і не роблячи помилок. але це дуже рідко, і для решти з нас ми використовуємо "git rebase" тощо, працюючи над своїми проблемами.

  Тож "git rebase" не є помилковим. Але це правильно лише в тому випадку, якщо це ВАШЕ ДУЖЕ ПРИВАТНЕ дерево git.

• Не піддавай своє лайно.

  Це означає: якщо ви все ще знаходитесь у фазі "git rebase", ви не виштовхуєте її. Якщо це не готово, ви надсилаєте патчі навколо або використовуєте приватні дерева git (як "заміна серії патчів"), про які взагалі не повідомляєте публіці.

(наголос мій)

Висновок

Зрештою, в ОП є такі розробники:

git checkout master
(edit files)
git commit -am "..."
(edit files)
git stash
git pull
git stash (pop|apply)

Тут є дві проблеми:

1. Розробники зобов’язуються освоїти. Блокуйте це негайно. Дійсно, це найбільша проблема.
2. Розробники постійно використовуючи git stashі git pullна майстра , коли вони повинні використовувати повнометражну гілка.

Немає нічого поганого в використанні git stash- особливо перед витягненням - але використання git stashцього способу є анти-схемою, коли в Git є кращі робочі процеси.

Їх використання git stashчервоної оселедця. Це не проблема. Зобов'язання опанувати - проблема.

Я особисто використовую лише stashдля коротких, несподіваних перерв, як хтось задає питання, яке потребує переходу на іншу гілку. Я роблю це, тому що раніше забув про приховування, тоді вони не застосовувались чисто. Регулярні комутації в галузях функцій набагато складніше забути і простіше об'єднати, тому зараз я прагну просто зробити неполадку, а потім зробити git reset HEAD~1або ребауз, якщо я не хочу зберігати його пізніше.

Однак найважливішою справою управління розподіленими версіями є те, що люди можуть використовувати бажаний робочий процес у власних сховищах до тих пір, поки спільні сховища відповідають стандартам. Я би переконався, що люди не просто використовують stashробочий процес, тому що вони не мають достатньої підготовки або обізнаності про альтернативи, але якщо вони все ж таки виберуть робочий процес, який ви знайдете неоптимальним, я б залишив його.

Я думаю, що частина вашого запитання, яка є антидіаграмою, полягає у використанні єдиної спільної ведучої гілки. Однак, якщо ви повинні включити гілку розробки на додаток до основної гілки, а потім використовувати скриньки для обробки власних контекстних комутаторів у гілці розвитку, це не було б антидіаграфом, і це дуже тісно відображає частину робочого процесу описати такі організації, як Etsy та Facebook.

Зважаючи на це, відповідь @Greg Burghardt вище є надто сприятливою для так званого робочого потоку git-flow або особливості. Раніше я виступав за подібну стратегію, але після того, як зрозумів, що це додає зайвої складності та створює помилкове почуття безпеки, я більше не займаюся. Це також перехід від часів недецентралізованих систем управління версіями, таких як підривна робота.

По-перше, оскільки Git є децентралізованою системою управління версіями на відміну від підривної, локальний сховище розробника - це, по суті, гігантська гілка коду сама по собі. Те, що розвивається окремо, місцеве місце не має і не повинно впливати на інших членів команди, якщо зламаний або помилковий код не буде висунутий до будь-яких спільних гілок спільного сховища.

Команда rebase, однак, може пошкодити історію гілки, коли виникає конфлікт злиття в одному з повторених комітетів. З http://ryantablada.com/post/the-dangers-of-rebasing-a-branch

Інша частина бази даних проходить безперебійно, всі тести, здається, проходять. Здійснюється PR.

А потім пишеться ще якийсь код, який спирається на властивість commentsForAllPosts, і все порушено. Але до кого ми йдемо і просимо допомоги? git blama показує, що рядок коду написав лише серверний інженер, і він підводить руки.

Тепер ваш інженер перебуває у відпустці, відпустці із лікарні чи хто знає. Ніхто не може зрозуміти, як повинен виглядати цей код!

Rebase знищив здатність команди переглядати історію, щоб знайти те, що пішло не так, оскільки будь-які конфлікти злиття на дочірній гілці вбиваються, а початковий код втрачається назавжди.

Якщо цей самий конфлікт злиття виник і злиття було використано, виною буде показано, що цей рядок коду було торкнутось у процесі злиття, присвоєння материнській гілці та зобов'язання над дочірньою гілкою. Деякі розгулюються з трьома перестановками, і ви можете повернути оригінальний намір назад в базу коду і працювати без тонни голови, чухаючи вказівний палець. І все, що ти насправді мав, - це ще один вчинок

Крім того, модель з декількома розгалуженнями передбачає, що жодна дві гілки ніколи не можуть містити взаємозалежних змін коду. Коли це неминуче відбувається, розробнику зараз доведеться жонглювати ще кількома гілками, щоб ефективно працювати.

Я бачу, що основна антидіаграма не пов’язана з гілками та прихованими, а більше про типи проблем, про які деякі дуже розумні люди вже певний час говорять: чи маєте ви впевненість у своєму коді за допомогою використання одиничні тести та хороша архітектура? Чи можете ви внести додаткові зміни до свого коду, щоб ваші розробники могли легко міркувати про зміни та зрозуміти, що зміни будуть робити? Чи ваші розробники навіть один раз запускають новий код, щоб побачити, чи справді він працює? (Так, я це бачив і раніше).

Якщо відповідь на ці запитання - ні, то не має значення, скільки у вас філій - розробники скажуть, що код готовий, працює і підходить для виробництва, коли його насправді немає, і жодна кількість гілок не буде допоможемо вам, коли цей код все-таки вийде на виробництво.

git stashє інструментом. Це само по собі не є зразком, ані антидіаграмою. Це інструмент, як молоток - це інструмент. Використання молотка для прибивання цвяхів є зразком, а використання молотка для приведення гвинтів - це анти візерунок. Так само є робочі процеси та середовища, деgit stash це правильний інструмент для використання, та робочі процеси та середовища, коли це неправильно.

Робочий процес "усі здійснюють і рухаються до основної лінії" - це той, хто працює досить розумно, коли немає змін із високим ризиком. Його часто бачать у svn середовищах, де є один авторитетний центральний сервер, який має код.

Однак Git пов'язаний з одним центральним сервером. З усіма розробниками роблять commit, pull(абоrebase , якщо ви в цьому), pushвесь час може зробити великий безлад.

Найбільші проблеми виникають у тому, що ви щось зламали, і ця робота порушена, і вам потрібно працювати над пріоритетною помилкою. Це означає, що вам потрібно трохи відкласти цю роботу, захопити останню, працювати над цим не маючи попередньої роботи, викликати проблеми зі збіркою, яку ви намагаєтеся зробити.

Для цього, git stash було б правильним інструментом для використання.

Однак існує більша проблема, що лежить в основі цього робочого процесу. Це те, що всі ролі гілок управління версіями є на одній гілці. Основна лінія, розробка, обслуговування, накопичення та упаковка - це все на Master. Це проблема. (Див. Розширені стратегії розгалуження SCM про цей підхід до галузей )

І так, ви подзвонили, що це не великий робочий процес і що з цим є проблеми. Однак проблема не в цьому інструменті git stash. Проблема полягає у відсутності чітких розгалужень на ролі чи для несумісної політики .

git stashоднак, це те, що я використовував, коли в мене була ситуація, коли я побудував трохи, потрапив у липкий стан, що я не був впевнений, чи був він правильним ... тому я приховав свої зміни а потім вивчив інший підхід до вирішення питання. Якщо це спрацювало - чудово, відкиньте речі на сховищі та продовжуйте продовжувати. Якщо інша розвідка стала жорсткішою, тоді поверніться до попередньої зміни та повторно застосуйте приховану роботу, щоб працювати над цим. Альтернативою було б здійснити, здійснити замовлення, відділити, а потім або продовжити цю нову гілку, або повернутися назад і скинути її. Питання в тому, чи дійсно варто вкласти це в історію, коли це просто щось, що я хочу вивчити трохи?

git stashне анти-шаблон. Використання git stashв якості альтернативи розгалуження, коли всі здійснюють Майстер, є анти-закономірністю, але не через цеgit stash .

Якщо ви ще цього не зробили, просто зачекайте, поки у вас виникнуть проблеми зі збірками , коли комусь потрібно внести значні архітектурні зміни у велику кількість файлів (і конфлікти злиття) або якийсь неперевірений код незавершеної роботи, який витікає з виробництва для цього анти-шаблон, щоб наздогнати вас.