История изменений

Диагноз предыдущего автора совершенно корректен. Для того, чтобы наглядно оценить сложившуюся после Ваших действий картинку, можете запустить gitk --all и посмотреть, как на данный момент устроен граф коммитов в Вашем репозитории. В принципе, можно обойтись командой git log --pretty=raw ... , но gitk очевидно нагляднее.

Добавлю, что существует возможность переписать историю, выправив весь набор коммитов в единую цепочку. Подчёркиваю: это действие НЕ является сколько-нибудь обязательным, и чаще всего проводится [неофитами git-а] для удовлетворения своего [ложного] чувства прекрасного. Однако, иногда такая возможность бывает полезна.

Итак, перед началом процедуры нужно выбрать последний перед нежелательным ветвлением коммит, допустим этот коммит имеет хэш abcdef. Выполняем команду git rebase -i abcdef. Эта команда пересоздаcт коммиты в текущей ветке поверх выбранного Вами коммита. Подчёркиваю: будут созданы новые коммиты, которые в принципе соответствуют Вашим старым, но являются всего лишь их копиями (а могут и не являться, если Вам это требуется, или если в процессе переналожения Вы будете вынуждены разрешать конфликты).

Итак, вначале эта команда предложит Вам выбрать порядок переналожения коммитов, запустив $EDITOR / core.editor со списком коммитов . Можете оставить предложенный git'ом список как есть, можете поменять порядок следования коммитов, можете вообще убрать какие-то коммиты. Я рекомендую выбившийся из цепочки коммит (см. gitk --all) накладывать первым (самым верхним) или последним (самым нижним) в списке.

После того, как список сформирован, нужно будет его сохранить и выйти из редактора. Далее git продолжит свою работу по возможности неинтерактивно.

Разрешение конфликтов. Будьте готовы к тому, что при наложении [выбившегося] коммита произойдёт конфликт, и автоматический процесс переналожения набора коммитов будет приостановлен до тех пор, пока Вы не разрешите все конфликтные места.

Для разрешения конфликтов удобно воспользоваться программой наподобие kdiff3 или meld, указав её git-у в качестве merge.tool:

apt-get install kdiff3
git config --global merge.tool kdiff3

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

git mergetool

и последовательно разрешить все обнаруженные конфликты.

После того, как конфликты разрешены, нужно оценить [глазами или тестами] результат, и, если всё хорошо, выполнить

git rebase --continue

и git продолжит процесс переналожения коммитов до следующей конфликтной ситуации или до конца списка.

Если в какой-то момент до окончания Вы решите отменить весь процесс целиком, Вы можете прервать выполнение, а потом сказать

git rebase --abort

и всё вернётся к Вашему первоначальному состоянию, «как будто ничего не было».

После того, как процесс ребэйза завершён (запустите ещё раз gitk и убедитесь в том, что «всё красиво»), Вам нужно опубликовать новую цепочку [на bitbucket].

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

Вообще, это ай-яй-яй, так делать низзя. [Гипотетические] пользователи Вашего репозитория уже могли склонировать его себе и начать какую-то свою работу поверх Ваших коммитов. Им придётся вытащить себе новую историю и перенакладывать свои коммиты поверх неё. Они могут разозлиться. Но если Вас это не пугает, то можете переписывать :)

У push для этого есть ключик -f . В крайнем случае, Вы можете удалить соотв. ветку на bitbucket.org и перезалить её снова.

Ну, вот как-то так :)

Диагноз предыдущего автора совершенно корректен. Для того, чтобы наглядно оценить сложившуюся после Ваших действий картинку, можете запустить gitk --all и посмотреть, как на данный момент устроен граф коммитов в Вашем репозитории. В принципе, можно обойтись командой git log --pretty=raw ... , но gitk очевидно нагляднее.

Добавлю, что существует возможность переписать историю, выправив весь набор коммитов в единую цепочку. Подчёркиваю: это действие НЕ является сколько-нибудь обязательным, и чаще всего проводится [неофитами git-а] для удовлетворения своего [ложного] чувства прекрасного. Однако, иногда такая возможность бывает полезна.

Итак, перед началом процедуры нужно выбрать последний перед нежелательным ветвлением коммит, допустим этот коммит имеет хэш abcdef. Выполняем команду git rebase -i abcdef. Эта команда пересоздат коммиты в текущей ветке поверх выбранного Вами коммита. Подчёркиваю: будут созданы новые коммиты, которые в принципе соответствуют Вашим старым, но являются всего лишь их копиями (а могут и не являться, если Вам это требуется, или если в процессе переналожения Вы будете вынуждены разрешать конфликты).

Итак, вначале эта команда предложит Вам выбрать порядок переналожения коммитов, запустив $EDITOR / core.editor со списком коммитов . Можете оставить предложенный git'ом список как есть, можете поменять порядок следования коммитов, можете вообще убрать какие-то коммиты. Я рекомендую выбившийся из цепочки коммит (см. gitk --all) накладывать первым (самым верхним) или последним (самым нижним) в списке.

