COURSE [GIT]

gistfile1.txt

COURSE [GIT]
https://ru.hexlet.io/courses/intro_to_git

Основы Git
git --version - посмотреть установленную версию
brew install git - установить гит
echo "export LANG=en_US.UTF-8" >> ~/.bashrc  потом source ~/.bashrc  - изменяет язык гита в консоли

git config --global user.name "Vitaliy Ismagilov" - установить имя
git config --global user.email "[email protected]" - установить почту
git config --global core.autocrlf true - игнорировать концы строк

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

Инициализация локального репозитория
mkdir example - Создаем папку в нужной директории
Cd example - переходим в нее
Git init - инициализируем репозиторий. Инициализация создаёт скрытую директорию .git (проверить это можно через ls -la). Внутри неё содержится конфигурация репозитория (в файле .git/config) и все изменения, которые когда-либо делались с репозиторием. Её удаление равносильно удалению репозитория. При этом код, с которым мы непосредственно работаем (то, что лежит вне .git) находится в так называемой рабочей копии. Рабочая копия называется копией не случайно. Удалив все её содержимое, мы ничего не теряем. Git всё помнит и позволяет восстановиться до исходного состояния. Рабочая копия - это директория, в которой находятся файлы проекта (то есть все, кроме самой директории .git).

git status - проверка состояния что находится в рабочей копии (до коммита).

Коммит
git add README.md -> Так Git увидит новый файл (подготавливает изменённый или добавленный файл к коммиту. Без её выполнения сделать коммит не получится.) По сути эта команда добавляет файл наш в статус отслеживания гитом.
git commit -m 'init project' -> Коммит с сообщением 'init project' (непосредственно фиксирует изменения в репозитории).

История: git log
git log -> посмотреть историю коммитов.
git log -p. -> выводит непрерывную разницу (diff) всех изменений по коммитам.
git show 3a64fccf14725593b7486ff09d6a6c325a5f8fcc -> Зная идентификатор коммита можно посмотреть изменения в коде (или короткий вариант git show 3a64fcc по 7 первым цифрам id коммита).
git diff -> показывает различия между репозиторием и вашей рабочей копией. Её полезно запускать тогда, когда вы хотите посмотреть изменения сделанные в рабочей копии, но не добавленные для коммита командой git add. (По сути показывает (по умолчанию) изменения, сделанные в рабочей копии).

Состояния файлов в Git
 - Неотслеживаемые файлы
В первую очередь все файлы делятся на отслеживаемые (tracked) и неотслеживаемые (untracked). Untracked – это новый файл, который не был добавлен для отслеживания командой git add. Все остальные файлы являются tracked.

специальный файл .gitignore, который поможет Git определить то, что точно не придётся коммитить. Больше вы эти файлы и директории не увидите даже после команды git status. Всё, что перечислено в этом файле, закоммитить не удастся. Правда, если вы хотите добавить в .gitignore то что уже было закоммичено, предварительно придётся удалить соответствующие данные из репозитория с помощью команды git rm.

 - Отслеживаемые файлы
С отслеживаемыми файлами всё сложнее. Начнём с того, что они тоже могут находиться в 3-х разных состояниях:
* неизменённое (unmodified)
* изменённое (modified)
* подготовлено к коммиту (staged).

Изменённое состояние тоже интуитивно понятно. Как только мы изменили любой файл в состоянии unmodified (но не untracked!), он автоматически становится modified. И вот тут нас поджидает сюрприз: если попробовать вызвать git commit, то файлы в состоянии modified в него не попадут. Предварительно их нужно перевести в состояние staged сделав git add. В этом и заключается смысл команды git add, она переводит файлы с любым состоянием, кроме unmodifed, в состояние staged. Это касается и файлов в состоянии untracked. И только после этого они попадут в коммит.

Три состояния Git

Working directory -> Staging area -> .git directory

- Working directory - состояние до git add (состояние untracked)
- Staging area -> состояние после git add  но до commit (состояние staged внутри директории .git).
- .git directory -> состояние после git commit.

Состояние файлов:
- Untracked
- Unmodified
- Modified
- Staged.


Сброс изменений файла
помогут две команды: reset и checkout.
* git reset path/to/file переводит файл из состояния staged в modified
* git checkout -- path/to/file переводит файл из состояния modified в unmodified, то есть по сути эта команда сбрасывает изменения.

Ветки в Git
веткa — master -> классная ветка локального репозитория
git branch - покажет все ветки (локальные) и текущую ветку символом *.
git branch new-feature -> создание новой ветки c названием new-feature
git checkout new-feature -> переключение на уже существующую ветку new-feature
git log --oneline --decorate --graph  - покажут инфо * c082d77 (HEAD -> new-feature, master) fix stripping
HEAD - последний коммит любого бранча.

Слияние
git merge - вы реализовали фичу и теперь хотите, чтобы этот код оказался в ветке master. Результатом слияния, становится особенный merge commit (Его отличие от остальных коммитов в том, что этот коммит не содержит изменений, но он ссылается сразу на двух родителей).
! Команда git merge выполняется из той ветки, в которую мы сливаем изменения, а аргументом передаётся имя той ветки, которую мы сливаем (git checkout master, а потом git merge new-feature).

Перемещение
Команда git rebase относится к продвинутым техникам Git, но именно она делает вас настоящим властелином репозиториев. Как только основы будут освоены, окунитесь в её изучение.

Распределенный Git (удалённый репозиторий)
origin – это имя удалённого репозитория.

Отправка изменений
git push origin master. - залить изменения TO origin FROM master. Эта команда выполняет отправку новых коммитов из текущего репозитория (master) в удалённый (origin)

Отслеживаемая ветка устанавливается командой git push --set-upstream origin master. Эта команда выполняет два действия: устанавливает отслеживание и отправляет изменения. Она выполняется ровно один раз, далее можно отправлять изменения набирая просто git push. 

Получение изменений
git pull  -> получить изменения, сделанные в удалённом репозитории, а затем слить их со своими локальными (по сути это комбинация git fetch + git pull в одной команде git pull).
git fetch ->  подтягивает (извлекает) изменения с сервера на ваш локальный репозиторий, но не сливает их со своими локальными.











/////////
https://www.software-testing.ru/edu/3-online/270-git

Установка Git на локальный компьютер
Команда git clone
Информационные команды:
* git status
* git diff
* git log
* git show
* git blame
Работа с удаленной информацией:
* git fetch
* git pull
Работа с локальными изменениями:
* git commit
* git push
* git merge
Работа с буфером:
* git stash
* git pop
Работа с ветками:
* git branch
* git branch delete
* git checkout
Работа с файлами:
* git add
* git reset
* git reset --soft
* git reset --hard
* git reset HEAD
Работа с git-конфигом:
* git alias
* user
* color
* .gitignore
Решение конфликтов:
* решение конфликта мержа ветки
* решение конфликта буфера



/////////___________________//////  https://learngitbranching.js.org/   //////________________//////////

 - Create branch and switch to it at same time -> git checkout -b [your branch name]
 - Create branch -> git branch [new branch name]
 - Switch to existing branch -> git checkout [branch name]
 - Merge branch into main -> You are in your branch (git checkout [your branch]) -> git merge main