Что вы делаете, когда объединяете разработку с мастером и есть коммит, который вы не хотите объединять с разработкой?

Допустим, ваш репозиторий выглядит так, и вы не хотите совершать коммит 3.

A - 1 - 2 - 3 - 4 - 5 [develop]
 \
  B - C [master]

Создайте новую ветку из разработки, удалите коммит, затем объедините.

Один из способов добиться этого — интерактивная перебазировка.

$ git switch develop
$ git branch tmp-develop
$ git switch tmp-develop

Удалите нежелательный коммит.

# The ~ means the first parent of commit 3
$ git rebase -i <commit 3>~

          3 - 4 - 5 [develop]
         /
A - 1 - 2 - 4 - 5 [tmp-develop]
 \
  B - C [master]

Затем объедините и удалите tmp-develop.

$ git switch master
$ git merge tmp-develop
$ git branch -d tmp-develop

          3 - 4 - 5 [develop]
         /
A - 1 - 2 - 4 - 5
 \               \
  B - C --------- M [master]

Однако если вам нужно делать это регулярно, это указывает на проблему в вашем процессе разработки.

ОБНОВЛЕНИЕ ...и есть.

Если быть более конкретным, упомянутая мной функция — это симулятор устройства, который периодически генерирует фиктивные данные телеметрии и помещает данные в базу данных. Мне нужно, чтобы это работало в ветке разработки, и в мастере нет необходимости в симуляторе.

Симулятор может и не нужен, но и удалять его тоже не нужно.

Обычно вся ваша тестовая инфраструктура хранится в master (теперь называемом «main»). Это позволяет любому разрабатывать и тестировать ваш код и упрощает весь процесс разработки. Код выпускается в отдельном процессе упаковки кода. Там вы можете удалить тестовый код, если это двоичный пакет. Если это проект с открытым исходным кодом, часто в нем упаковано все дерево исходного кода, тесты и все такое.

Альтернативно можно сделать симулятор устройства тестовой зависимостью. Либо ваш менеджер зависимостей устанавливает его, либо его необходимо установить вручную, как и любую другую стороннюю зависимость, например базу данных. Вас могут соблазнить подмодули, но они не заменяют управление зависимостями и часто доставляют больше хлопот, чем пользы.

Часто проекты предоставляют несколько файлов конфигурации для нескольких сред: разработки, тестирования и производства. Все они проверены. Они не содержат никаких секретов и настроек для каждого разработчика, таких как имена пользователей.

Секреты (ключи API или пароли) и подробная конфигурация (имена пользователей, имена хостов) помещаются в переменные среды , поэтому они никогда не сохраняются на диск и не могут быть случайно зафиксированы. В большинстве систем конвейеров развертывания есть способы безопасного хранения этих секретов, или вы можете использовать что-то вроде Vault.

Допустим, есть мастер, развиваем ветку. master предназначен для развертывания, и я не хочу объединять какие-либо неутвержденные коды. В ветке разработки я совершил 10 коммитов. скажем, f(функция) 1~10. функции 2,4,7 еще не протестированы, но другие коммиты необходимо объединить. И есть функция 1, которая добавляется только для разработки.

Это проблема. Хотя вы можете перетасовать коммиты, это быстро усложняется и приводит к ошибкам.

Не следует делиться ничем, что не было полностью протестировано. Никто не должен напрямую использовать общую ветку; они рискуют поделиться сломанным кодом (что усложнит работу каждого) или заблокировать выпуск.

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

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

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