Git
# -------------------------------------------------------------------
# Git (менеджер контроля версий кода)
# Помнит всю историю изменений, в т.ч. при командной разработке
# Локальный репозиторий (на моей машине) / удаленный репозиторий (на сервере)
# GitHub/Bitbucket/GitLab - облачное хранилище удаленных репозиториев (самые популярные)
# -------------------------------------------------------------------
------------------------------------------------------------------------------
| WORKFLOW |
------------------------------------------------------------------------------
| Create | Browse | Revert | Update | Branch | Commit | Publish |
| | | | | | (save) | |
------------------------------------------------------------------------------
| init | status | reset | pull | checkout | add | push |
| clone | log | checkout | fetch | branch | commit | |
| ------- | show | revert | merge | ---------- | | |
| config | diff | | am | workflow | | |
| remote | branch | | | | | |
------------------------------------------------------------------------------
# -------------------------------------------------------------------
# Create (инициализация)
# -------------------------------------------------------------------
$ git --version
$ git init // создать пустой репозиторий (.git - папка где будет хранится история изменений)
$ git clone https://url.ru // скачать проект к себе (набор дирректорий с файлами) с сервера GitHub
.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 // Не учитывать права на файлы
$ git remote // список удаленных репозиториев
$ git remote -v // список удаленных репозиториев (подробно)
$ git remote add https://github.com/litovchenko1/site.git // добавить удаленный сервер (облачное хранилище), origin - имя репозитория
$ git remote set-url origin https://iv-litovchenko:@github.com/iv-litovchenko/maptex.git
# -------------------------------------------------------------------
# Browse (обзор изменений)
# -------------------------------------------------------------------
// Проверка состояния изменений (зеленые строчки - что-до добавили, красные строчки - что-то удалили)
$ git status
$ git status -u // включая содержимое папок
$ git shortlog
$ git log // если пришли в новую контору и решили посмотреть что там (история изменений)
$ git log --oneline // выведем только заголовок с помощью
$ git log --since=2.weeks // показать коммиты за последние две недели
$ git log -n 3
$ git log -n 10 // количество коммитов
$ git show // посмотреть в наглядном виде
$ git diff
# -------------------------------------------------------------------
# Revert (откат имзеенний)
# -------------------------------------------------------------------
// Указатель HEAD - это указатель на текущий коммит
// ID-коммита - это сокращенное название контрольной суммы SHA-1
$ git reset // позволяет перемещаться по указателям
$ git reset HEAD~ // отмена последнего коммита (файлы из данного последнего коммита переходят в статус unstaged, то есть в то состояние, в котором они были до коммита)
$ git reset --hard HEAD~1 // полное удаление последнего коммита
// Например: у вас есть следующие коммиты A←B←C←HEAD. Коммит C самый последний и на него указывает HEAD (указатель на текущее состояние).
// После выполнения команды git reset --hard HEAD~1 вы получите состояние A←B←HEAD (коммит C будет удален). HEAD теперь указывает на коммит B.
// Отмена до состояния репозитория (если мы по экспериментировали и хотим откатится до того состояния как в репозитории)
$ git checkout -- ИМЯ-ФАЙЛА // откатывает до того состояния как в репозитории
$ git checkout . // отменить все изменения
// Как удалить коммит в gitLab?
$ git reset --hard <последний перед удаляемыми коммит>
$ git push -f
# -------------------------------------------------------------------
# Update (получение изменений)
# -------------------------------------------------------------------
$ git fetch // скачивает обновления из удаленного репозитория (remote), но не сливает их с текущей веткой (нужно будет сделать еще git merge)
$ git pull // скачать (забрать) изменения с удаленного репозитория (это команда-псевдоним сразу двух git команд - git fetch и git merge.)
$ git pull origin main // стянуть изменения в мою ветку (например task-18)
$ git push origin master:backup-17-11-2022 // рез. копия проекта: ветки — локальная:удалёная (замена zip-пованию)
# -------------------------------------------------------------------
# Commit (сохранение изменений)
# -------------------------------------------------------------------
// Публикация изменений - все файлы могут быть в трех состояниях:
// A) Модифицированные (измененные, но не проиндексированные)
// B) Индексированные (подготовленные для фиксации)
// C) Зафиксированные (сохранены в .git-каталоге)
// Изменения автору проекта (какого-либо расширения) можно отправить в виде реквеста
// Добавление в индекс (индексирование файлов и нахождение изменений в них)
$ git add . // добавить все изменени
$ git add
$ git add
// Удаление из индекса
$ git rm --cached <ИМЯ-ФАЙЛА> // если файл был добавлен по ошибке - удаляем из индекса
$ git rm -r --cached <ИМЯ-ПАПКИ> // если папка была добавлена по ошибке - удаляем из индекса
// Фиксация изменений (сохранение изменений (не любое изменение на проекте, а зафиксированное изменение в репозитории))
$ git commit -am "Коммент - Первый коммит" // зафиксировать изменения + их коммит
$ git commit -m "Коммент - добавляем файл" // только коммит (если без -m - название будет вводится в ручную)
$ git commit // Откроется окно с редактором
# -------------------------------------------------------------------
# Publish (публикация изменений)
# -------------------------------------------------------------------
// Для отправки изменений в удаленный репозиторий (например на GitHub) Нужно:
// 1) Создать аккаунт на github
// 2) Создать репозиторий на github
$ git push // отправить/протолкнуть изменения в удаленный репозиторий на сервер
$ git push -u origin master // название сервера удаленного репозитория, - название ветки
$ git push origin ao-1
$ git push origin --all // отправить все сразу
$ git push origin --tags // отправить все теги сразу
$ git tag 1.2.0 (теги добавляются только в ветку )
# -------------------------------------------------------------------
# Branch (работа с ветками - по умолчанию ветка master (main))
# -------------------------------------------------------------------
// Ветка - это исходный код в независимом паралельном варианте
// Ветки нужны что бы разделить код (например одна ветка для разработки нового функционала, другая ветка для продакшина).
// После ветки сливаются в основную ветку (зависит от workflow).
$ git branch // список веток ("*" звездочкой помечена текущая ветка на которой находимся)
$ git branch -v // список веток с их различием
$ git branch <...BRANCH_NAME...> // создать ветку
$ git branch -D <...BRANCH_NAME...> // удалить ветку
$ git checkout <...NAME...> // переключится на ветку
$ git checkout -b new_f // создать ветку и переключится на нее
// Когда закончили работу с веткой переключаемся на основную, и вливаем в нее нашу ветку
$ git checkout master
$ git merge <...BRANCH_NAME...> // возьмет две ветки, которые мы объединяем, найдет общий базовый коммит, а затем воспроизведет последовательность коммитов из двух веток в базовом коммите, чтобы объединить ветки
$ git rebase <...BRANCH_NAME...> // берет всю вашу функциональную ветку и перемещает ее в конец основной ветки .
// Пример - в ветке таск-92
// да, запушить и влить в мастер либо локально (и снова запушить) либо через мерж или пулл реквест
1) сначала коммит
2) потом пулл (забрать)
3) потом пуш (отправить)
// Мерж конфликтов (объединение изменений одного файла из разных источников)
// 2 разных разработчика поменяли код в 1 и том же файле
// Слева текущая ветка | По центру результат объединения | Справа вливаемая ветка
// Области: зеленые области - нет конфликтов; красные области - зоны конфликтов
// При разгуливании конфликтов можно использовать добавку в стеш (после git pull, после выбор из стеша)
// Модель ветвления (gitflow - подход к работе на основе таск-трекера)
// Ветки создаются на github. На локальной машине они не создаются.
// Под каждую новую задачу создается новая ветка от ветки
- это оригинальная ветка
- На ветке - задачи тестируются
- Название новых веток задается как <код_проекта>_<название_изменения>_<№задачи> на основе таск-трекера
- Ветки создаются от ветки
- После делается пулл-реквестти в ветку (примите мои изменения)
- После решения задачи ветка удаляется
- Каждому релизу присваивается тэг версии X.X.X
// Как организовать работу (тракинг) - TAB Issuse
- 1) Создаем задачу на GitHub [projname - сокращенное название проекта].[1 - номер задачи]
- 2) На основе номера задачи (ID) создаем ветку projname.1_название
- 3) Делаем локальные изменения
- 4) На GitHub делаем Pull Request -> в (merge -> pull request)
- 5) Далее на GitHub Pull Request в
# -------------------------------------------------------------------
# Описание GitHub-сервиса
# -------------------------------------------------------------------
// Интерфейс
- TAB Issuse - создать баг/задачу (трекинг)
- TAB Fork - создание форка
- TAB Watch - отслеживание репозитория
- Настройка Web-Hook - можно организовать авто-деплой
- https://github.com/settings/tokens (Personal access tokens (classic))
// SSH-ключи для GitHub
1) $ ssh-keygen // команда создает ключ (спрашивает где сохранить, просит придумать пароль)
2) далее берем копируем публичный ключ ($ cat /home/i/ilitovfa/.ssh/id_rsa.pub)
3) далее идем на github и добавляем публичный ключ в разделе SSH-keys
# -------------------------------------------------------------------
# Правила оформления коммитов
# -------------------------------------------------------------------
// Есть два подхода к сохранению изменений в историю:
- атомарные коммиты — логически отделимые операции разделяются на отдельные коммиты;
- массовый коммит со всеми изменениями по задаче.
// Правильно составлять описания коммитов:
- Правило 1: оставляйте пустую строку между заголовком и описанием
- Правило 2: ограничивайте длину заголовка 50 символами (гарантирует читабельность заголовка, позволяет кратко описть изменения)
- Правило 3: пишите заголовок с прописной (заглавной) буквы
- Правило 4: не ставьте точку в конце заголовка описания
- Правило 5: используйте повелительное наклонение в заголовке. Вот примеры (Сделай уборку, Закрой дверь, Вынеси мусор)
- Правило 6: ограничивайте длину строки в теле описания 72 символами
- Правило 7: в теле описания отвечайте на вопросы «что?» и «почему?», а не «как?» Сфокусируйтесь на объяснении причин изменений — на том, как всё работало до изменений и что здесь было не так, и на том, как оно работает сейчас
// Коммит должен быть — лаконичным и однородным (не длинным).
// Рекомендуется начинать описание коммита со строки длиной до 50 символов, которая обобщает изменения.
// За ней должна следовать пустая строка, а затем более подробное описание коммита.
/interactive/content_wiki/soft || git.txt
Здесь можно оставить комментарий!