Инструкция-шпаргалка для начинающих

  • Tutorial
Если в один прекрасный момент вам ударило в голову желание насадить разумное, доброе, вечное, и пересадить всех с SVN на GIT, сразу встают три проблемы:
  • Объяснить зачем это нужно разработчикам и руководству
  • Ввести в обиход новую схему работы с кодом
  • Научить ничего не подозревающих девелоперов новым техникам

Поскольку мы пользуемся весьма эффективной схемой работы с кодом через git в одном из проектов, я решил её внедрить всюду, до куда дотянулись руки, для чего оформил в небольшую инстркуцию-шпаргалку, включающую в себя краткие ответы на «Зачем», описание схемы работы и список команд и телодвижений для разработчика с новой системой.

Основные постулаты работы с кодом:
  • Каждая задача решается в своей ветке.
  • Коммитим сразу, как что-то получили осмысленное.
  • В master мержится не разработчиком, а вторым человеком, который производит вычитку и тестирование изменения
  • Все коммиты должны быть осмысленно подписаны.
  • Репозиторий должен держаться сухим и шелковистым

Так как некоторые разработчики почему-то работают под Windows, пришлось описать в том числе и установку-настройку-рецепты при работе под Windows.

Полученной инструкцией я кидаюсь во всех новых и старых разработчиков, которым даю доступ до репозиториев с рабочим кодом.

Предупреждаю сразу, инструкция отвечает на вопрос «зачем» разработчику, незнакомому с DVCS, а не начальству.
Так же, предполагается, что master ветку никогда не трогают с --force, желательно, чтобы это было невозможно вообще (зарезано на уровне gitolite).
Инструкция — начинающих разработчиков, а не Tips & Tricks, из этих соображений я опустил моменты «выхода из самосозданной задницы». Все случаи не упомнишь, гораздо проще разрулить на месте по факту если что-то из ряда вон выходящее.

Собственно инструкция: Работа с Git.pdf (135Kb).
Для желающих адаптировать её к своей ситуации, исходник: Работа с Git.odt (90Kb).
p.s.: Забыл сказать о лицензии: Public Domain. Делайте что хотите, только в терновый куст не бросайте.