После того, как список сформирован, нужно будет его сохранить и выйти из редактора. Далее git продолжит свою работу по возможности неинтерактивно.

Разрешение конфликтов. Будьте готовы к тому, что при наложении [выбившегося] коммита произойдёт конфликт, и автоматический процесс переналожения набора коммитов будет приостановлен до тех пор, пока Вы не разрешите все конфликтные места.

Для разрешения конфликтов удобно воспользоваться программой наподобие kdiff3 или meld, указав её git-у в качестве merge.tool:

apt-get install kdiff3
git config --global merge.tool kdiff3

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

git mergetool

и последовательно разрешить все обнаруженные конфликты.

После того, как конфликты разрешены, нужно оценить [глазами или тестами] результат, и, если всё хорошо, выполнить

git rebase --continue

и git продолжит процесс переналожения коммитов до следующей конфликтной ситуации или до конца списка.

Если в какой-то момент до окончания Вы решите отменить весь процесс целиком, Вы можете прервать выполнение, а потом сказать

git rebase --abort

и всё вернётся к Вашему первоначальному состоянию, «как будто ничего не было».

После того, как процесс ребэйза завершён (запустите ещё раз gitk и убедитесь в том, что «всё красиво»), Вам нужно опубликовать новую цепочку [на bitbucket].

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

Вообще, это ай-яй-яй, так делать низзя. [Гипотетические] пользователи Вашего репозитория уже могли склонировать его себе и начать какую-то свою работу поверх Ваших коммитов. Им придётся вытащить себе новую историю и перенакладывать свои коммиты поверх неё. Они могут разозлиться. Но если Вас это не пугает, то можете переписывать :)

У push для этого есть ключик -f . В крайнем случае, Вы можете удалить соотв. ветку на bitbucket.org и перезалить её снова.

Ну, вот как-то так :)

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

git log --pretty=raw ...

Добавлю, что существует возможность переписать историю, выправив весь набор коммитов в единую цепочку. Подчёркиваю: это действие НЕ является сколько-нибудь обязательным, и чаще всего проводится [неофитами git-а] для удовлетворения своего [ложного] чувства прекрасного. Однако, иногда такая возможность бывает полезна.

Итак, перед началом процедуры нужно выбрать последний перед нежелательным ветвлением коммит, допустим этот коммит имеет хэш abcdef. Выполняем команду git rebase -i abcdef. Эта команда пересоздат коммиты в текущей ветке поверх выбранного Вами коммита. Подчёркиваю: будут созданы новые коммиты, которые в принципе соответствуют Вашим старым, но являются всего лишь их копиями (а могут и не являться, если Вам это требуется, или если в процессе переналожения Вы будете вынуждены разрешать конфликты).

Итак, вначале эта команда предложит Вам выбрать порядок переналожения коммитов, запустив $EDITOR / core.editor со списком коммитов . Можете оставить предложенный git'ом список как есть, можете поменять порядок следования коммитов, можете вообще убрать какие-то коммиты. Я рекомендую выбившийся из цепочки коммит (см. gitk --all) накладывать первым (самым верхним) или последним (самым нижним) в списке.

После того, как список сформирован, нужно будет его сохранить и выйти из редактора. Далее git продолжит свою работу по возможности неинтерактивно.

Разрешение конфликтов. Будьте готовы к тому, что при наложении [выбившегося] коммита произойдёт конфликт, и автоматический процесс переналожения набора коммитов будет приостановлен до тех пор, пока Вы не разрешите все конфликтные места.

Для разрешения конфликтов удобно воспользоваться программой наподобие kdiff3 или meld, указав её git-у в качестве merge.tool:

apt-get install kdiff3
git config --global merge.tool kdiff3

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

git mergetool

и последовательно разрешить все обнаруженные конфликты.

После того, как конфликты разрешены, нужно оценить [глазами или тестами] результат, и, если всё хорошо, выполнить

git rebase --continue

и git продолжит процесс переналожения коммитов до следующей конфликтной ситуации или до конца списка.

Если в какой-то момент до окончания Вы решите отменить весь процесс целиком, Вы можете прервать выполнение, а потом сказать

git rebase --abort

и всё вернётся к Вашему первоначальному состоянию, «как будто ничего не было».

После того, как процесс ребэйза завершён (запустите ещё раз gitk и убедитесь в том, что «всё красиво»), Вам нужно опубликовать новую цепочку [на bitbucket].

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

Вообще, это ай-яй-яй, так делать низзя. [Гипотетические] пользователи Вашего репозитория уже могли склонировать его себе и начать какую-то свою работу поверх Ваших коммитов. Им придётся вытащить себе новую историю и перенакладывать свои коммиты поверх неё. Они могут разозлиться. Но если Вас это не пугает, то можете переписывать :)

У push для этого есть ключик -f . В крайнем случае, Вы можете удалить соотв. ветку на bitbucket.org и перезалить её снова.

Ну, вот как-то так :)