Как работать с системой GIT: делимся опытом

8673

Привет! Мы — Penguin-team, агентство контекстной рекламы, а это — наш блог по бизнесу, маркетингу и РРС. Каждый месяц мы выпускаем гайды, статьи и инструкции о том, как работать с eCommerce, брендировать, настраивать Google Рекламу и другие каналы трафика.

Наш блог читают маркетологи, SEM-специалисты и предприниматели; его рекомендуют на SEMConf и других конференциях.

Еще больше уникальных материалов — в рассылке 👇 Подписывайтесь!

Получать еще больше уникальных материалов 👉🏻

Спасибо за подписку!

Содержание

8673

В интернете есть много разных подходов, которые описывают логику работы с системой GIT, но далеко не все схемы могут подойти в отдельно взятом случае. Это связано как с самим проектом, так и количеством разработчиков и, в конце концов, с организацией труда внутри самой команды. Мы используем довольно простую схему в работе и решили поделиться своим опытом с вами.

Наша схема работы с GIT рассчитана на небольшие команды разработчиков (до 10-ти пингвинов) и самое важное – это то, что наша схема рассчитана на проекты, в которых работа ведется в основном линейно и постоянно.

Наша практическая схема

Главный репозиторий (удаленный) состоит всего из двух веток:

master (в ней никогда не ведутся работы)
dev (она всегда взаимодействует с разработчиками и берет на себя весь удар).

Локально у каждого разработчика кроме веток master и dev, есть еще своя ветка (penguinХ). Всю работу разработчик делает только в своей ветке и потом соединяет эти изменения с веткой dev.

Очень важно! Перед тем, как что-либо мержить в ветку dev, нужно сразу проверить, не было ли изменений на сервере в ней.

Если в результате мержа нет никаких конфликтов, то все отлично, продолжаем работу дальше (в своей ветке). В идеальном варианте все конфликты вы решаете только на своей стороне (в своей ветке) и в ветку dev попадают уже все решенные проблемные ситуации. Таким образом, ветка dev тоже остается всегда рабочей и всегда содержит в себе самый новый функционал проекта.

При загрузке данных на сервер всегда делайте push в ветку dev. Как только все изменения загружены на сервер, можете подключаться по ssh на сервер и, будучи в ветке master, делать команду git merge dev.

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

Основные понятия и команды

Начало работы

Создание нового репозитория, первый коммит, привязка удалённого репозитория с github.com, отправка изменений в удалённый репозиторий.

    # указана последовательность действий:
git init # инициируем гит в этой папке
touch readme.md # создаем файл readme.md
git add readme.md # делаем этот файл отслеживаемым
git commit -m "Первый коммит" # создаем первый коммит с вменяемым названием
git remote add origin git@github.com:nicothin/test.git # добавляем предварительно созданный пустой удаленный репозиторий
git push origin master # отправляем данные из локального репозитория в удаленный (в ветку master)

Создать новый репозиторий

git init # создать новый проект в текущей папке
git init folder-name # создать новый проект в указанной папке

Клонирование репозитория

git clone git@github.com:nicothin/web-design.git # клонировать удаленный репозиторий в одноименную папку
git clone git@github.com:nicothin/web-design.git foldername # клонировать удаленный репозиторий в папку «foldername»
git clone git@github.com:nicothin/web-design.git . # клонировать репозиторий в текущую папку

Добавление файлов к отслеживанию, индексация отслеживаемых

    git add text.txt # добавить к отслеживанию этот существующий файл
git add . # добавить к отслеживанию все новые файлы из текущей папки и её подпапок, индексировать отслеживаемые файлы
git add -i # запуск оболочки интерактивного индексирования для добавления в индекс только выбранных файлов (см. [git-scm.com
git add -p # поочередный просмотр файлов с показом изменений и задаваемым вопросом об отслеживании/индексировании (удобно для добавления в коммит только каких-то конкретных файлов)

Убрать файл, папку из отслеживания

    git rm --cached readme.txt # удалить файл из отслеживаемых (файл останется на месте)
git rm --cached -r folder # удалить папку из отслеживаемых (папка останется на месте)

Отмена индексации

git reset HEAD # убрать из индекса все индексированные файлы
git reset HEAD text.txt # убрать из индекса указанный файл

Коммиты

git commit -m "Name of commit" # закоммитить отслеживаемые индексированные файлы (указано название коммита)
git commit -m -a "Name of commit" # закоммитить отслеживаемые индексированные файлы (указано название коммита, не требует git add, не добавит в коммит неотслеживаемые файлы)
git commit # закоммитить отслеживаемые индексированные файлы (откроется редактор для введения названия коммита)
git commit --amend # изменить последний коммит (Insert — режим ввода, : — командный режим; в командном режиме: :wq — сохранить и выйти)
git commit --amend -m "Новое название" # переименовать последний коммит (только если ещё не был отправлен в удалённый репозиторий)

Отмена коммитов

git revert HEAD --no-edit # создать новый коммит, отменяющий изменения последнего коммита без запуска редактора сообщения
git revert b9533bb --no-edit # создать новый коммит, отменяющий изменения указанного (b9533bb) коммита без запуска редактора сообщения (указаны первые 7 символов хеша коммита)

История изменений

