Оглавление

Git

# -------------------------------------------------------------------
# Git - менеджер контроля версий кода, в т.ч. при командной разработке
# Описные, терминология, общие команды
# -------------------------------------------------------------------

// Любая система контроля версий позволяет сохранить историю изменений в хронологическом порядке
// Локальный репозиторий (на моей машине) / удаленный репозиторий (на сервере)
// Репозиторий (хранилище проекта и вся его история создания) - это папка-хранилище,
// где хранятся и поддерживаются какие-либо данные (исходные коды)

>> git --version

# -------------------------------------------------------------------
# Инициализация или клонирование репозитория с кодом
# -------------------------------------------------------------------

>> git clone https://url.ru // скачать проект к себе (набор дирректорий с файлами) с сервера GitHub
>> git init // создать пустой репозиторий (.git - папка где будет хранится история изменений)

# -------------------------------------------------------------------
# Предустановки, файл .gitignore
# Просмотр и добавление удаленных репозиториев в настройки файла
# -------------------------------------------------------------------

.gitignore // файл с описанием списка файлов на исключение
.gitkeep // пустой файл необходим в случае если необходимо добавить в git пустую директорию

// Есть суперглобальная конфигурацию
// Есть глобальная конфигурация
// Есть локальная конфигурация .git/gitconfig (все изменения только для локальной машины)
>> git config --list // список настроек
>> git config --global user.name "Ivan Litovchenko" // установка автора коммитов
>> git config --global user.email "iv-litovchenko@mail.ru" // установка почты автора коммитов
>> git config --global push.default matching // Настройка для push
>> git config --global push.default simple // Настройка для push
>> git config --global core.fileMode false
>> git config core.fileMode false // Не учитывать права на файлы

// Добавить удаленный репозиторий
// GitHub/Bitbucket/GitLab - облачное хранилище удаленных репозиториев (самые популярные)
// Есть вариант добавить по https
// Есть вариант добавить по ssh
// Репозиторий по умолчанию имеет название (ключ) "origin"
// origin/feature/AST-14 (пример: репозиторий/фича/проект-№задачи
>> git remote add origin https://github.com/litovchenko1/site.git // добавить удаленный сервер (облачное хранилище), origin - имя репозитория
>> git remote // список удаленных репозиториев
>> git remote -v // список удаленных репозиториев (подробно)

# -------------------------------------------------------------------
# Добавление в индекс у себя в локальном репо
# Коммит (фиксация-сохранение) изменений у себя в локальном репо
# -------------------------------------------------------------------

// Публикация изменений - все файлы могут быть в трех состояниях:
// A) Модифицированные (измененные, но не проиндексированные)
// B) Индексированные (подготовленные для фиксации)
// C) Зафиксированные (сохранены в .git-каталоге)
// Изменения автору проекта (какого-либо расширения) можно отправить в виде реквеста

// 1.1) Добавление в индекс (индексирование файлов и нахождение изменений в них)
>> git add . // добавить все изменени
>> git add
>> git add

// 1.2) Удаление из индекса
>> git rm --cached <ИМЯ-ФАЙЛА> // если файл был добавлен по ошибке - удаляем из индекса
>> git rm -r --cached <ИМЯ-ПАПКИ> // если папка была добавлена по ошибке - удаляем из индекса

// 2) Фиксация изменений (сохранение изменений (не любое изменение на проекте, а зафиксированное изменение в репозитории))
>> git commit -am "Коммент - Первый коммит" // зафиксировать изменения + их коммит
>> git commit -m "Коммент - добавляем файл" // только коммит (если без -m - название будет вводится в ручную)
>> git commit // Откроется окно с редактором

// 3) Проверка состояния изменений
// Зеленые строчки - что-до добавили
// Красные строчки - что-то удалили
>> git status
>> git status -u // включая содержимое папок

// 4) Отмена до состояния репозитория
// Если мы по экспериментировали и хотим откатится до того состояния как в репозитории
>> git checkout -- ИМЯ-ФАЙЛА // откатывает до того состояния как в репозитории

# -------------------------------------------------------------------
# Отправка изменений в удаленный репозиторий (например загрузка на GitHub)
# Забор изменений с удаленного репозитория
# -------------------------------------------------------------------

