Ежедневный Git

    Уже были статьи про основы гита (0, 1, 2), были и статьи про внутреннее устройство репозитория. Сегодня поговорим, как простому смертному работать с гитом на автопилоте и не морочить себе голову.

    Во-первых, шорткаты (в порядке убывания популярности):

    alias gst='git-status'
    alias ga='git-add'
    alias gc='git-commit -m'
    alias gp='git pull && git push'
    alias gull='git pull'
    alias gush='git push'
    alias gb='git-branch'
    alias gco='git-checkout'
    alias gd='git-diff'

    Во-вторых, отображение текущей ветки в командной строке:
    export PS1='`__git_ps1 "%s"` \w \$ '

    Выглядит так:
    lazy-args-in-futures ~/Work/io/oleganza-io.git $

    (Как установить: ericgoodwin.com/2008/4/10/auto-completion-with-git)

    Типичный поток работы в одной ветке


    1) Что-то пописали, прогнали тесты
    2) $ gst — увидели, какие файлы новые, какие обновленные.
    3) $ ga a b c — добавили новые и обновленные файлы в индекс.
    4) $ gc 'something is done' — записали коммит в репозиторий
    5) Снова что-то написали, снова закоммитили.
    6) $ gp — слили чужие изменения, залили свои изменения. Если вдруг возник конфликт, вам об этом напишут, будете мерджить.

    Чтобы просто подтянуть обновления, набираем $ gull (git pull).

    Локальные ветки

    Принцип: одна фича — одна ветка. Один багфикс (если предполагается длиннее двух коммитов) — одна ветка. Один эксперимент — одна ветка. Одна фича внутри эксперимента — ветка от ветки. Ну, вы уловили идею.

    Зачем оно нужно? Представьте, что вы начали день с фичи А, а к вам подошли и сказали, что нужно зафиксить Б. А через пять минут выяснилось, что для того, чтобы по-человечески зафиксить Б, нужно прикрутить и проверить Ц. Если каждую из этих задач держать в отдельных ветках, то голова не пойдет кругом, и работа не встанет поперек горла.

    Набираем:
    master ~/project $ gco -b my-feature

    Получаем:
    my-feature ~/project $

    Список всех веток: $ gb
    Переключиться на другую ветку: $ gco some-branch

    Не забывайте, что вы всегда можете подлить какую-нибудь ветку в текущую с помощью git merge other-branch.

    Жизненные ситуации с ветками

    1) Исправление бага/добавление фичи. Делаем ветку, все тестируем, подливаем в нее master: gull && git merge master, снова тестируем, выходим в мастер (gco master), подливаем ветку (git merge my-branch), тестируем, заливаем мастер (gush) и удаляем ветку (gb -D my-branch).

    2) Публикация ветки для совместной работы: gush origin my-branch:refs/heads/my-branch
    Удаление ветки: gush origin :refs/heads/my-branch (внимание на пробел перед двоеточием)

    3) Вы сидите в одной ветке и сделали что-то, что хотели бы закоммитить в другую ветку. Если вы еще не закоммитили, то делаем git reset HEAD для уже добавленных файлов (через ga/git-add), потом git-stash, выходим в нужную ветку, делаем git-stash apply и далее действуем так, как будто мы прямо тут все и меняли.

    4) Вы сделали коммит в некоторую экспериментальную ветку, который имеет смысл залить в мастер, но git merge my-branch не подходит, потому что после этого коммита были еще несколько экспериментальных коммитов.

    На этот случай есть git-cherry-pick. Вначале, посмотрите git-log и скопируйте номер нужного коммита. Далее, вы должны закоммитить все изменения в той ветке, в которую будете кидать выдернутый коммит. Затем, делаете git-cherry-pick и разруливаете конфликты, если возникли.
    У меня такая ситуация была именно с добавлением коммита в мастер, поэтому после этих хирургических манипуляций мне нужно было подлить мастер в локальную ветку. Поскольку cherry-pick всего лишь применяет дифф (номер коммита становится другим), то ветка не знает, что внесенное изменение у нее уже есть, и не может нормально его смерджить. Поэтому, при мердже мастера в ветку вы гарантированно получите глупые конфликты а-ля «строчка АБВ конфликтует с АБВ».
    Если кто-нибудь знает, как избежать конфликтов в такой ситуации (и сэкономить 5 минут времени), поделитесь опытом.

    Скучные нравоучения напоследок

    1) Коммиты должны быть мелкими. Дифф на пять экранов должен быть исключением, а не правилом.
    2) На первых порах не морочьте себе голову с rebase и «чистотой» линии коммитов. Это беспокоит только последних эстетов или Линуса (который мерджит десяток веток в день). Читать git-log и игнорировать банальные merge commits нет никакой проблемы.
    3) Читайте git-log после pull, ругайте своих коллег за невразумительные описания коммитов.
    4) Изучите .git/config :-)

    В следующий раз нужно написать пару слов о комфортной работе с git-submodule и git-svn.
    Поделиться публикацией
    Похожие публикации
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 36
    • 0
      Под кат, пожалуйста.
      • 0
        чем гит лучше моего svn сервера? для меня это самвй важный вопрос.. я почитал и совсем немножко представляю его отличия, но пока не вижу реальной выгоды. а вы?
        • 0
          Возьмите и попробуйте поработать сами. Иначе тут будет холивар и разговор глухого со слепым.
          • 0
            от меня - не будет.. я же вашего субъективного мнения спрашиваю, мне интересно. просто для мало того, что ror переехал на git :) я хочу понять зачем это стоит делать кроме "расширения кругозора", потому что svn и git - вторичные инструменты и просто так переходить не хочется.
            • +3
              Мое мнение: гит проще, быстрее и надежнее.
              • 0
                насчет проще с oleganza не соглашусь, у нас даже после длительной работы с свн вьезжали долго

                работа с ветками (мерджи) дествительно гораздо проще
                • 0
                  практика с SVN только мешает при переезде на git.
                  • 0
                    У меня девушки которые ручным тестирование и контентом заведуют вполне справляются.

                    Картинку добавить, css поправить, простенький шаблон поменять. Потом все закоммитить и вылить на сервер. Не преувеличивайте сложность.
              • +4
                Для меня было две практических причины перейти с svn на mercurial для своих проектов:
                - в distributed scm намного лучше дела с бранчами
                - не надо париться с бекапами — каждая рабочая копия уже независимый бэкап репозитория
                • 0
                  по поводу первого пункта, нельзя–ли поподробнее? Что конкретно намного лучше ? Я конечно про сравнение с svn 1.5

                  А какая запарка с бэкапами у вас в svn? Это одна комманда в крон, ну или 5 минут на организацию полного зеркала
                  • 0
                    Сразу скажу — имхо, действительно серьезные и объективные преимущества у DVCS есть svn есть только в достаточно распределенных проектах. Ну или люди говорят, удобно в большой команде — более точно можно контролировать доступ к основной ветке. Вроде того что у каждого тимлида по ветке, они сливают туда изменения от подчиненных, делают review, а потом Самый Главный Лид мержит в главную ветку.

                    Что касается меня: да, 1.5 я еще не пробовал толком — для своих нужд уже к меркуриалу привык, а на работе, прости господи, VSS. Меркуриал определенно мне нравится скоростью, маленьким размером репозитория, и тем что бранч в общем-то можно создать тупо скопировав папку с исходниками.

                    С зеркалами очень просто, для этого нужно два компутера, а у меня репозиторий на VDS и 3-4 компутера с которых я работаю, и ни один из них не включен круглосуточно.
                • +1
                  Лично мне Git не нравится. Собственно - git это куча скриптов, бинарников и тому подобного которое работает как одна большая scm. Плюс, не нравится что базу время от времени нужно пересобирать что бы оно не тормозило и не жрало много места.
                  Из личных предпочтений - Mercurial. Во первых нормально работает на разных платформах (да да, знаю, Git уже тоже доточили напильником для винды). Во вторых - быстро работает. В третьих - command-line интерфейс не сильно отличается от SVN. В четвертых - написан на питоне, достаточно компактен, кода относительно не много (меньше чем в Git, Bazaar и SVN раза в два при той же функциональности). Работает чуть медленнее Git, но быстрее Bazaar. Есть виндовый гуй а-ля TortoiseSVN. Trac умеет работать с репозиторием.

                  P.S. У Mercurial и Git общие корни - все выросло из обсуждения в linux-kernel mailing list. Просто ребята не договорились как делать scm и пошли своими дорогами.
                  • +1
                    Чтобы не было холивара, предупрежу всех читателей, что тема Git vs. Mercurial уже обсуждалась в миллионе блогов. Ищите их в гугле и ругайтесь там.
                    • +1
                      Я не собираюсь разводить холивар, ни в коем случае. Просто высказал свое мнение.
                  • +1
                    У нас на проекте использовался svn + track. Почти год назад перешли на git и жить стало легче. Так как распределенная разработка, то если пропадает связь до сервера, не беда, есть локальный репозитарий, на своем компьютере. Когда линк поднимается, можно сделать push на сервер.
                    "git stash"/"git stash apply" - вещь супер.
                  • +2
                    Редкий пример хорошей статьи. Спасибо.
                    • 0
                      > Уже были статьи про основы гита, были и статьи про внутреннее устройство репозитория.
                      Хотелось бы ссылочек, если можно.
                    • +2
                      Вместо gs лучше использовать gst, ибо

                      $ gs --help
                      ESP Ghostscript 8.15.4 (2007-03-14)
                      • +2
                        Разумно. Но я пока что с gs проблем себе не создал. Буду иметь в виду.
                      • +1
                        Кстати, помнишь ты говорил, что "export PS1='`__git_ps1 "%s"` \w \$ '" работает только в последней версии.
                        • +1
                          маленькое замечание к 3): вместо git-stash && git-checkout && git-stash apply можно использовать git-checkout -m
                          • НЛО прилетело и опубликовало эту надпись здесь
                            • 0
                              Спасибо, добавил в список ссылок.
                              • 0
                                У Вас, надо сказать, намного понятнее для неподготовленного читателя, т.е. для меня
                              • 0
                                Спасибо большое за статью. Будет очень интересно почитать про git-svn.
                                • 0
                                  пользуюсь SVN
                                  git отпугивает тем, что воодит новые сущности, надобность в которых сильно не ощущается
                                  хотя сама идея децентрализованного хранилища и работы с локальным репозиторием кажется правильной
                                  хотелось бы прочитать статью про переход на git с svn, но не типа "вместо svn up набирайте git up", а с описанием различий в базовых понятиях и подходах к работе с хранилищем.

                                  спасибо.
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                    • 0
                                      Спасибо. Попробую.
                                      • 0
                                        Дело в том, что я только пол года назад внедрил в своём проекте SVN: это не было слишком тягостно, но не без сопротивления "среды" ))
                                        Если теперь я приду и скажу "SVN - это прошлый век, давайте юзать git", меня побъют ))
                                        Внимание вопрос: как менеджерам и рядовым сотрудникам объяснить, зачем им нужно (ли) перейти с SVN на git? зачем им тратить своё время на освоение новой логики и технологии, когда они только что освоили и привыкли к SVN?
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                    • 0
                                      интересно, а усложняется ли (или вообще возможна ли) работа с git, если в репозитории нужно учитывать права доступа пользователей? т.е. разные люди имеют доступ к только к определенным директориям репозитория.
                                      • 0
                                        Нет, такое гит не поддерживает: вы клонируете весь репозиторий и делаете с ним, что хотите. Поддерживается лишь хранение юникс-атрибутов rwx, но это не ограничивает доступ.

                                        Если хотите разграничить доступ — разбивайте проект на разные репозитории, кладите на защищенный сервер и ограничивайте доступ к каждому репозиторию (например, с помощью gitosis, а можно и просто юникс-средствами ограничить доступ к определенным директориям на сервере).

                                      • 0
                                        Копию статьи Eric Goodwin (ссылка протухла) положил здесь: eagleas.livejournal.com/32478.html
                                        • 0
                                          В следующий раз нужно написать пару слов о комфортной работе с git-submodule и git-svn.

                                          Есть примерные сроки? =)

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

                                          Самое читаемое