Git - это бесплатная распределенная система управления версиями с открытым исходным кодом, предназначенная для быстрой и эффективной обработки всего, от небольших до очень крупных проектов. Git прост в освоении, занимает мало места и обладает молниеносной производительностью. Он превосходит инструменты SCM, такие как Subversion, CVS, Perforce и ClearCase, с такими функциями, как дешевое локальное ветвление, удобные промежуточные области и несколько рабочих процессов.
Особенность Git, которая действительно отличает его от почти всех других SCM, - это его модель ветвления. Git позволяет и поощряет создание нескольких локальных веток, которые могут быть полностью независимыми друг от друга. Создание, слияние и удаление этих линий разработки занимает секунды. Это означает, что вы можете делать что-то вроде:
Примечательно, что когда вы отправляете в удаленный репозиторий, вам не нужно отправлять все свои ветки. Вы можете предоставить общий доступ только к одной из своих веток, нескольким или всем. Это дает людям возможность пробовать новые идеи, не беспокоясь о том, что им придется планировать, как и когда они собираются объединить их или поделиться ими с другими.
Есть способы добиться этого с помощью других систем, но эта работа намного сложнее и подвержена ошибкам. Git делает этот процесс невероятно простым и меняет способ работы большинства разработчиков, когда они его изучают.
Git работает быстро. В Git почти все операции выполняются локально, что дает огромное преимущество в скорости для централизованных систем, которым постоянно приходится где-то связываться с сервером. Git был создан для работы с ядром Linux, а это означает, что ему с самого первого дня приходилось эффективно обрабатывать большие репозитории.
Git написан на C, что сокращает накладные расходы времени выполнения, связанные с языками более высокого уровня. Скорость и производительность были основной целью Git с самого начала.
Давайте посмотрим, как общие операции сочетаются с Subversion, общей централизованной системой управления версиями, похожей на CVS или Perforce. Меньше - быстрее.
Для тестирования большие инстансы AWS были настроены в одной зоне доступности. Git и SVN были установлены на обеих машинах, репозиторий Ruby был скопирован на серверы Git и SVN, и на обоих выполнялись общие операции. В некоторых случаях команды не совпадают в точности. Здесь была предпринята попытка сопоставления по наименьшему общему знаменателю. Например, тесты «фиксации» также включают время для отправки запроса на Git, хотя в большинстве случаев вы фактически не отправляете запрос на сервер сразу после фиксации, когда две команды не могут быть разделены в SVN.
Обратите внимание, что это лучший сценарий для SVN - сервера без нагрузки с гигабитным подключением к клиентской машине. Почти все это время было бы еще хуже для SVN, если бы это соединение было медленнее, в то время как многие из Git-времени не пострадали бы. Очевидно, что во многих из этих распространенных операций управления версиями Git на один или два порядка быстрее SVN, даже в идеальных условиях для SVN. Одно место, где Git работает медленнее, - это начальная операция клонирования. Здесь Git загружает всю историю, а не только последнюю версию. Как видно из приведенных выше диаграмм, операция, выполняемая только один раз, ненамного медленнее.
Также интересно отметить, что размер данных на стороне клиента очень похож, хотя Git также имеет каждую версию каждого файла для всей истории проекта. Это показывает, насколько он эффективен при сжатии и хранении данных на стороне клиента.
Одна из самых приятных особенностей любой распределенной SCM, включая Git, - это то, что она распределенная. Это означает, что вместо «проверки» текущей части исходного кода вы выполняете «клонирование» всего репозитория.
Это означает, что даже если вы используете централизованный рабочий процесс, у каждого пользователя, по сути, есть полная резервная копия главного сервера. Каждую из этих копий можно подтолкнуть, чтобы заменить основной сервер в случае сбоя или повреждения. Фактически, у Git нет единой точки отказа, если нет только одной копии репозитория.
Благодаря распределенной природе Git и превосходной системе ветвления можно относительно легко реализовать почти бесконечное количество рабочих процессов.
Централизованный рабочий процесс очень распространен, особенно у людей, переходящих из централизованной системы. Git не позволит вам толкать, если кто-то нажал с момента последней загрузки, поэтому централизованная модель, когда все разработчики отправляют на один и тот же сервер, работает нормально.
Другой распространенный рабочий процесс Git включает в себя менеджера интеграции - одного человека, который фиксирует «благословенный» репозиторий. Затем ряд разработчиков клонируют данные из этого репозитория, отправляют их в свои собственные независимые репозитории и просят интегратора внести их изменения. Это тип модели разработки, который часто встречается в репозиториях с открытым исходным кодом или GitHub.
Для более масштабных проектов часто эффективен рабочий процесс разработки, подобный процессу ядра Linux. В этой модели некоторые люди («лейтенанты») отвечают за определенную подсистему проекта и объединяют все изменения, связанные с этой подсистемой. Другой интегратор («диктатор») может получать изменения только от своих лейтенантов, а затем отправлять их в «благословенный» репозиторий, из которого все затем клонируют снова.
Модель данных, которую использует Git, обеспечивает криптографическую целостность каждого бита вашего проекта. Каждый файл и фиксация проверяются по контрольной сумме и извлекаются по ее контрольной сумме при повторной проверке. Из Git невозможно получить что-либо, кроме точно введенных вами битов.
Также невозможно изменить какой-либо файл, дату, сообщение фиксации или любые другие данные в репозитории Git без изменения идентификаторов всего, что находится после него. Это означает, что если у вас есть идентификатор фиксации, вы можете быть уверены не только в том, что ваш проект точно такой же, как в момент фиксации, но и в том, что в его истории ничего не изменилось. Большинство централизованных систем контроля версий по умолчанию не обеспечивают такой целостности.
В отличие от других систем, в Git есть нечто, называемое «промежуточной областью» или «индексом». Это промежуточная область, где коммиты могут быть отформатированы и проверены перед завершением коммита.
Одна вещь, которая отличает Git от других инструментов, заключается в том, что можно быстро подготовить некоторые из ваших файлов и зафиксировать их без фиксации всех других измененных файлов в вашем рабочем каталоге или необходимости перечисления их в командной строке во время фиксации.
Это позволяет размещать только части измененного файла. Прошли те времена, когда в файл вносились две логически не связанные модификации, прежде чем вы осознали, что забыли зафиксировать одну из них. Теперь вы можете просто подготовить изменение, необходимое для текущего коммита, и подготовить другое изменение для следующего коммита.Эта функция позволяет при необходимости вносить в файл столько различных изменений, сколько необходимо.
Конечно, Git также позволяет легко игнорировать эту функцию, если вам не нужен такой контроль - просто добавьте '-a' в свою команду фиксации, чтобы добавить все изменения во все файлы в промежуточную область.
Git выпущен под лицензией GNU General Public License версии 2.0, которая является лицензией с открытым исходным кодом. Проект Git решил использовать GPLv2, чтобы гарантировать вам свободу обмена и изменения бесплатного программного обеспечения - чтобы убедиться, что программное обеспечение является бесплатным для всех его пользователей.
Hexlet - Введение в Git
В июле 2020 года мы объявили о своем намерении требовать использования аутентификации на основе токенов (например, токен личного доступа, OAuth или токен установки приложения GitHub) для всех аутентифицированных операций Git. С 13 августа 2021 г. мы больше не будем принимать пароли учетных записей при аутентификации операций Git на GitHub.com.
Затронутые рабочие процессы
Настольные приложения, использующие Git (GitHub Desktop не затрагивается) Любые приложения/сервисы, которые получают доступ к репозиториям Git на GitHub.com напрямую, используя ваш пароль. Это изменение не коснется следующих клиентов: Если для вашей учетной записи включена двухфакторная аутентификация, вам уже необходимо использовать аутентификацию на основе токена или SSH. Если вы используете GitHub Enterprise Server, мы не объявляли о каких-либо изменениях в нашем локальном предложении. Если вы поддерживаете приложение GitHub, приложения GitHub не поддерживают аутентификацию по паролю.
Мы описали нашу мотивацию, когда объявили об аналогичных изменениях в аутентификации с помощью API, следующим образом:
В последние годы клиенты GitHub воспользовались рядом улучшений безопасности GitHub.com, таких как двухфакторная аутентификация, оповещения о входе в систему, проверенные устройства, предотвращение использования скомпрометированных паролей и поддержка WebAuthn. Эти функции затрудняют злоумышленнику получение пароля, который повторно использовался на нескольких веб-сайтах, и использование его для попытки получить доступ к вашей учетной записи GitHub. Несмотря на эти улучшения, по историческим причинам клиенты без включенной двухфакторной аутентификации могли продолжать аутентифицировать операции Git и API, используя только свое имя пользователя и пароль GitHub.
Начиная с 13 августа 2021 г. мы больше не будем принимать пароли учетных записей при аутентификации операций Git и будем требовать использования аутентификации на основе токенов, например токена личного доступа (для разработчиков) или токена установки приложения OAuth или GitHub (для интеграторов). для всех аутентифицированных операций Git на GitHub.com. Вы также можете продолжать использовать SSH-ключи там, где вам удобно.
Токены предлагают ряд преимуществ в плане безопасности по сравнению с аутентификацией на основе пароля:
Что вам нужно сделать сегодня
Дополнительные сведения см. в разделе Авторизация приложений OAuth и объявление в блоге разработчиков.
Включение двухфакторной аутентификации
Если вы хотите убедиться, что ваша учетная запись не поддерживает аутентификацию на основе пароля, вы можете включить двухфакторную аутентификацию для своей учетной записи сегодня. Это потребует от вас использовать личный токен доступа для всех аутентифицированных операций через Git и сторонние интеграции.
Браунауты
Чтобы все затронутые клиенты знали об изменении аутентификации, во время двух запланированных отключений мы временно отключим поддержку аутентификации по паролю, а операции Git, выполняемые с использованием пароля, временно завершатся сбоем.
График
Сегодня — если вы используете пароли для аутентификации операций Git с GitHub.com сегодня, вы скоро получите электронное письмо с призывом обновить метод аутентификации или сторонний клиент.
git hist
git status
git add .
git log
git commit -m "Описание изменения"
git push
Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript. ya.ru + Token1Восстановление файла в предыдущее состояние
git log
git checkout <обозначение коммита> <имя файла>
Показать настройки всех уровней
git config --list --global
IgorL@igor2022 MINGW64 ~/PycharmProjects/LawBot (master)$ git config --listdiff.astextplain.textconv=astextplainfilter.lfs.clean=git-lfs clean -- %ffilter.lfs.smudge=git-lfs smudge -- %ffilter.lfs.process=git-lfs filter-processfilter.lfs.required=truehttp.sslbackend=opensslhttp.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crtcore.autocrlf=truecore.fscache=truecore.symlinks=falsepull.rebase=falsecredential.helper=managercredential.https://dev.azure.com.usehttppath=trueinit.defaultbranch=masteruser.name=IgorLytkinuser.email=core.repositoryformatversion=0core.filemode=falsecore.bare=falsecore.logallrefupdates=truecore.symlinks=falsecore.ignorecase=trueremote.origin.url=https://github.com/IgorLytkin/LawBot.gitremote.origin.fetch=+refs/heads/*:refs/remotes/origin/*branch.master.remote=originbranch.master.merge=refs/heads/master
Посмотреть все настройки и где они хранятся
git config --list --show-origin
IgorL@igor2022 MINGW64 ~/PycharmProjects/LawBot (master)$ git config --list --show-originfile:C:/Program Files/Git/etc/gitconfig diff.astextplain.textconv=astextplainfile:C:/Program Files/Git/etc/gitconfig filter.lfs.clean=git-lfs clean -- %ffile:C:/Program Files/Git/etc/gitconfig filter.lfs.smudge=git-lfs smudge -- %ffile:C:/Program Files/Git/etc/gitconfig filter.lfs.process=git-lfs filter-processfile:C:/Program Files/Git/etc/gitconfig filter.lfs.required=truefile:C:/Program Files/Git/etc/gitconfig http.sslbackend=opensslfile:C:/Program Files/Git/etc/gitconfig http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crtfile:C:/Program Files/Git/etc/gitconfig core.autocrlf=truefile:C:/Program Files/Git/etc/gitconfig core.fscache=truefile:C:/Program Files/Git/etc/gitconfig core.symlinks=falsefile:C:/Program Files/Git/etc/gitconfig pull.rebase=falsefile:C:/Program Files/Git/etc/gitconfig credential.helper=managerfile:C:/Program Files/Git/etc/gitconfig credential.https://dev.azure.com.usehttppath=truefile:C:/Program Files/Git/etc/gitconfig init.defaultbranch=masterfile:C:/Users/IgorL/.gitconfig user.name=IgorLytkinfile:C:/Users/IgorL/.gitconfig user.email=file:.git/config core.repositoryformatversion=0file:.git/config core.filemode=falsefile:.git/config core.bare=falsefile:.git/config core.logallrefupdates=truefile:.git/config core.symlinks=falsefile:.git/config core.ignorecase=truefile:.git/config remote.origin.url=https://github.com/IgorLytkin/LawBot.gitfile:.git/config remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*file:.git/config branch.master.remote=originfile:.git/config branch.master.merge=refs/heads/master
Head First Git: A Learner's Guide to Understanding Git from the Inside Out (2022). Автор: Raju Gandhi ISBN: 978-1-492-09251-3, 13.01.2022.
Глава 1. Начало Git
mkdir created-using-the-command-line cd created-using-the-command-linegit init git config --global user.name "IgorLytkin" git config --global user.email "
git add Checklist.md
git commit -m "My first commit"
Состояния файла
UNTRACKED - Git видит новый файл в рабочем каталоге. Это файл, который никогда не добавлялся в индекс. Git помечает этот файл как неотслеживаемый”, и таким образом Git сообщает нам , что вам, вероятно, следует добавить его в индекс (и в конечном итоге зафиксировать).
STAGED - Файл был добавлен в индекс. Если вы впервые добавили этот конкретный файл в индекс, Git начнет отслеживать этот файл. Несмотря на это, добавление файла в индекс помечает его как “STAGED”.
UNMODIFIED - Как только вы фиксируете, он берет все файлы, которые вы добавили в индекс , и фиксирует их в своей памяти. Затем он помечает все эти файлы как “неизмененные”. Это то состояние, к которому вы все должны стремиться. Это говорит вам о том, что содержимое файла надежно сохранено в памяти Git.
MODIFIED - Если вы отредактировали файл после того, как он был зафиксирован, файл переходит в измененное состояние в качестве напоминания о том, что вы должны в конечном итоге зафиксировать его.
Историю коммитов Git часто называют ориентированным ациклическим графом, или сокращенно DAG, в котором коммиты образуют “узлы”, а указатели на родительский объект образуют “ребра”. Они являются направленными, потому что дочерние элементы указывают на родительские, и ациклическими , потому что родители не указывают обратно на своих дочерних элементов.
Глава 2. Разветвление (множественные ходы мыслей)
Branch - ветвь.
Ветви позволяют вам сохранять ваши изменения полностью независимыми друг от друга. Один из способов подумать о вашей истории коммитов - это визуализировать ваши коммиты в виде бутонов на ветке дерева. Когда вы работаете с любой веткой, коммиты выполняются последовательно, появляясь один за другим.
Фиксация (commit) представляет собой момент времени, а ветвь представляет собой серию фиксаций. Напомним, что серия коммитов - это также история коммитов. Таким образом, ветви - это разные истории коммитов, все в одном репозитории! В любой момент вы можете создать новую ветвь, переключаться между ветвями, отказаться от ветки (то есть решить отказаться от всей работы, которую вы в нее вложили) и даже объединить ветви.
git branch my-first-branch git branch
git switch my-first-branch
Каждый раз, когда вы переключаете ветки, Git переписывает ваш рабочий каталог, чтобы он выглядел так, как это было, когда вы делали самую последнюю фиксацию в ветке, на которую вы только что переключились. Ветви ”Feature" часто называют ветвями “topic”. По сути, они одинаковы.
git branch -v
integration branch - ветвь интеграции, master/main или выбранная.
Глобальные настройки Git git config --global -l
Слияние ветвей Git
IgorL@igor2022 MINGW64 /d/Git/headfirst-git-samples/80s-diner (master)
$ git branch -v
add-fall-menu ad0416a update heading
add-thurs-menu f3ddca3 add thursdays menu
* master f3ddca3 add thursdays menu
IgorL@igor2022 MINGW64 /d/Git/headfirst-git-samples/80s-diner (add-fall-menu)
$ git switch master
Switched to branch 'master'
IgorL@igor2022 MINGW64 /d/Git/headfirst-git-samples/80s-diner (master)
$ git merge add-thurs-menu
Updating 620f49f..f3ddca3
Fast-forward
thursdays-menu.md | 10 ++++++++++
1 file changed, 10 insertions(+)
create mode 100644 thursdays-menu.md
IgorL@igor2022 MINGW64 /d/Git/headfirst-git-samples/80s-diner (master)
$ ls -la
total 14
drwxr-xr-x 1 IgorL 197121 0 Aug 17 13:57 ./
drwxr-xr-x 1 IgorL 197121 0 Aug 17 13:02 ../
drwxr-xr-x 1 IgorL 197121 0 Aug 17 13:57 .git/
-rw-r--r-- 1 IgorL 197121 425 Aug 17 11:17 menu.md
-rw-r--r-- 1 IgorL 197121 417 Aug 17 13:57 thursdays-menu.md
IgorL@igor2022 MINGW64 /d/Git/headfirst-git-samples/80s-diner (master)
$ git merge add-fall-menu
Merge made by the 'ort' strategy.
fall-menu.md | 12 ++++++++++++
1 file changed, 12 insertions(+)
create mode 100644 fall-menu.md
IgorL@igor2022 MINGW64 /d/Git/headfirst-git-samples/80s-diner (master)
$ ls -la
total 18
drwxr-xr-x 1 IgorL 197121 0 Aug 17 14:31 ./
drwxr-xr-x 1 IgorL 197121 0 Aug 17 13:02 ../
drwxr-xr-x 1 IgorL 197121 0 Aug 17 14:31 .git/
-rw-r--r-- 1 IgorL 197121 570 Aug 17 14:31 fall-menu.md
-rw-r--r-- 1 IgorL 197121 425 Aug 17 11:17 menu.md
-rw-r--r-- 1 IgorL 197121 417 Aug 17 14:31 thursdays-menu.md
После второго git merge (слияние ветви master с ветвью add-fall-menu) в рабочем каталоге появился файл fall-menu.md. Почему не появился после первого git merge?
Конфликты слияния возникают, если две ветви вносят изменения в один файл. Для разрешения конфликта нужно отредактировать конфликтный файл, устранить конфликт, добавить файл и выполнить фиксацию.
Глава 3. Осматриваясь вокруг (исследуя свой репозиторий Git)
git log
$ git log -v
commit 8d670e93e297b126fc0466caf37c0033b6c018ab (HEAD -> spicy-version)
Author: Rosemary Berry <
Date: Mon Mar 15 18:52:50 2021 -0400
update recipe name
commit 4cca5a7b3225a88c2df12bd157f5877bc3dded9e
Author: Rosemary Berry <
Date: Mon Feb 15 17:24:41 2021 -0500
make it spicy
commit 5db2b68c4cf2699e89fe1b526a7e4a171d83b2ef (master)
Author: Rosemary Berry <
Date: Sat Jan 2 19:22:59 2021 -0500
first attempt
IgorL@igor2022 MINGW64 /d/Git/headfirst-git-samples/chapter03/recipes (spicy-version)
$ git log --abbrev-commit
commit 8d670e9 (HEAD -> spicy-version)
Author: Rosemary Berry <
Date: Mon Mar 15 18:52:50 2021 -0400
update recipe name
commit 4cca5a7
Author: Rosemary Berry <
Date: Mon Feb 15 17:24:41 2021 -0500
make it spicy
commit 5db2b68 (master)
Author: Rosemary Berry <
Date: Sat Jan 2 19:22:59 2021 -0500
first attempt
IgorL@igor2022 MINGW64 /d/Git/headfirst-git-samples/chapter03/recipes (spicy-version)
$ git log --pretty=oneline
8d670e93e297b126fc0466caf37c0033b6c018ab (HEAD -> spicy-version) update recipe name
4cca5a7b3225a88c2df12bd157f5877bc3dded9e make it spicy
5db2b68c4cf2699e89fe1b526a7e4a171d83b2ef (master) first attempt
IgorL@igor2022 MINGW64 /d/Git/headfirst-git-samples/chapter03/recipes (spicy-version)
$ git log --pretty=oneline --abbrev-commit
8d670e9 (HEAD -> spicy-version) update recipe name
4cca5a7 make it spicy
5db2b68 (master) first attempt
Отображение полного графа всех ветвей в репозитории:
IgorL@igor2022 MINGW64 /d/Git/headfirst-git-samples/chapter03/recipes (master)
$ git log --oneline --all --graph
* 8d670e9 (spicy-version) update recipe name
* 4cca5a7 make it spicy
| * 0065b8a (different-base) cut down salt
| * 549e0da use sour cream
|/
* 5db2b68 (HEAD -> master) first attempt
Глава 4. Отмена (исправление ошибок)
git restore
git restore --staged
git rm
git mv
PHP (/pi:.eɪtʃ.pi:/ англ. PHP: Hypertext Preprocessor — «PHP: препроцессор гипертекста»; первоначально PHP/FI (Personal Home Page / Form Interpreter), а позже названный Personal Home Page Tools[11] — «Инструменты для создания персональных веб-страниц») — C-подобный скриптовый язык[12] общего назначения, интенсивно применяемый для разработки веб-приложений. В настоящее время поддерживается подавляющим большинством хостинг-провайдеров и является одним из лидеров среди языков, применяющихся для создания динамических веб-сайтов.
1С-Битрикс: Управление сайтом - система управления контентом веб-проекта (CMS) от российской компании «Битрикс». Сайт: https://www.1c-bitrix.ru/
"Go представляет компилируемый статически типизированный язык программирования от компании Google. Язык Go предназначен для создания различного рода приложений, но прежде всего это веб-сервисы и клиент-серверные приложения. Хотя также язык обладает возможностями по работе с графикой, низкоуровневыми возможностями и т.д.
Работа над языком Go началась в 2007 в недрах компании Google. Одним из авторов является Кен Томпсон, который, к слову, является и одним из авторов языка Си (наряду с Денис Ритчи). 10 ноября 2009 года язык был анонсирован, а в марте 2012 года вышла версия 1.0. При этом язык продолжает развиваться. Текущей версией является версия 1.19, которая вышла в августе 2022 года.
Язык Go развивается как open source, то есть представляет проект с открытым исходным кодом, и все его коды и компилятор можно найти и использовать бесплатно. Официальный сайт проекта - https://golang.org, где можно найти много полезной информации о языке.
Go является кроссплатформенным, он позволяет создавать программы под различные операционные системы - Windows, Mac OS, Linux, FreeBSD, Android и т.д. Код обладает переносимостью: программы, написанные для одной из этих операционных систем, могут быть легко с перекомпиляцией перенесены на другую ОС." [1]
"поддержка параллелизма в языке Go реализована в форме механизма взаимодействующих последовательных процессов (Communicating Sequential Processes, CSP), основанного на идеях специалиста в области теории вычислительных машин и систем Чарльз Энтони Ричард Хоар (C. A. R. Hoare)" [1]
Взаимодействующие последовательные процессы (англ. communicating sequential processes, CSP) — формальный язык для описания моделей взаимодействия в параллельных системах[1]. Относится к математическим теориям параллелизма, известных как исчисление процессов (или алгебра процессов), основанных на передаче сообщений по каналам. Оказал влияние на разработку языков Оккам[1][2], Limbo, Go[3].
Теория CSP была впервые описана в статье Энтони Хоара в 1978 году[4]. Первоначальная версия была неудачной, так как не представляла неограниченный индетерминизм. Впоследствии под влиянием идей, заимствованных из модели акторов Карла Хьюитта теория была значительно изменена. В версиях CSP Хоара от 1985 года уже используется неограниченный индетерминизм; с тех пор теория значительно развита[5] и остаётся предметом активных исследований[6].
На практике CSP применялась в качестве инструмента формальной спецификации систем с параллелизмом, таких как, например, транспьютер T9000[7] или безопасной системы электронной коммерции[8].
1. Семён Новиков. Программирование на Golang · Stepik
2. GeeksForGeeks - GoLang
sudo apt install golang-go
Массивы Срезы (слайсы, slices)
Массив - это последовательность элементов одного типа фиксированной длины. Срез — это последовательность элементов одного типа переменной длины.