// Нужно:
// 1) Создать аккаунт на github
// 2) Создать репозиторий на github
>> git push // отправить/протолкнуть изменения в удаленный репозиторий на сервер
>> git push -u origin master // название сервера удаленного репозитория, - название ветки
>> git push origin ao-1

>> git remote set-url origin https://iv-litovchenko:@github.com/iv-litovchenko/maptex.git
>> git pull // скачать (забрать) изменения с удаленного репозитория с сервера
>> git pull origin main // стянуть изменения в мою ветку (например task-18)
>> git fetch // вытянуть все изменения с удаленного репозитория с сервера включая ветки

# -------------------------------------------------------------------
# Просмотр истории изменений (список коммитов, логи, справка)
# -------------------------------------------------------------------

// Указатель HEAD - это указатель на текущий коммит
// ID-коммита - это сокращенное название контрольной суммы SHA-1
>> git reset // позволяет перемещаться по указателям
>> git log
>> git log // если пришли в новую контору и решили посмотреть что там
>> git log --oneline
>> git log --since=2.weeks // показать коммиты за последние две недели
>> git log -n 3
>> git log -n 10 // количество коммитов
>> git show // посмотреть в наглядном виде
>> git diff

# -------------------------------------------------------------------
# Работа с ветками (создание, слияние, удаление, конфликты)
# По умолчанию в Git есть только ветка
# -------------------------------------------------------------------

// Ветка - это исходный код в независимом паралельном варианте
// Ветки нужны что бы разделить код (например одна ветка для разработки нового функционала, другая ветка для продакшина).
// После ветки сливаются в основную ветку (зависит от workflow).
>> git branch // список веток ("*" звездочкой помечена текущая ветка на которой находимся)
>> git branch -v // список веток с их различием
>> git branch <...NAME...> // создать ветку
>> git branch -D <...NAME...> // удалить ветку

>> git checkout <...NAME...> // переключится на ветку
>> git checkout -b new_f // создать ветку и переключится на нее

// Когда закончили работу с веткой переключаемся на основную, и вливаем в нее нашу ветку
>> git checkout master
>> git merge <...NAME...> // сольет ветку
>> git rebase <...NAME...> // сольет ветку и уничтожит ее

// Мерж конфликтов (объединение изменений одного файла из разных источников)
// 2 разных разработчика поменяли код в 1 и том же файле
// Слева текущая ветка | По центру результат объединения | Справа вливаемая ветка
// Области: зеленые области - нет конфликтов; красные области - зоны конфликтов
// При разгуливании конфликтов можно использовать добавку в стеш (после git pull, после выбор из стеша)

// Для мерджа конфликтов нужно поставить прогу https://sourceforge.net/projects/kdiff3/files/
// !!! Конфликты решаются только в своей ветке
>> git config --global merge.tool kdiff3
>> git config --global mergetool.kdiff3.cmd '"C:\\Program Files\\KDiff3\\kdiff3" $BASE $'
>> git mergetool // если есть конфликт, запускаем утилиту и разруливаем конфликт
>> git cherry-pick // берёт изменения, вносимые одним коммитом, и пытается повторно применить их в виде нового коммита в текущей ветке

# -------------------------------------------------------------------
# Модель ветвления
# Git Flow (подход №1 к работе на основе таск-трекера)
# -------------------------------------------------------------------

// Ветки создаются на github. На локальной машине они не создаются.
// Под каждую новую задачу создается новая ветка от ветки

- это оригинальная ветка
- На ветке - задачи тестируются
- Название новых веток задается как <код_проекта>_<название_изменения>_<№задачи> на основе таск-трекера
- Ветки создаются от ветки
- После делается пулл-реквестти в ветку (примите мои изменения)
- После решения задачи ветка удаляется
- Каждому релизу присваивается тэг версии X.X.X

>> git tag 1.2.0 (теги добавляются только в ветку )
>> git push ...

// Как организовать работу (тракинг) - TAB Issuse
- 1) Создаем задачу на GitHub [projname - сокращенное название проекта].[1 - номер задачи]
- 2) На основе номера задачи (ID) создаем ветку projname.1_название
- 3) Делаем локальные изменения
- 4) На GitHub делаем Pull Request -> в (merge -> pull request)
- 5) Далее на GitHub Pull Request в

