Перенести ТОЛЬКО измнения одного комита,из одной ветки в другу

#git #git_cherry_pick

Можно ли перенести изменения из одной ветки в другую, без конфликта. 

Хочу сделать такое, у меня есть 2 платы (2 ветки), на которых могу отлаживать алгоритмы,
отличаются платы только файлом инициализации (или комитом инициализации, может быть
несколько файлов)

После добавления изменений в одной ветки, хочу перекинуть только внесенные изменения
в другую ветку. Команда  cherry-pick, делает такое с конфликтом, так как есть изменения
в файлах инициализации.  



Хорошо, опишу чуть подробнее,я занимаюсь embedded программированием и использую git
чисто для себя, что бы
создавать тестовые ветки всякой разной периферии, и не терять(портить) основной проект.  

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

Моя программа имеет модульный (.с, .h файлы) состав, инициализация каждой периферии,
находится в своем модуле, что бы можно было
кинуть два файла в другой(новый), проект и не искать как же его потом включить. (Но
тут уже да рассматриваю вариант, вынести все функции инициализации в отдельный файл).

Но в данном варианте, такое не подходит по тому что, помимо файлов инициализации,
под каждую плату пришлось вносить некоторые мелкие изменения в несколько модулей, (из
за отличия размера flash в процессора, изменился размер страницы, и на одно плате в
функции передачи данных изменил способ передачи без использования DMA)
хоть это как то и можно вынести, в файл конфигурации, но всё равно что нибудь новое
может вылезти ещё, типа как с изменением способа передачи.

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

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

Ответы

Ответ 1

Я полностью согласен с комментарием player one: вы задаёте какой-то технический вопрос,
но возникает он из-за неправильной организации рабочего процесса. И правильно будет
рекомендовать вам навести порядок в рабочем процессе, а не пояснять, как разрубить
гордиев узел с конкретным техническим вопросом.

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

Вам не кажется, что у вас по сути ДВА проекта, а не ОДИН? И вам нужно два репозитория,
один проект = один репозиторий?

Тут же всплывает проблема дублирования: это будут два настолько одинаковых репозитория,
что настоятельно нужно вспомнить принцип DRY (Don't repeat yourself) и рекомендовать
подумать над тем, чтобы убрать ненужные дубликаты.

Не зная деталей проекта сложно что-то конкретное рекомендовать. Я бы предложил вынести
общую часть в 'core' ("движок") и подключать его к своим двум проектам (получается
три репозитория: корневой, с общей частью и два мелких репозитория с отличающимися
частями). Не знаю, насколько это подходит к вашему проекту, у меня вообще слово "плата"
вызывает ассоциацию с печатными платами, не представляю, как их хранят в гит.

А вот насчёт конфигурационного файла тут тоже весьма настоятельно рекомендую задуматься
о том, чтобы вынести эти файлы за рамки версионного контроля через механизм .gitignore.

Так по крайней мере принято именно в качестве удобного процесса совместной работы
нескольких людей (каждый может сделать свои настройки и в гит они не попадут, не будут
конфликтовать друг с другом), на разных окружениях (development - stage - production).