2015-09-23 3 views
1

У Perforce есть концепция branch mapping, где вы просто определяете сопоставление между разными путями.Что такое git-эквивалент сопоставления ветвей perforce?

Вы могли бы иметь следующую ветвь сохраненного выполните картирование

//depot/proj1/path1/... //depot/proj1/path1-renamed/... 

После этого отображение осуществляется развитие может продолжаться в обеих ветвях и время от времени слияния на основе отображения может произойти.

В git У меня есть аналогичная «переименование» и независимая ветвь развития после этого, но все же я хочу время от времени объединять изменения от одной ветви к другой.

#desired in git 
//https://github.com/mucommander/mucommander-commons-io/tree/master/src/main/java/com/mucommander/commons/io //https://github.com/mucommander/mucommander-commons-io/tree/master/src/main/java/com/mucommander/commons/io2 

Как это сделать? Что такое эквивалент эквивалентной ветви в git?

+1

В Git нет эквивалентного поведения. Вероятно, вам понадобится символическая ссылка. – meagar

+0

Я этого не ожидал. Я работаю над решением, используя переименование до и после интеграции с мастером. В основном я создаю сопоставление как набор 'git mv ' – raisercostin

+0

. Я понимаю, что вы пытаетесь сделать, и снова все, что я могу вам сказать, это то, что я не верю, что Git поддерживает это. Вы должны символически ссылаться path2 на path1 и вносить свои изменения. – meagar

ответ

0

Я думаю, что в Git вы вместо этого создали бы другую ветку. Таким образом, у вас будет два филиала: io и io2, а не два каталога под одной ветвью.

Чтобы сохранить отношения между ними, вы должны создать io2 из io, используя git branch--track kid parent.

0

Если и path1-renamed должны быть действительными путями, то тот факт, что они имеют одинаковое содержимое, должны быть отображены с помощью одной символической ссылки или нескольких символических ссылок для общих файлов (если существуют небольшие различия).

Нет смысла «сливать» каталоги на уровне git. Вы просто «синхронизируете» их любым способом (например, копирование, симлинку и т. Д.) И фиксируете результат.

+1

Я хотел бы «слить» их с тех пор, как модифицировал 'path1/A.java', а кто-то еще изменил' path2/A.java'. Я хотел бы объединить изменения, сделанные в другой ветке, зная, что в какой-то момент они переименовали путь 1 в путь2 и что A.java на самом деле является одной и той же единицей работы для нас обоих. – raisercostin

+0

Предлагая альтернативы здесь, так как именно то, что вам кажется нужным, невозможно в git: если они просто переименованы (а оригинальная копия не была сохранена), вы можете переупаковать их поверх своей ветки, в результате чего ваши изменения будут заменены на их переименовать где-то посередине и затем переименовать обратно в порядок восстановления. – aronisstav