git merge overwrites changes

git git-merge

5339 просмотра

4 ответа

12 Репутация автора

Can anyone help in avoiding git merge issue. I am trying to merge my branch lets say my_branch into another branch lets say another_branch. As another_branch is base branch.So to add work done in my_branch ,First I am merging my_branch. To do so I am doing these steps.

git checkout another_branch
git pull anothr_branch

Once I have updated latest changes in another_branch I switch to my_branch

git checkout my_branch
git merge anothr_branch

And before doing all this yes I am committing and staging my changes to save it locally. So no doubt to lose any of my changes.

But I don't see all changes of another_branch.So I am calling it overwrite.

What could be the reason?

Автор: deep Источник Размещён: 19.07.2016 06:46

Ответы (4)


1 плюс

695 Репутация автора

Что вы, вероятно, хотите сделать, это использовать rebase. Повторная установка помещает коммиты в ветку назначения после коммитов в ветке источника.

Таким образом, локально, если я нахожусь в моей ветви функций, я буду использовать git rebase master- это помещает коммиты, которые у меня есть в моей ветви функций, поверх последних коммитов master.

Для удаленной ветви, которую я обычно использую git pull --rebase, которая хранит ваши изменения, извлекает изменения с сервера, помещает ваши изменения поверх самых последних изменений с сервера.

Лучшее наглядное руководство о том, как работает перебазировка, которое я встречал, это Atlassian .

Вы можете узнать больше об rebaseэтих ресурсах:

Автор: Vidur Размещён: 19.07.2016 06:53

0 плюса

1661 Репутация автора

Git не перезаписывает, пока вы не пометите файлы с конфликтами как разрешенные (даже если это не так).

Git не пытается быть умным со слиянием. Когда вы сливаетесь, если оно может слиться чисто, оно так и сделает. Если это невозможно, он остановит процесс слияния и отметит конфликты, которые вам следует разрешить вручную. После завершения разрешения конфликтов файла вы должны пометить его как разрешенный с помощью команды git add <file>...(той же команды, которую вы используете для отслеживания файлов).

Git отмечает конфликты так:

<<<<<<< HEAD:index.html
< div id="footer" > contact : email.support@kozbara.com</div>
=======
<div id="footer" >
please contact us at support@kozbara.com</div>
>>>>>>> anotherBranch:index.html

Верхняя часть (часть перед ====) находится в HEAD из файла index.html. Нижняя часть - из ветви с именем anotherBranch из того же файла.

Может быть, вы хотели бы прочитать эту часть из учебника git.

Автор: joker Размещён: 19.07.2016 08:25

2 плюса

557 Репутация автора

Here's a daily routine we've been using in a multi-developer, multi-team environment that's simple enough and works well.

Допустим, у вас есть ветка разработчика, в которой хранится текущая версия вашего продукта в разработке. Мастер ветвь , которая хранит текущую версию производства. У каждого разработчика есть своя ветка для реализации функции или исправления ошибки.

Каждое утро все разработчики делают следующее:
Checkout dev .
Тянуть.
Оформить заказ рабочая ветка .
Перебазировать на dev

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

Разработчик:
внесите изменения.
От себя

Разработчик Dev: ветка
Checkout от разработчика до слияния .
Тянуть.
Checout Dev .
Слияние из ветки от разработчика до слияния .
От себя

Автор: jp2g Размещён: 19.07.2016 01:22

0 плюса

89 Репутация автора

Я решил проблему со следующим расположением веток:

featureA - ответвление от разработки, много изменений во всех файлах. Не работал над этим долгое время.

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

Я хотел, чтобы все новые вещи от Develop были в функции A. Так я и сделал:

  1. Объединить Разработать в FeatureA -> переписал все в FeatureA
  2. Объединить FeatureA в копию Develop для проверки, если что-то изменится -> так же, как и выше
  3. Тогда я попытался перебазировать

На ветке FeatureA:

git rebase develop

(который переместил бы всю ветку Feature поверх ветки Develop и сохранил бы все коммиты) -> этого не произошло. Он переписал все с развитием.

Затем: по развитию отрасли:

git rebase featureA

(это переместило всю ветку разработки поверх функции A) И это сработало! Однако были конфликты, которые имеют смысл, потому что файлы редактировались на обоих, но это то, что я хотел, потому что теперь я мог выбирать.

error: could not apply fa39187... something to add to patch A

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

git rebase --continue

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

git rebase --skip

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

Автор: danjar Размещён: 01.10.2018 12:08
Вопросы из категории :
32x32