Git порядок операций

Question

Я работаю (один) над хранилищем.У меня есть хранилище в GitHub и локально на моем компьютере.В настоящее время у меня есть три ветви: функции, разработки и основные.Я делаю некоторые изменения в ветви функций прямо сейчас, и мне было интересно, если мой подход к этому корректен.

Обычно (если я работаю в ветви функций), я бы зафиксировалмои изменения, затем отправка в удаленный репозиторий, затем объединение функций в разработку, а затем отправка разработки.Но мне было интересно, имеет ли значение, если я вместо этого фиксирую свои изменения, затем объединяюсь с разработкой и затем нажимаю дважды (один толчок для функций и один толчок для разработки)?Это то же самое?Или разница между этими двумя рабочими процессами?Что такое "типичный"?

Answer 1

Порядок выполнения этих операций не имеет значения.То есть вы делаете три вещи: слияние одной ветви (target) с другой (current);нажатие target;и нажав current.Конечно, имеет значение слияние перед нажатием current (потому что слияние target в current увеличивает current либо с помощью ускоренной перемотки вперед до target, либо на коммит слияния, который объединяет target с current) - но оба предложенных вами рабочих процесса делают это.

Таким образом, вопрос заключается в порядке нажатия target и слияния target в current.Ни одна из этих операций никоим образом не влияет на другую, поэтому это не имеет значения.

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

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

Но если выработать в одиночку (так что единственная «команда», с которой вы должны координировать свои действия - это вы сами) и выполнять слияния (чтобы история не переписывалась обычно), это не имеет значения, и ни один из способов не является «более типичным» или «более правильным».

Answer 2

Или делайте свою работу локально, однако это удобно и продвигайте все, что будет готово в любое время.Если вы выполняете функцию и выполняете слияние, тогда вы можете git push origin feature develop.Единственный типичный порядок - вы нажимаете на публикацию и публикуете то, что готово.

---

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

Вы можете даже носить несколько историй в репо, смешивать и сочетать их так, как вам нравится.Как только вы освоитесь с Git, вы можете перенести свою историю подмодулей, например, в основной репо;это делает утилиты для небольших утилит намного более удобными для работы, вот фрагмент из файла makefile:

setup:  utils/.git

utils/.git:
    @if _=`git rev-parse -q --verify utils`; then \
        git config submodule.utils.active true \
        && git config submodule.utils.url "`pwd -P`" \
        && git clone -s . utils -nb utils \
        && git submodule --quiet absorbgitdirs utils \
        && git -C utils checkout $$(git rev-parse :utils); \
    fi

(исправление повреждения закладки markdown), и я несу историю utils со связанными проектами.Если он станет больше, например, размер gnulib, я просто сделаю свои клоны --reference хранилищем с известной историей для него, тогда на диске останется только одна копия, примерно на 99%.Но это далеко впереди игры, достаточно сказать, что если я исправлю или настрою утилиту, то это легко, сделаю ее там, где она сразу полезна, и опубликую ее там, где это необходимо, вы можете найти все репозитории с историей, например

root=(`git rev-list --max-parents=0 heads/utils`)
find $projects -name objects -execdir git cat-file -e $root \; -printf %h\\n

Answer 3

Предполагается, что вы используете GitHub, и поток состоит в том, что работа, выполненная в ветви features, должна быть в какой-то более поздний момент перенесена в ветку develop, тогда один общий рабочий процесс будет состоять в том, чтобы использовать запрос извлечения в GitHub.

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