Буду благодарен каким-либо полезным комментариям, указанием на очепятки и прочему фидбеку.
Поделиться публикацией
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама
Комментарии 65
  • +5
    Ссылочку на .odt поправте…

    И спасибо за труд.
    • +5
      Ой! :) И правда. Спасибо огромное, поправил.
    • +1
      Отличный мануал, буду делится им со всеми знакомыми кто еще не перешел на GIT и говорят «а зачем нам парится, нас все устраивает» :)
      • +2
        в случаях, если кто-то сделает push c --force, pull будет работать не всегда правильно. В этом случае для мастер ветки надо заменить «git pull» на «git fetch origin; git reset --hard origin/master» и «git rebase master» на «git rebase -i master»
        • +1
          Предполагается, что master ветку никогда не трогают с --force, причем это зарезано на уровне gitolite.
          Инструкция, она для начинающих разработчиков, а не Tips & Tricks.
          Исключительно из этих соображений я опустил моменты «выхода из самосозданной задницы».
          • +1
            Данным аспектам вполне уместно было бы оказаться в предисловии публикуемой инструкции.
      • +2
        * Объяснить зачем это нужно разработчикам и руководству
        это вот всё-таки важный, но нераскрытый момент :) Особенно в контексте «зачем нужно руководству».

        Краткий ответ: потому что не появляются задержки от работы с системой контроля версий.

        Это не слишком весомый аргумент. Задержки на связь с локальным хранилищем при 100% работе в рамках офиса — фактически никакие.

        А переход на новую систему контроля версий — это сама по себе задержка/время/деньги.
        • +2
          К сожалению, в случае с SVN это не так. Для того, чтобы создать новую ветку, слить ветки, выгрузить версию, загрузить версию, на любой коммит — уходит время, причем довольно ощутимое даже в локальной сети — на каждый чих вычисляются диффы.
          В нашем случае, хранилище находится не в локальной сети на на серверах в Интернете (офисы децентрализованы и разбросаны по нескольким странам и городам), что добавляет еще бОльшие задержки.
          Работая с DVCS этих задержек нет, любые изменения и телодвижения происходят без задержек.
          Потери времени на переход на другую SCM были практически нулевыми — только на изучение инструкции, и сделать checkout нового репозитория в понедельник утром.
          Разработчики они всё-таки умные люди, и потому сменить TortoiseSVN на TortoiseGIT не так сложно, а «лишние» телодвижение на создание ветки и ревью кода окупаются снижением ошибок в продакшене.
          • +3
            А что, кто-то бранчит в свине? :-)
            • 0
              Да, но только для действительно мажорных работ.
          • +1
            Чуть не забыл ответить на главное! «Особенно в контексте «зачем нужно руководству».»
            Руководству надо одно — чтобы процесс шел. Причем процесс шел лучше, чем был.
            А инструкция — она для разработчиков, зачем это надо им.
          • +1
            А вообще может ли кто поделиться сравнением всех основных систем контроля версий: CVS, SVN, Git, Mercurial? Так получилось, что я не работал ни с одной из них и даже не представляю, с какой начинать знакомство.
            • 0
              CVS сразу забыть как архивную, и сразу смотреть на SVN как хороший пример централизованной системы («старого типа» в моём понимании).
              Git или Mercurial представители DVCS и по сути близки, о разнице между ними писали много в том числе на хабре.
              Для себя я сделал выбор в сторону Git, но разницы с чем начинать жить нет никакой — изучение базовых команд занимает день, углубление в дебри идёт естественным путём в процессе по мере столкновения.
            • +1
              у нас не практикуется массовое использование бранчей, поэтому один раз кликнуть коммит удобнее, чем собирать коммиты в пачку и затем пушить на сервер.
              • 0
                Основной плюс «массовых бранчей» — история мастера плоская, но при просмотре дерева истории сразу видно когда какой баг решался.
                Основной плюс «пачки коммитов» — можно во-1х проследить логику разработчика (упрощает жизнь ревьюера), во-2х очень бегло смотреть на некоторые изменения типа «добавил в дерево готовый фреймворк», которые добавляют много файла, и мешают читать основной дифф.
              • +2
                GIT хорошая штука.

                Я вообще-то приверженец CVS, поскольку ну хватало нам его всегда раньше.
                Когда была война кланов CVS и SVN и молодость победила, я в общем то не понимал принципиальных отличий между работой под CVS и SVN. Ну да, ну действительно шуршало оно сервером, когда происходили многочисленные коммиты и вообще в процессе работы, ну и что :-).

                А вот GIT это действительно революционная штука.

                Спасибо за статью!
                • +1
                  Исходя из моего опыта, гит лучше понимается и воспринимается, если изучать его снизу вверх: начиная с комманд git cat-file, git update-ref, git write-tree, git reflog, git rev-parse и т.д. Даже есть вот такой туториал на аглицком: ftp.newartisans.com/pub/git.from.bottom.up.pdf.
                  • 0
                    Ссылка не работает. Там в конце лишняя точка. Вот правильная: ftp.newartisans.com/pub/git.from.bottom.up.pdf
                    • 0
                      Сам гит может быть, но вот с точки зрения пользователя, это убийство веником и взрыв мозга бедного девеолпера, который еще вчера писал всё в одного для самого себя любимого не используя VCS.
                    • 0
                      Для работы с Git под Windows самое удобное – использовать TortoiseGit.

                      SmartGit гораздо удобней.
                      • 0
                        Вы реселлер? :)
                        • 0
                          Нет, довольный юзер. Вообще этот клиент бесплатен для персонального использования.
                          • 0
                            Ну у меня не персональное использование, и честно, лично я пользуюсь командной строкой даже в винде.
                            Черепах удобен виндузятникам просто потому, что они пересаживаются с TortoiseSVN, а потому им просто запомнить новые три буквы.
                            • 0
                              Я пересел с SmartSVN :)

                              А так да, тоже иногда консолькой пользуюсь.
                      • +1
                        Абсолютно согласен с вашими постулатами по работе с кодом.

                        Но я только одного не пойму, разве для этого необходимо переходить на Git? Почему в Subversion тоже самое нельзя сделать? При этом я подразумеваю, что создание нового бранча — это не часы, а минут 10. Или в Git'е реализована еще более крутая система автомерджинга?

                        • +2
                          Чтобы понять в чем отличие работы с ветками в GIT и SVN надо попробовать там и там.
                          После этого на SVN возвращаться не захочется.
                        • +2
                          >Или в Git'е реализована еще более крутая система автомерджинга?

                          Да. Бранчи и мержи в Гите — банальны. Это, пожалуй, самое подходящее слово. Раз — и готово. Занимает секунды.
                          • 0
                            Доли секунды! :)
                            • +1
                              Ну, с такой скоростью я не умею команды набирать:)
                        • +1
                          Не всем ;)
                          • 0
                            Посыпаю голову пеплом :( Был уверен что присылал.
                          • +3
                            Объясните, зачем Вы делаете rebase? Какую проблему Вы этим решаете и какую пользу от этого получаете?
                            • +2
                              1) Плоская история. Отсутствуют merge коммиты вносящие какие-либо разрешения конфликтов.
                              Это позволяет локализовать, отменять отдельные фичи и прочие вещи без создания дополнительных конфликтов.
                              2) Разрешение конфликтов самим разработчиком. Ты стартовал используя мастер от утра понедельника, сдаёшь в обед среды. За это время в мастере могло поменяться много чего. Ты сам производишь разрешение всех конфликтов в своём коде так, как будто ты только что в среду начал и сразу же сдал. Протестировав относительно самого последнего кода.
                              В целом, используя такой подход (сливать только чистые изменения), история проекта становится сухой и шелковистой.

                              При работе классическим образом, сливая просто ветки «как есть», процесс разрешения конфликтов либо падает на review'ера, либо история становится «косичкой» — сделали вилку из мастера в ветку A, потом слили в мастер ветку B, потом слили в A новый мастер, потом результат опять слили в мастер. Получается косичка, в которой не всегда ясно что откуда пришло и какое изменение создало проблемы.

                              Если история «плоская», всегда существует точка, которая вводит баг. И git bisect становится панацеей.
                              • 0
                                1. Не понял. Вы что, исправления конфликтов делаете путем мержа в мастер?
                                2. Опять не понял. Разработчик сам решает конфликты, при чем тут rebase?

                                Про косичку я опять Вас не понял. Как раз в случае косички все изменения предельно ясны — четко видно, что откуда взялось и куда влилось.

                                Если история плоская, Вы не можете взять и отменить бранч, внесший проблему. Вы можете только отменить коммит, но это не всегда возможно, потому что проблема запросто может быть размазана по нескольким коммитам.
                                • +2
                                  В мастер слияние производит не автор кода, а ревьюер, который вычитывает и проверяет работоспособность кода. Если код основан не на последнем мастере, возможны конфликты которые надо будет решить в момент merge.
                                  Как еще можно обновить код чтобы он соответствовал последнему мастеру, оставляя его в ветке, кроме «merge master» или «rebase master»?

                                  В случае косички видно, что начинали делать относительно определённого кода, в момент слияния с мастером потребовались такие-то изменения.
                                  В случае ребейза информация о том, что потребовался какой-то микрорефакторинг просто исчезает, так как она не является информативной.

                                  Например, мы делили апельсин поменяли все функции класса, добавив им в конце парметр (, Request=None).
                                  Это изменение уже в мастере.

                                  В ветке мы писали новый метод этого класса, причем начали писать до этого изменения.
                                  Если мы мержим — у нас появляется доп коммит типа «add Request argument, as introduced in solution to bug #Y».
                                  Если мы делаем rebase, мы напарываемся на конфликт в момент ребейза уже на самом первом коммите, добавляем прямо там этот аргумент, и делаем rebase continue.
                                  На выходе — ветка, в которой этот аргумент _был изначально_. Тем самым, мы избавляемся от непонятного лишнего неинформативного коммита.
                                  • +2
                                    Ревьюер смержил с мастером — увидел конфликт — откатил мерж — вернул бранч автору на доработку. Пока автор не исправит конфликт, его бранч в мастер не пойдет. А еще правильнее, чтобы автор сам проверял наличие конфликта, мержа с мастером в своем локальном репозитории.

                                    Исчезновение информации о микрорефакторинге — это отвратительно. Ребейз разрывает связь между коммитами одного бранча, из-за этого становится невозможно откатить весь бранч.

                                    Пример:

                                    Через некоторое время после мержа обнаруживаем, что внесен баг.

                                    Мое решение — найти мерж, на котором был внесен баг, и откатить весь бранч.

                                    Ваше решение — найти коммит и что-то с ним сделать. Что? Откатить коммит в общем случае нельзя — ведь он логически и функционально связан с прочими изменениями в других коммитах. Откатив коммит, Вы порвете эту связь и сломается вообще всё. Откатить бранч целиком Вы не можете — ребейз уничтожил информацию о связанных коммитах. Что Вы будете делать?
                                    • +1
                                      В мастере _есть_ мержи всех веток, так как они туда мержатся после ребейза с --no-ff.
                                      Поэтому откатывается _весь_ мерж.
                                      Ребейз не уничтожает информацию о связанных коммитах — цепочка как была так и осталась.
                                      Судя по вопросам, вы ни разу не пользовали ребейз?
                                      • 0
                                        Я не использую ребейз. То, что делает ребейз — это уничтожение чрезвычайно важной информации о цепочке коммитов. Это отвратительно, поэтому я его не использую. Для меня остается загадкой, для чего люди используют эту вредную функцию.

                                        Но если Вы говорите, что ребейз не уничтожает информацию — тогда я ничего не понимаю. Что тогда делает ребейз?
                                        • +1
                                          Ребейз меняет родителя у цепочки коммитов.
                                          То есть было: A=>B=>C=>D
                                          Стало: Q=>B'=>C'=>D'
                                          • 0
                                            Не понимаю, зачем это надо. Есть где-нибудь подробное описание с примерами? Хочу решить для себя эту загадку. Потому что функция явно вредная, но ведь не спроста же ее придумали.
                                            • +2
                                              Вредность функции в том, что ребейз можно делать только пока ты полностью контролируешь ветку.
                                              А если есть некая ветка, в которой A=>B=>C=>D, её кто-то слил к себе и сделал E.
                                              После ребейза у тебя стало Q=>B'=>C'=>D'
                                              А E по-прежнему основывается на D а не на D'.
                                              Вот это и есть проблема.

                                              То же самое с --amend.
                                              Но если ты единственный и неповторимый контроллер ветки, то делай с ней всё что угодно — хоть rebase, хоть amend коммитов прошлых — всё будет в порядке.

                                              Советую вкурить оригинальную документацию и мысли Линуса на тему чистой истории
                                              Еще по теме:
                                              www.jarrodspillers.com/2009/08/19/git-merge-vs-git-rebase-avoiding-rebase-hell/
                                              blog.experimentalworks.net/2009/03/merge-vs-rebase-a-deep-dive-into-the-mysteries-of-revision-control/
                                              • +4
                                                Черт подери! ВНЕЗАПНО я все понял. Во времена разбирательства с ребейзом я почему-то еще не открыл для себя --no-ff, а без него получалось именно то, о чем я говорил — отребейзеная ветка сливалась с мастером в прямую линию, не образуя мержа. Вот и получалось, что информация о бранче терялась.

                                                Теперь у меня все состыковалось. Ребейз — клевая штука, спасибо:)
                                                • +1
                                                  Толи еще будет когда вы узнаете про «git rebase -i» ;)
                                • НЛО прилетело и опубликовало эту надпись здесь
                                  • +1
                                    В мастере поддерживается прямая история, состоящая из мержей с --no-ff.
                                    То есть выглядит это так:
                                    *------*-----*-----*
                                    _`----' `---' `---'

                                    Где * — это коммиты в мастере, merge'ы, а петельки под ним — непосредственно ветки по каждой фиче-багу
                                    • 0
                                      Поддерживаю. Я всегда делаю --no-ff.
                                • +4
                                  По-моему mercurial лучше
                                • +1
                                  Поясните мне, пользователю SVN с многолетним стажем, спросить пару вещей о git:

                                  1. Коммит происходит в локальный репозиторий. В мастер-ветку делается push только по окончанию разработки некоторой фичи (что вполне может занять пару дней или даже неделю). Так вот — не страшно ли, что в это время винт на машине разработчика сдохнет и всё пойдет прахом (на SVN-сервере всяко есть и бекапы и RAID, а иначе это и не сервер никакой)?
                                  2. Если коммит происходит в локальный репозиторий — как мне работать над фичей с разных машин (например, с работы и из дому)?
                                  3. Если фича касается нескольких разных людей (например — какой-нибудь протокол, поддержка которого должна параллельно наращиваться клиентом и сервером, которые разрабатываются разными людьми) — как над этим вообще работать? В SVN люди могут поочередно добавлять запросы-ответы в репозиторий, тестируя каждый свою часть кода, а тут у каждого — свой репозиторий. Как взаимодействовать?
                                  • +3
                                    1. В инструкции я как раз и пишу, чтобы пуш делали минимум раз в день — перед уходом, либо если переключаются надолго на другую ветку.
                                    2. Пуш ветки перед уходом, дома pull эту ветку и продолжил работу.
                                    3. У нас как правило получается так, что сервер делает фичу, тестирует, заливает, после этого ставится задача фронтенду и бэкенду на поддержку. Они делают у себя фичу, тестируют, заливают.

                                    Да, можно в одну ветку по очереди коммитить а-ля svn, тогда перед каждым коммитом делается так:
                                    git stash
                                    git pull origin specialbranch
                                    git stash pop
                                    git add/rm
                                    git commit
                                    git push origin specialbranch
                                    получится как в svn — все изменения по очереди накладываются разными людьми в общую ветку на сервере.
                                    • +3
                                      Спасибо, Вы очень хорошо объяснили. Я понял, что некоторые вещи я раньше не так понимал.
                                      • 0
                                        При работе с разных машин делаю так:
                                        git fetch && git reset --keep origin/my
                                        При этом, если по случайности исправил один файл там и тут, то комманда не проходит, и дальше можно решать, как мёрджить.
                                    • 0
                                      Вот ещё эпическая статья, про то как правильно использовать git. Всем очень советую к прочтению.
                                      nvie.com/posts/a-successful-git-branching-model/
                                      • 0
                                        Статья великолепная. В приложение к ней обязательно к применению: git-flow
                                      • 0
                                        Да, сейчас все переходят на DVCS, и это правильно. Но вот я недавно на одной конференции слышал как докладчик с упоением рассказывал как круто они используют для синхронизации кода между разработчиками… Dropbox! Про SVN, или, боже упаси, GIT, они вообще, наверное, не слышали… Вот так вот люди делают игры для социальных сетей.
                                        З.Ы. Имелась в виду конференция SocialDev в Питере.
                                        • 0
                                          Спасибо за труд, отличная дока!.. Поможет многим сомневающимся начать использовать git.
                                          • 0
                                            Ссылки на pdf и odt побились. Можете перезалить куда-нибудь?
                                            • 0
                                              временные трудности — поднять свой блог как всегда некогда :)
                                              pdfку пока взять можно тут
                                              • 0
                                                И опять поломалось :)
                                            • 0
                                              спасибо, теперь нашлось! )
                                              • 0
                                                «Твой костоломовский почерк по сводкам узнаю». Ну действительно, к кому и идти с такими вопросами, как не к лучшему другу. :-)

                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.