GIT почему-то влепил коммит в середину истории. Теперь не могу откатиться.

прямой команды на merge не давал

git pull это git fetch и git merge, см. ман.

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

Я рекомендую прочесть книгу по гит. Станет гораздо понятнее.

Диагноз предыдущего автора совершенно корректен. Для того, чтобы наглядно оценить сложившуюся после Ваших действий картинку, можете запустить 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 и перезалить её снова.

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

git commit -a

Это равносильно

git add .
git commit

git commit -a

Это равносильно

git add .
git commit

Почти. Это равносильно:

git add -u .
git commit

А что, git reset --hard HEAD~1 не помогает вернуться к предыдущему состоянию?

Или можно вообще сделать новый мастер, в котором не должно быть твоего тупикового коммита:

git branch -m old-master
git checkout -b master origin/master

Итак, перед началом процедуры нужно выбрать последний перед нежелательным ветвлением коммит

Проблема в том, что у меня нет нежелательного ветвления. У меня ветвление было вполне желательно, и я не ожидал что оно вот так вот выйдет боком.

Как я делал это ветвление, написано здесь:

Git: как откатиться назад, но оставить коммит для истории
Git: как откатиться назад, но оставить коммит для истории

После этого «отката» я перепроверил, что нахожусь в основной ветке, сделал тестовый коммит («Первый коммит после о...» на рисунке), убедился что коммит нормально коммитится.

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


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


PS: Да, не любит меня Git. Решил повтыкать в ProGit, а git-scm.com недоступен. Он переехал что-ли куда-то, и я об этом не знаю?

Ну, с полной уверенностью можно предположить, что commit2 с Вашего рисунка оказался тем или иным способом на bitbucket, причём, в тамошней ветке master. Могу предположить, что перед тем, как сресетиться обратно на commit1, Вы выполнили git push <bitbucket> master.

Почему я в этом уверен? Потому что Ваш листинг №2 из нынешнего вопроса, про невозможность git push однозначно говорит, что состояния ветки master в Вашем локальном репозитории и ветки master на bitbucket разошлись, перестали вытягиваться в линию.

Вообще, на самом деле, git внутри устроен очень просто :)

Каждый коммит состоит из слепка некоторого дерева файлов и связанной с этим слепком метаинформации: кто сохранил состояние дерева, когда и зачем, с каким комментарием.

Кроме того, у каждого коммита есть 0, 1 или более «предков».

Когда Вы создаёте первый коммит в пустом репозитории, то у этого коммита оказывается 0 предков, то есть он становится корневым.

Когда Вы просто совершаете ряд последовательных коммитов, то у каждого из них оказывается ровно один предок - предыдущий коммит.

Когда Вы делаете мёрж, то получается коммит с 2 (или более, если мёрж более сложный) предками.

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

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

Заметьте, до сих пор я вообще ни разу не упомянул огров ветки. Собственно говоря, всему этому графу и git'овской машинерии по его созданию и модификации ветки не нужны, они превосходно существуют и без веток*. Можно создавать коммиты, не привязанные ни к каким веткам, перепрыгивать с коммита на коммит, используя только уникальный идентификатор коммита (sha1) итп

Какая-либо ветка в случае git'а - это просто метка, именованный указатель на какой-либо определённый коммит в графе. Нужны они, в основном для удобства человеков, а также для того, чтобы встроенный в git сборщик мусора, который запускается каждые N коммитов или N дней, мог определить, что некоторый коммит более не требуется, так как ни одна из существующих в репозитории веток-меток не указывает на цепочку коммитов, в которую включён данный коммит (здесь, натурально, прямые аналогии с тем, как работает GC в яве).

Ветки разделяются на локальные (те, которые предназначены для модификации в данном локальном репозитории) и ремоутные - это копии локальных веток в каком-либо удалённом репозитории. Вы можете зайти в каталог .git и глазами посмотреть на содержимое каталога .git/refs/ и файлика .git/packed-refs. Если хотите, можете создать новые или изменить существующие файлики в refs или записи в packed-refs, а потом выполнить команды git log, git branch или запустить графическую гляделку на дерево коммитов (gitk или qgit)

С учётом вышеизложенного коммит в git происходит так:

1. Вы подготавливаете дерево файлов и добавляете его в индекс (как устроен индекс, пока не важно, важно, что в нём сохраняется точное состояние файлов). За формирование индекса ответственна команда git add (git add -i делает картинку более сложной, но непринципиально)
2. далее Вы говорите git commit. git в ответ на это выполняет такую последовательность действий:
   1. Из .git/HEAD вычитывается ссылка на текущий верхний коммит. Если в .git/HEAD находится непосредственно SHA1 коммита (эта ситуация возможна, если Вы перед этим говорили git checkout abc123def), то используем его в качестве родительского. Если в .git/HEAD находится ссылка на какую-либо ветку (например, ref: refs/heads/master), то вычитываем, на какой sha1 указывает эта ветка, и используем результат как родителя.
   2. далее формируем из сохранённого в индексе состояния файлов и накопленной мета-информации навый коммит в репозитории (на git-scm.com есть хорошая статья, как сделать это при помощи колышков и скотчанизкоуровневых утилит). На выходе у нас SHA-1 только что сделанного коммита.
   3. после этого обновляем ветку-ссылку: если в HEAD было явно прописан SHA-1 предка, то пишем туда новый SHA-1. Если в HEAD была ссылка не ветку, то новый SHA-1 пишется в файлик этой ветки.
   4. очищаем индекс

Вот так, можно сказать, примитивно, всё и работает.

