Який найкращий робочий процес Git для роботи з проектом з відкритим кодом із змінами, пов'язаними з роботодавцем?

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

Що я робив до цих пір, це підтримувати приватну гілку Git, де я вношу всі свої зміни з відповідною детальністю. Потім я використовую cherry-pickдля додавання відкритих джерел зобов’язань у головну гілку і передаю їх назад у Github.

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

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

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

Ось стратегія, яка може працювати для вас:

Створіть 2 приватні git repos, причому одне репо призначене для роботи в компанії, а інше - загальне (я б хотів зробити це назад).

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

Маючи це визначення, ви можете відокремити, що ви будете виконувати назад, а що не потрібно робити.

Має сенс, що те, що ви кодуєте для спільноти, має бути в загальному вигляді, оскільки занадто конкретний фрагмент коду нікому не принесе користі (і навіть не може зробити це для головного відділення).

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

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

Я також вважаю, що git може зробити набагато більше, ніж ти думаєш. Я переглянув це відео на Vimeo: http://vimeo.com/46010208, і вона зробила блискучу роботу, пояснивши багато дурних речей, які може зробити Git.

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

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

Таким чином вам ніколи не доведеться турбуватися про поділ або заздалегідь вирішити, чим поділитися, а що не поділяти. Оскільки ви додали гнучкості оригінальному проекту, ви завжди зможете згодом поділитися деякими частинами роботи вашої компанії.