Комментарии 28
Да, reset`ом частенько пользуюсь, полезно.
Наверное каждый кто только начинал работать с git следовали другими командами:
- скопировать папку с репозиторием куда-нибудь
- удалить исходную папку
- git clone ...
- вернуть изменения с помощью copy-paste
Она помогает избавиться от глупых опечаток, которые иногда закрадываются в коммиты.
От глупых опечаток в коммите помогает избавиться команда "git commit --amend". А такой ресет часто полезен когда надо слить 2 или более коммитов на одной ветке в один.
А вместо экзотической "git reset --hard HEAD~1" проще использовать обычный checkout, если конечно workspace чистый... Гораздо чаще используется команда "git reset --hard HEAD" чтобы как-раз этот workspace почистить от изменений. Ну "git clean" с флажками по вкусу тоже иногда бывает нужен.
Про аменд соглашусь, но вот слить несколько коммитов в один лучше через "git rebase -i ...", а не через reset --soft. Тем более это совсем не обязательно нескольо последних коммитов.
Про то, что проще использовать обычный checkout не соглашусь. Проще запомнить, что "git reset --hard COMMIT" гарантированно приводит рабочее пространство к определенному состоянию, а запоминать разные способы уже как бы лишнее. Тем более вы не противник ресета, а просто ограничиваете область его применения.
checkout на коммит сделает "detached head", а ветку не тронет.
Что делать, если удалённая ветка оказывается удалённой?
Это была шутка про великий и могучий русский язык, серьёзно отвечать не надо.
стешить стоит и с новыми файлами
git stash --include-untracked
которые не удаляет git reset --hard
но можно удалить их
git clean -df
предварительно проверив, ничего ли лишнего не удаляем с помощью
git clean -dfn
git remote update
Кажется, хаб PHP стоит поменять на хаб Git
3-5 доставили.
3 – "как я в первый раз сломал git репозиторий" (hg не ломался вообще, а тут в первую же неделю). Не надо этому учить новичков. Пусть вначале разберутся с reflog... А тогда они уже сами будут знать про reset --hard.
Вообще git reset – это как во времена DOS файлы Disk Editor-ом восстанавливать... Можно восстановить, а можно всё сломать. А может оказаться, что уже и не восстановить (gc прошёл).
Как вообще всё это можно выучить, если постоянно этим не пользуешься?((
Не нужно учить. Нужно прочитать документацию/книгу что бы иметь общее представление о возможностях. Что бы знать что гуглить.
А вот когда они понадобятся, вот тогда уже разбираться.
Использовать GUI, чтоб ничего не учить, очевидно. И даже не гуглить.
Покажите мне хотя бы один gui, который может например смержить 3 ветки через octopus?
Я думаю вы даже не слышали о таком. Да и не услышите, пока продолжаете пользоваться gui.
Если вы запускаете octopus вручную на машине разработчика — у вас очень насыщенная и интересная жизнь. С такой жизнью не до GUI, конечно.
Вот видите, вы даже не поняли о чем речь. Я не про сервис для деплоя. Я про мерж-стратегию говорю, коих в гите штук 20 есть.
Собрать монорепозиторий с сохранением истории? Пожалуйста - subtree.
Удалить секреты при публикации проекта? Пожалуйста - filter-branch.
И куча всего, о чем в GUI нет даже упоминания.
Мне приходилось за 10 лет 2 раза использовать subtree merge. Но я бы и не подумал что это вообще возможно, если б не вычитал в книге. Я бы просто грохнул всю историю, копипастнув код.
На картинке octopus merge. У коммита 4 родителя.
Вот видите, вы даже не поняли о чем речь.
Пардон, не владею телепатией.
Я про мерж-стратегию говорю, коих в гите штук 20 есть.
Всё еще не подразумевает необходимость сливания многих веток на машине разработчика. Для этого есть пулл реквесты и CI.
Ну и не говоря уж о том, что Git Extensions это прекрасно делает. Из GUI.
Собрать монорепозиторий с сохранением истории? Пожалуйста — subtree.
Это определенно то, что надо знать, ага.
За 12 лет работы с гитом это мне пригодилось ровно 0 раз, хотя прочитал об этом я в рамках начального погружения в git.
Удалить секреты при публикации проекта? Пожалуйста — filter-branch.
Секреты сразу не надо хранить, это во-первых. А во-вторых — я считаю filter-branch откровенно небезопасной вещью, и совершенно правильно, что её нет в нормальных GUI.
И куча всего, о чем в GUI нет даже упоминания.
С примерами у вас, правда, не очень задалось. Но я конечно вам и так поверю — куча так куча.
Покажите мне хотя бы один gui, который может например смержить 3 ветки через octopus?Почему бы просто не заменить такую экзотику на два последовательных слияния?
Ключ -p для всех команд, которые его поддерживают.
p.s. Надо бы сваять бота, который бы оставлял подобные комментарии в то и дело появляющихся постах про команды git.
8 недооцененных команд Git, которые должен знать каждый программист (помимо привычных pull, push, add, commit)