До того, как я начал работать в одноклассниках я думал, что знаю как пользоваться системой контроля версий. Но там мне дали ссылку на документацию по git. Эту книгу можно читать бесконечно, но на мой взгляд для того, чтобы начать пользоваться git она абсолютно бесполезна. Это не проблема скажете вы и будете совершенно правы. На том же хабре есть куча статей на тему как пользоваться git. Но пару дней назад один мой товарищ попросил объяснить ему некоторые непонятые им моменты. Я объяснил, как смог и хочу поделиться просто еще одной шпаргалкой на тему «10 простых действий по использованию git в повседневной работе». Не такой уж и маленькой она получилась, поэтому я пока напишу только как работать с git для вашего рабочего проекта, а потом, отдельно, что делать если вы хотите вносить изменения в чужой проект.

Не хотелось бы описывать как настраивать аутентификацию для git.
Насколько я знаю можно настроить либо ssh ключи, либо использовать логин/пароль и ввести их в глобальных или локальных настройках git. Думаю когда заводишь аккаунт на github там про все про это написано. Лично у меня стоит Linux и настроены pub/priv ssh ключи для github. Для windows я обычно пользовался cygwin и использовал там те же ssh ключи.

И еще. Я по какой-то непонятной причине почти не пользуюсь IDE для работы с git. Если использовать IDE, то думаю все равно с какой системой контроля версий работать.

10 шагов для работы с проектом


Хочу написать что нужно делать если вы работаете в компании в которой используется git. Как правило для каждой задачи, которую вы делаете вам надо будет заводить отдельную ветку (branch), называть ее по имени задачи в вашей системе управления задач (например по имени задачи в JIRA), а после завершения выполнения задачи и прохождения процедуры проверки кода другими работниками объединять вашу ветку с общим кодом.

  1. Создаем локальную копию вашего проекта

    # git clone "project_url"

    Для github project_url можно найти нажав зеленую кнопку «Clone or download» на странице проекта.
  2. Обновляем локальную копию — подгружаем изменения, которые внесли другие участники в эту ветку

    # git pull

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

    Примечание - произошел конфликт
    git тупо не разрешит сделать pull если у вас есть локально измененные файлы и update их модифицирует. Можно тут использовать git stash / git pull / git shash pop.
    Допустим вы внесли изменения и сделали commit. Есть 2 варианта — если ваши изменения и удаленные не конфликтуют, то git создаст еще один дополнительный сommit и предложит вам отредактировать сообщение этого вновь созданного комита.

    Если есть конфликты, то я делаю так.

    Смотрим какие файлы конфликтуют (both modified)

    # git status

    , правим их, добавляем

    # git add "conflict_file_name"

    , комитим

    # git commit -m "Merge master"
  3. Узнаем название вашей текущей ветки, смотрим какие файлы были изменены локально, смотрим какие комиты (commits) вы не отправили на общий сервер

    # git status
  4. Выкидываем все ваши локальные изменения. Применять осторожно, можно выстрелить в ногу.

    # git reset --hard

    Примечание: современные IDE хранят историю изменения файлов локально, так что ничего страшного. Стреляйте.
  5. Создаем ветку, обычно по имени задачи в JIRA. Примечание: ветка создается от той ветки в которой вы в настоящий момент находитесь (см. предыдущий пункт), поэтому как правило надо сначала переключиться в ветку master. Если есть измененный файлы, то ничего страшного — они никуда не пропадут.

    Переключаемся в ветку master:

    # git checkout master

    Создаем новую ветку:

    # git checkout -b "task_name"

  6. Если вы хотите внести изменения в ветку, которую пилит ваш товарищ, то надо сначала обновиться, а потом переключиться в его ветку

    # git fetch
    # git checkout "task_name"

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

    # git fetch

    # git merge origin/master

  8. После внесения локальных изменений их надо так сказать «закомитить». Надо отметить, что git вносит изменения (создает новый commit) в вашу локальную версию, на сервер ничего не отправляет. Для отправки на сервер есть другая команда. Лично я комичу из IDE. Но можно и руками.

    Сообщаем git какие файлы мы хотим закомитить:

    # git add file_list

    Или сразу все файлы

    Коммитим:

    # git commit -m "Commit message"
  9. Отправляем файлы в репозиторий на сервере

    # git push

    Примечание — git ругается, что не знает куда отправлять — смотри примечание к пункту 2.

    Примечание - git ругается, что файлы не обновлены
    Обычно настройки git server такие, что вы не можете отправить свои изменения если кто-то отправил свои изменения в вашу ветку. Поэтому нужно обновить состояние вашей ветки — смотри пункт 2.
  10. Отправляем изменения на просмотр (review) другим участникам. Это UI штука, к git отношения не имеет. В github, например, надо просто в UI перейти в свою ветку и создать Pull request (PR)
  11. Сливаем ваши изменения в основную ветку. Тут есть несколько вариантов. По умолчанию git просто встроит все ваши комиты в общую ветку. То есть все увидят ваши нелепые попытки исправить несобирающийся билд, падающие тесты и просто вечерние комиты, которые вы сделали, чтобы не потерять результаты кропотливого дневного труда. Это хорошо, если вы эксбиционист, но как правило жедательно все комиты собрать в один и встроить в общую ветку именно одним комитом (т.н. squash commit) — так другим будет легче разобраться что же вы сделали перед тем, как что-то пошло не так и откатить ваши изменения. Поэтому желательно делать squash:
    1. github ui magic

      В интерфейсе github есть зеленая кнопочка «squash & commit». Через UI переходим в свою ветку, создаем Pull request (PR), а потом в интерфейсе PR выбираем и жмете «squash & commit».
    2. squash commit

      Переходим в основную ветку (master)

      # git checkout master

      , обновляемся

      # git pull

      , делаем squash commit

      # git merge "branch name" --squash
      . Все изменения, из нашей ветки появятся как локальные, но уже в основной ветке. Смотрим что мы наваяли. Посмотреть изменения — пункт 3. Комитим — пункт 8, отправляем на сервер — пункт 9. Можно делать squash commit не в основную ветку, а завести новую, сделать в нее squash commit и из нее сделать merge в основную (смотри следующий пункт).
    3. merge

      Ваши комиты в этом случае не склеятся в один. Переходим в основную ветку (master)

      # git checkout master

      , обновляемся

      # git pull

      , делаем обычный commit

      # git merge "branch name"

      , отправляем на сервер — пункт 9.
    4. rebase

      Можно сделать rebase ветки и, например, склеить все ваши комиты в один.

      Лично я так не делаю
      Потому что там нужна магия по выбиранию всех ваших комитов и отделению ваших от неваших (от тех, которые были добавлены из мастера) и тут во время rebase еще можно нарваться на изменение комита, который был подтянут из мастера. Можно делать rebase каждый раз, когда вы подтягиваете изменения из мастера. Так я тоже не делаю потому что если вы как чай работаете вдвоем над одной веткой и делаете rebase, то велика вероятность конфликтов.

