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

[cypok]

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

Это на два коммита назад, а не на два дня.

Хеш можно взять в вебинтерфейсе гитхаба.

А еще вытащить из вывода git log и вообще любого просмотрщика истории коммитов для git.

И вообще, причем здесь github.com?

[Anserchik]

нигде про дни не сказано.

П.С. а статья действительно нафиг не нужна. Или это хинт?? Для себя или для кого-то? В любом случае этому тут не место

[opium]

Ну для тех кто гитом пользуется только нужно.

[Alukardd]

Кому ЭТО нужно?!
На Хабре есть удобно собранные команды по Git — habrahabr.ru/blogs/Git/60347/
Я уже не говорю о man и поиске в инете…

[SbWereWolf]

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

[opium]

Перефразировал про откат.

[btd]

Тут как бы ничего нового нету.

[ka8725]

Еще можно было бы описать здесь когда еще можно пользоваться git push -f:
git add -A
git commit --amend -m 'commit message'
git push -f

Это если нужно внести изменения в последний комит без создания нового. Не рекомендуется использовать в большой команде (даже противопоказано я бы сказал). Делать push --force можно только в том случае, если ты уверен, что в этот момент никто не делает push из твоей команды.

[TheShock]

А не проще git pull — git commit — git push?

[denver]

Это не откатит коммиты, о чем речь?

[TheShock]

Название топика вводит в заблуждение. Решение этой проблемы:

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

через откат коммитов категорически неверное.

[denver]

Поддерживаю, следующий push от «разработчиков» вернет коммиты на место :)

[TheShock]

А если все «разработчики» будут работать через откат коммитов — это вообще веселье

[VolCh]

А можно ли в гите/гитхабе как-то слить несколько коммитов в один? Простой пример: закоммитил фичу какую-то, запушил в центр, задеплоил её из центра, проверил, а там опечатка, пофиксил, опять закоммитил, запушил и задеплоил. Всё ок. Но не хочется, чтобы промежуточный коммит был всем виден. Хочется сделать такой коммит, чтобы из всех реп, которые клонились/пуллились с репа в котором был коммит с опечаткой, он исчез при следующем пулле…

[7even]

Вообще несколько коммитов можно слить в один с помощью git rebase -i — но в данном случае, когда коммиты уже запушены, так делать категорически не стоит. Ребэйс по сути создает новые коммиты вместо старых — а если старые уже лежат в центральном репозитории, и другие разработчики основывают свою работу на них, git push -f здорово усложнит им жизнь.

[VolCh]

О других разработчиках речи нет, но вот пуши и пуллы в центр с нескольких клонов возможны. В начале любой правки первая команда pull, а push со стороны между локальным циклом push-commit-pull исключён. Но вот pull с ненужной в истории опечаткой попасть в другой клон через центр может до того как её пофиксили.

Я пытался решить эту задачу в Mercurial с помощью плагинов, но от надобности помнить о rebase в каждом клоне не избавился. Думал может из-за этого нюанса git популярнее hg :-/

[7even]

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

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

[VolCh]

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

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

[7even]

Не очень понял про мержи — если ветка под фичу не создается, и работа ведется в одной и той же ветке, то что с чем мерджить тогда? :)

А под веткой я имею в виду branch. Клон — это уже отдельный репозиторий.

[VolCh]

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

[7even]

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

Я бы не использовал такой workflow — какой смысл в ветке для фичи, если она регулярно мерджится в основную? Тогда уж проще делать все сразу в основной, заодно можно будет и исправлять последний коммит через git commit --amend.

[opium]

Правильнее тут будет откатиться софтом и закоммитить ещё раз этот коммит и будет у вас тот же самый, но правильный коммит.
Это будет бест практик в таком случае.

[Exabiche]

Делать git push --force — за исключением редких случаев очень плохая идея. Обычно это приводит к повторному клонированию репозитория остальными участниками команды.

[minister35]

На смену jQuery-разработчикам пришли пользователи такой VCS, как github.com.