Galina Iaroshenko iOS-developer, ИТ-переводчица, пишу статьи и гайды. Из-за большого количества команд новичкам бывает сложно освоить Git. В этом руководстве мы расскажем обо всем, что вам нужно знать, чтобы приступить к работе с Git, начиная с создания первого репозитория и заканчивая слиянием веток. Помимо архитектуры Git рассмотрим принципы работы таких команд, как add, checkout, reset, commit, merge, rebase, cherry-pick, pull, push и tag. Данная статья является переводом. Автор: Leandro Proença. Ссылка на оригинал. В этой статье помимо архитектуры Git будут рассмотрены принципы работы таких команд, как add, checkout, reset, commit, merge, rebase, cherry-pick, pull, push и tag. 💡 Обо всем по порядку Вы должны практиковаться параллельно с чтением поста. Давайте сначала создадим новый проект с именем git-101, а затем инициализируем репозиторий git с помощью команды git init: $ mkdir git-101 $ cd git-101 Git CLI предоставляет два типа команд: Plumbing – состоит из низкоуровневых команд, используемых Git за кулисами, когда пользователи вводят высокоуровневые команды. Porcelain – которые являются высокоуровневыми командами, обычно используемыми пользователями Git. В этом руководстве мы увидим, как команды plumbing связаны с командами porcelain, которые мы используем изо дня в день. Больше полезных материалов вы найдете на нашем телеграм-канале «Библиотека программиста» Интересно, перейти к каналу ⚙️ Архитектура Git Внутри проекта, содержащего репозиторий Git, ознакомимся с компонентами Git: $ ls -F1 .git/ HEAD config description hooks/ info/ objects/ refs/ Мы остановимся на основных: .git/objects/ .git/refs HEAD Разберем подробно каждый компонент. 💾 База данных объектов Используя find, инструмент UNIX, мы можем ознакомиться со структурой папки .git/objects: $ find .git/objects .git/objects .git/objects/pack .git/objects/info В Git все хранится в структуре .git/objects, которая представляет собой Git Object Database. Что мы можем сохранить в Git? Все. 🤔 Подождите! Как это возможно? С помощью хэш-функций. 🔵 Спасаемся хэшированием Хэш-функция преобразует данные произвольного динамического размера в значения фиксированного размера. Делая это, мы можем хранить/сохранять что угодно, потому что конечное значение всегда будет иметь один и тот же размер. Плохая реализация хэш-функций может легко привести к коллизиям, когда два разных данных динамического размера могут отображаться в один и тот же окончательный хэш фиксированного размера. SHA-1 – известная реализация хэш-функции, которая в целом безопасна и почти не имеет коллизий. Возьмем, к примеру, хэширование строки my precious: $ echo -e "my precious" | openssl sha1 fa628c8eeaa9527cfb5ac39f43c3760fe4bf8bed Примечание. Если вы работаете в Linux, вы можете использовать команду sha1sum вместо OpenSSL. 🔵 Сравнение различий в содержании Хорошее хэширование – это безопасная практика, когда мы не можем знать необработанное значение, т. е. реверс-инжиниринг. В случае если мы хотим знать, изменилось ли значение, мы просто помещаем значение в хэш-функцию и вуаля – мы можем сравнить разницу: $ echo -e "my precious" | openssl sha1 fa628c8eeaa9527cfb5ac39f43c3760fe4bf8bed $ echo -e "no longer my precious" | openssl sha1 2e71c9ae2ef57194955feeaa99f8543ea4cd9f9f Если хэши разные, то можно считать, что значение изменилось. Можете ли вы найти здесь возможность? Как насчет использования SHA-1 для хранения данных и просто отслеживания всего путем сравнения хэшей? Это именно то, что Git делает внутри 🤯. 🔵 Git и SHA-1 Git использует SHA-1 для генерации хэширования всего и сохраняет его в .git/objectsпапке. Просто так! hash-object, команда plumbing: $ echo "my precious" | git hash-object --stdin 8b73d29acc6ae79354c2b87ab791aecccf51701f Сравним с OpenSSL версией: $ echo -e "my precious" | openssl sha1 fa628c8eeaa9527cfb5ac39f43c3760fe4bf8bed Упс … это совсем другое. Это потому, что Git добавляет определенное слово, за которым следует размер содержимого и разделитель
iOS-developer, ИТ-переводчица, пишу статьи и гайды. Из-за большого количества команд новичкам бывает сложно освоить Git. В этом руководстве мы расскажем обо всем, что вам нужно знать, чтобы приступить к работе с Git, начиная с создания первого репозитория и заканчивая слиянием веток. Помимо архитектуры Git рассмотрим принципы работы таких команд, как add, checkout, reset, commit, merge, rebase, cherry-pick, pull, push и tag. Данная статья является переводом. Автор: Leandro Proença. Ссылка на оригинал. В этой статье помимо архитектуры Git будут рассмотрены принципы работы таких команд, как add, checkout, reset, commit, merge, rebase, cherry-pick, pull, push и tag. 💡 Обо всем по порядку Вы должны практиковаться параллельно с чтением поста. Давайте сначала создадим новый проект с именем git-101, а затем инициализируем репозиторий git с помощью команды git init: $ mkdir git-101 $ cd git-101 Git CLI предоставляет два типа команд: Plumbing – состоит из низкоуровневых команд, используемых Git за кулисами, когда пользователи вводят высокоуровневые команды. Porcelain – которые являются высокоуровневыми командами, обычно используемыми пользователями Git. В этом руководстве мы увидим, как команды plumbing связаны с командами porcelain, которые мы используем изо дня в день. Больше полезных материалов вы найдете на нашем телеграм-канале «Библиотека программиста» Интересно, перейти к каналу ⚙️ Архитектура Git Внутри проекта, содержащего репозиторий Git, ознакомимся с компонентами Git: $ ls -F1 .git/ HEAD config description hooks/ info/ objects/ refs/ Мы остановимся на основных: .git/objects/ .git/refs HEAD Разберем подробно каждый компонент. 💾 База данных объектов Используя find, инструмент UNIX, мы можем ознакомиться со структурой папки .git/objects: $ find .git/objects .git/objects .git/objects/pack .git/objects/info В Git все хранится в структуре .git/objects, которая представляет собой Git Object Database. Что мы можем сохранить в Git? Все. 🤔 Подождите! Как это возможно? С помощью хэш-функций. 🔵 Спасаемся хэшированием Хэш-функция преобразует данные произвольного динамического размера в значения фиксированного размера. Делая это, мы можем хранить/сохранять что угодно, потому что конечное значение всегда будет иметь один и тот же размер. Плохая реализация хэш-функций может легко привести к коллизиям, когда два разных данных динамического размера могут отображаться в один и тот же окончательный хэш фиксированного размера. SHA-1 – известная реализация хэш-функции, которая в целом безопасна и почти не имеет коллизий. Возьмем, к примеру, хэширование строки my precious: $ echo -e "my precious" | openssl sha1 fa628c8eeaa9527cfb5ac39f43c3760fe4bf8bed Примечание. Если вы работаете в Linux, вы можете использовать команду sha1sum вместо OpenSSL. 🔵 Сравнение различий в содержании Хорошее хэширование – это безопасная практика, когда мы не можем знать необработанное значение, т. е. реверс-инжиниринг. В случае если мы хотим знать, изменилось ли значение, мы просто помещаем значение в хэш-функцию и вуаля – мы можем сравнить разницу: $ echo -e "my precious" | openssl sha1 fa628c8eeaa9527cfb5ac39f43c3760fe4bf8bed $ echo -e "no longer my precious" | openssl sha1 2e71c9ae2ef57194955feeaa99f8543ea4cd9f9f Если хэши разные, то можно считать, что значение изменилось. Можете ли вы найти здесь возможность? Как насчет использования SHA-1 для хранения данных и просто отслеживания всего путем сравнения хэшей? Это именно то, что Git делает внутри 🤯. 🔵 Git и SHA-1 Git использует SHA-1 для генерации хэширования всего и сохраняет его в .git/objectsпапке. Просто так! hash-object, команда plumbing: $ echo "my precious" | git hash-object --stdin 8b73d29acc6ae79354c2b87ab791aecccf51701f Сравним с OpenSSL версией: $ echo -e "my precious" | openssl sha1 fa628c8eeaa9527cfb5ac39f43c3760fe4bf8bed Упс … это совсем другое. Это потому, что Git добавляет определенное слово, за которым следует размер содержимого и разделитель
Данная статья является переводом. Автор: Leandro Proença. Ссылка на оригинал.
В этой статье помимо архитектуры Git будут рассмотрены принципы работы таких команд, как add, checkout, reset, commit, merge, rebase, cherry-pick, pull, push и tag.
Вы должны практиковаться параллельно с чтением поста.
Давайте сначала создадим новый проект с именем git-101, а затем инициализируем репозиторий git с помощью команды git init:
git
git init
$ mkdir git-101 $ cd git-101
Git CLI предоставляет два типа команд:
В этом руководстве мы увидим, как команды plumbing связаны с командами porcelain, которые мы используем изо дня в день.
Больше полезных материалов вы найдете на нашем телеграм-канале «Библиотека программиста» Интересно, перейти к каналу
Внутри проекта, содержащего репозиторий Git, ознакомимся с компонентами Git:
$ ls -F1 .git/ HEAD config description hooks/ info/ objects/ refs/
Мы остановимся на основных:
Разберем подробно каждый компонент.
Используя find, инструмент UNIX, мы можем ознакомиться со структурой папки .git/objects:
find
.git/objects
$ find .git/objects .git/objects .git/objects/pack .git/objects/info
В Git все хранится в структуре .git/objects, которая представляет собой Git Object Database.
Что мы можем сохранить в Git? Все.
🤔 Подождите!
Как это возможно?
С помощью хэш-функций.
Хэш-функция преобразует данные произвольного динамического размера в значения фиксированного размера. Делая это, мы можем хранить/сохранять что угодно, потому что конечное значение всегда будет иметь один и тот же размер.
Плохая реализация хэш-функций может легко привести к коллизиям, когда два разных данных динамического размера могут отображаться в один и тот же окончательный хэш фиксированного размера.
SHA-1 – известная реализация хэш-функции, которая в целом безопасна и почти не имеет коллизий.
Возьмем, к примеру, хэширование строки my precious:
my precious
$ echo -e "my precious" | openssl sha1 fa628c8eeaa9527cfb5ac39f43c3760fe4bf8bed
Примечание. Если вы работаете в Linux, вы можете использовать команду sha1sum вместо OpenSSL.
Хорошее хэширование – это безопасная практика, когда мы не можем знать необработанное значение, т. е. реверс-инжиниринг.
В случае если мы хотим знать, изменилось ли значение, мы просто помещаем значение в хэш-функцию и вуаля – мы можем сравнить разницу:
$ echo -e "my precious" | openssl sha1 fa628c8eeaa9527cfb5ac39f43c3760fe4bf8bed $ echo -e "no longer my precious" | openssl sha1 2e71c9ae2ef57194955feeaa99f8543ea4cd9f9f
Если хэши разные, то можно считать, что значение изменилось.
Можете ли вы найти здесь возможность? Как насчет использования SHA-1 для хранения данных и просто отслеживания всего путем сравнения хэшей? Это именно то, что Git делает внутри 🤯.
Git использует SHA-1 для генерации хэширования всего и сохраняет его в .git/objectsпапке. Просто так!
hash-object, команда plumbing:
hash-object
plumbing
$ echo "my precious" | git hash-object --stdin 8b73d29acc6ae79354c2b87ab791aecccf51701f
Сравним с OpenSSL версией:
Упс … это совсем другое. Это потому, что Git добавляет определенное слово, за которым следует размер содержимого и разделитель
Ваш адрес email не будет опубликован. Обязательные поля помечены *
Сохранить моё имя, email и адрес сайта в этом браузере для последующих моих комментариев.
Δ
Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.