Git rebase для ветки, созданной несколько дней назад

Мне нужна помощь в понимании git rebase для этой ситуации. Я проверил ветку, созданную кем-то 10 дней назад. я проверил с помощью

git checkout -b <some name> origin/branchname

(Я просто использовал другое имя, чтобы идентифицировать его)

После проверки, если я выполняю перебазирование, находясь в этой проверенной ветке,

git rebase origin/master

Он показывает некоторые ошибки, такие как 1) Завершающие пробелы - я читал об этом, но даже после того, как я попробовал эту команду, которую я нашел в Интернете, я все еще вижу предупреждения.

 git config core.whitespace nowarn

2) Автоматическое слияние CONFLICT (добавить/добавить): конфликт слияния в... эти файлы находятся в основной ветке, но содержимое немного изменено в ветке проверки. Итак, как мне это исправить? У меня нет полномочий что-либо менять в мастере напрямую, если это способ исправить это. Эти файлы должны иметь содержимое из этой ветки проверки, чтобы тестирование работало нормально, поскольку оно связано с этим.. пожалуйста, объясните мне..

С уважением


git whitespace git-merge git-rebase
person geej    schedule 12.07.2011    source источник
comment
для моей первой проблемы я наткнулся на этот stackoverflow .com/questions/2327917/, но может кто-нибудь объяснить команду, которую я должен запустить, поскольку я не понимаю из предоставленного ответа .. спасибо.   -  person geej    schedule 12.07.2011

Ответы (3)


arrow_upward
2
arrow_downward

Ребята в значительной степени ответили на вопрос о пробелах, но не коснулись части вопроса о перебазировании. Вот что происходит при перебазировании:

сначала заходишь в какую-то ветку, потом говоришь:

git rebase master

Это означает, что вы хотели бы перебазировать текущий HEAD (ваша ветка темы) на master. Git возвращается в историю вашей тематической ветки и в историю основной ветки и находит коммит, который является первым общим предком для них обоих. Этот коммит будет старой базой для вашей тематической ветки. Затем он берет все коммиты, которые произошли с тех пор в вашей ветке, и «повторно применяет» их в порядке появления поверх текущего мастера. Иногда может возникнуть конфликт, тогда процесс перебазирования останавливается и ждет вашего разрешения. Таким образом, вам нужно разрешить их вручную, отредактировав файлы, а затем пометив их как разрешенные с помощью git add conflicted_file. Когда это будет сделано, вам нужно будет сказать git rebase --continue

Теперь вы НЕ меняете файлы в основной ветке, делая это - изменения происходят в вашей тематической ветке, а разрешение конфликтов записывается в вашей тематической ветке.

надеюсь, это поможет.

person Eugene Sajine    schedule 12.07.2011
comment
да это помогает. так что изменения, которые я делаю в тематической ветке, такие же, как и в мастере, верно? похоже, это можно сделать только в том случае, если кто-то уверен, что изменения в ветке темы не нужны ... иначе зачем кому-то разрешать ее, сопоставляя с тем же содержимым, что и мастер? - person geej; 12.07.2011
comment
нет, не совсем. Опять же, изменения, записанные в тематической ветке, вообще не влияют на основную ветку. Во время операции перебазирования master становится новой базой для фиксации ветки темы, но указатель master не перемещается. Если вы хотите продвигать результаты перебазирования в свою главную ветку, вам нужно будет перейти в основную ветку и выполнить тему git merge. Это приведет к быстрому слиянию вперед, и главный указатель будет перемещен так, чтобы указывать на тот же коммит, что и ваша тематическая ветка. - person Eugene Sajine; 14.07.2011
comment
вы можете создать тестовое репо и поиграть с двумя ветвями, зафиксировав разные вещи, а затем попытаться перебазировать одну на другую. Прежде чем вы это сделаете, запустите gitk --all &. это запустит графический интерфейс для браузера истории. Затем после каждой выполняемой операции нажимайте F5, чтобы обновить графический интерфейс. Это должно показать вам, как работает процесс и каковы результаты. - person Eugene Sajine; 14.07.2011

arrow_upward
1
arrow_downward

Если это что-то вроде вопроса "проблемы с пробелами git svn windows linux", который вы упомянуть, то команды будут такими:

git config core.whitespace nowarn
git config core.autocrlf true

(чтобы сохранить эти настройки в соответствии с текущим репозиторием).
Это заставит все файлы принять один стиль eol, не позволяя файлу в источнике/мастере иметь идентичные строки с другим eol, который ваша собственная копия перебазирует (что объясняет сообщения об ошибках CONFLICTS (add/add)).

Но я по-прежнему сомневаюсь в autocrlf true и предпочитаю управление стилем eol через .gitattributes файлы< /а>.

person VonC    schedule 12.07.2011

arrow_upward
0
arrow_downward

cd в папку .git вашего репозитория. Вы можете не увидеть эту папку, если используете проводник, в котором не включено отображение скрытых файлов или файлов с . или _ впереди. Внутри папки .git у вас будет файл с именем config. Откройте его в текстовом редакторе, и вы сможете увидеть часть с именем [core]. Добавьте туда whitespace = nowarn. Другое место, где вы можете найти .gitconfig, находится в вашем каталоге home, если вы используете Linux-машину. Если это в Windows, это зависит от того, как вы установили git (через cygwin или msysgit).

Если msysgit увидит этот вопрос (Куда записывается git config --global ?) для расположения файла .gitconfig. Если это cygwin, то вы можете увидеть его содержимое по cat ~/.gitconfig.

person yasouser    schedule 12.07.2011