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


И еще. Я по какой-то непонятной причине почти не пользуюсь 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.