Установка на проект системы контроля версий git
Максимально простые и понятные инструкции. Ничего лишнего
Интернет полон справочных материалов о принципах работы и об архитектуре инструментария разработчика.
Мы же публикуем в нашей базе знаний «истории использования» — это максимально простые и последовательные инструкции.
Мы же публикуем в нашей базе знаний «истории использования» — это максимально простые и последовательные инструкции.
технический директор
Схема обмена
Чтобы спокойно работать в режиме прямых коммитов командами
git push origin master
git pull origin master
используем схему с двоичным репозиторием = bare repository (центральный)
git push origin master
git pull origin master
используем схему с двоичным репозиторием = bare repository (центральный)
Каждая часть схемы может располагаться как на разных серверах, так и на двух и вообще все на одном сервере. Все зависит от путей к удаленным веткам
Создание DEV репозитория
- На PRODUCTION в корне проекта создаем файл .gitignore
В него вписываем все что не относится к коду который будет меняться и по смыслу не должно подпадать под версионный контроль
download/
images/
song_1.mp3/
video/
нормальный файл приложен .gitignore -
после этого создаем репозиторий
git init
-
Идем на сервер или в каталог где будет располагаться двоичный репозиторий
там создаем bare версию
git init --bare
получаем путь к репозиторию
sven@omega:~/www/github$ pwd
/var/www/sven/data/www/github
-
Возвращаемся на PRODUCTION и ставим на bare repository удаленый алиас
git remote
add origin ssh: //sven@o.aniart.com.ua/var/www/sven/data/www/github
убеждаемся что все ок git remote -v
origin ssh: //sven@o.aniart.com.ua/var/www/sven/data/www/github/ (fetch)
origin ssh: //sven@o.aniart.com.ua/var/www/sven/data/www/github/ (push)
кому интересно, здесь все описано очень подробно
-
Загружаем с PRODUCTION весь код в bare repository
git push origin master
-
Идем на сервер (каталог ) где будет DEV и клонируем из bare repository все что только что загрузили
git clone ssh://sven@o.aniart.com.ua/var/www/sven/data/www/github
это сразу настраивает алиас origin
кто хочет, может сделать последовательно
git init
git remote add origin ssh://sven@o.aniart.com.ua/var/www/sven/data/www/github git pull origin master
При клонировании репозитория, как правило, автоматически создаётся ветка master, которая отслеживает origin/master, поэтому git push и git pull работают для этой ветки "из коробки" и не требуют дополнительных аргументов.
Полезные команды и ключи
-- как посмотреть какие алиасы настроены
git remote -v
origin ssh://sven@o.aniart.com.ua/var/www/sven/data/www/github/ (fetch)
origin ssh://sven@o.aniart.com.ua/var/www/sven/data/www/github/ (push)
-- как удалить из версионного контроля, если туда попало что-то большое и не нужное
-- прежде всего картинки или download
git rm --cached -r images
git rm --cached -r song_1.mp3
git rm --cached -r video
git rm --cached -r download
-- если накосячили и репозитории не имеют общего коммита предка, пользуем специальный ключ
git pull --allow-unrelated-histories dev master
-- можно ставить удаленные ветки на отслеживание в локальные ветки, и экономить кучу времени на прописывание каждый раз алиасов и веток
git checkout -b serverfix origin/serverfix
Получение локальной ветки с помощью git checkout из удалённой ветки автоматически создаёт то, что называется отслеживаемой веткой. Отслеживаемые ветки — это локальные ветки, которые напрямую связаны с удалённой веткой. Если, находясь на отслеживаемой ветке, вы наберёте git push, Git уже будет знать, на какой сервер и в какую ветку отправлять изменения. Аналогично выполнение git pull на одной из таких веток сначала получает все удалённые ссылки, а затем автоматически делает слияние с соответствующей удалённой веткой
git push origin serverfix:SVEN-5
— здесь говорится “возьми мой serverfix и сделай его удалённым SVEN-5”
Можно использовать этот формат для отправки локальной ветки в удалённую ветку с другим именем.
Так ваша локальная ветка serverfix отправится в ветку SVEN-5 удалённого проекта.
если в
git rm --cached -r ...
не поставить --cached + удалит все файлы с диска
git rm --cached -r ...
не поставить --cached + удалит все файлы с диска
Порядок работы с DEV
Для каждого задания или отдельного таска
-- делаем ветку
git checkout -b SVEN-5
-- поработали, написали код, добавили какие-то файлы
-- коммитим изменения
git add .
git commit -am"суть работы"
-- заливаем в мастер ветку
git checkout master
git merge SVEN-5
-- когда получено разрешение выливать на PRODUCTION, отправляем в центральный репозитарий. Изменения забираем с центрального на мастер
git push origin master
-- старые ветки можно удалять
git branch -d SVEN-5
-- можно узнать какие ветки слиты и можно удалять (все кроме *)
git branch --merged
* master
new
new2
new3
-- можно узнать какие ветки НЕ слиты и содержат изменения
git branch --no-merged
Полезные команды
Стандартная фиксация изменений
Вариант №1 Добавить измененные файлы в индекс перед commit
git add filename1 filename
git commit
Вариант №2 - добавить все файлы: измененные, новые, удаленные
git add .
git commit
Если что-то пошло не так, до фиксации (commit), из индекса всегда можно удалить случайно попавшие туда файлы
Вариант №1
git reset filename1
Вариант №2
git rm --cached filename1
git reset HEAD - сбросить весь индекс полностью
Как восстановить файл с одного из предыдущих коммитов
git checkout #коммита им файла
git checkout 2378d5ad6e3d5fc87df858678c226d9fc9c47c66 temp.tmp
смотри git log
Как удалить из индекса git файл, который не должен там быть или
который нужно игнорировать
1 . внести этот файл в .gitignore
2 . git rm --cached filename - исключить из индекса
3 . закоммитить
Как вернуть изменённый файл назад?
Правильнее всего - это НЕ РАБОТАТЬ в master ветке. Всегда делать изменения в отдельной ветке и только проверенные и утвержденные должны сливаться в master.
Master - это эталонная стабильная ветка.
Вариант №1
git reset --soft id-commit - уничтожить в ветке коммит, но оставить
индекс и дерево файлов нетронутыми
Вариант №2
git reset --hard id-commit - уничтожить, коммит, индекс и файлы до
состояния указанного коммита
Работа с ветками
git branch new-branch — создаст новую ветку new-branch на основании
текущей
git checkout branch — переключение между ветками
git merge — слияние веток (разрешение возможных конфликтов)
Тэги
git tag stable- 1
создать «легковесный» тэг, связанный с последним
коммитом. Если тэг уже есть, то еще один создан не будет
git tag -d stable- 2 — удалить тег.
git tag -l — перечислить тэги.
Временно "спрятать" изменения
Часто возникает такая ситуация, что пока вы работаете над частью своего проекта, всё находится в беспорядочном состоянии, а вам нужно переключить ветки, чтобы немного поработать над чем-то другим. Проблема в том, что вы не хотите делать коммит с наполовину доделанной работой только для того, чтобы позже можно было вернуться в это же состояние. Ответ на эту проблему — команда git stash.
git stash - изменения больше не видны гиту
посмотреть список спрятанных работ
git stash list
stash@{0}: WIP on master: 049d078 added the index file
stash@{1}: WIP on master: c264051... Revert "added file_size"
stash@{2}: WIP on master: 21d80a5... added number to log
git stash apply - восстановить последнюю спрятанную работу
Если вы хотите применить одну из старых работ , можете сделать это, указав её имя так:
git stash apply stash@{2}.
Информация об истории коммитов, аналитика с разной детализацией
Статистика
Вариант №1 Добавить измененные файлы в индекс перед commit
git add filename1 filename
git commit
Вариант №2 - добавить все файлы: измененные, новые, удаленные
git add .
git commit
Если что-то пошло не так, до фиксации (commit), из индекса всегда можно удалить случайно попавшие туда файлы
Вариант №1
git reset filename1
Вариант №2
git rm --cached filename1
git reset HEAD - сбросить весь индекс полностью
Как восстановить файл с одного из предыдущих коммитов
git checkout #коммита им файла
git checkout 2378d5ad6e3d5fc87df858678c226d9fc9c47c66 temp.tmp
смотри git log
Как удалить из индекса git файл, который не должен там быть или
который нужно игнорировать
1 . внести этот файл в .gitignore
2 . git rm --cached filename - исключить из индекса
3 . закоммитить
Как вернуть изменённый файл назад?
Правильнее всего - это НЕ РАБОТАТЬ в master ветке. Всегда делать изменения в отдельной ветке и только проверенные и утвержденные должны сливаться в master.
Master - это эталонная стабильная ветка.
Вариант №1
git reset --soft id-commit - уничтожить в ветке коммит, но оставить
индекс и дерево файлов нетронутыми
Вариант №2
git reset --hard id-commit - уничтожить, коммит, индекс и файлы до
состояния указанного коммита
Работа с ветками
git branch new-branch — создаст новую ветку new-branch на основании
текущей
git checkout branch — переключение между ветками
git merge — слияние веток (разрешение возможных конфликтов)
Тэги
git tag stable- 1
создать «легковесный» тэг, связанный с последним
коммитом. Если тэг уже есть, то еще один создан не будет
git tag -d stable- 2 — удалить тег.
git tag -l — перечислить тэги.
Временно "спрятать" изменения
Часто возникает такая ситуация, что пока вы работаете над частью своего проекта, всё находится в беспорядочном состоянии, а вам нужно переключить ветки, чтобы немного поработать над чем-то другим. Проблема в том, что вы не хотите делать коммит с наполовину доделанной работой только для того, чтобы позже можно было вернуться в это же состояние. Ответ на эту проблему — команда git stash.
git stash - изменения больше не видны гиту
посмотреть список спрятанных работ
git stash list
stash@{0}: WIP on master: 049d078 added the index file
stash@{1}: WIP on master: c264051... Revert "added file_size"
stash@{2}: WIP on master: 21d80a5... added number to log
git stash apply - восстановить последнюю спрятанную работу
Если вы хотите применить одну из старых работ , можете сделать это, указав её имя так:
git stash apply stash@{2}.
Информация об истории коммитов, аналитика с разной детализацией
Статистика
- git log
- git log --stat - подробно по каждому коммиту
- git log --summary
- git log -p - подробно по каждому файлу
- git diff filename - по конкретному файлу
- git diff --cached — изменения, внесенные в индекс.
- git show — показать изменения, внесенные отдельным коммитом
Вам понравился лайфхак?
Напишите нам о чем хотите узнать еще?
Напишите нам о чем хотите узнать еще?
технический директор
Понравилась статья? Поставьте свою оценку, чтоб мы понимали о чем писать еще.
Установка на проект системы контроля версий git
Голосов: 34
, Рейтинг: 1.77
Не пропустите. Похожие публикации
- Технология композитного сайта от Битрикс
- Ти можеш обирати, знижка 12% на усі коробкові версії.
- Внедрение Perfectum CRM+ERP
- Кейс: телефония Ringostat для Maxi.az — одного из топовых интернет-магазинов Азербайджана
- Нетрадиционный подход к коммуникации аудиторией соцсети
- ANTI-MEETUP: неформальное общение
- Startup Review #5
- Управление школой, составление расписания
- Администрирование Битрикс и Битрикс24 серверов