Какая тактика позволяет поддерживать ветку на вершине без тонны слияний?

Question

С одной стороны, перебазирование - это замечательный способ держать ветку на вершине мастера, но силовые толчки болезненны, если над ней работает более 1 человека, и становятся непрактичными, когда из этой ветви извлекается еще больше веток.

С другой стороны, постоянные слияния мастера с веткой загромождают историю и делают окончательную интерактивную перебазировку непосредственно перед тем, как объединить ее с мастером еще сложнее, если это вообще невозможно.

Интересно, гденайти список распространенных способов поддержания актуальности ветки сотрудничества?

Answer 1

Rebase - это путь, если вы не хотите слияния.

Если это создает трудности, возможно, вы захотите пересмотреть свой рабочий процесс, например:

• , если на одной ветви не работают несколько человек,
• , если на ветвиПредполагается иметь подветви, перебазировать его только после того, как он будет готов к объединению в master,
• и т. д.

Но, как говорит Лассе Вогстер Карлсен, это больше идей и направлений, чемоднозначный ответ.

Answer 2

Я думаю, ваша главная проблема в том, как вы координируете свою работу:

С одной стороны, перебазирование - отличный способ держать ветку на вершине мастера, но принудительные толчки болезненны, если над ним работает более 1 человека, и становятся непрактичными, когда еще больше веток происходит от этой ветви.

Акцент мой.

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

Итак, если вы хотите выполнить перебазирование, не нажимайте, пока вы не перебазируете . Держите свои коммиты в тайне, и вы можете делать с ними все что угодно. Как только ваши коммиты выглядят хорошими для публикации, нажмите их. Как только ваши коммиты выдвинуты (= публичные), они больше не должны переписываться. Вместо этого используйте коммит слияния.

Кроме того, по моему опыту, многие люди слишком обеспокоены сохранением «линейной истории». Правда в том, что история не линейна, и обычно лучше записать правду, чем линейную ложь, imho. Git был создан специально для работы с нелинейной историей, нет абсолютно никакой технической причины хранить линейную историю. Линейная история может быть немного легче для анализа людьми, но если цена за линейную историю такова, что некоторые коммиты становятся непроверяемыми из-за ошибок rebase (это может легко случиться, если вы не перепроверете каждый переписанный коммит после длительного git rebase), тогда вы только что выбросили один из лучших инструментов, предлагаемых git: git bisect. Эта команда работает лучше всего, если вы избегаете лжи об истории.

Не поймите меня неправильно: git rebase имеет свое применение, и git push -f существует и по уважительной причине. Все, что я говорю, это: Эти инструменты имеют неизбежные негативные последствия, и если вы не приложите никаких усилий, чтобы смягчить их, вам не следует использовать их в первую очередь . Они не созданы для бессмысленного использования. Если вам нужно использовать эти инструменты, вам также необходимо приложить усилия: 1) Повторно протестировать все переписанные коммиты. 2) Общайтесь с членами вашей команды о любом необходимом принудительном толчке. Если вы этого не сделаете, вы получите описанные проблемы.