git log -p index.html # показать историю изменений файла index.html (выход из длинного лога: Q)
git log -p -5 index.html # показать историю изменений файла index.html (последние 5 коммитов, выход из длинного лога: Q)
git log -2 # показать последние 2 коммита
git log -2 --stat # показать последние 2 коммита и статистику внесенных ими изменений
git log -p -22 # показать последние 22 коммита и внесенную ими разницу на уровне строк (выход из длинного лога: Q)
git log --pretty=format:"%h - %an, %ar : %s" -4 # показать последние 4 коммита с форматированием выводимых данных
git log --graph -10 # показать последние 10 коммитов с ASCII-представлением ветвления
git log --since=2.weeks # показать коммиты за последние 2 недели
git log --pretty=format:"%h %ad | %s%d [%an]" --graph --date=short # мой формат вывода, висящий на алиасе оболочки
git log master..branch_99 # показать коммиты из ветки branch_99, которые не влиты в master
git log branch_99..master # показать коммиты из ветки master, которые не влиты в branch_99

Ветки

git branch # показать список веток
git branch -v # показать список веток и последний коммит в каждой
git branch new_branch # создать новую ветку с указанным именем
git checkout new_branch # перейти в указанную ветку
git checkout -b new_branch # создать новую ветку с указанным именем и перейти в неё
git merge hotfix # влить в ветку, в которой находимся, данные из ветки hotfix
git branch -d hotfix # удалить ветку hotfix (если её изменения уже влиты в главную ветку)
git branch --merged # показать ветки, уже слитые с активной (их можно удалять)
git branch --no-merged # показать ветки, не слитые с активной
git branch -a # показать все имеющиеся ветки (в т.ч. на удаленных репозиториях)
git branch -m old_branch_name new_branch_name # переименовать локально ветку old_branch_name в new_branch_name
git branch -m new_branch_name # переименовать локально ТЕКУЩУЮ ветку в new_branch_name
git push origin :old_branch_name new_branch_name # применить переименование в удаленном репозитории
git branch --unset-upstream # завершить процесс переименования

Удалённые репозитории

git remote -v # показать список удалённых репозиториев, связанных с этим
git remote remove origin # убрать привязку удалённого репозитория с сокр. именем origin
git remote add origin git@github.com:nicothin/test.git # добавить удалённый репозиторий (с сокр. именем origin) с указанным URL
git remote rm origin # удалить привязку удалённого репозитория
git remote show origin # получить данные об удалённом репозитории с сокращенным именем origin
git fetch origin # скачать все ветки с удаленного репозитория (с сокр. именем origin), но не сливать со своими ветками
git fetch origin master # то же, но скачивается только указанная ветка
git checkout origin/github_branch # посмотреть ветку, скачанную с удалённого репозитория (локальной редактируемой копии не создаётся! если нужно редактировать, придётся влить)
git checkout --track origin/github_branch # создать локальную ветку github_branch (данные взять из удалённого репозитория с сокр. именем origin, ветка github_branch) и переключиться на неё
git push origin master # отправить в удалённый репозиторий (с сокр. именем origin) данные своей ветки master
git pull origin # влить изменения с удалённого репозитория (все ветки)
git pull origin master # влить изменения с удалённого репозитория (только указанная ветка)

Работа с ветками, конфликт слияния

Есть master (публичная версия сайта), в двух параллельных ветках (branch_1 и branch_2) было отредактировано одно и то же место одного и того же файла, первую ветку (branch_1) влили в master, попытка влить вторую вызывает конфликт.

# указана последовательность действий:
git checkout master # переключаемся на ветку master
git checkout -b branch_1 # создаём ветку branch_1, основанную на ветке master
subl . # редактируем и сохраняем файлы
git commit -a -m "Правка 1" # коммитим (теперь имеем 1 коммит в ветке branch_1)
git checkout master # возвращаемся к ветке master
git checkout -b branch_2 # создаём ветку branch_2, основанную на ветке master
subl . # редактируем и сохраняем файлы
git commit -a -m "Правка 2" # коммитим (теперь имеем 1 коммит в ветке branch_2)
git checkout master # возвращаемся к ветке master
git merge branch_1 # вливаем изменения из ветки branch_1 в текущую ветку (master), удача (автослияние)
git merge branch_2 #  вливаем изменения из ветки branch_2 в текущую ветку (master), КОНФЛИКТ автослияния
# Automatic merge failed; fix conflicts and then commit the result.
subl . # выбираем в конфликтных файлах те участки, которые нужно оставить, сохраняем
git commit -a -m "Устранение конфликта" # коммитим результат устранения конфликта

В данной статье мы постарались максимально полезно показать вам способы работы с GIT, а также привели список основных команд, которые помогут вам организовать работу на своих проектах.
Используйте GIT в своих приложениях, так вы максимально эффективно будете контролировать процесс разработки.

Понравилась статья? Оцените ее:
1 Star

Содержание

Наша практическая схема Основные понятия и команды Начало работы Создать новый репозиторий Клонирование репозитория Добавление файлов к отслеживанию, индексация отслеживаемых Убрать файл, папку из отслеживания Отмена индексации Коммиты Отмена коммитов История изменений Ветки Удалённые репозитории Работа с ветками, конфликт слияния

Топовые статьи

Гайд по рекламе в Facebook. Часть 1: бизнес-менеджер и рекламный кабинет

103593

11 минут

LTV, CAC, CRR: что значат, как считать и чем реально полезны

49755

6 минут

Гайд по Google Ads (2022). Часть 6: реклама в YouTube

44685

10 минут

43674

8 минут

Создание фида Google Merchant Center для основных CMS

41859

12 минут

Александр

ex php backend developer

Ex-пингвин. Ранее активно занимался разработкой интернет-магазинов, созданием продуктов, API сервисов. Дополнительно занимался преподаванием курса php для новичков в течении 1,5 года.