Документ описывает основы использования системы контроля версий Git, включая инициализацию репозиториев, работу с коммитами, создание веток и управление изменениями. Подчеркиваются важные правила, такие как регулярные коммиты и запрет изменений в ветке master, а также упоминаются лучшие практики для командной работы и разрешения конфликтов. Также обсуждается необходимость использования внешних сервисов для хранения репозиториев в случае увеличения команды разработчиков.

1. Распределённая
cистема контроля версий файлов
Git
Никита Шультайс
http://shultais.ru

2. Зачем мне это?

3. Распределённая? Что это значит?

4. У нас уже есть проект, но оне еще не в Git'e
cd /path/to/project/
git init

5. Но не все файлы должны быть под VCS!
Зачем нам *.pyc, *.*~ и тестовые аватарки?
echo *.pyc >> .git/info/exclude
или
vim .git/info/exclude

6. Это все?
git add .
git commit -a -m «Первый коммит»

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

8. Я изменил файл и добавил новый?
Что делать?
git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: first.txt
# new file: second.txt
#

9. Зафиксируем изменения
git commit -a -m "Добавил второй файл."
[master e951bad] Добавил второй файл.
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 second.txt

10. И это все?
Я просто отмечаю изменения, которые сделал,
чтобы в один момент к ним вернуться?
Вся сила в ветках

11. Мой сайт уже 6 месяцев работает стабильно, зачем...
Бля-я-я, что-то сломалось.
Что делать, ведь я уже внес столько изменений?

12. Сила копирования
realty
new_realty
old_realty
super_new_realty
realty_v2
new_realty_v2

13. Затеял новую фичу или правишь баг?
Создай ветку.
git branch new-feature
git checkout new-feature

14. Опять упал ваш стабильный сайт?
git checkout master

15. Правило 1. В master всегда должна
находится текущая рабочая версия продукта.
Следствие: правки кода в master запрещены.

16. На каждый баг я буду создавать ветку?
git branch hotfixes
git checkout hotfixes

17. Правим баг, тестируем
git commit -a -m «fix #341»
git checkout master
git merge hotfixes

18. Я закончил новую фичу, что теперь?
git commit -a -m «Закрыл #76»
git checkout master
git merge new-feature
Опять баг?
git checkout hotfiexes
git merge master
Правим баг
git commit -a -m «fix #1245»
git checkout master
git merge hotfixes

19. А есть какие-то хорошие практики?
Hotfixes — правка багов
Develop — текущая разрабатываемая версия

21. Сегодня я много кодил. Все зря.
Что делать?

22. CTRL+Z

23. git checkout .

24. Правило 2. Постоянно делайте коммиты

25. Я обнаружил, что случайно
удалил важный файл 10 коммитов назад.
Что делать?
git checkout HEAD~10 важный_файл

26. Ок, релиз готов, как мне его залить на сайт?
Скопировать весь репозиторий?
git diff HEAD~1 > update.patch
patch -p1 < update.patch
git archive -o update.zip HEAD
$(git diff --name-only HEAD~1)

27. Мы наняли еще одного программиста
Вариант 1. Равноправный доступ.
Новый разработчик копирует ваш репозиторий
git clone /home/username/project myrepo
git clone ssh://user@somehost:port/~user/repository
git clone git://user@somehost:port/~user/repository/project.git

28. Правило 3.
В любом новом репозитории, действуют правила 1 и 2

29. Новый разработчик написал новую фичу.
Но ветка master его репозитория уже отличается
от ветки master центрального.
git checkout master
git pull
git merge new-feature
git push

30. Мы наняли еще одно программиста-
стажера и не можем дать ему доступ на
изменение главного репозитория

31. Мы наняли удаленного верстальщика.
Хранить главный репозиторий
на моей машие уже неудобно.

32. GitHub $12/месяц
Gitent-scm.com
На корпоративном сайте

33. А если разместить репозиторий
прямо на сервере с сайтом?
git push

34. Читайте «Магия Git» и Хабр

35. Спасибо