2015-01-05 2 views
0

Я хочу нажать несколько отдельных коммитов на дистанционное репо git. Я последовал ответ Джеффа здесь, чтобы сделать это:git: Pushing Single Commits, Переупорядочение с rebase, Дубликат Commits

How can I pushing specific commit to a remote, and not the previous commits?

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

http://gitready.com/advanced/2009/03/20/reorder-commits-with-rebase.html

По существу я сделал:

git clone 
git commit 
git commit 
... 
git pull 
git rebase -i HEAD~3 
git push origin <SHA>:master 

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

git clone 
git commit 
git commit 
... 
git pull 
git log --pretty=format:"%h - %an : %s" // log before rebasing 
git rebase -i HEAD~3 
git pull 
git log --pretty=format:"%h - %an : %s" // log after rebasing 
git pull 
git log --pretty=format:"%h - %an : %s" // log after rebasing after pulling 

Так что я отвечал на этот вопрос:

git: Duplicate Commits After Local Rebase Followed by Pull

ответ Роджера там привел меня на этот вопрос: Почему я вижу повторяющиеся транзакции после перезагрузки и вытягивания?

Сверху, бревно, прежде чем перебазирования выглядит следующим образом:

84e4015 - Me : Local Commit 3 
0dbe86a - Me : Local Commit 2 
d57ba2a - Me : Merge branch 'master' of remote repository 
a86ea35 - Me : Local Commit 1 before reordering 
2fc4fe7 - Remote User 2 : Remote Commit 2 
b7a8656 - Remote User 1 : Remote Commit 1 
8ce80fc - Me : Merge branch 'master' of remote repository 

И журнал после перебазирования выглядит следующим образом:

cf1ff7b - Me : Local Commit 3 
cd14463 - Me : Local Commit 2 
b9d44fb - Me : Local Commit 1 after reordering 
9777c56 - Remote User 2 : Remote Commit 2 
a2d7d8b - Remote User 1 : Remote Commit 1 
8ce80fc - Me : Merge branch 'master' of remote repository 

Обратите внимание, что оригинал 2 совершает 2fc4fe7 и b7a8656 новые ШАС; 9777c56 и a2d7d8b. Я считаю, что это начало проблемы.

Теперь после того, как я другой мерзавец тянуть бревно выглядит следующим образом:

e8e1a85 - Me : Merge branch 'master' of remote repository 
cf1ff7b - Me : Local Commit 3 
cd14463 - Me : Local Commit 2 
b9d44fb - Me : Local Commit 1 after reordering 
9777c56 - Remote User 2 : Remote Commit 2 
a2d7d8b - Remote User 1 : Remote Commit 1 
2fc4fe7 - Remote User 2 : Remote Commit 2 // duplicate 2 
b7a8656 - Remote User 1 : Remote Commit 1 // duplicate 1 
8ce80fc - Me : Merge branch 'master' of remote repository 

Обратите внимание, что удаленные коммиты теперь дублируются, и оригинальные ПОР на пульте дистанционного управления совершает, 2fc4fe7 и b7a8656, вернулись.

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

Является ли это тем, что я перебил фиксацию, которая уже была нажата на пульт? Если да, то что я должен был сделать, чтобы избежать этого? Мне нужно переустановить мои коммиты, чтобы я мог нажимать одну фиксацию. Должен ли я использовать систему ветвления для этого? Если да, как использовать ветви для решения этой проблемы?

+0

Возможный дубликат [Git commits дублируется в той же ветке после выполнения rebase] (http://stackoverflow.com/questions/9264314/git-commits-are-duplicated-in-the-same-branch-after -do-a-rebase) – Whymarrh

ответ

1

Короткий ответ заключается в том, что rebase не изменение commits, , но скорее копирует их. Git обычно затем скрывает оригиналы, но если ваши оригиналы включают те, которыми пользуются другие пользователи, вы (и, конечно же, они) и все еще видите эти оригиналы.

Как правило, вы должны только перезаряжать свои личные, неопубликованные коммиты.Поскольку ни у кого нет еще имеет их копию по определению, то факт, что вы делаете свои собственные копии, а затем (через rebase) скрываете свои оригиналы, не проблема: теперь вы видите свои копии вместо своих оригиналов, и никто else также видит, и вы можете продолжить переустановку, если это необходимо. Как только вы опубликуете (через push или подобное) коммит, вы больше не сможете его изменить, потому что у кого-то теперь есть копия вашего оригинала, включая его идентификатор SHA-1, и они все равно будут иметь его позже.

Что вы сделали в этом случае, это переустановка (то есть, копия) их совершает, а также ваши собственные. Часть проблемы связана с использованием git pull, что означает «выборка, а затем слияние», когда то, что вы хотели, было «выборка, а затем перебаза». Вы можете сделать шаги отдельно:

git fetch 
git rebase 

или использовать git pull --rebase:

git pull --rebase 

который говорит pull сценария, который после выполнения выборки, он должен сделать перебазирование вместо слияния. Вы также можете настроить git для этого автоматически, без аргумента --rebase.

Основная проблема сейчас в том, что у вас есть слияние, которое вы, вероятно, не хотели. Если это так, вам нужно «отменить» это слияние (с git reset, см. Другие публикации в стеке).


Это не может: объект мерзавец, в том числе фиксации, называют его ID объекта, который является crypographic контрольная сумма его содержимого. Конец состоит из его родительского идентификатора, идентификатора дерева, автора и коммиттера (имя, адрес электронной почты и метки времени) и сообщение фиксации. Если вы измените какой-либо из них, вы получите новую, другую фиксацию с другим идентификатором.

Вы также можете настроить его для использования git pull --rebase=preserve. Тем не менее, сохранение сличений в операциях переадресации является отдельной темой (которую я уже рассмотрел ранее в проводниках stackoverflow).

+0

Имеет смысл, после того как я прочитал ваш ответ, я нашел это сообщение: [Когда я должен использовать git pull --rebase?] (http://stackoverflow.com/questions/2472254/when-should- я потребительной ГИТ-выдвижная перебазироваться). Он дополняет этот ответ, и есть несколько ответов, объясняющих, что на самом деле делает git pull -rebase. Я попробую использовать git pull -rebase и пометьте ваш ответ как ответ, если/когда он будет работать. Благодаря! – Samuel

+0

Это получилось. 'git pull --rebase' переустанавливает мои локальные коммиты, чтобы они были на вершине, то есть более поздние, чем фиксации в удаленном репо. Поэтому, когда я переустанавливаю свои обязательства по изменению порядка, я не переустанавливаю фиксации, которые были перенесены на удаленное репо. Благодаря! – Samuel