LINUX.ORG.RU
Форум — Development  

Вопрос о правильном мердже

 


1

3

Вот наткнулся тут на статью http://habrahabr.ru/post/179123/ и задумался.

А как вообще решать такие проблемы? На ум пришло много вариантов разной степени извращенности. Но как мне кажется, что наиболее логичным было бы наличие у rebase и merge опции, которая бы считала конфликтом любое изменение файла в двух разных ветках и предлагала бы вручную разрешить через mergetool. Стали искать в манах. Просмотрел merge strategy, но не нашел ничего подобного. Существует ли _ПРОСТОЙ_ способ обезопасить себя от таких ситуаций?

★★★★★

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

Dudraug ★★★★★
() автор топика

статью не читал. там че, удаленный ветки не глядя мержат?

1. делать локальный мерж на мастер, пероверять, пушить мастер

2. делать rebase на мастер, смотреть, безопасно мержить и пушить

3. делать cherry-pick нужного коммита на master, пушить

x0r ★★★★★
()
Ответ на: комментарий от x0r

статью не читал. там че, удаленный ветки не глядя мержат?

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

В случае rebase получается что сам коммит внес ошибку,а в случае merge что мерджевый комит сделал это.

Dudraug ★★★★★
() автор топика
Ответ на: комментарий от x0r

2. делать rebase на мастер, смотреть, безопасно мержить и пушить

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

Dudraug ★★★★★
() автор топика
Ответ на: комментарий от Dudraug

он вносит те же самые изменения что и раньше

но diff будет разный т.к. коммит лег на новый код.

x0r ★★★★★
()
Ответ на: комментарий от backbone

Согласен, но diff покажет рядом стоящие строки.

Ну для примера из статьи да, Но на самом деле между строками нашего бранча и измененым контекстом может быть еще сто строк кода и тогда эти изменения не войдут в «контекст патча». Но идее так то понятна и она вроде как очевидна. Тогда уж лучше даже сделать git fetch(или remote update) и перед ребейзом посмотреть историю origin/master и подумать. Просто хотелось бы узнать если какие-нибудь решения на уровне гита.

Dudraug ★★★★★
() автор топика
Ответ на: комментарий от Dudraug

Но на самом деле между строками нашего бранча и измененым контекстом может быть еще сто строк кода

Они могут быть такие же точно и вдругом файле. Конфликт только из-за факта редактирования одного файла не решение. Более-менее можно обезопаситься юнит тестами.

mashina ★★★★★
()
Ответ на: комментарий от mashina

Они могут быть такие же точно и вдругом файле. Конфликт только из-за факта редактирования одного файла не решение. Более-менее можно обезопаситься юнит тестами.

Тесты это само собой. Полноценно обезопасить себя от такого без тестов и не получится. Но просто мне казалось, что наличие опции которая говорит «всегда давать пользователю в ручную решить конфликты для 3-way merge» очевидно.Но тут походу ее нет=(

Dudraug ★★★★★
() автор топика

наиболее отчетливо проблема мерджа проявляется когда один разработчик меняет чужой код. При этом его код, допустим становится рабочий (как правило ценой удаления чужого кода, не вникая в детали), а чужой код или то-что от него осталось перестает работать. Фактических происходит затирание чужих правок, о чем с радостью узнает после очередного вытягивания первый. И это хорошо, что заметит сразу...

swwwfactory ★★
()
Ответ на: комментарий от swwwfactory

Фактических происходит затирание чужих правок

Не-не-не. Пример из статьи куда интереснее;)

Dudraug ★★★★★
() автор топика

считала конфликтом любое изменение файла в двух разных

Только ведь «ломающий» код может быть и в другом файле. Всякие include'ы и т. п.

drake ★
()

А где проблема? В статье сделан подлог. Типо вася написал 2*3 = 5, хотя явно видно что вася сделал замену 2 -> 3, 4 -> 5. Причем контекст изменился, как при мердже, так и при ребейзе. Вся статья суть сплошное 4.2. Хабр, епт.

// baverman

anonymous
()

Существует ли _ПРОСТОЙ_ способ обезопасить себя от таких ситуаций?

