![](/user_photo/_userpic.png)
- •Практическая работа №1. Основы git. Система контроля версий Git.
- •Практическая работа №2. Изучение git.
- •Теоретическая часть Постановка задачи контроля версий (vcs)
- •Для справки Как получить помощь в Git?
- •Как Git хранит данные?
- •Vcs, хранящие изменения файлов
- •Git и данные
- •Три состояния файла в Git
- •Практическая часть
- •Содержимое отчёта
- •Практическая работа №3 . Разработка базы git Создание Git-репозитория.
- •Практическая работа №4. Основы ветвления и слияния в git
- •Практическая работа №5. Работа с сервером. Git push и git pull
- •Как узнать, что есть незапушенные коммиты
- •Как избавиться от мердж-коммита
- •Мердж-коммит в PhpStorm
- •Практическая работа №6. Распределенный git
- •Диспетчер интеграции
- •Диктатор и помощники
- •Практическая работа №7. Оборудование git Ветвление в Git - о ветвлении в двух словах
- •Практическая работа №10. Объекты в git
- •Практическая работа №11. Работа на GitHub.
Как избавиться от мердж-коммита
Мердж-коммит появляется, когда вы сделали локальный коммит, а после этого подтянули новые коммиты с сервера. Мердж-коммит не несет смысловой информации, кроме самого факта мерджа. Без него история коммитов выглядит чище.
Чтобы избавиться от него, подтягивайте изменения командой git pull с флажком --rebase
$ git pull --rebase origin master
Copy
При этом ваш локальный коммит окажется "поверх" нового коммита с сервера, а мердж-коммита не будет. И не забудьте после этого запушить свой коммит на сервер.
Мердж-коммит в PhpStorm
PhpStorm помогает избавиться от мердж-коммитов через меньшее количество действий. Если мы запушим локальные коммиты и получим rejected из-за того, что на сервере есть новые коммиты, то PhpStorm выдаст предупреждение, где предложит выбрать вариант: как подтянуть новые коммиты, с мерждем или ребейзом. Жмите кнопку "Rebase", мердж-коммита не будет и при этом локальный коммит сразу запушится на сервер.
Практическая работа №6. Распределенный git
Цель работы:
Мы рассмотрим работу с Git в распределённой среде как в роли рядового разработчика, так и в роли системного интегратора. То есть вы научитесь успешно вносить свой код в проект, делая это как можно более просто и для вас, и для владельца проекта, а также научитесь тому, как сопровождать проекты, в которых участвует множество разработчиков.
Теоретическая часть.
Распределенный рабочий процесс
В отличие от централизованных систем контроля версий (ЦСКВ), распределенная природа Git позволяет более гибко взаимодействовать разработчикам в рамках проекта. В централизованных системах каждый разработчик представляет собой узел, который более или менее одинаково взаимодействует с центральным хабом. Однако, в Git каждый разработчик это и узел и хаб, то есть каждый разработчик может как отправлять код в другие репозитории, так и поддерживать публичный репозиторий, в который другие разработчики смогут отправлять свой код, взяв его за основу. Это предоставляет огромное количество вариаций для организации рабочего процесса над проектом и/или для команды, поэтому мы расскажем об основных парадигмах, отражающих преимущество гибкости Git. Так же мы рассмотрим сильные и слабые стороны каждой из них; вы сможете выбрать наиболее подходящую или позаимствовать необходимые функции сразу из нескольких.
Централизованная работа
В централизованных системах, как правило, присутствует только одна модель взаимодействия — централизованный рабочий процесс. Центральный хаб или репозиторий может принимать код, а все остальные синхронизируют свою работу с ним. Все разработчики являются узлами (пользователями хаба) и синхронизируются только с ним.
Рисунок 53. Централизованный рабочий процесс
Это означает, что если два разработчика клонируют репозиторий и каждый внесёт изменения, то первый из них сможет отправить свои изменения в репозиторий без проблем. Второй разработчик должен слить изменения, сделанные первым разработчиком, чтобы избежать их перезаписи во время отправки на сервер. Эта концепция верна как для Git, так и для Subversion (или любой ЦСКВ), и прекрасно работает в Git.
Если в вашей организации или команде уже используется централизованный рабочий процесс, то вам ничего не нужно менять для работы с Git. Достаточно создать один репозиторий и предоставить каждому члену команды push-доступ; Git не позволит перезаписать изменения, сделанные другими.
Предположим, Джон и Джессика начинают работать над проектом одновременно. Джон вносит изменения и отправляет их на сервер. Затем Джессика пытается отправить свои изменения, но сервер их отклоняет. Ей говорят, что она пытается отправить изменения, для которых невозможно выполнить быструю перемотку и она не сможет это сделать пока не получит все новые для неё изменения и не сольёт их. Такой рабочий процесс привлекает большинство людей, так как реализует парадигму, с которой они уже знакомы.
Такой подход применим не только к небольшим командам. Используя модель ветвления Git, сотни разработчиков могут одновременно работать над одним проектом, используя при этом десятки веток.
Практическая часть.