Комментарии 24
делаем откат изменений в для примера на два назадЭто на два коммита назад, а не на два дня.
git reset --hard HEAD~2
Хеш можно взять в вебинтерфейсе гитхаба.А еще вытащить из вывода git log и вообще любого просмотрщика истории коммитов для git.
И вообще, причем здесь github.com?
нигде про дни не сказано.
П.С. а статья действительно нафиг не нужна. Или это хинт?? Для себя или для кого-то? В любом случае этому тут не место
П.С. а статья действительно нафиг не нужна. Или это хинт?? Для себя или для кого-то? В любом случае этому тут не место
Ну для тех кто гитом пользуется только нужно.
Кому ЭТО нужно?!
На Хабре есть удобно собранные команды по Git — habrahabr.ru/blogs/Git/60347/
Я уже не говорю о man и поиске в инете…
На Хабре есть удобно собранные команды по Git — habrahabr.ru/blogs/Git/60347/
Я уже не говорю о man и поиске в инете…
Перефразировал про откат.
Тут как бы ничего нового нету.
Еще можно было бы описать здесь когда еще можно пользоваться
Это если нужно внести изменения в последний комит без создания нового. Не рекомендуется использовать в большой команде (даже противопоказано я бы сказал). Делать push --force можно только в том случае, если ты уверен, что в этот момент никто не делает push из твоей команды.
git push -f:git add -A
git commit --amend -m 'commit message'
git push -f
Это если нужно внести изменения в последний комит без создания нового. Не рекомендуется использовать в большой команде (даже противопоказано я бы сказал). Делать push --force можно только в том случае, если ты уверен, что в этот момент никто не делает push из твоей команды.
А не проще git pull — git commit — git push?
А можно ли в гите/гитхабе как-то слить несколько коммитов в один? Простой пример: закоммитил фичу какую-то, запушил в центр, задеплоил её из центра, проверил, а там опечатка, пофиксил, опять закоммитил, запушил и задеплоил. Всё ок. Но не хочется, чтобы промежуточный коммит был всем виден. Хочется сделать такой коммит, чтобы из всех реп, которые клонились/пуллились с репа в котором был коммит с опечаткой, он исчез при следующем пулле…
Вообще несколько коммитов можно слить в один с помощью
git rebase -i — но в данном случае, когда коммиты уже запушены, так делать категорически не стоит. Ребэйс по сути создает новые коммиты вместо старых — а если старые уже лежат в центральном репозитории, и другие разработчики основывают свою работу на них, git push -f здорово усложнит им жизнь.О других разработчиках речи нет, но вот пуши и пуллы в центр с нескольких клонов возможны. В начале любой правки первая команда pull, а push со стороны между локальным циклом push-commit-pull исключён. Но вот pull с ненужной в истории опечаткой попасть в другой клон через центр может до того как её пофиксили.
Я пытался решить эту задачу в Mercurial с помощью плагинов, но от надобности помнить о rebase в каждом клоне не избавился. Думал может из-за этого нюанса git популярнее hg :-/
Я пытался решить эту задачу в Mercurial с помощью плагинов, но от надобности помнить о rebase в каждом клоне не избавился. Думал может из-за этого нюанса git популярнее hg :-/
Есть и другой способ решить проблему — использовать популярный workflow, при котором работа над фичей ведется в отдельной ветке, а потом мерджится в основную линию разработки с ключом
Правда, если опечатка обнаружилась уже после мерджа в основную линию, тут уже ничего не поделаешь.
--squash (все изменения ветки сплющиваются в один коммит). В этом случае можно не беспокоиться о чистоте истории — после мерджа ветка фичи все равно обычно удаляется.Правда, если опечатка обнаружилась уже после мерджа в основную линию, тут уже ничего не поделаешь.
Хм, а если работа над веткой велась итерационно, несколько мержей было, но без создания новой ветки, то изменения в одном коммите будут накапливаться между мержами или игнорируя предыдущие мержи? По идее первое, но мало ли.
И ещё вопрос если можно — под веткой вы имеете в виду clone или branch? Просто часто сталкивался в hg — говорят «ветка», а имеют в виду «клон».
И ещё вопрос если можно — под веткой вы имеете в виду clone или branch? Просто часто сталкивался в hg — говорят «ветка», а имеют в виду «клон».
Не очень понял про мержи — если ветка под фичу не создается, и работа ведется в одной и той же ветке, то что с чем мерджить тогда? :)
А под веткой я имею в виду branch. Клон — это уже отдельный репозиторий.
А под веткой я имею в виду branch. Клон — это уже отдельный репозиторий.
Ветка под фичу создаётся, но после мержа не удаляется, а разработка фичи в ней продолжается, потом ещё мерж и т. д. При этом в основную вносятся и другие коммиты.
В этом случае каждый мердж из фичи в основную ветку будет отдельным коммитом (добавляющим в основную ветку изменения, сделанные в фиче с момента последнего мерджа), и такие коммиты-мерджи будут лежать там вперемешку с другими коммитами.
Я бы не использовал такой workflow — какой смысл в ветке для фичи, если она регулярно мерджится в основную? Тогда уж проще делать все сразу в основной, заодно можно будет и исправлять последний коммит через
Я бы не использовал такой workflow — какой смысл в ветке для фичи, если она регулярно мерджится в основную? Тогда уж проще делать все сразу в основной, заодно можно будет и исправлять последний коммит через
git commit --amend.Правильнее тут будет откатиться софтом и закоммитить ещё раз этот коммит и будет у вас тот же самый, но правильный коммит.
Это будет бест практик в таком случае.
Это будет бест практик в таком случае.
Делать git push --force — за исключением редких случаев очень плохая идея. Обычно это приводит к повторному клонированию репозитория остальными участниками команды.
На смену jQuery-разработчикам пришли пользователи такой VCS, как github.com.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как откатить коммиты на github.com