# -------------------------------------------------------------------
# Модель ветвления
# Git Workflow (подход №2 к работе)
# -------------------------------------------------------------------

// https://danielkummer.github.io/git-flow-cheatsheet/index.ru_RU.html
- Ветка (стабильная ветка для продакшина)
- Ветка (срочное изменение) - для срочной правки багов. После завершения фикса изменения выливаются в ветку , и в ветку
- Ветка (новая фича, задача) - здесь делаем таски, ветка для разработки фич. После завершения фича выливается в ветку
- Ветка (для разработки) - создается от ветки , от этой ветки создается ветки релиза
- Ветка (Собираются фичи из ветки разработки в релиз ветку). Собираются изменения и выгружаются в , ставится тег №X.X.X релиза

// Плагин упрощающий работу с git workflow (предварительно нужно установить)
>> brew install git-flow-avh
>> git flow init // инициализация
>> git flow feature start <...NAME...> // начало новой фичи (забор с ветки "develop")
>> git flow feature finish <...NAME...> // начало новой фичи (переброс в ветку "develop")
>> git flow feature publish <...NAME...> // публикация

# -------------------------------------------------------------------
# Описание GitHub-сервиса
# -------------------------------------------------------------------

// Интерфейс
- TAB Issuse - создать баг/задачу (трекинг)
- TAB Fork - создание форка
- TAB Watch - отслеживание репозитория
- Настройка Web-Hook - можно организовать авто-деплой

// SSH-ключи для GitHub
1) >> ssh-keygen // команда создает ключ (спрашивает где сохранить, просит придумать пароль)
2) далее берем копируем публичный ключ (>> cat /home/i/ilitovfa/.ssh/id_rsa.pub)
3) далее идем на github и добавляем публичный ключ в разделе SSH-keys

https://raw.githubusercontent.com/iv-litovchenko/maptex_content/master/soft || git.txt

#178 | 2022-07-19 15:11:33 Проверено

Pull - это fetch + update После update в панели git откроется отдельная вкладка где можно посмотреть что прилетело

fetch - просто получение удаленных изменений, но без обновления локальных веток После этого в панели git в логе будет видно что удаленная ветка продвинулась дальше Ставишь фильтр по ветке, добавляешь в него локальную и удалённую ветку, выбираешь через shift всё новые коммиты и справа видишь все изменения Альтернатива - после fetch сделать compare from branch и выбрать удалённую ветку - получишь все теже изменения, только в большом окне.

#215 | 2022-08-30 14:10:09 Проверено

Пиши отчёт так, чтобы менеджер мог понять на каком этапе реализации находится задача и насколько отклоняется от графика.

Что было сделано вчера?

Какие проблемы возникли?

Что планируется на сегодня

#231 | 2022-09-03 08:21:16 Проверено

Еще раз разобраться когда работаешь в ветке такска как забирать изменения из маин?

#235 | 2022-09-06 08:54:36 Проверено

sudo apt update

sudo apt install git-flow

git flow init -d -f

https://onstartup.ru/sistemy-kontrolja-versij/git-flow/

#267 | 2022-09-13 14:50:43 Проверено

git init

git checkout -b master

git add .

git commit -m "initial commit"

git tag 1.0.0

git remote add origin https://gitlab.com/francis01/greetr.git

git push -u origin --all

git push -u origin --tags

#272 | 2022-09-15 13:04:33 Проверено

О самих Git hooks и основных типах

Если вкратце, hook — кастомный скрипт, выполняющийся до или после событий вроде commit, push. Вот и все, действительно очень просто. Каждый проект после инициализации содержит папку .git/hooks, в которой Git ищет скрипты для выполнения при наступлении событий.

Хуки разделяются на клиентские (локальные) и серверные (удаленные). Локальные хуки не затрагивают мою команду, и их можно оптимизировать под себя как угодно.

#432 | 2023-02-20 12:27:03 Проверено

В ветке таск-92
1) сначала коммит
2) потом пулл
3) потом пуш

да, потом запушить и влить в мастер либо локально (и снова запушить) либо через мерж или пулл реквест

#439 | 2023-02-21 15:17:21 Проверено

"Кто первый встал, того и тапки!" Перед push, сделай fetch и проверь, нет ли конфликтов.

Здесь можно оставить комментарий!