Примечания:

  • Ветка с общим кодом обычно называется master.
  • Можно спрятать все ваши локальные изменения — смотри команду git stash.
  • Можно применить комит в вашу ветку из какой-нибудь другой — смотри git cherry-pick.
  • Магия. rebase. Склеить несколько комитов в один или переместить комиты из локальной ветки в начало списка — чтобы потом было легко их склеить — git rebase.

Комментарии (11)


  1. Shtucer
    05.09.2017 17:22
    +1

    Заголовок предполагает инструкцию по лечению git'а, а в статье инструкция по использованию оного.


    1. Dreyk
      05.09.2017 23:33

      занудливый конечно комментарий, но (как часто и бывает с занудствованием) — верный


    1. domix32
      06.09.2017 10:26

      А чем он у вас болен?


      1. Shtucer
        06.09.2017 11:29

        С чего вы решили, что он у меня болен?


        1. domix32
          06.09.2017 22:26

          Ну, раз вы предполагаете его лечить, значит у него какие-то проблемы.


          1. Shtucer
            06.09.2017 22:27

            Не я предлагаю, а автор поста. Будьте внимательны.


  1. KoMePcAHT
    05.09.2017 22:10
    +3

    Я по какой-то непонятной причине почти не пользуюсь IDE
    Лично я комичу из IDE

    т.е. вы почти не комитите?


  1. BerkutEagle
    06.09.2017 06:30
    +2

    Вы просто перечислим некоторые команды git. git help > habr


  1. iberezhnyk
    06.09.2017 15:05

    Как по мне, мне более подходит другой подход:
    1) Создаём (или используем сущуствующую) ветку develop с master-a;
    2) Создаем ветку, как говорил автор, для фичи с названием (или ID) в Gira или др.;
    3) Пишем код, делая время от времени коммиты;
    4) Делаем Rebase;
    5) Выполняем push в свою ветку;
    6) После review, если с кодом всё нормально, делаем слиение нашей ветки в develop (Можно сначало develop в нашу ветку, дабы узнать какие нас ждут конфликты);
    7) Если нужно доделывать, то доделываем);
    8) Удаляем origin/[наша ветка];
    9) Делаем нужные правки и делаем коммит;
    10) Снова Rebase и идём к пункту 5;
    11) Переходим в develop с нашими изменениями;
    12) Переходим к пункту 1.

    P.S. Правило:
    Одной фичей занимается один человек. Один человек занимается одной фичей.


  1. pinoquinho Автор
    06.09.2017 15:16

    Пожалуй что не соглашусь с правилом 1 фича — 1 выстрелчеловек. В идеальном мире — да, возможно.
    Допустим мы решили на сайте сделать новую кнопочку. У нас есть верстальщик и программист. Дизайнер нам все нарисовал, верстальщик сверстал, программист сделал, а оно не работает. Например верстальщик что-то не учел и в общей верстке это не работает. Или пришел продукт, посмотрел, не понравилось, решили переделать. Надо править. Это норма.
    Или разработчик бэкенд, разработчик фронтенд. Да, набросали АПИ, но что это за работа в которой не требуется изменений.
    Или 10 лет назад вообще все комитили в мастер и никого это не смущало.


  1. ashumkin
    09.09.2017 00:22

    Смотрим какие файлы конфликтуют (both modified)

    # git status

    , правим их, добавляем

    # git add «conflict_file_name»

    правим? неужто руками? может лучше
    git mergetool
    ?