Как откатить коммиты на github.com

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

    Выбираем нужный бранч(ветку), у меня она master
    git checkout master

    делаем откат изменений в репозитории для примера на два коммита назад
    git reset --hard HEAD~2

    Можно сделать до какого то определенного коммита по хешу
    git reset --hard HEAD hash
    Хеш можно взять в вебинтерфейсе гитхаба.

    Далее делаем принудительный коммит в основной репо на гитхабе
    git push -f origin master
    без -f будет ругаться что у вас версия младше чем в гитхабе и вам надо сделать pull
    Share post

    Similar posts

    Comments 24

      +4
      делаем откат изменений в для примера на два назад
      git reset --hard HEAD~2
      Это на два коммита назад, а не на два дня.

      Хеш можно взять в вебинтерфейсе гитхаба.
      А еще вытащить из вывода git log и вообще любого просмотрщика истории коммитов для git.

      И вообще, причем здесь github.com?
        –2
        нигде про дни не сказано.

        П.С. а статья действительно нафиг не нужна. Или это хинт?? Для себя или для кого-то? В любом случае этому тут не место
          –3
          Ну для тех кто гитом пользуется только нужно.
            +2
            Кому ЭТО нужно?!
            На Хабре есть удобно собранные команды по Git — habrahabr.ru/blogs/Git/60347/
            Я уже не говорю о man и поиске в инете…
              0
              мне нужно, но гугл мне почему то не выдал эту статью когда я искал ответ.
          0
          Перефразировал про откат.
          +1
          Тут как бы ничего нового нету.
            0
            Еще можно было бы описать здесь когда еще можно пользоваться git push -f:
            git add -A
            git commit --amend -m 'commit message'
            git push -f

            Это если нужно внести изменения в последний комит без создания нового. Не рекомендуется использовать в большой команде (даже противопоказано я бы сказал). Делать push --force можно только в том случае, если ты уверен, что в этот момент никто не делает push из твоей команды.
              0
              А не проще git pull — git commit — git push?
                0
                Это не откатит коммиты, о чем речь?
                  +1
                  Название топика вводит в заблуждение. Решение этой проблемы:
                  Ситуация когда у вас уже есть клон репозитория с которым вы работаете, делаете pull и смотрите что там какая то фигня накоммитчена от разработчиков.

                  через откат коммитов категорически неверное.
                    +2
                    Поддерживаю, следующий push от «разработчиков» вернет коммиты на место :)
                      +2
                      А если все «разработчики» будут работать через откат коммитов — это вообще веселье
                0
                А можно ли в гите/гитхабе как-то слить несколько коммитов в один? Простой пример: закоммитил фичу какую-то, запушил в центр, задеплоил её из центра, проверил, а там опечатка, пофиксил, опять закоммитил, запушил и задеплоил. Всё ок. Но не хочется, чтобы промежуточный коммит был всем виден. Хочется сделать такой коммит, чтобы из всех реп, которые клонились/пуллились с репа в котором был коммит с опечаткой, он исчез при следующем пулле…
                  0
                  Вообще несколько коммитов можно слить в один с помощью git rebase -i — но в данном случае, когда коммиты уже запушены, так делать категорически не стоит. Ребэйс по сути создает новые коммиты вместо старых — а если старые уже лежат в центральном репозитории, и другие разработчики основывают свою работу на них, git push -f здорово усложнит им жизнь.
                    0
                    О других разработчиках речи нет, но вот пуши и пуллы в центр с нескольких клонов возможны. В начале любой правки первая команда pull, а push со стороны между локальным циклом push-commit-pull исключён. Но вот pull с ненужной в истории опечаткой попасть в другой клон через центр может до того как её пофиксили.

                    Я пытался решить эту задачу в Mercurial с помощью плагинов, но от надобности помнить о rebase в каждом клоне не избавился. Думал может из-за этого нюанса git популярнее hg :-/
                      0
                      Есть и другой способ решить проблему — использовать популярный workflow, при котором работа над фичей ведется в отдельной ветке, а потом мерджится в основную линию разработки с ключом --squash (все изменения ветки сплющиваются в один коммит). В этом случае можно не беспокоиться о чистоте истории — после мерджа ветка фичи все равно обычно удаляется.

                      Правда, если опечатка обнаружилась уже после мерджа в основную линию, тут уже ничего не поделаешь.
                        0
                        Хм, а если работа над веткой велась итерационно, несколько мержей было, но без создания новой ветки, то изменения в одном коммите будут накапливаться между мержами или игнорируя предыдущие мержи? По идее первое, но мало ли.

                        И ещё вопрос если можно — под веткой вы имеете в виду clone или branch? Просто часто сталкивался в hg — говорят «ветка», а имеют в виду «клон».
                          0
                          Не очень понял про мержи — если ветка под фичу не создается, и работа ведется в одной и той же ветке, то что с чем мерджить тогда? :)

                          А под веткой я имею в виду branch. Клон — это уже отдельный репозиторий.
                            0
                            Ветка под фичу создаётся, но после мержа не удаляется, а разработка фичи в ней продолжается, потом ещё мерж и т. д. При этом в основную вносятся и другие коммиты.
                              +1
                              В этом случае каждый мердж из фичи в основную ветку будет отдельным коммитом (добавляющим в основную ветку изменения, сделанные в фиче с момента последнего мерджа), и такие коммиты-мерджи будут лежать там вперемешку с другими коммитами.

                              Я бы не использовал такой workflow — какой смысл в ветке для фичи, если она регулярно мерджится в основную? Тогда уж проще делать все сразу в основной, заодно можно будет и исправлять последний коммит через git commit --amend.
                    0
                    Правильнее тут будет откатиться софтом и закоммитить ещё раз этот коммит и будет у вас тот же самый, но правильный коммит.
                    Это будет бест практик в таком случае.
                    +1
                    Делать git push --force — за исключением редких случаев очень плохая идея. Обычно это приводит к повторному клонированию репозитория остальными участниками команды.
                      +1
                      На смену jQuery-разработчикам пришли пользователи такой VCS, как github.com.

                      Only users with full accounts can post comments. Log in, please.