2013-07-12 2 views
1

В моем рабочем процессе у меня есть две основные ветки: master и development.Git rebase конфликтное понимание

Мы решили недавно перебазироваться development на master, потому что мы сделали много исправлений на master и мы продолжили развитие функций на development.

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

Таким образом, мы имели некоторый конфликт (нормальный после 7 месяцев развития на Differents ветви), но некоторые из них были бросить странно ...

Например, много времени у нас было что-то вроде:

$ git status 
# On branch master 
# Unmerged paths: 
# (use "git add/rm ..." as appropriate to mark resolution) 
# 
#  added by them:  X 
#  added by us:  Y 

Но для added by us, файл присутствовали в master и я n development для фиксации. Вы должны знать, что файлы в вопросе, по крайней мере 10 месяцев старый ....

Мой вопрос здесь: Что такое точное значение added by us?

И rebase хорошая практика?

+1

Если вы хотите свернуть коммиты в своем личном хранилище, которые вы никогда не делили, когда-либо; rebase - хорошая идея. Если вы хотите скомпрометировать коммиты, которые были использованы другими членами вашей команды и хотят заработать свою ненависть, перебазирование - хорошая идея. – tjd

ответ

6

Я предполагаю, что us означает вашу текущую ветку, а them - фиксация, которую вы в настоящее время перезаряжаете. Но это на самом деле очень незначительная точка, потому что:

Вы не должны перезаряжать работу за 7 месяцев !!!

Rebasing следует использовать только в локальном коде, который еще не нажат. Если вы используете его для чего-то другого, вы, вероятно, делаете что-то неправильно. Это как-раз тот случай.

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

  • Вы должны сделать 100 сливает вместо 1 и ухода за конфликты в 100 раз, а не один раз (каждый шаг в перебазировании является слиянием)
  • Вашей историей является total lie. Я предполагаю, что вы не тщательно проверяете каждую переустановленную фиксацию (потому что это, очевидно, было бы сумасшедшим). Результатом этого является то, что в более поздней точке ни один из кодов там не может работать или даже имеет смысл. Информация о разрешении конфликта также теряется (она не теряется, если вы делаете слияние - вы можете получить ее, не сравнившись с обоими родителями).
+1

Rebasing - действующий инструмент, даже для больших фрагментов истории, в случае перезаписи больших филиалов. –

+0

Я также считаю, что это действительно так, вы можете «скворовать» эти коммиты перед переустановкой, чтобы облегчить ситуацию. Так что это что-то вроде «rebase -i commitBeforeBranchCreation», сделать все сквош, исправить, а затем «rebase masterBranch» ...таким образом, конфликты намного меньше. – mjsr