Используя git flow, я создаю новую ветку, newFunction
, от develop
ветка.
Я добавляю newFunction в пример класса:
class ExampleClass
{
public function exampleFunction(){
return "example";
}
public function newFunction(){
return "new";
}
}
Допустим, я сливаю это develop
Я возвращаюсь через несколько месяцев, и мой класс выглядит следующим образом.
class ExampleClass
{
public function exampleFunction(){
return "example";
}
public function anotherFunction(){
return "another";
}
public function yetAnotherFunction(){
return "yetAnother";
}
public function newFunction(){
return "new";
}
}
Можно ли применить diff
между develop
а также newFunction
в тот момент? Возможно использование git patch
или какая-то черная магия.
Так что я бегу волшебный git something
команда, и я получаю что-то вроде этого:
class ExampleClass
{
public function exampleFunction(){
return "example";
}
public function anotherFunction(){
return "another";
}
public function yetAnotherFunction(){
return "yetAnother";
}
public function newFunction(){
return "new";
}
public function newFunction(){
return "new";
}
}
и если бы я сделал это снова, я бы получил это:
class ExampleClass
{
public function exampleFunction(){
return "example";
}
public function anotherFunction(){
return "another";
}
public function yetAnotherFunction(){
return "yetAnother";
}
public function newFunction(){
return "new";
}
public function newFunction(){
return "new";
}
public function newFunction(){
return "new";
}
}
и т.п.
Я знаю, что код, который он генерирует в настоящее время, неверен, так как в функциях его имя совпадает.
Я бы использовал это для генерации стандартного кода в устаревшей системе, например.
Я думаю, что команда, которую вы ищете, мерзавец применить. Предполагая, что последний коммит в ветви newFunction добавляет только четыре строки для newFunction, вы можете применить такое же изменение в ветви разработки с помощью следующих команд:
git checkout develop
git diff newFunction^ newFunction | git apply --3way
# "newFunction^" means the second last commit on newFunction branch
Git apply в этом случае попытается применить то же самое изменение, которое было сделано во время последнего коммита в ветви newFunction, к ветви разработки.
При тестировании с тестовым репозиторием, добавляющим одну функцию для каждого коммита, вышеприведенный git apply не применялся чисто. Но при использовании трехстороннего режима результаты останутся открытыми для ручного разрешения, например, git status
покажет both modified
для файла и git ls-files -u
покажет что-то вроде
100644 21ecaba537582661c82c9dd2dff920a88a4b69a1 1 file.php
100644 56728941868d309cc06a49a8c49afc72cb0285b7 2 file.php
100644 0bbcab178802667c0228e424ce84f4c13a2b4c94 3 file.php
Поведение по умолчанию для git — вставка некоторых текстовых маркеров для части конфликтов слияния, с которой мне очень трудно работать. Я предпочитаю объединять графически, используя KDiff3, и вооружившись выводом из ls-файлов, мы можем получить все соответствующие версии и создать файлы с соответствующим содержимым, на котором мы запускаем kdiff3. Например.
$ git cat-file blob 21ecaba537582661c82c9dd2dff920a88a4b69a1 > file1.php
$ git cat-file blob 56728941868d309cc06a49a8c49afc72cb0285b7 > file2.php
$ git cat-file blob 0bbcab178802667c0228e424ce84f4c13a2b4c94 > file3.php
$ kdiff3 -o file_merged.php file1.php file2.php file3.php
$ mv file_merged.php file.php
$ git add file.php
$ git commit -m "Manually resolved git apply result"
С двумя ручными выравниваниями различий не трудно решить:
Лично я создал скрипт, который по своей сути выполняет приведенные выше команды для разрешения конфликтов git, хотя и немного сложнее, и я использую его все время, мне нравится kdiff3.
Других решений пока нет …