Комментарии 32
Может нужно начать с того в каких случая можно, в каких случаях нельзя использовать git для управления версиями исходников. В каких конфигурация он помогает, а в каких он реально просто мешает и создает трудности. Привести для сравнения решения одной и той же задачи контроля версий на примере 3-4 вариантов и показать все +++ и ---.
При всём своём опыте я бы не взялся за то, что вы хотите. Если взять простейший вариант — то вы не увидите разницы — любая SCM умеет делать базовые операции. Если вдаваться в подробности, то вы не поймете зачем это всё там нужно (иначе у вас не было бы таких вопросов).
Поэтому проще всего для начинающего разработчика взять любую современную SCM – mercurial или git. Если же вы уже работаете с какой-либо системой, то не меняйте её пока сами не почувствуете, что переросли её.
Новичку — меркуриал. Он безопаснее и им практически невозможно отстрелить себе ногу.
Когда набьется практика — можно попробовать гит. Он предоставляет больше возможностей, но вместе с большой силой приходит большая ответственность. Редкий человек не отстрелит себе ногу-другую в первые месяцы знакомства с гитом.
Если новичок работет над проектом в команде, то он будет использовать то, что и остальные. Если в одиночку, то вряд ли будет делать что-то сложное с VCS, поэтому все равно стоит взять гит. Так или иначе, придется потратить время на освоение этого инструмента, позже окупится
Новичку — git, и мастеру git, и вообще всем git, где команда больше одного человека. Ибо де-факто индустриальный стандарт, почти весь опенсорс на гите, и зачительная часть закрытой разработки тоже. А жаль, меркуриал я когда-то использовал, и он мне показался как-то удобнее и человечнее.
Я заметил, что больше всех подобные комментарии выдают люди у которых нет ни одной публикации.
Видимо потому, что не понимают сколько труда стоит «накатать» такой материал, причем как правило написать его не ради «профита», а просто чтобы поделится с людьми, сделать, что-то полезное.
Поэтому еще раз повторюсь, думаю прививка в виде собственной статьи, является лучшим лекарством от подобных комментариев.
П.С. Я если честно статью прочитал по диагонали (время уже позднее и сил нет), но выглядит она хорошо, я добавил в закладки и обязательно прочитаю более вдумчиво, поэтому хочу сказать спасибо автору и пожелать творческих успехов!

Как я понимаю, в картинке под фразой «Вот как будет выглядеть ваше дерево после soft reset и нового коммита» пропущена стрелочка от зеленого кружка к красному.
Лучше изменить подход немного и походу чтения статьи пробовать выполнять комманды и доводить деревья к деревьям в примерах
Видеоуроки не помогут. Практика, практика и еще раз практика. И, конечно же, чтение документации, статей и т.п.
«Просветление» наступило (и до сих пор постепенно происходит) только после того как сел, открыл git book, и начал «прорабатывать» каждую главу на практике. Вплоть до того, что создал репу на гитхабе, склонил её на комп и на отдельный ноут — имитируя таким образом работу нескольких разработчиков, конфликты и т.д.
я просто использовал простой прием: вызов stash перед тем, как разлогиниться каждый день вечером (конечно, только если я вносил какие-то изменения в мое рабочее дерево), и соответствуюзий вызов stash apply при каждом новом логине.
временную работу — в стэши на 30 дней? ох-ох-ох… не делайте так…
одна из засад со стэшами, например, в том, что при их удалении при
pop
, они стираются из reflog
, и тогда придётся колдовать c git fsck
как по мне, stash нужен лишь для кратковременного переключения между ветками и последующим быстрым возвратом назад (ну или для переноса изменений между коммитами, переключение между которым не проходит без него), но не для сохранения незаконченных фич…
У меня есть практический вопрос-просьба к автору перевода или к гуру, владеющим GIT.
В небольшой компании используются несколько серверов (Debian 5-9).
При развёртывании серверов всегда ставится пакет etckeeper. Это, кто не знает, такая классная штука, которая отслеживает все изменения в каталоге /etc, шлёт алерты об изменениях на почту, в Телеграм и т.д. ну и, естественно, использует GIT для этого дела. Поскольку на серверах много различного ПО, пара мониторинговых систем, а так-же бекапятся текстовые конфиги, за несколько лет этот каталог .git в /etc/ начал занимать столько места, сколько занимает вся остальная OS, и даже чуток больше ;).
Вопрос такой — какую можно выполнить красивую команду (или группу команд), для того, что-бы очистить (удалить полностью!) записи старее чем, допустим, один месяц?
Спасибо.
В гите с некоторых пор есть механизм для неполного клонирования, можно попробовать использовать его у вас. Если вам нужно оставить, например, последние 100 коммитов истории, искомые команды будут какие-то такие:
# mv /etc/.git /tmp/etckeeper.git
# git clone --bare --depth 100 file:///tmp/etckeeper.git /etc/.git
# rm -rf /tmp/etckeeper.git
Нужно только позаботиться об обработке возможных ошибок и убрать захардкоженное имя временной директории. Плюс, добавить поиск по истории, если нужно работать именно по дате, а не количеству последних коммитов. В общем, придётся оформить в виде полноценного скрипта. Кстати, file:///
— это важно.
Предложенный способ привлекателен тем, что убирает из репозитория коммиты без изменения хэшей оставшихся, как это сделал бы git rebase
. Но я не гарантирую отсутствие подводных камней.
В visual studio code встроен гит клиент или как это назвать. Очень наглядно, интуитивно. Все комманды можно вызывать из меню (не надо искать их тексты в шпаргалках, как я делал раньше). Всем рекомендую
К примеру, сразу возникают вопросы — что такое «операция переключения между ветками», что при этом происходит? Почему на понятие checkout «повешено» сразу два значения — это самое переключение и слив на комп из репозитория?
Если кто подскажет статью «git для таких вот даунов», буду признателен.
Почему на понятие checkout «повешено» сразу два значения — это самое переключение и слив на комп из репозитория?
А здесь ответа и не будет. На эту тему (некоторой нелогичности интерфейса) даже карикатуры есть.
К примеру, сразу возникают вопросы — что такое «операция переключения между ветками», что при этом происходит? Почему на понятие checkout «повешено» сразу два значения — это самое переключение и слив на комп из репозитория?
«слив на комп из репозитория» делается через clone и fetch. А через checkout — только в svn.
В git же команда checkout делает два действия: 1) делает выбранную ветку текущей 2) приводит рабочее дерево к состоянию текущего коммита (верхняя стрелка на первой картинке).
Git снизу вверх