Да, code review.

Такие проблемы - не технические, и их не возможно решить техническими средствами.

anonymous
()
Ответ на: комментарий от anonymous

Читать, *****, надо, читать. Код пишется для людей!

anonymous
()
Ответ на: комментарий от anonymous

Такие проблемы - не технические, и их не возможно решить техническими средствами.

Так никто и не спорит, что не техническая проблема. Просто технические средства могут _упростить_ (именно упростить, а не решить) решение проблемы=)

Dudraug ★★★★★
() автор топика
Ответ на: комментарий от Dudraug

Да нет, там все правильно.

Я Антон, у меня есть сабжевая репа с историей. Что мне надо сделать чтоб увидеть коммит в котором 2+2=4 меняется на 2*3=5? У меня, честно говоря, с первого раза не получилось.

anonymous
()
Ответ на: комментарий от anonymous

Распутывать такие ситуации одинаково сложно/легко что для мерджа, что для ребейза. hint: время коммита.

anonymous
()
Ответ на: комментарий от anonymous 
$ git log -p --graph
*   commit 37a2de6fb41e36d525940dd47f7395faeb5e518b
|\  Merge: 9942b9e d57cb66
| | Author: Dudraug
| | Date:   Sat Feb 8 01:23:23 2014 +0400
| |
| |     Merge branch 'test'
| |
| * commit d57cb6620713b91426eb2ba9def71938b7c5bfe1
| | Author: Dudraug
| | Date:   Sat Feb 8 01:15:22 2014 +0400
| |
| |     2+3=5
| |
| | diff --git a/1.txt b/1.txt
| | index 838c07f..8252a53 100644
| | --- a/1.txt
| | +++ b/1.txt
| | @@ -1,6 +1,6 @@
| |  +
| |  2
| |  and
| | -2
| | +3
| |  =
| | -4
| | +5
| |
* | commit 9942b9ecb5787dcab145ba306849291c6da1bf83
|/  Author: Dudraug
|   Date:   Sat Feb 8 01:16:15 2014 +0400
|
|       2*2=4
|
|   diff --git a/1.txt b/1.txt
|   index 838c07f..c93f470 100644
|   --- a/1.txt
|   +++ b/1.txt
|   @@ -1,4 +1,4 @@
|   -+
|   +*
|    2
|    and
|    2
|
* commit 3ea802f73438230185db1944f42ebeda7e527b85
  Author: Dudraug
  Date:   Sat Feb 8 01:13:41 2014 +0400

      2+2=4

  diff --git a/1.txt b/1.txt
  new file mode 100644
  index 0000000..838c07f
  --- /dev/null
  +++ b/1.txt
  @@ -0,0 +1,6 @@
  ++
  +2
  +and
  +2
  +=
  +4

Dudraug@Dudraug /usr/bin/test
$ cat 1.txt
*
2
and
3
=
5

$ git checkout test
Switched to branch 'test'

Dudraug@Dudraug /usr/bin/test
$ git log -p --graph
* commit d57cb6620713b91426eb2ba9def71938b7c5bfe1
| Author: Dudraug
| Date:   Sat Feb 8 01:15:22 2014 +0400
|
|     2+3=5
|
| diff --git a/1.txt b/1.txt
| index 838c07f..8252a53 100644
| --- a/1.txt
| +++ b/1.txt
| @@ -1,6 +1,6 @@
|  +
|  2
|  and
| -2
| +3
|  =
| -4
| +5
|
* commit 3ea802f73438230185db1944f42ebeda7e527b85
  Author: Dudraug
  Date:   Sat Feb 8 01:13:41 2014 +0400

      2+2=4

  diff --git a/1.txt b/1.txt
  new file mode 100644
  index 0000000..838c07f
  --- /dev/null
  +++ b/1.txt
  @@ -0,0 +1,6 @@
  ++
  +2
  +and
  +2
  +=
  +4

Dudraug@Dudraug /usr/bin/test
$ cat 1.txt
+
2
and
3
=
5
Dudraug ★★★★★
() автор топика
Последнее исправление: Dudraug (всего исправлений: 3)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Development