Как стать автором
Обновить

Комментарии 32

Опять повторение стандартной документации. Сколько можно повторений!
Может нужно начать с того в каких случая можно, в каких случаях нельзя использовать git для управления версиями исходников. В каких конфигурация он помогает, а в каких он реально просто мешает и создает трудности. Привести для сравнения решения одной и той же задачи контроля версий на примере 3-4 вариантов и показать все +++ и ---.
У меня довольно большой опыт работы с приложениями для контроля версиями (SCM). Начинал с MS SourceSafe, потом CVS, активно учувствовал в разработке Borland StarTeam, потом Subversion как для себя, так и по работе в polarion.com — Subversive Subversion Team Provider for Eclipse. Довелось работать и с IBM Rational ClearCase (брр..). Сейчас использую Mercurial для своих проектов и git на работе.
При всём своём опыте я бы не взялся за то, что вы хотите. Если взять простейший вариант — то вы не увидите разницы — любая SCM умеет делать базовые операции. Если вдаваться в подробности, то вы не поймете зачем это всё там нужно (иначе у вас не было бы таких вопросов).
Поэтому проще всего для начинающего разработчика взять любую современную SCM – mercurial или git. Если же вы уже работаете с какой-либо системой, то не меняйте её пока сами не почувствуете, что переросли её.
Всё просто.

Новичку — меркуриал. Он безопаснее и им практически невозможно отстрелить себе ногу.

Когда набьется практика — можно попробовать гит. Он предоставляет больше возможностей, но вместе с большой силой приходит большая ответственность. Редкий человек не отстрелит себе ногу-другую в первые месяцы знакомства с гитом.

Если новичок работет над проектом в команде, то он будет использовать то, что и остальные. Если в одиночку, то вряд ли будет делать что-то сложное с VCS, поэтому все равно стоит взять гит. Так или иначе, придется потратить время на освоение этого инструмента, позже окупится

Новичку — git, и мастеру git, и вообще всем git, где команда больше одного человека. Ибо де-факто индустриальный стандарт, почти весь опенсорс на гите, и зачительная часть закрытой разработки тоже. А жаль, меркуриал я когда-то использовал, и он мне показался как-то удобнее и человечнее.

Напишите такую статью, будет интересно.
Чем замечателен Хабр? Тем, что для всех кто на него пробился, это площадка с равными возможностями. Не нравится, что кто-то в 10-й раз пишет статью для новичков и она попадает в ленту? Так пожалуйста всё в Ваших руках, напишите СВОЮ ГЕНИАЛЬНУЮ СТАТЬЮ получите за нее кучу «лайков» сотни плюсов в карму и любуйтесь на нее в «топах» ленты. Все люди разные у всех разный взгляд на вопрос. И даже если человек в «10-й раз» пишет о каких-то начальных азах одного и того же, вполне возможно, что через иной угол рассмотрения или через другой стиль подачи его материал найдет своего благодарного читателя.
Я заметил, что больше всех подобные комментарии выдают люди у которых нет ни одной публикации.
Видимо потому, что не понимают сколько труда стоит «накатать» такой материал, причем как правило написать его не ради «профита», а просто чтобы поделится с людьми, сделать, что-то полезное.
Поэтому еще раз повторюсь, думаю прививка в виде собственной статьи, является лучшим лекарством от подобных комментариев.

П.С. Я если честно статью прочитал по диагонали (время уже позднее и сил нет), но выглядит она хорошо, я добавил в закладки и обязательно прочитаю более вдумчиво, поэтому хочу сказать спасибо автору и пожелать творческих успехов!


Спасибо за наводку на 'git purr', это отлично! :)
пожалуйста, ради этого все и писалось :))
Их только 3 штуки?
Я нашёл только pull, push и merge/rebase
Неплохая статья (хоть и больше вводная, но все же), только вот косяков многовато, причесать бы ее. Как минимум картинка переведена неверно(где git lifecycle), отсутствует пара предлогов. А так, фундаметальненько
спасибо, картинку поправили. А где еще косяки? все поправлю с удовольствием, если увижу
Отличная статья. Спасибо!
Как я понимаю, в картинке под фразой «Вот как будет выглядеть ваше дерево после soft reset и нового коммита» пропущена стрелочка от зеленого кружка к красному.
нет, не пропущена. Так в оригинале. HEAD же отбрасывается, поэтому не нужна ему стрелка :)
Он отбрасывается, но у него по-прежнему есть parent commit. На него теперь никто не ссылается, но он сам то указывает! И из reflog его всегда можно восстановить.
Про родительский коммит вы правы безусловно, но, просто это в данном случае несущественно для текста.Про восстановление из reflog написано на том самом рисунке :)
Легко читается, не каждому это удается, спасибо.
Да, возможно как то бы начать с небольшого проекта и как им управлять не спеша. А то после 10 абзаца я потерялся. Но сам смысл и понимание — теорию я немного уловил. Спасибо за такую большую статью. Теперь осталось на ютубе видео уроки посмотреть и можно использовать в практике. Честно признаюсь для новичков статья тяжеловата.

Лучше изменить подход немного и походу чтения статьи пробовать выполнять комманды и доводить деревья к деревьям в примерах

Видеоуроки не помогут. Практика, практика и еще раз практика. И, конечно же, чтение документации, статей и т.п.

Начал осваивать Гит только пару лет назад с помощью вот таких вот статей, видео, web интерактивных обучающих сервисов. Это было ужасно, я ничерта не понимал (до этого системы контроля версий вообще не использовал). Я бы не советовал начинающим такие статьи.
«Просветление» наступило (и до сих пор постепенно происходит) только после того как сел, открыл 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 встроен гит клиент или как это назвать. Очень наглядно, интуитивно. Все комманды можно вызывать из меню (не надо искать их тексты в шпаргалках, как я делал раньше). Всем рекомендую

К сожалению статья не очень хороша. Не очень понятна. Ранее я с git можно сказать не работал, только с SVN. Вероятно статья кажется хорошей тем, кто с git давно и хорошо знаком.
К примеру, сразу возникают вопросы — что такое «операция переключения между ветками», что при этом происходит? Почему на понятие checkout «повешено» сразу два значения — это самое переключение и слив на комп из репозитория?
Если кто подскажет статью «git для таких вот даунов», буду признателен.
Я бы посоветовала сначала еще раз прочесть первую часть этой статьи :) там явно объясняется, что веток вообще не существует :)
НЛО прилетело и опубликовало эту надпись здесь
Почему на понятие checkout «повешено» сразу два значения — это самое переключение и слив на комп из репозитория?

А здесь ответа и не будет. На эту тему (некоторой нелогичности интерфейса) даже карикатуры есть.
К примеру, сразу возникают вопросы — что такое «операция переключения между ветками», что при этом происходит? Почему на понятие checkout «повешено» сразу два значения — это самое переключение и слив на комп из репозитория?

«слив на комп из репозитория» делается через clone и fetch. А через checkout — только в svn.
В git же команда checkout делает два действия: 1) делает выбранную ветку текущей 2) приводит рабочее дерево к состоянию текущего коммита (верхняя стрелка на первой картинке).
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.