Система контроля версий
— это система, записывающая изменения в файл или набор файлов в течение времени и позволяющая вернуться позже к определённой версии. Она позволяет вернуть файлы к состоянию, в котором они были до изменений,вернуть проект к исходному состоянию, увидеть изменения, увидеть, кто последний менял что-то и вызвал проблему, кто поставил задачу и когда и многое другое.
1. Когда нужно работать с другими разработчиками (ранее использовались централизованные системы контроля версий в которых хранились все данные об изменениях) Минус состоит в том, что если сервер упал, то все разработчики не имеют к нему доступ
2. Когда нужно сохранить все версии программы, VCS способна вернуть любую сохранённую версию программы.
Каждый раз, когда вы делаете коммит, то есть сохраняете состояние своего проекта в Git, система запоминает, как выглядит каждый файл в этот момент, и сохраняет ссылку на этот снимок
Для примера, чтобы посмотреть историю проекта, Git не нужно соединяться с сервером для её получения и отображения — система просто считывает данные напрямую из локальной базы данных. Это означает, что вы увидите историю проекта практически моментально. Если вам необходимо посмотреть изменения, сделанные между текущей версией файла и версией, созданной месяц назад, Git может найти файл месячной давности и локально вычислить изменения, вместо того, чтобы запрашивать удалённый сервер выполнить эту операцию, либо вместо получения старой версии файла с сервера и выполнения операции локально.
В Git для всего вычисляется хеш-сумма, и только потом происходит сохранение. В дальнейшем обращение к сохранённым объектам происходит по этой хеш-сумме. Это значит, что невозможно изменить содержимое файла или каталога так, чтобы Git не узнал об этом. Данная функциональность встроена в Git на низком уровне и является неотъемлемой частью его философии. Вы не потеряете информацию во время её передачи и не получите повреждённый файл без ведома Git.
These are serializable objects.
Коммит состоит ИЗ
1) HASH - уникальное значение, по которому мы можем отыскать нужный нам коммит. Идентификатор коммита,
2) Автор,
3) время коммита,
4)комментарий, а также
5) ссылка на предка, на предыдущий коммит.
6) Ссылка на дерево Объектов - Дерево - содержит ссылки на файлы. Blob (Binary Large object)- содержание файла, байты.
Как создать коммит? сперва нужные файлы добавляются в индекс, это некий список файлов, состояние которых мы хотим сохранить.
git add .
Затем мы создаём сам коммит
git commit - для создания файла с многострочным комментарием
Перезаписать, обновить последний коммит
git commit --amend -m “comment” Change the last commit and give a new comment
git commit --amend —no-edit Modify the most recent commit without changing its commit message
git restore "fileName"
git restore —staged "fileName"
git restore --source="commit" or "file"
Убрать все изменения в файле. Вернуть файл из индексаgit reset HEAD~1 отменить последний коммит (—mix) by default
git reset —mix "commitHash" Отменить коммит, изменения удаляются из индекса, но остаюстя в рабочем каталоге.
git reset —soft HEAD~1
git reset —hard HEAD~1
git revert "commitHash" - отменить все сдленные изменения в коммите, и создать новый коммит, старый коммит останется в истории
Ветка - это независимая линия разработки. Которая позволяет вести разработку с несколькими версиями проекта параллельно.
git branch "branchName" - создаст ветку, но не перейдёт в неё. HEAD будет указывать на текущую ветку.
git switсh -c "branchName" - создаст ветку и перейдёт в неё.
git branch —move bad_name correct_name - локальное переименование
git branch -m old_name new_name
git checkout "hash" - перейти в бранч с нужным коммитом, поиск коммита по Хешу
git switch main - веруться в мастер ветку (мейн)
git switch "branchName"
git branch -v - вывести все веткеи с полседними комитами
git branch --merged -показать слитые ветки
git branch --no-merged - показать те что не слитые
git branch -c "branchName"
git push --set-upstream origin corrected-branch-name- пуш в удалённый репозиторий ветки
git push --set-upstream origin vsabadash/applying_specific_options - если гит не видит ветку, запушить ведку в удалённый репо (origin) текущая ветка в
git push origin --delete bad-branch-name - удалить из удалённого репо
git init
git clone "repoName" -
git pull
git fetch
git merge
git config --local name.name "Test22"
git config --global user.email johnconnor@gmail.com
git config --system
git config —global, —local —system
git config --list --show-origin
git config —global user.name 'Vitalii"
git config --global user.email johnconnor@gamil.conm
git config --list - check all settings
git status
git add .
git commit -m 'comment'
git commit --amend -m 'comment'
git commit --amend --no-edit
git restore --staged "fileName"
git restore "filename"
git revert "commit"
git reset --soft Head~1
git reset --mix
git reset --hard
git rev-list "hash".."hash" --count # Посчитать количество коммитов от хеша к хешу
git rev-list "hash"..head
git rev-list HEAD —count посчитать колличество коммитов
git rev-list c07147e..head --count
git branch -v - verbose verion
git switch -c "branchName"
git bracnh "branhcName" head becomes on current branch
git branch --no-merged
git branch --merged
git branch -d Testing - delete local branch
git branch -D testing - forced localremoval
git branch --move "bad_branch_name" "correct_name" - rename branch
git push --set-upstream origin "correct_branch" - add the new branch into remote
git push origin —delete master - delete remote branch
git branch -v
[]
git switch -c new_branch - created
git push --set-upstream origin "new_branch" - add to remote
git push origin --delete new_branch -delete from remote
[]
git remote add "shortName" "remoteBranch name" - how to add remote repo.
git merge "branchName"
git rebase "branchName"
git rebase -i Head~3 - # squash - but we need to count hashes you want to squash
git rev-list "hash"..head
git rev-list HEAD —count посчитать колличество коммитов
git rev-list c07147e..head --count
r - изменить коммент
p - оставить коммент
f - cжать без коммента
s - сжать с комментом
d - удалить
exec - execute tests or smth that can be executable
ssh-keygen.exe -t ed25519 -C 'your_email'
~/.ssh/
copy pub key > put in github->setting->ssh
ssh -T git@github.com - check ssh
ssh -T git@gitlab.com - chec gitlab ssh
git tag
git tag -a "tagName" -m "comment"
git tag -d v1git tag -a "tagName" "commitHash"
git checkout "tagName" - This will put you in a detached HEAD state, meaning you’re not on any branch. If you want to make changes,you should create a new branch from that commit:
git git checkout -b "new_branch_name" "commit_hash"
git stash
git stash list
git stash apply {stashIndex}
git stash pop
git stash --keep-index
git stash --include-untracked
git stash --patch
git stage branch "branchName"
git log
git log --stat
git log --oneline --decorate --all --graph
git log -p
git config --global alias.lol log -10
git config --global alias.last log -1 -p
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.s status
git config --global alias.last 'log -1 HEAD’
git config --global alias.graph '—oneline —decorate —graph —all'
git config --global alias.aa "add ."
git config --global alias.s "status"
git reflog
# вы увидите список всего, что сделали в git, во всех ветках! у каждого элемента есть индекс HEAD@{индекс} найдите тот, перед которым всё сломалось
git reset HEAD@{index} волшебная машина времени
# How to restore deleted commit
git reflog # показывает список ДЕЙСТВИЙ во всех ветках
reset HEAD@{index}
git branch "newBranchName" "commitHash"
# Есть 2 вида хуков
# Клиентские и Серверные
# Клиентские: # Находятся: Хуки на стороне клиента располагаются в папке .git/hooks
# # Если вы решите использовать какой-либо из # предустановленных скриптов, то достаточно его просто переименовать, убрав суффикс # .sample.
1) **Pre-commit** (предкоммит): Запускается перед созданием коммита. Часто используется для проверки форматирования кода или запуска линтеров. - Пример: Предотвращение коммита, если код не соответствует стиля
2) **Prepare-commit-msg** (подготовка сообщения коммита): Запускается перед тем, как откроется редактор сообщения коммита, позволяя изменить или добавить контент в сообщение.
3) **Commit-msg** (сообщение коммита): Запускается после ввода сообщения коммита, но до его завершения. Может использоваться для проверки соблюдения правил написания сообщений.
4) **Post-commit** (посткоммит): Запускается после завершения коммита. Часто используется для уведомления команды или логирования информации.
5) **Pre-push**(перед пушем): Запускается перед выполнением `git push`. Используется для проверки прохождения всех тестов перед отправкой изменений в удаленный репозиторий. - Пример: Убедиться, что все юнит-тесты проходят перед пушем.
Эти хуки запускаются на сервере Git, обычно во время операций, таких как пуш или слияние, и используются для обеспечения соблюдения правил на уровне репозитория.
# **Pre-receive** (предприемный): Запускается на сервере перед тем, как пуш будет принят. Часто используется для обеспечения соблюдения политик, например, требования прохождения тестов или завершения код-ревью. # - Пример: Отклонение пуша, который не соответствует стандартам вклада в репозиторий.
# **Update** (обновление): Похож на `pre-receive`, но запускается для каждой ветки, которая обновляется, давая больше контроля над отдельными ветками. # - Пример: Отклонение пуша в ветку `main`, если он исходит не от определенной команды.
# **Post-receive** (после приема): Запускается после того, как пуш был принят. Часто используется для деплоя или уведомления. # - Пример: Триггер сборки в CI (непрерывной интеграции) после пуша нового кода.