Как использовать систему контроля версий Git
Давайте выясним как использовать систему контроля версий Git.
Начнем с простого: для чего Git нужен?
Например, для того, чтобы при разработке в команде не возникало необходимости спрашивать у коллег — а не собираются ли они в данный момент вносить правки в файл Х?
А то ж вы как раз собираетесь внести туда свои изменения, а затем залить новую версию на сервер. Поэтому если допустим Петя, в то время пока вы работали, загрузил свою измененную версию, то вы ее перезапишите, и правки Пети исчезнут.
Как Git это решает? С помощью слияния (merge) вашего коммита (измененного состояния) и коммита Пети.
Коммиты не висят в воздухе, а лежат на ветках.
По-умолчанию есть ветка master. А мы уже от нее ответвляемся, чтобы была возможность работать над несколькими задачами, так, чтобы они не затрагивали друг-друга. Так, решив изменить цвет ссылок, мы, находясь на ветке master, напишем:
git checkout -b change_link_color
Тут нам Git выведет, что произошло переключение на ветку change_link_color. Кстати, советую очень внимательно читать, что Git пишет, потому что может оказаться, что переход на другую ветку по какой-либо причине не произошел.
Итак, на новой ветке мы можем вносить любые изменения и они никоим образом не отразятся на самой главной ветке master.
Вообще эта ветка master лежит в нашем локальном репозитории, и если даже мы случайно внесем туда какие-то изменения, то на сервере, где удаленная ветка с аналогичным названием является боевой (той которая отражает состояние нашего сайта для всех пользователей), ничего не случится.
Но master локальный нужен все же в таком же состоянии как удаленный, нам же от него еще другие ветки может понадобиться создавать.
Итак, вернемся к ветке change_link_color. Те файлы, в которые мы внесли изменения, тут же стали modified.
Чтобы проверить те ли файлы вы изменили, вводим команду:
git status
Git нам выводит, например, что-то такое:
On branch change_link_color
Changes not staged for commit:
(use «git add …» to update what will be committed)
(use «git checkout — …» to discard changes in working directory)
modified: app/app.css
Как видите он сам нам подсказывает, что теперь делать. А что-то делать нужно, ведь изменения не подготовлены для коммита. Но давайте сначала проверим, что именно мы натворили в файле app.css:
git diff
Git выведет все строчки с изменениями. Иногда можно по неосторожности зацепить лишние изменения, так что такую проверку я рекомендую ввести в привычку. Если все верно, то подготавливаем к коммиту наши изменения.
Если мы напишем:
git add app/app.css
или же (что удобно, когда файлов много)
git add —all
то введя вновь
git status
увидим, что продвинулись:
Changes to be committed:
(use «git reset HEAD …» to unstage)
modified: app/app.css
Ага, мы только что привели наш файл к состоянию — проиндексированный. Теперь нужно создать слепок состояния (в котором нас все устраивает и содержатся только нужные в данный момент изменения) — коммит. Или же передумать и ввести:
git reset HEAD app/app.css
тем самым отправив файл обратно в непроиндексированное состояние.
Но мы уж доведем дело до конца и создадим наш commit. Пишем
git commit -m «do red links»
Что ж теперь индексированных файлов у нас больше нет, зато есть commit. Мы можем его увидеть, введя
git log
Кажется дико сложным? На самом деле к этим этапам быстро привыкаешь, и если на данном примере польза от нескольких состояний файлов не очень очевидна, то немного практики на живом проекте, и все станет понятно 🙂
Если мы хотим отправить данную ветку на удаленный сервер, то пишем
git push origin change_link_color
Если мы хотим ветку смержить с другой то пишет
git merge add_menu
где add_menu другая ветка.
При слиянии могут возникнуть конфликты. Впрочем, их довольно удобно решать через интерфейс, допустим, WebStrom.
Иногда нужно просто забрать с удаленного репозитория ветку. Допустим Петя начал что-то разрабатывать, но не доделав, уехал в отпуск. Ладно хоть запушил на сервер, так что мы теперь можем взять эту ветку и над ней поработать.
git fetch origin do_new_login
В данный момент мы забрали ветку в локальный репозиторий. Но если мы решим просмотреть текущие ветки, набрав команду:
git branch
то не увидим там ветку do_new_login.
Для того, чтобы она появилась, необходимо на нее перейти:
git checkout do_new_login
Прятанье
Иногда возникает ситуация, что в процессе работы, нам необходимо перейти на другую ветку. Для того, чтобы не создавать commit для незаконченной задачи, можно воспользоваться прятаньем:
git stash
Эта команда скрывает локальные изменения.
Для того, чтобы их потом достать (и оттуда удалить), нужно ввести:
git stash pop
Объединить коммиты
Если у нас аж три коммита, которые мы хотели привести к одному, чтобы не удлинять историю коммитов, то пишем
git rebase -i HEAD~3
Получим окно редактирования вида:
pick 567fghg Второй коммит
pick 4643a5f Третий коммит
pick e0ca8b9 Последний 4-ый коммит
Теперь заменим pick на s у двух последних коммитов, это будет значить, что мы их используем, но сливаем с предыдущим комитом.
Не забываем сохранить, затем пишем название получившегося коммита.
Очистить локальный репозиторий
Иногда возникает необходимость полностью очистить локальный репозиторий от изменений. В данном случае используем команду:
git clean -d
Поправить последний коммит
Если после создания коммита, вы поняли, что что-то забыли сделать, то
после внесения изменений в файлы,достаточно набрать команду
git commit —amend
Изменения будут добавлены в последний коммит.
На сегодня, пожалуй, хватит 🙂