git fetch в этой схеме - это, в целом, получение из удалённого репозитория точных копий (с тем же sha-1) коммитов, отсутствующих в репозитории локальном и сохранение в .git/refs/remotes/<repository-id>/... тех веток (указателей), которые имеются в удалённом репозитории в .git/refs/heads.

git push - это отправка в удалённый репозиторий точных копий локальных коммитов, отсутствующих в нём, и опять же, обновление ссылок. Здесь ситуация немножко сложнее в том смысле, что git push (вернее низкоуровневый git-receive-pack, который запускается на удалённом для приёма данных git-push) по умолчанию модифицирует ссылки непосредственно в .git/refs/heads удалённого репозитория. Поэтому по умолчанию здесь допускаются только такие изменения веток-меток, которые меняют ссылку на коммит, являющийся потомков («сыном», «внуком» и так далее) текущего коммита. Ну, чтобы ничего случайно не потерялось.

git pull - это как Вам уже указали, git fetch с последующим git merge-м.

git reset <sha1> - это запись в текущую ветку-метку нового значения. Если при этом используется --hard, то вдобавок изменяется ещё и текущее дерево и состояние индекса.

Во-от, как-то так. Ложки не существует.

Ох, не любит меня Git.

дальше можно не читать

git add .
git commit -a
git push

Кстати, почему он такой многословный? После привычных hg ci && hg push вводить это регулярно задалбывает…

Как вариант, стоит почитать пока что это: http://www-cs-students.stanford.edu/~blynn/gitmagic/intl/ru/index.html

Настрой алиасы в .gitconfig. И дождёшься таки, чтобы руки оторвали тебе за коммиты всего и вся.

Кстати, почему он такой многословный? После привычных hg ci...

Охх...

git config alias.ci '!sh -c "set -e; if test $# -eq 0; then git add -u; else git add "$@"; fi; git commit"'

Соль и перец по вкусу.

Надеюсь, не облажался в кавычках. Если облажался, или если хочется навернуть сильно больше логики по разбору параметров, то можно реализовать честным скриптом в /usr/libexec/git-core. Но, как Вы понимаете, это остаётся в качестве упражнения читателю.

git add -u воспроизводит поведение SVN, более-менее. Ну, ради тех, кому хочется почувствовать себя вернувшимся на 10 лет назад :) Тогда, поди, и гемо радикулит не так часто мучал, и вообще девушки вокруг были моложе.

Настрой алиасы в .gitconfig. И дождёшься таки, чтобы руки оторвали тебе за коммиты всего и вся.

Ну только если я сам себе их оторву, ибо я единственный разработчик.

Ну в общем, восстановил состояние на нужный мне коммит. Локально восстановил, естественно. Пришлось создать restore-ветку, в ней экспериментировать.

Теперь надо понять, как это состояние залить на сервер, чтобы не напороться по второму разу на те же грабли.

Насколько я понял, проблема в том, что локально и на сервере не совпадают ветки. Мне бы, честно говоря, хватило бы того, чтобы на сервере было тупо зеркало моего локального репозитария.

Поэтому сейчас стоит вопрос: по какому пути пойти? Разбираться, как заливать только ветку, или разбираться, как заливать данные для получения полного зеркала на сервере.

git branch -v master shit *recovery

git branch -D master git branch -m master git push -f origin master

ну, для начала просто попробовать

git push <remote-server> -f master

(<remote-server> - это обычно origin, но вообще при помощи git remote можно вывести весь список и управлять им, если надо)

В зависимости от настроек удалённого сервера эта команда (принудительное переписывание ветки master) может сработать, а может и нет. «Заборонено, см. рис. 1». Если forced push не удался, то можно попробовать удалить ветку master в удалённом репозитории вовсе:

git push <remote-server> :master

(в этом случае мы отправляем пустой референс в master на <remote-server>, что эффективно удаляет его). После этого можно заливать текущий локальный master обычным способом.

Если же и второй способ не сработал («здравствуй, Gerrit!» :) ), то можно попытаться удалить ветку master через web-интерфейс удалённого сервера. Я почему так уверенно говорю про web-интерфейс: «обычные» git-сервера с настолько жестокими настройками по манипулированию ветками если и существуют, то наверняка там есть внешняя, нестандартная система управления правами, которая обычно доступна через web.

Хочу обратить внимания на то, что данная команда

git branch -D master

но вообще при помощи git remote можно вывести весь список и управлять им, если надо

Весь список чего?

Если forced push не удался

Блин, о форсед пуш речи выше по тексту не идет.

в этом случае мы отправляем пустой референс

Что есть референс?

После этого можно заливать текущий локальный master обычным способом

Обычным - это каким?

Весь список чего?

список сконфигурированных удалённых репозиториев. В каждом локальном репозитории может отслеживаться состояние нескольких удалённых. Для этого информацию о их местонахождении заносят в .git/config либо при промощи команды git remote, либо текстовым редактором. Команда git remote --help , как и все остальные команды git, показывает релевантную страничку man. Попробуйте её прочесть, чтобы мне не было нужды пересказывать её Вам.

Блин, о форсед пуш речи выше по тексту не идет.

push -f (== push --force) - это как раз forced push.

Что есть референс?

reference. ссылка. См. выше мой рассказ про то, что ветки в git - это метки. Теги, кстати, тоже метки. Просто они не двигаются туда-сюда, и у них есть режим с GPG-подписью и прочими атрибутами, более сложный, чем просто запись в .git/refs/tags.

Обычным - это каким?

git push <remote> master

без ключика --force

Вообще, повторюсь, у каждой git'овой команды есть соответствующая ей страничка man. Добывается при помощи ключика --help . Не стесняйтесь ей пользоваться.