Правильна ли следующая стратегия коммита Git? - PullRequest
2 голосов
/ 17 февраля 2012

Я только что сделал следующее с Git, но я не уверен, что это правильный путь. У меня есть файл, в котором есть кое-что. Затем есть ветвь, которая добавляет дополнительный материал в этот файл (расширяет его, это плагин, который мы продаем отдельно). Допустим, у branch1 и branch2 есть файл со следующим содержимым:

-----------
branch1
-----------
123

-----------
branch2
-----------
123
qwe
-----------

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

-----------
branch1
-----------
1234

-----------
branch2
-----------
1234
qwe
-----------

Но код не работает полностью, и теперь мне нужно переключиться на branch2 и внести некоторые изменения в код, расширяющий файл (смените «qwe» на «qwer»). Однако во время работы я также нахожу некоторые ошибки в базовом коде («1234») и исправляю их (замените «1234» на «12345»). Теперь мой рабочий каталог с HEAD, находящимся в branch2, имеет следующий

-----------
branch2 (working directory)
-----------
12345
qwer
-----------

Теперь мне нужно зафиксировать это, результат, к которому я стремлюсь, равен

-----------
branch1
-----------
12345

-----------
branch2
-----------
12345
qwer
-----------

Я боюсь, что, если я просто передам это в Branch2, а затем по отдельности повторно применю изменение 1234-> 12345 к Branch1 и передам это тоже, это даст ожидаемые результаты, но Git распознает это как два отдельных независимых коммитов, и когда я буду проходить аналогичный процесс в будущем (например, 12345-> 123456 в branch1, а затем слияние branch1-> branch2), я получу конфликт в этом месте. Поэтому мое решение состоит в том, чтобы использовать интерактивное размещение, чтобы зафиксировать только изменение qwe-> qwer в branch2. Затем сохраните оставшиеся изменения (иначе это не позволит переключиться обратно на branch1), переключитесь на другую ветку, примените stash, передайте 1234-> 12345 к branch1 и, наконец, объедините branch1-> branch2.

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

Ответы [ 3 ]

1 голос
/ 18 февраля 2012

Вы можете использовать интерактивное добавление (git add -p), чтобы выполнить изменение 'qwer' и зафиксировать его в branch2, но вместо использования:

git stash
git checkout branch1
git stash pop

Вы можете:

git checkout -m branch1

, который переносит ваши изменения в рабочее дерево для branch1 и сохраняет несколько команд git

1 голос
/ 17 февраля 2012

Ваш подход кажется мне разумным.Однако я сделал бы это по-другому:

  1. Как только я увижу ошибки в базовом коде, спрячьте их и переключитесь на branch1 и исправьте их там. Test , polish, commit.

  2. Выкинь старое слияние branch1 в branch2 и повтори его с исправлениями из шага 1 (я так понимаю, для ручных слияний git-rerere может уменьшить дублирующую работу, но я никогда не использовал ее), или просто объединить снова и жить с немного запутанной историей.

Это гарантирует, что «исправления ошибок»на самом деле подходит для branch1 и не слегка нарушен вне кода branch2, и что они одинаковы в обеих ветвях.

С другой стороны, ответ «не делай этого»: плохая архитектура программного обеспечения для «плагина», требующего изменения основного программного кода;это делает его на самом деле не плагином .Если вы это исправите, то основная программа и плагин станут независимыми деревьями (если вы используете Git), и слияние не требуется (хотя обновления для совместимости, как в вашем qwe → qwer, все еще возможно необходимы).

0 голосов
/ 18 февраля 2012

Мы используем ветку кандидата на выпуск для объединения различных функций.Rerere - это то, на что вы хотите опираться.Подробнее читайте здесь:

http://dymitruk.com/blog/2012/02/05/branch-per-feature/

...