Add c что это

Git для начинающих. Часть 8. Добавление, удаление и переименование файлов в репозитории

В рамках данного урока рассмотрим вопросы, касающиеся добавления, удаления и переименования файлов в git репозитории.

• Добавление файлов в git репозиторий
• Удаление файлов из git репозитория и из stage
  • Удаление файла из stage
  • Удаление файлов из git репозитория
    • Первый способ
    • Второй способ
    • Первый способ
    • Второй способ

    Добавление файлов в git репозиторий

    Добавление файлов в репозиторий – это достаточно простая операция, мало чем отличающаяся от отправки изменений в отслеживаемых файлах в репозиторий. Мы уже не раз выполняли эту операцию в предыдущих уроках, но сделаем это ещё раз. Создадим новый репозиторий, для этого перейдите в каталог, в котором вы хотите его расположить и введите команду git init .

    > git init

    Создайте в каталоге файл README.md любым удобным для вас способом, мы сделаем это с помощью команды touch .

    > touch README.md

    Теперь проверим состояние отслеживаемой директории.

    > git status On branch master Initial commit Untracked files: (use "git add . " to include in what will be committed) README.md nothing added to commit but untracked files present (use "git add" to track) 

    Как вы можете видеть: в рабочей директории есть один неотслеживаемый файл README.md . Git нам подсказывает, что нужно сделать для того, чтобы начать отслеживать изменения в файле README.md : необходимо выполнить команду git add , сделаем это.

    > git add README.md

    Посмотрим ещё раз на состояние.

    > git status On branch master Initial commit Changes to be committed: (use "git rm --cached . " to unstage) new file: README.md

    Видно, что информация о появлении нового файла попала в stage . Для того чтобы это изменение зафиксировалось в репозитории необходимо выполнить команду git commit .

    > git commit -m "add README.md file" [master (root-commit) 0bb6c94] add README.md file 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 README.md

    Теперь в рабочей директории и в stage нет объектов, информацию об изменении которых необходимо внести в репозиторий.

    > git status On branch master nothing to commit, working tree clean

    В репозиторий был сделан один коммит.

    > git log --oneline 0bb6c94 add README.md file

    Удаление файлов из git репозитория и из stage

    Удаление файла из stage

    Вначале разберемся со stage . Создадим ещё один файл.

    > touch main.c

    “Отправим” файл main.c в stage .

    > git add main.c

    Внесем изменения в README.md .

    > echo "# README" > README.md

    Информацию об этом также отправим в stage .

    > git add README.md

    Посмотрим на состояние stage .

    > git status On branch master Changes to be committed: (use "git reset HEAD . " to unstage) modified: README.md new file: main.c

    Если нам необходимо убрать из stage , какой-то из этих файлов (main.c или README.md), то для этого можно воспользоваться командой git –rm cashed , сделаем это для файла main.c .

    > git rm --cached main.c rm 'main.c'

    Теперь посмотрим на состояние рабочей директории и stage .

    > git status On branch master Changes to be committed: (use "git reset HEAD . " to unstage) modified: README.md Untracked files: (use "git add . " to include in what will be committed) main.c

    Видно, что изменения в файле README.md готовы для коммита, а вот файл main.c перешел в состояние – неотслеживаемый. Отправим main.c в stage и, после этого, сделаем коммит в репозиторий.

    > git add main.c > git commit -m "add main.c and do some changes in README.md" [master 49049bc] add main.c and do some changes in README.md 2 files changed, 1 insertion(+) create mode 100644 main.c

    Удаление файлов из git репозитория

    Удалить файл из репозитория можно двумя способами: первый – удалить его из рабочей директории и уведомить об этом git ; второй – воспользоваться средствами git . Начнем с первого способа. Для начала посмотрим, какие файлы у нас хранятся в репозитории.

    > git ls-tree master 100644 blob 7e59600739c96546163833214c36459e324bad0a README.md 100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 main.c

    Удалим файл main.c из рабочей директории.

    > rm main.c > ls README.md

    Уведомим об этом систему git .

    > git rm main.c rm 'main.c'

    Вместо команды git rm можно использовать git add , но само слово add в данном случае будет звучать несколько неоднозначно, поэтому лучше использовать rm . На данном этапе еще можно вернуть все назад с помощью команды git checkout — , в результате, в нашу рабочую директорию будет скопирован файл из репозитория. Создадим коммит, фиксирующий удаление файла.

    > git commit -m "remove main.c" [master d4e22ae] remove main.c 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 main.c

    Теперь в репозитории остался только один файл README.md .

    > git ls-tree master 100644 blob 7e59600739c96546163833214c36459e324bad0a README.md

    Второй способ – это сразу использовать команду git rm без предварительного удаления файла из директории. Вновь создадим файл main.c и добавим его в репозиторий.

    > touch main.c > git add main.c > git commit -m "add main.c file" [master 6d93049] add main.c file 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 main.c > git ls-tree master 100644 blob 7e59600739c96546163833214c36459e324bad0a README.md 100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 main.c

    Удалим файл из репозитория.

    > git rm main.c rm 'main.c' > git commit -m "deleted: main.c file" [master ba7d027] deleted: main.c file 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 main.c

    Файла main.c больше нет в репозитории.

    > git ls-tree master 100644 blob 7e59600739c96546163833214c36459e324bad0a README.md

    Его также нет и в рабочем каталоге.

    > ls README.md

    Удалите файл README.md из репозитория самостоятельно.

    Переименование файлов в git репозитории

    Как и в случае с удалением, переименовать файл в git репозитории можно двумя способами – с использованием и без использования средств операционной системы.

    Первый способ. Создадим файл test_main_file.c и добавим его в репозиторий.

    > touch test_main_file.c > git add test_main_file.c > git commit -m "add test_main_file.c" [master 6cf53ac] add test_main_file.c 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 test_main_file.c

    Содержимое репозитория после этого будет выглядеть так.

    > git ls-tree master 100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 test_main_file.c

    Переименуем его на test_main.c .

    Сделаем это в рабочей директории.

    > mv test_main_file.c test_main.c

    Теперь отправим изменение в репозиторий.

    > git add . > git commit -m "Rename test_main_file.c" [master 79528c4] Rename test_main_file.c 1 file changed, 0 insertions(+), 0 deletions(-) rename test_main_file.c => test_main.c (100%)

    В репозитории и в рабочей директории будет находится только файл test_main.c .

    > git ls-tree master 100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 test_main.c > ls test_main.c

    Второй способ.

    В рамках второго способа рассмотрим работу с командой git mv . Переименуем файл test_main.c в main.c . Текущее содержимое репозитория и рабочего каталога.

    > git ls-tree master 100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 test_main.c > ls test_main.c

    Переименуем файл test_main.c на main.c средствами git .

    > git mv test_main.c main.c > git commit -m "Rename test_main.c file" [master c566f0e] Rename test_main.c file 1 file changed, 0 insertions(+), 0 deletions(-) rename test_main.c => main.c (100%)

    Имя файла изменилось как в репозитории так и в рабочем каталоге.

    > git ls-tree master 100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 main.c > ls main.c

    Отличный курс по git делают ребята из GeekBrains , найдите в разделе “Курсы” курс “Git. Быстрый старт” , он бесплатный!

    Раздел: Git Git для начинающих Метки: Git, Git для начинающих, Уроки по Git

    Git для начинающих. Часть 8. Добавление, удаление и переименование файлов в репозитории : 1 комментарий

    1. Игорь 09.12.2021 В целом, очень неплохо написанный начальный курс. Что бросилось в глаза, так это то, что вы вводите такую конструкцию как git rm –cached без объяснений, что это значит и чем отличается от простого git rm. Между тем это достаточно важный и не слишком очевидный момент (cached, staged). Я не искал по всем частям опубликованного вами материала. Возможно, есть и другие подобные места, требующие чуть более основательных пояснений. Я понимаю, что в короткую статью очень сложно втиснуть все нужное, не раздувая ее до объема книги, но тем не менее.

    Создание собственных команд в GIT

    

    1. Что такое alias (знакомство)
    2. Создание alias с выполнением функции
    3. Alias с переменной
    4. Alias для создания удаленного репозитория BitBucket в Git Bash

    1. Что такое alias (знакомство)

    В Git имеется возможность добавления собственных команд, которые значительно расширяют возможности Git-а, как инструмента. Вы можете создавать собственные команды и научить Git выполнять их. А также делать существующие длинные команды Git-а более короткими, что значительно сократить время вашей работы с Git-ом. Я не буду описывать все команды, которые можно создавать в Git, а расскажу только самые полезные и интересные.

    Самые частые команды, которые мы используем – это:

    $ git commit -m «message»

    И каждый раз мы вводим их, чтобы добавить в индекс новые или измененные файлы и зафиксировать эти изменения. Но можно существенно сократить время на ввод этих команд, если создать новую команду, которая будет объединять несколько последовательных команд.

    Новые команды можно создавать с помощью встроенной команды Git-а: alias.

    Давайте создадим нашу первую команду. Введите в Git Bash:

    $ git config —global —add alias.ac ‘!git add -A && git commit -m’

    В этом примере мы создали команду ac, которая объединяет команды Git: add . и commit -m.

    Знак – оповещает, что будет команда оболочки.

    Параметр —global указывает, что изменения вносятся в глобальный конфигурационный файл Git — а (т.е. корневой каталог, куда установлен Git), а не репозитория.

    Параметр —add , как не сложно догадаться, добавляет новый алиас. Если вы хотите удалить алиас, то следует заменить —add на —unset . Если хотите перезаписать алиас, то тогда нужно поставить —replace-all .

    Зайдите в какой-нибудь локальный репозиторий (Git Bash):

    Теперь попробуем выполнить новую команду в Git Bash:

    [master 04851cd] test new alias ac 1 file changed, 1 insertion(+) create mode 100644 11.txt

    Команда отличная, но я привыкла после этих команд выполнять git status, чтобы посмотреть текущий статус репозитория. Поэтому предлагаю еще расширить возможности новой команды.

    Перепишем алиас ac:

    $ git config —global —replace-all alias.ac ‘!git add -A && git commit -m && git status’

    Если выполнить команду ac в таком варианта, то git Bash выдаст ошибку:

    error: pathspec ‘arg’ did not match any file(s) known to git

    Потому что после команды commit -m ожидается комментарий:

    $ git commit -m «какой-то комментарий»

    И комментарий – это динамический параметр, поэтому здесь нужна переменная, в которую мы будем передавать свое значение. Правильное добавление алиаса будет таким:

    $ git config —global —replace-all alias.ac ‘!git add -A && git commit -m «$1» && git status’

    Теперь выполним команду ac в Git Bash:

    $ git ac «test arg»

    [master 7949a4d] test arg 1 file changed, 1 insertion(+), 1 deletion(-) On branch master Your branch is ahead of 'origin/master' by 2 commits. (use "git push" to publish your local commits) nothing to commit, working tree clean

    Все работает верно! Наш комментарий «test arg» передался в переменную $1 и выполнил последовательно команды Git-а.

    Ну вот теперь, когда мы познакомились с alias, можно попробовать что-то посложнее.

    2. Создание alias с выполнением функции

    Создадим функцию с bash-командами и обернем ее командой Git-а. Т.е. при выполнении команды Git-а, выполнится функция с bash командами. Создайте в директории с установленным Git-ом файл ~\Git\etc\.my_functions и пропишите там функцию fn:

    Затем откройте git bash и командой добавьте alias, который назовем echofn:

    $ git config —global —add alias.echofn $’!bash -c \’source /etc/.my_functions && fn\»

    Алиас echofn будет запускать bash, а bash -с, в свою очередь, выполнит строку в одинарных кавычках. В строке команда source прочитает файл .my_functions и выполнит функцию fn. Обратите внимание, что внутренние одинарные кавычки должны быть экранированы (\’), т.к. они находятся внутри одинарных кавычек. Впереди с описанием команды необходимо поставить знак $, чтобы правильно передать всю строку с bash командами и не возникало ошибки: bash: syntax error near unexpected token `>’

    Теперь, если выполним нашу новую команду в Git Bash:

    , то получим результат:

    3. Alias с переменной

    Есть еще способ создания алиаса. Можно команды-алиасы прописывать прямо в файлах Git-а. Пропишите в файле ~\Git\etc\gitconfig строки:

    [alias] hw = "!f()< echo \"Hello World!!\"; echo \"My name is $1. And I'm developer\"; >;f "

    Затем запустите новую команду в Git Bash:

    Hello World!! My name is Olga. And I'm developer

    Чтобы посмотреть все наши созданные алиасы, выполните команду в Git Bash, чтобы прочитать строки с помощью регулярного выражения, начинающиеся со слова «alias» из конфигурационных настроек Git-а:

    $ git config —get-regexp ‘^alias\.’

    А еще лучше создайте новую команду Git-a. Выполните команду в Git Bash:

    $ git config —global alias.aliases «config —get-regexp ‘^alias\.'»

    (а затем выполните созданную команду в Git Bash):

    Результат покажет все ваши алиасы:

    alias.hw !f()< echo "Hello World!!"; echo "My name is $1. And I'm developer"; >;f alias.echofn !bash -c 'source /etc/.my_functions && fn' alias.ac !git add -A && git commit -m "$1" && git status alias.aliases config --get-regexp '^alias\.'

    4. Alias для создания удаленного репозитория BitBucket в Git Bash

    Самое полезное я оставила на конец. Если вы используете в качестве удаленного репозитория BitBucket, то наверняка сталкивались с такой проблемой – как создать новый репозиторий из консоли. Например: вы создали новый репозиторий на локальной машине, делали в нем изменения файлов. И вот когда закончили и решили запушить это на BitBucket, то вам выдается ошибка, что на BB репозитория нет и его надо сначала создать. Вы идете на сайт BitBucket-а, создаете там пустой репозиторий, потом из консоли Git Bash делаете связку с удаленным репозиторием. Не слишком изящно, да? Если у вас нет возможности установить дополнительные инструменты, то тут как раз подойдет создание новой команды.

    На площадке BitBucket есть API, который позволяет исполнять команды для различных действий. Документацию по API команд вы можете посмотреть тут.

    Цепочка команд формируется в виде форматированного контента в формате JSON. А далее необходимо этот форматированный контент послать на ресурс API BitBucket. Послать можно с помощью библиотеки CURL, которая поставляется вместе с пакетом Git Bash.

    Пропишите в файле ~\Git\etc\.my_functions строки:

    new_repo() < curl -X POST -u ":" -H "Content-Type: application/json" \ https://api.bitbucket.org/2.0/repositories/iammultic/"$namerep" \ -d '< "scm": "git", "is_private": true, "project": >' >

    Итак, мы создали функцию new_repo, которая будет создавать с помощью Curl и API BitBucket 2.0.

    удаленный репозиторий. Вместо – вы прописываете свой логин, зарегистрированный в BitBucket; вместо – прописываете APP пароль, который можно сгенерировать в BitBucket-е нажав на свой профиль-> Personal settings-> App Paswords-> Create app password. Откроется диалоговое окно:

    

    Затем выбираете необходимые параметры и жмете Create.

    Далее вы увидите пароль – строку:

    

    Запишите свой пароль. Этот пароль вы можете использовать для аутентификации в различных приложениях. Например: графических редакторах версионного контроля и т.д.

    Вернемся к нашей функции new_repo… Обратите внимание на строку перед функцией namerep= «$1». «$1» – это параметр, который будет передаваться из Git, а namerep – это глобальная bash переменная, которая потом будет использована внутри функции. Эта переменная будет принимать наименование нашего нового репозитория.

    Теперь, в файле ~\Git\etc\gitconfig пропишите строки и сохранитесь:

    [alias] cr = "! bash -c 'source /etc/.my_functions && new_repo ' $1"

    Далее, выполните новую команду в Git Bash:

    $ git cr repo1

    Если вы посмотрите в своем аккаунте список репозиторий в BB, то увидите там новый репозиторий repo1

    

    Удаленный репозиторий мы создали, но нам надо также его создать на локальной машине и связать его с удаленным. Здесь можно выбрать — каким способом вы хотите сделать связь между удаленным и локальным репозиторием. Можно сделать клон:

    $ cd c:/workplace $ clone git@bitbucket.org:iammultic/repo1.git

    , либо создать такую директорию в вашей рабочей области на локальной машине и связать репозитории:

    $ cd c:/workplace $ mkdir repo1 $ cd c:/workplace/repo1 $ git remote add origin git@bitbucket.org:iammultic/repo1.git

    Я выбираю первый вариант.

    Добавьте пару строк в ранее созданную функцию (~\Git\etc\.my_functions):

    new_repo() < curl -X POST -u "iammultic:********************" -H "Content-Type: application/json" \ https://api.bitbucket.org/2.0/repositories/iammultic/$namerep \ -d '< "scm": "git", "is_private": true, "project": >' ; cd /c/workspace ; git clone git@bitbucket.org:iammultic/$namerep.git >

    Выполните в Git Bash команду:

    $ git cr repo2

    Проверьте создание нового репозитория в Bitbucket и создание локального репозитория в вашей рабочей директории на локальной машине.

    Все примеры работающие, проверенные – можно использовать в работе с Git и BitBucket. И вы можете создать больше полезных для себя alias-ов и применять их, чтобы не тратить много времени на ведение и контроль версии файлов.

    Add c что это

    Вы новичок с git? Выполните несколько следующих шагов, чтобы комфортно делать изменения в кодовой базе, открывать pull request (PR) и сливать текущий код с главной веткой проекта (merge). Важные термины git и GitHub выделены синим текстом, и предоставляются ссылки на официальную документацию по git.

    Примечание: здесь приведен вольный перевод статьи [1].

    [Шаг 0: Установка git, создание учетной записи на GitHub]

    Установка git и получение учетной записи GitHub бесплатны. Обратите внимание, что в этом руководстве мы будем использовать git только в командной строке. Однако существует несколько хороших утилит для git, имеющих графический интерфейс. Автор считает, что командная строка упростит обучение специфических командам git, после чего можно будет попробовать и GUI-интерфейс для git.

    После того, как git скачан и установлен, создайте себе учетную запись GitHub [2].

    Стоить заметить, что GitHub не тоже самое, что git. Git это система управления версиями с открытым исходным кодом, созданная разработчиками в 2005 году, работающими на Linux. GitHub это компания, основанная в 2008 году, которая создала публичный ресурс для хранения репозиториев, интегрированный с инструментами git. GitHub не нужен для использования git, однако обратное неверно — GitHub нельзя использовать без git. Существует много других альтернатив GitHub, таких как GitLab, BitBucket, и решения на основе Вашего собственного хоста, такие как gogs и gittea. Все они именуются в терминологии git как удаленные (сетевые) хранилища (remotes), и совершенно не обязательно их использовать. Вам не нужен удаленный сервер, чтобы использовать git, однако удаленный сервер упростит совместное использование Вашего кода другими программистами.

    [Шаг 1: Создание локального репозитория git]

    Основной принцип использования git — один репозиторий на один проект. Хотя в целом это не обязательно — просто общепринятая практика, точно такая же как одна папка под один проект. Когда создается новый проект на локальной машине, создайте для него новый репозиторий (repository, часто для краткости репозиторий называют ‘repo’).

    Для git мы будем использовать строку терминала. Если Вы пользователь Linux, но плохо ориентируетесь в базовых командах этой операционной системы, изучите ресурс [4].

    Если Вы пользователь Windows, и установили пакет инструментария git, то в контекстном меню Проводника появятся две ссылки для запуска утилит git: Git GUI here и Git Bash Here. Контекстное меню с этим ссылками открывается, если кликнуть правой кнопкой мыши на папке проекта. Если запустить Git Bash Here, то сразу запустится консоль командной строки с текущим каталогом проекта.

    

    Чтобы начать, откройте окно терминала и поменяйте текущий каталог на тот, где находится Ваш проект. И на Linux, и на Windows это делается командой cd (change directory). Например, у Вас на диске есть каталог projects, и нужно создать новый проект в новом каталоге myproject. Для этого команды в консоли Linux могут быть примерно такие:

    $ cd ~/Desktop $ mkdir myproject $ cd myproject/ 

    После этих команд текущим каталогом будет myproject, это будет папка проекта.

    Для случая, когда папка проекта STM32F407-Blink уже существует на диске, в консоли команд Windiows:

    C:\Users\andrey>cd m:\work\STM32F407-Blink C:\Users\andrey>m: m:\work\STM32F407-Blink> 

    Чтобы создать репозиторий проекта в папке myproject, запустите команду git init:

    $ git init Initialized empty Git repository in /Users/пользователь/Desktop/myproject/.git/ 

    [Шаг 2: добавление нового файла в репозиторий]

    Пойдем дальше, и создадим новый файл для проекта с помощью любого текстового редактора, либо (под Linux) командой touch. Команда touch newfile.txt просто создаст пустой файл с именем newfile.txt.

    $ touch main.c $ ls main.c 

    Когда Вы добавили, или изменили файлы в папке, где находится git repo, то при запуске git заметит, что внутри repo существует этот файл. Однако git не будет отслеживать изменения в добавленном файле (файлах), если ему это не указать явным образом. Git сохраняет/обслуживает изменения только в тех файлах, на которых у него настроен трекинг, поэтому нам нужна специальная команда для git, если мы хотим, чтобы он отслеживал наш новый файл.

    После создания нового файла можно использовать команду git status чтобы увидеть, о каких файлах git знает, что они существуют. Пример вывода команды git status в только что созданном репозитории, в котором пока не настроен трекинг файлов проекта:

    m:\work\STM32F407-Blink>git status On branch master 

    No commits yet 

    Untracked files: (use "git add < file >. " to include in what will be committed) 

     .gitignore .mxproject Drivers/ EWARM/ Inc/ STM32F407-Blink.ioc Src/ backup.bat clean.bat readme.txt util/ 

    nothing added to commit but untracked files present (use "git add" to track) 

    m:\work\STM32F407-Blink> 

    Этим выводом git нам сообщает: «вижу, что в каталоге репозитория создано несколько новых файлов и каталогов, но пока не введете команду ‘git add’, я ничего с этими файлами делать не буду». Список этих файлов выделен красным цветом , который показывает, что за этими файлами git должен следить, но пока они не добавлены в базу git и не отслеживаются.

    Одна из самых запутанных вещей, когда Dы впервые изучаете git, является концепция staging environment, и как это связано с фиксацией проекта в репозитории (commit).

    Фиксация (commit) это запись в базу данных репозитория новых изменений, которые были сделаны в файлах проекта с момента последней фиксации (далее вместо «фиксации» буду использовать термин commit). В сущности Вы делаете изменения в своем repo (например, добавление файла или модификация файла) и затем говорите операцией commit для git, чтобы он внес эти изменения в commit.

    Commit-ы составляют историю изменений проекта, и позволяют перейти к любой стадии проекта (откатить проект), для которой ранее был сделан commit.

    Как указать git, какие файлы надо поместить в commit? Здесь мы сталкиваемся с термином staging environment, или индексом. Как было видно на шаге 2, когда мы сделали изменения в своем repo, git сказал, что файл (файлы) был изменен, но с ним никаких операций не проводилось (наподобие операций, которые делаются над файлами, добавленными в commit).

    Чтобы добавить файл в commit, необходимо сначала добавить его в staging environment (проиндексировать). Чтобы это сделать, мы будем использовать команду git add < имяфайла >(см. шаг 3 далее).

    Как только была выполнена команда git add для файла (файлов), которые необходимо добавить в staging environment репозитория, можно теперь сказать git, чтобы он упаковал этот файл (файлы) в commit с помощью команды git commit.

    Замечание: staging environment иногда называют ‘staging’, это более новый, предпочтительный термин для организации хранилища репозитория, но в будущем Вы заметите, что staging называют также индексом.

    [Шаг 3: добавление файла в staging environment]

    Добавление файла в staging environment делает команда git add. Если после неё вы вернетесь к команде git status, то увидите, что git добавил этот файл в staging environment (будет выведена строка «Changes to be committed»).

    Пример команды git add (маска * вместо имени файлов говорит о том, что нужно добавить сразу несколько файлов и папок):

    d:\asm\STM32F407-Blink>git add * 

    d:\asm\STM32F407-Blink> 

    Если добавляемых файлов и папок много, то для создания базы данных git задумается на несколько секунд. Пример вывода команды git status после добавления файлов в базу (список файлов большой, поэтому он сокращен многоточиями . ):

    m:\work\STM32F407-Blink>git status On branch master 

    No commits yet 

    Changes to be committed: (use "git rm --cached . " to unstage) 

     new file: .gitignore new file: .mxproject new file: Drivers/CMSIS/Core/Include/cmsis_armcc.h new file: Drivers/CMSIS/Core/Include/cmsis_armclang.h new file: Drivers/CMSIS/Core/Include/cmsis_compiler.h new file: Drivers/CMSIS/Core/Include/cmsis_gcc.h new file: Drivers/CMSIS/Core/Include/cmsis_iccarm.h . new file: Drivers/STM32F4xx_HAL_Driver/Inc/Legacy/stm32_hal_legacy.h new file: Drivers/STM32F4xx_HAL_Driver/Inc/Legacy/stm32f4xx_hal_can_legacy.h new file: Drivers/STM32F4xx_HAL_Driver/Inc/stm32_assert_template.h new file: Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal.h new file: Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal_adc.h new file: Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal_adc_ex.h new file: Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal_can.h . new file: EWARM/Project.eww new file: EWARM/STM32F407-Blink.dep new file: EWARM/STM32F407-Blink.ewd new file: EWARM/STM32F407-Blink.ewp new file: EWARM/STM32F407-Blink.ewt new file: EWARM/settings/Project.wsdt new file: EWARM/settings/STM32F407-Blink.Release.cspy.bat new file: EWARM/settings/STM32F407-Blink.Release.cspy.ps1 new file: EWARM/settings/STM32F407-Blink.Release.driver.xcl new file: EWARM/settings/STM32F407-Blink.Release.general.xcl new file: EWARM/settings/STM32F407-Blink.STM32F407-Blink.cspy.bat new file: EWARM/settings/STM32F407-Blink.STM32F407-Blink.cspy.ps1 new file: EWARM/settings/STM32F407-Blink.STM32F407-Blink.driver.xcl new file: EWARM/settings/STM32F407-Blink.STM32F407-Blink.general.xcl new file: EWARM/settings/STM32F407-Blink.crun new file: EWARM/settings/STM32F407-Blink.dbgdt new file: EWARM/settings/STM32F407-Blink.dnx new file: EWARM/startup_stm32f407xx.s new file: EWARM/stm32f407xx_flash.icf new file: EWARM/stm32f407xx_flash_for_bootloader.icf new file: EWARM/stm32f407xx_sram.icf new file: Inc/main.h new file: Inc/pins.h new file: Inc/stm32f4xx_hal_conf.h new file: Inc/stm32f4xx_it.h new file: STM32F407-Blink.ioc new file: Src/main.c new file: Src/stm32f4xx_hal_msp.c new file: Src/stm32f4xx_it.c new file: Src/system_stm32f4xx.c new file: backup.bat new file: clean.bat new file: readme.txt new file: util/append-STM32-hardware-CRC/.gitignore new file: util/append-STM32-hardware-CRC/LICENSE.md new file: util/append-STM32-hardware-CRC/README.md new file: util/append-STM32-hardware-CRC/src/crc32.sln new file: util/append-STM32-hardware-CRC/src/crc32/Program.cs new file: util/append-STM32-hardware-CRC/src/crc32/Properties/AssemblyInfo.cs new file: util/append-STM32-hardware-CRC/src/crc32/Vurdalakov/AssemblyInfo.cs new file: util/append-STM32-hardware-CRC/src/crc32/Vurdalakov/CRC32.cs new file: util/append-STM32-hardware-CRC/src/crc32/Vurdalakov/CRC32Managed.cs new file: util/append-STM32-hardware-CRC/src/crc32/Vurdalakov/CommandLineOption.cs new file: util/append-STM32-hardware-CRC/src/crc32/Vurdalakov/CommandLineOptions.cs new file: util/append-STM32-hardware-CRC/src/crc32/Vurdalakov/CommandLineParser.cs new file: util/append-STM32-hardware-CRC/src/crc32/app.config new file: util/append-STM32-hardware-CRC/src/crc32/crc.c new file: util/append-STM32-hardware-CRC/src/crc32/crc32.csproj 

    m:\work\STM32F407-Blink> 

    Git был разработан для отслеживания изменений только в программном коде, оформленном как простой текст. Однако в каталоге проекта может быть и много других файлов, которые генерируются в процессе компиляции (*.obj, *.a, *.bin, *.hex, *.lst, *.map и другие подобные). Эти файлы по сути временные, не несут в себе никакой смысловой нагрузки, и программистом не просматриваются и не редактируются. Существуют и другие файлы, которые нет смысла добавлять в базу git — например файлы документации (*.pdf, *.html, *.chm), картинки (*.bmp, *.jpg, *.png).

    Перечисленные файлы не являются текстовыми, просмотр их в сыром виде, как текста, никакой пользы не дает. Но если не настроить их исключение из базы git, то в будущем при активной работе с проектом это создаст большую проблему — база данных git будет нести много бесполезной нагрузки и сильно разрастаться в объеме.

    Для борьбы с этой проблемой был специально создан файл .gitignore, который позволяет создать список файлов и папок, которые не должны отслеживаться git. Вот пример такого файла:

    *.o *.obj *.a *.d bin/* deleted/* doc/* EWARM/Debug/* EWARM/Release/* util/append-STM32-hardware-CRC/obj/* util/append-STM32-hardware-CRC/bin/*

    Обратите внимание, что здесь используется прямой слеш /, а не обратный, как обычно принято указывать в путях Windows.

    Существует команда git add -n *, которая позволяет не добавить, а предварительно посмотреть список файлов, которые добавит команда git add *. Это очень полезно для отладки файлов .gitignore.

    [Шаг 4: создание commit]

    Настало время сделать Ваш первый commit!

    Запустите команду git commit -m «Тут вставьте комментарий к commit-у»:

    m:\work\STM32F407-Blink>git commit -m "210607 first commit" [master (root-commit) f5663fa] 210607 first commit 1035 files changed, 888505 insertions(+) create mode 100644 .gitignore create mode 100644 .mxproject create mode 100644 Drivers/CMSIS/Core/Include/cmsis_armcc.h create mode 100644 Drivers/CMSIS/Core/Include/cmsis_armclang.h create mode 100644 Drivers/CMSIS/Core/Include/cmsis_compiler.h create mode 100644 Drivers/CMSIS/Core/Include/cmsis_gcc.h create mode 100644 Drivers/CMSIS/Core/Include/cmsis_iccarm.h . create mode 100644 Drivers/STM32F4xx_HAL_Driver/Inc/Legacy/stm32_hal_legacy.h create mode 100644 Drivers/STM32F4xx_HAL_Driver/Inc/Legacy/stm32f4xx_hal_can_legacy.h create mode 100644 Drivers/STM32F4xx_HAL_Driver/Inc/stm32_assert_template.h create mode 100644 Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal.h create mode 100644 Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal_adc.h create mode 100644 Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal_adc_ex.h create mode 100644 Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal_can.h . create mode 100644 EWARM/Project.eww create mode 100644 EWARM/STM32F407-Blink.dep create mode 100644 EWARM/STM32F407-Blink.ewd create mode 100644 EWARM/STM32F407-Blink.ewp create mode 100644 EWARM/STM32F407-Blink.ewt create mode 100644 EWARM/settings/Project.wsdt create mode 100644 EWARM/settings/STM32F407-Blink.Release.cspy.bat create mode 100644 EWARM/settings/STM32F407-Blink.Release.cspy.ps1 create mode 100644 EWARM/settings/STM32F407-Blink.Release.driver.xcl create mode 100644 EWARM/settings/STM32F407-Blink.Release.general.xcl create mode 100644 EWARM/settings/STM32F407-Blink.STM32F407-Blink.cspy.bat create mode 100644 EWARM/settings/STM32F407-Blink.STM32F407-Blink.cspy.ps1 create mode 100644 EWARM/settings/STM32F407-Blink.STM32F407-Blink.driver.xcl create mode 100644 EWARM/settings/STM32F407-Blink.STM32F407-Blink.general.xcl create mode 100644 EWARM/settings/STM32F407-Blink.crun create mode 100644 EWARM/settings/STM32F407-Blink.dbgdt create mode 100644 EWARM/settings/STM32F407-Blink.dnx create mode 100644 EWARM/startup_stm32f407xx.s create mode 100644 EWARM/stm32f407xx_flash.icf create mode 100644 EWARM/stm32f407xx_flash_for_bootloader.icf create mode 100644 EWARM/stm32f407xx_sram.icf create mode 100644 Inc/main.h create mode 100644 Inc/pins.h create mode 100644 Inc/stm32f4xx_hal_conf.h create mode 100644 Inc/stm32f4xx_it.h create mode 100644 STM32F407-Blink.ioc create mode 100644 Src/main.c create mode 100644 Src/stm32f4xx_hal_msp.c create mode 100644 Src/stm32f4xx_it.c create mode 100644 Src/system_stm32f4xx.c create mode 100644 backup.bat create mode 100644 clean.bat create mode 100644 readme.txt create mode 100644 util/append-STM32-hardware-CRC/.gitignore create mode 100644 util/append-STM32-hardware-CRC/LICENSE.md create mode 100644 util/append-STM32-hardware-CRC/README.md create mode 100644 util/append-STM32-hardware-CRC/src/crc32.sln create mode 100644 util/append-STM32-hardware-CRC/src/crc32/Program.cs create mode 100644 util/append-STM32-hardware-CRC/src/crc32/Properties/AssemblyInfo.cs create mode 100644 util/append-STM32-hardware-CRC/src/crc32/Vurdalakov/AssemblyInfo.cs create mode 100644 util/append-STM32-hardware-CRC/src/crc32/Vurdalakov/CRC32.cs create mode 100644 util/append-STM32-hardware-CRC/src/crc32/Vurdalakov/CRC32Managed.cs create mode 100644 util/append-STM32-hardware-CRC/src/crc32/Vurdalakov/CommandLineOption.cs create mode 100644 util/append-STM32-hardware-CRC/src/crc32/Vurdalakov/CommandLineOptions.cs create mode 100644 util/append-STM32-hardware-CRC/src/crc32/Vurdalakov/CommandLineParser.cs create mode 100644 util/append-STM32-hardware-CRC/src/crc32/app.config create mode 100644 util/append-STM32-hardware-CRC/src/crc32/crc.c create mode 100644 util/append-STM32-hardware-CRC/src/crc32/crc32.csproj 

    m:\work\STM32F407-Blink> 

    Выведенный список файлов покажет, что в этом commit содержится. В комментарии, указанном опцией -m, обычно кратко указывают, что было сделано в этом commit. Это могут быть как новые функции (файлы модулей), добавленные в проект, или исправления ошибок, или может быть просто исправление опечатки. Не стоит в комментарии к commit писать что-то на подобие «asdfadsf» или «foobar». Это введет в депрессию других людей, просматривающих репозиторий, да и Вас тоже, когда через пару месяцев никто уже и не вспомнит, какие изменения и зачем были в этот момент сделаны. Коммиты навсегда останутся в репозитории (технически их все-таки удалить можно, если очень хочется, но это пожалуй грязный трюк), и если для commit плохо составлен комментарий, то в будущем он станет фактически бесполезным.

    Примечание переводчика: люблю начинать комментарий к commit шестью цифрами, обозначающими год, месяц, день, например вот так (2021 год, июнь, 4 число): git commit -m «210604 first commit». Не делайте текст комментария на русском языке, потому что это может привести к проблеме кодировки текста (кракозябрам) на некоторых платформах.

    [Шаг 5: создание новой ветки (branch)]

    Теперь, когда Вы создали новый commit, давайте попробуем сделать что-то более продвинутое.

    Может произойти так, что Вы хотите добавить в проект новую функцию, но беспокоитесь о внесении изменений в проект при разработке этой функции. Для такой ситуации в git предусмотрена такая вещь, как ветка (branch).

    Ветки позволяют вам перемещаться назад и вперед между состояниями проекта. Официальная документация git описывает branch-и так: ‘A branch in Git is simply a lightweight movable pointer to one of these commits.’ («Ветвь в Git это просто облегченный, перемещаемый указатель на один из существующих commit-ов»). Например, если Вы хотите добавить новую страничку на свой сайт, то можете создать новую ветку только для этой страницы, без какого-либо влияния на основную часть проекта. Как только Вы закончите разработку этой странички и убедились, что все сделали правильно, можно будет влить внесенные изменения в основную ветку проекта (primary branch, операция слияния называется merge). Когда Вы создаете новую ветку, Git сохранит трек commit-ов, то которых эта ветка ушла, так что он знает всю историю за этими файлами.

    Допустим, что Вы находитесь на основной ветви проекта, и хотите создать новую ветку, чтобы разработать новую веб-страничку. Для этого выполните команду git checkout -b . Эта команда автоматически создаст новую branch, и перейдет на неё от primary branch.

    После выполнения этой команды Вы можете использовать команду git branch, чтобы убедиться, что ветка была создана:

    $ git branch master * my-new-branch 

    Звездочка слева от имени ветки показывает, на какой ветви Вы находитесь в настоящий момент.

    По умолчанию каждый репозиторий git содержит первую ветку с именем master (и она обычно используется как primary branch, главная ветка в проекте). В рамках мировой тенденции по толерантности и борьбы с расизмом некоторые группы разработчиков начинают использовать альтернативные имена для ветки по умолчанию (например, в этом руководстве мы используем для главной ветки «primary», primary branch). В другой документации и других обсуждениях Вы можете по прежнему увидеть «master» или другие термины для обозначения главной ветки. Независимо от имени просто имейте в виду, что у каждого репозитория есть главная ветка, которую можно рассматривать как официальную (проверенную) версию репозитория. Если это вебсайт, то главная ветка это так версия сайта, которую пользователи видят в онлайне. «Главность» ветки не нужна (git не рассматривает какие-либо ветки иначе, чем другие ветки), но по традиции git в проекте используется именно так.

    Если Вы интересуетесь решениями по использованию разных имен для веток, то на GitHub есть соответствующий материал по переименованию главной ветви, см. [5].

    Если сейчас Вы переключитесь обратно на primary branch, и сделаете некоторые дополнительные commit-ы, то новая ветка не увидит эти новые изменения, пока эти изменения не будут влиты (merge) в новую ветку.

    [Шаг 6: Создание нового репозитория на GitHub]

    Если Вы хотите следить за своим кодом (управлять версиями проекта) только локально, но GitHub (или другие онлайн-хранилища репозиториев) использовать совершенно не обязательно. Однако если Вы хотите работать в команде разработчиков, то можете использовать GitHub для совместной работы (изменениями кода) в одном проекте.

    Чтобы создать новый repo на GitHub, залогиньтесь на сайте github.com и перейдите на домашнюю страницу. Там можно найти опцию «New repository» (новый репозиторий) под знаком «+» рядом с картинкой Вашего профиля, в верхнем правом углу панели навигации:

    

    После клика на эту кнопку GitHub запросит у Вас имя для repo и для его краткого описания:

    

    После заполнения информации на этой страничке кликните на кнопку Create repository для создания нового repo.

    GitHub спросит, хотите ли Вы создать совершенно новый repo с нуля, или хотите добвавить repo, который создан у Вас локально. Для последнего случая, когда мы уже создали локально новый repo, и хотим поместить его на GitHub следуйте указаниям ‘. or push an existing repository from the command line’:

    m:\work\STM32F407-Blink>git remote add origin https://github.com/microsindotnet/STM32F407-Blink.git 

    m:\work\STM32F407-Blink>git branch -M main 

    m:\work\STM32F407-Blink>git push -u origin main Logon failed, use ctrl+c to cancel basic credential prompt. Username for 'https://github.com': microsindotnet Password for 'https://microsindotnet@github.com': Enumerating objects: 1123, done. Counting objects: 100% (1123/1123), done. Delta compression using up to 2 threads Compressing objects: 100% (1092/1092), done. Writing objects: 100% (1123/1123), 12.04 MiB | 1.70 MiB/s, done. Total 1123 (delta 450), reused 0 (delta 0) remote: Resolving deltas: 100% (450/450), done. To https://github.com/microsindotnet/STM32F407-Blink.git * [new branch] main -> main Branch 'main' set up to track remote branch 'main' from 'origin'. 

    m:\work\STM32F407-Blink> 

    Примечание: нужно будет поменять URL в первой команде так, чтобы URL соответствовал Вашему имени пользователя и имени репозитория. На страничке GitHub будет соответствующая подсказка, откуда можно напрямую копировать и вставлять команды git remote add, git branch и git push.

    [Шаг 7: Проталкивание (push) ветки на GitHub]

    Теперь мы сделаем push для commit нашей новой ветки в наш новый репозиторий на GitHub. Это даст возможность другим людям увидеть изменения, которые Вы сделали. Если изменения были одобрены владельцем репозитория, то они могут быть объединены с основной веткой репозитория (merged into primary branch).

    Чтобы сделать push изменений в новую ветку на GitHub, нужно выполнить команду git push origin имявашейветки. GitHub автоматически создаст эту ветку в своем сетевом репозитории:

    $ git push origin my-new-branch 

    Counting objects: 3, done. Delta compression using up to 8 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 313 bytes | 0 bytes/s, done. Total 3 (delta 0), reused 0 (delta 0) To https://github.com/microsindotnet/STM32F407-Blink.git * [new branch] my-new-branch -> my-new-branch 

    Примечание: если Вы используете GitHub локально впервые, то эта команда может предложить ввести имя пользователя и пароль GitHub.

    Возможно, Вам будет непонятно, что в этой команде означает слово «origin». Когда Вы клонируете удаленный репозиторий на своем локальном компьютере, git создает для Вас псевдоним. Почти во всех случаях этот псевдоним называется «origin». По существу это слово является кратким обозначением URL удаленного репозитория. Итак, чтобы выгрузить (push) Ваши изменения в удаленный репозиторий, то существует 2 варианта команды: git push git@github.com:git/git.git имявашейветки или git push origin имявашейветки.

    Если Вы обновите страницу GitHub, то увидите, что указанная ветка была помещена в репозиторий. Также можно кликнуть на ссылку ‘branches’, чтобы увидеть свою ветку.

    Теперь мы будем делать pull request.

    [Шаг 8: Создание pull request (PR)]

    Запрос на извлечение (pull request, или PR) это способ оповещения владельцев репозитория, что Вы хотите сделать некие изменения в своем коде. Это позволит владельцам repo просмотреть Ваш код и убедиться, что он достаточно хорош, чтобы поместить эти изменения в primary branch.

    Вот так выглядит страница PR перед отправкой запроса:

    И вот так это выглядит, когда запрос PR был отправлен:

    Вы можете увидеть большую зеленую кнопку внизу ‘Merge pull request’. Клик на ней означает, что Вы вольете свои изменения в primary branch.

    Иногда Вы будете совладельцем, или единственным владельцем репозитория, и в этом случает может не понадобиться создавать PR, чтобы влить Ваши измнения. Однако все-таки хорошей идеей будет сделать PR, чтобы можно было сохранить более полную историю Ваших обновлений и убедиться, что всегда создается новая ветка при внесении изменений.

    [Шаг 9: Merge PR]

    Пойдем дальше и кликнем на кнопку ‘Merge pull request’. Это сольет ваши изменения с главной веткой проекта.

    Когда это было сделано, лучше всего удалить Вашу ветку (слишком большое количество веток загрязняют репозиторий), для этого кликните на кнопку ‘Delete branch’.

    Вы можете дополнительно проверить, что Ваши commit-ы были влиты путем клика на ссылку ‘Commits’ на первой страничке репозитория.

    Появится список всех commit-ов в этой ветке.

    Здесь также справа можно увидеть хеш-код для commit. Хеш-код это уникальный идентификатор для определенного commit. Он полезен для обращения к определенным commit-ам, и когда делается откат изменений. Для отката используйте команду git revert < хешкод >.

    [Шаг 10: как закачать изменения в репозитории GitHub на свой компьютер]

    Сейчас repo на GitHub выглядит несколько иначе, чем локальный repo на компьютере. Например commit, который Вы сделали в своей ветке и слили его с главной веткой, не существует в главной ветке репозитория на локальной машине.

    Чтобы получить самые последние изменения, которые Вы сделали в удаленном репозитории, или те изменения, которые сделал кто-то другой, используйте команду git pull origin master (когда работаете с primary branch). В большинстве случаев эту команду можно сократить до git pull.

    $ git pull origin master 

    remote: Counting objects: 1, done. remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (1/1), done. From https://github.com/microsindotnet/STM32F407-Blink * branch master -> FETCH_HEAD b345d9a..5381b7c master -> origin/master Merge made by the 'recursive' strategy. mnelson.txt | 1 + 1 file changed, 1 insertion(+) 

    Это покажет Вам все файлы, которые изменены, и как они были изменены. Теперь мы можем использовать команду git log, чтобы посмотреть все новые commit-ы.

    Примечание: может понадобиться переключиться обратно на главную ветку(primary branch). Это делается командой git checkout master.

    [Ссылки]

    1. An Intro to Git and GitHub for Beginners (Tutorial) site:hubspot.com.
    2. Join GitHub Create your account site:github.com.
    3. Краткий справочник по Git.
    4. The Linux command line for beginners site:ubuntu.com.
    5. Renaming the default branch from master site:github.com.

    Git. Урок 2. Внутренняя реализация.
    Индексация. Коммиты.
    Команды: init, config, status, add, commit.

    Узнаем, как работает Git, и чем репозиторий отличается от обычной папки. Научимся индексировать изменения и создавать коммиты.

    

    Урок: 2
    Команды: init, config, status, add, commit
    В КОНЦЕ УРОКА ЕСТЬ ВИДЕО
    Предыдущий урок
    Урок 1
    Git. Введение. Установка и настройка.
    Следующий урок

    Урок 3. Git. Ветвление. Создание, переключение, удаление веток. Команды: branch, checkout, status, log, diff.

    Оглавление
    Теоретический блок

    1. Основные понятия
    2. Настройки пользователя Git
    3. Создание репозитория. Команда git init.
    4. Состояния файлов в Git репозитории. Команда git status.
    5. Внутреннее устройство Git. Объекты.
    6. Делаем файлы отслеживаемыми. Команда git add.
    7. Делаем первый коммит. Команда git commit.
    7.1. Создание коммита. Этап 1. Создание графа.
    7.2. Создание коммита. Этап 2. Создание объекта коммита
    7.3. Создание коммита. Этап 3. Направить ветку на текущий коммит.
    8. Делаем второй коммит

    Практический блок

    1. Задание. Файловая структура.
    2. Задание. Условие.
    3. Задание. Решение: Код + Видео.
    4. Домашнее задание

    ТЕОРЕТИЧЕСКИЙ БЛОК
    1
    Основные понятия

    В прошлом уроке мы бегло разобрали, что такое репозиторий, коммит и ветка. Остановимся сейчас подробнее на этих понятиях. И для начала дадим более-менее формальные определения, а после разберем их подробнее на примерах.

    1. Репозиторий – папка проекта, отслеживаемого Git, содержащая дерево изменений проекта в хронологическом порядке. Все файлы истории хранятся в специальной папке .git/ внутри папки проекта.
    2. Индекс – файл, в котором содержатся изменения, подготовленные для добавления в коммит. Вы можете добавлять и убирать файлы из индекса.
    3. Коммит – фиксация изменений, внесенных в индекс. Другими словами, коммит – это единица изменений в вашем проекте. Коммит хранит измененные файлы, имя автора коммита и время, в которое был сделан коммит. Кроме того, каждый коммит имеет уникальный идентификатор, который позволяет в любое время к нему откатиться.
    4. УказателиHEAD , ORIGHEAD и т. д. – это ссылка на определенный коммит. Ссылка – это некоторая метка, которую использует Git или сам пользователь, чтобы указать на коммит.
    5. Ветка – это последовательность коммитов. Технически же, ветка – это ссылка на последний коммит в этой ветке. Преимущество веток в их независимости. Вы можете вносить изменения в файлы на одной ветке, например, пробовать новую функцию, и они никак не скажутся на файлах в другой ветке. Изначально в репозитории одна ветка, но позже мы рассмотрим, как создавать другие.
    6. Рабочая копия. Директория .git/ с её содержимым относится к Git. Все остальные файлы называются рабочей копией и принадлежат пользователю
    1. git init – создает новый репозиторий
    2. git status – отображает список измененных, добавленных и удаленных файлов
    3. git add – добавляет указанные файлы в индекс
    4. git commit – фиксирует добавленные в индекс изменения

    Важно
    Мы стараемся делать наши уроки доступными для широкого круга пользователей, независимо от операционной системы, на которой они работают. Поэтому все примеры в данном и последующих уроках мы будем приводить на Git Bash . Git Bash – это оболочка, основанная на Bash и реализующая все его стандартные функции.

    Если вы пользователь Linux, у вас уже есть Bash , и код из наших примеров может быть выполнен напрямую в Терминале.

    Если же вы пользуетесь Windows, то могли заметить, что вместе с основными компонентами Git поставил к вам на компьютер Git Bash . Вы можете запустить ее, нажав ПКМ по директории, откуда вы хотите ее запустить, и выбрав из меню Git bash here . Также вы можете вызывать Git напрямую из встроенной консоли cmd , если вам так удобнее.

    2
    Настройки Git

    В зависимости от области действия и места хранения в Git cуществуют 3 типа настроек:

    1. Системные. Представляют собой настройки на уровне всей системы, то есть они распространяются на всех пользователей. Файл с этими настройками хранится по следующему пути: C:\Program Files\Git\etc\gitconfig для Windows и /etc/gitconfig для пользователей Linux/MacOS.
    2. Глобальные. Эти настройки одинаковы для всех репозиториев, созданных под вашим пользователем. Среди них есть, например, имя ветки по умолчанию. Файл с этими параметрами хранятся по следующему адресу: C:/User//.gitconfig в windows, или ~ /.gitconfig в Unix системах.
    3. Локальные. Это настройки на уровне репозитория, они не будут применяться к другим вашим проектам. Эти параметры хранятся в каждом вашем репозитории по адресу: .git/config .

    

    Области действия настроек Git

    Изменить настройки Git можно двумя способами:

    1. Отредактировать файл gitconfig (на уровне системы) или .gitconfig (глобально) или .git/config (на уровне репозитория) напрямую, то есть используя текстовый редактор.
    2. Воспользоваться утилитой git config . Кроме того, с помощью этой утилиты можно посмотреть значение соответствующего параметра.

    Команда git config

    git config
    

    —global
    Изменение настроек на уровне пользователя. Без указания данного ключа настройки будут изменены только на уровне текущего репозитория.

    —system
    Изменение настроек на уровне системы (то есть сразу для всех пользователей).

    Параметры, флаги
    user.name Имя пользователя
    user.email Электронная почта пользователя
    Другие параметры
    Что делает
    Устанавливает значение соответствующего параметра в конфигурации Git

    # Задаем значение имени на уровне репозитория
    $ git config user.name John
    # Просматриваем значение параметра
    $ git config user.name
    John
    # Задаем значение email глобально
    $ git config —global user.email daniella@email.com

    Давайте попробуем задать имя пользователя глобально. Воспользуемся утилитой git config с параметром —global :

     $ git config --global user.name smartiqa $ git config --global user.email info@smartiqa.com 

    Приведем файл /.gitconfig после изменения:
    Файл /.gitconfig с заданным пользователем

     [filter "lfs"] clean = git-lfs clean -- %f smudge = git-lfs smudge -- %f process = git-lfs filter-process required = true [user] name = smartiqa email = info@smartiqa.com [init] defaultBranch = develop 

    Как видно поля user.name и user.email действительно стали такими, какими мы их задали.
    3
    Создание репозитория. Команда git init

    Как было сказано выше, репозиторий должен обязательно содержать папку .git/ с историей этого репозитория. Создать эту папку можно двумя способами:

    1. Создать новый репозиторий.
    2. Клонировать к себе на компьютер существующий репозиторий.

    Команда git init

    git init
    
    Что делает
    Создает пустой репозиторий в директории, откуда была вызвана

    # Создаем пустой репозиторий в папке проекта
    $ cd projects/project_folder/
    $ git init
    Initialized empty Git repository in projects/project_folder/

    Создадим папку test_repository и на ее базе создадим репозиторий Git:

     $ mkdir test_repository $ cd test_repository/ $ git init Initialized empty Git repository in /Users/smartiqa/test_repository/.git/ 

    Эта команда создала папку .git внутри папки вашего проекта. По ходу работы мы будем разбираться, чем же наполнена эта папка. А пока приведем структуру ее содержимого:

    Папка test_repository/.git

     test_repository/.git ├── HEAD ├── branches ├── config ├── description ├── hooks ├── info │ └── exclude ├── objects │ ├── info │ └── pack └── refs ├── heads └── tags 

    4
    Состояния файлов в Git репозитории. Команда git status

    1. Рабочая директория — Working directory . Это файловая структура, с которой непосредственно работает пользователь в конкретный момент времени. Технически же — это копия определенной версии вашего проекта, которую вы извлекли из базы Git и в которую пытаетесь внести свои изменения.
    2. Индекс или Область подготовленных файлов — Index / Staging area . Это область, где хранятся имена файлов и изменения в них, которые должны войти в следующий коммит. Технически индекс — это просто файл.
    3. Директория Git — Git Directory . Папка, в которой Git хранит все версии вашего проекта и также свои служебные файлы. Данная папка носит название .git и располагается в корневой директории вашего проекта.

    

    Части проекта Git

    Таким образом, получается, что ваши файлы путешествуют между этими тремя областями. Файлы, с которыми вы напрямую работаете — это Working Directory. Что-то изменили в этих файлах — изменилось состояние Working Directory.

    Хотите зафиксировать эти изменения — скажите Git, какие именно из всех изменений, вы хотите сохранить. Для этого вы добавляете изменения в файлах во вторую область — Staging (он же Index). Это некое среднее состояние между Working Directory и Git Directory — изменения уже на пути к фиксации, но еще не сохранены в базе Git.

    Если вы уверены, что все изменения, которые вы добавили в Index / Staging, необходимо сохранить в базу Git, то вы делаете коммит, и они в сжатом виде помещаются в Git Directory. Теперь все надежно сохранено в папке .git .

    

    Перемещение изменений между областями Git

    А теперь давайте более подробно разберемся с тем, в каких состояниях могут быть файлы с точки зрения Git. Каждый файл может находится только в одном из двух состояний:

    1. Отслеживаемый. Об этих файлах Git знает и отслеживает изменения в них. Отслеживаемые файлы в свою очередь могут находится в следующих состояниях:

    1. Неизмененный. То есть с момента последнего коммита в файле не было никаких изменений
    2. Измененный. То есть с последнего коммита в файле были произведены какие-то изменения.
    3. Подготовленный к коммиту. Это значит, что вы внесли изменения в этот файл и затем проиндексировали их, и эти изменения будут добавлены в следующий коммит.

    Приведем наглядную визуализацию состояний и переходов между ними.

    

    Состояния файлов Git
    Чтобы посмотреть статус текущих файлов, нам потребуется команда git status .

    Команда git status

    git status
    
    Дополнительные параметры, флаги
    Что делает
    Выводит информацию о статусе файлов, находящихся в репозитории

    # Cмотрим на статус файлов
    $ git status

    new file: discrete math/hw-3/dm_sem_11_done.pdf
    new file: it theory/3/itt_3.pdf
    deleted: progrmmings/c/non-evaluated/out.txt

    Changes not staged for commit:
    (use «git add/rm . » to update what will be committed)
    (use «git restore . » to discard changes in working directory)
    modified: .gitignore

    Перейдем к примеру. Создадим в нашем тестовом репозитории два файла: alpha.txt и num.txt . Первый будет содержать букву a , а второй – цифру 1 :

    Папка test_repository

     test_repository/ ├── alpha.txt └── num.txt 

    Посмотрим, что при этом покажет команда git status :

     $ git status On branch develop No commits yet Untracked files: (use "git add . " to include in what will be committed) alpha.txt num.txt nothing added to commit but untracked files present (use "git add" to track) 

    Видно, что на данный момент у нас нет ни одного коммита. Давайте это исправим. Но прежде всего нам нужно разобраться с тем, как Git работает изнутри.

    5
    Внутреннее устройство Git. Объекты.

    Всю информацию Git представляет в виде «объектов». Объект – это файл, содержащий определенную информацию о репозитории и его файлах. Все объекты хранятся в директории .git/objects/ . Объекты бывают трех типов:

    1. Blob (англ. binary large object ) – большой бинарный объект, другими словами просто бинарный файл. Для каждого файла в репозитории формируется blob-файл , который содержит его имя и сжатое содержимое. Blob-файл формируется, когда мы добавляем файл в индекс.
    2. Tree (англ. tree – дерево). Дерево – это такой тип графа. Оно нужно нам, чтобы показывать связи между файлами в репозитории. Деревья формируются для каждой директории репозитория (в том числе для корневой) во время коммита и показывают, какие файлы (или поддиректории) лежат в данной директории. Таким образом, объект дерева состоит из имен 1) blob-объектов для файлов, которые лежат в данной директории, и 2) других деревьев для всех поддиректорий.
    3. Объект коммита. Этот объект содержит в себе имя автора коммита, время коммита и объект дерева корневой директории проекта.
    1. Сжимает содержимое этого файла и создает blob-объект .
    2. Записывает имя этого объекта в файл индекса.

    

    Структура хранения данных репозитория в Git

    1. Git – это большая картотека объектов.
    2. Git хранит все файлы и связи между ними, как объекты в директории .git/objects .
    3. Объект – это файл с некоторой информацией о репозитории.
    4. Объекты бывают трех типов: Blob , Tree и Commit .
    5. Blob-объекты хранят информацию о файлах репозитория и их содержимом.
    6. Tree-объекты хранят информацию о расположении этих файлов в репозитории.
    7. Индекс же нужен Git, чтобы понимать, какие из файлов мы добавим в последующий коммит, а какие – нет.

    Теперь рассмотрим подробнее, как добавлять файлы в индекс и что при этом происходит.
    6
    Делаем файлы отслеживаемыми. Команда git add
    Чтобы сделать файл отслеживаемым, существует команда git add . Разберемся с ней чуть подробнее.

    Команда git add

    git add
    
    Параметры, флаги
    -A, —all
    С этим флагом под действие команды попадут все файлы в репозитории
    Другие флаги
    Что делает
    Добавляет файлы в индекс

    # Добавляем файл dijkstra.c в индекс:
    $ git add dijkstra.c

    # Добавляем все измененные файлы в индекс:
    $ git add -A
    # или
    $ git add —all

    Теперь добавим файл alpha.txt в индекс:

     $ git add alpha.txt 

    Посмотрим на статус файлов теперь:

     $ git status On branch develop No commits yet Changes to be committed: (use "git rm --cached . " to unstage) new file: alpha.txt Untracked files: (use "git add . " to include in what will be committed) num.txt 

    

    Команда git add. Добавление новых файлов в индекс.

    Теперь видно, что мы добавили файл alpha.txt в индекс и Git видит его. Но что же все-таки произошло? Работал Git так:

    1. Создал новый blob-объект.

    1. К типу файла (т.е. blob) через пробел дописывается длина содержимого и нулевой байт. В нашем случае для файла alpha.txt , содержащего a мы получим: blob 1\0 .
    2. Затем к полученной строке прибавляется само содержимое файла. То есть blob 1\0a .
    3. Затем эта строка отдается хэш-функции SHA-1 , которая и выдает нам 40-символьный результат.

    Хэш файла alpha.txt

     ca87a297fe24e72165a6c462b2e1df12a01cbc34 

    Это значит, что Git создаст директорию .git/objects/ca/ и сохранит в нее blob-файл с именем 87a297fe24e72165a6c462b2e1df12a01cbc34 .

    

    Команда git add. Этап 1. Формирование Blob-файла.

    Хэширование нужно затем, чтобы однозначно определить файл его содержимым (если содержимое файлов различно хотя бы одним символом, то хэши будут сильно отличаться друг от друга). А разбиение по поддиректориям нужно затем, чтобы потом было проще найти нужный нам файл среди множества других.

    Заметьте, что простое добавление файла в Git приводит к сохранению его содержимого в директории objects . Оно будет храниться там, даже если мы удалим alpha.txt из рабочей копии.

    2. После сохранения blob-файла , гит добавляет его имя в индекс.

    Как было сказано выше, индекс – это список файлов, за которыми следит Git. Он хранится в .git/index . Каждая строчка состоит из имени файла и его хэша. Вот таким получился индекс репозитория, рассмотренного выше:

    Содержимое файла .git/index

     alpha.txt ca87a297fe24e72165a6c462b2e1df12a01cbc34. 

    

    Команда git add. Этап 2. Добавление файла в индекс.
    Добавим таким же образом, файл num.txt :

     $ git add num.txt 

    И посмотрим статус:

     $ git status On branch develop No commits yet Changes to be committed: (use "git rm --cached . " to unstage) new file: alpha.txt new file: num.txt 

    Теперь допустим, что мы передумали и решили изменить содержимое файла num.txt c 1 на 1024 . Сделаем это и посмотрим статус снова:

     $ git status On branch develop No commits yet Changes to be committed: (use "git rm --cached . " to unstage) new file: alpha.txt new file: num.txt Changes not staged for commit: (use "git add . " to update what will be committed) (use "git restore . " to discard changes in working directory) modified: num.txt 

    Видно, что файл num.txt одновременно находится в двух состояниях: подготовленный к коммиту и измененный . Но как такое возможно? Давайте разбираться.

    Помните, мы находили хэш-сумму от содержимого файла? Теперь мы это содержимое поменяли и хэш-сумма стала другой. Git это заметил, и предупредил нас. Если мы сейчас сделаем коммит, то в него попадет файл num.txt со значением 1 , а не 1024 . Чтобы в коммит попали новые изменения, нам нужно заново проиндексировать файл num.txt .

     $ git add num.txt 

    

    Команда git add. Добавление новых изменений файла в индекс.
    Можем убедиться, что все хорошо, заново просмотрев статус:

     $ git status On branch develop No commits yet Changes to be committed: (use "git rm --cached . " to unstage) new file: alpha.txt new file: num.txt 

    Подведем итог
    Мы узнали, что:

    1. Чтобы сделать файл отслеживаемым, существует команда git add .
    2. Когда мы делаем файл отслеживаемым, происходит следующее:
       2.1. Создается blob-объект для этого файла. Имя blob-объекта – 40-символьный хэш содержимого файла, причем первые две буквы хэша отводятся под имя поддиректории в папке .git/objects , а остальные 38 – под имя самого файла. Такое разделение имени ускоряет поиск blob-файла среди других.
       2.2. Имя этого blob-файла записывается в индекс ( .git/index ). С этого момента GIt считает файл подготовленным к коммиту.
    3. Если мы поменяем содержимое файла, нам нужно снова добавить его в индекс командой git add .

    7
    Делаем первый коммит. Команда git commit.

    Итак, как уже было сказано выше, коммит хранит не только снимок (все индексированные файлы) репозитория, но и имя автора со временем, что бывает полезно. Чтобы сделать коммит в Git, есть команда git commit .

    Команда git commit

    git commit
    
    Параметры, флаги

    -m
    Добавляет к коммиту комментарий. Создать коммит без описания нельзя, но описание можно добавить другими способами (например, из файла). Описывать коммит надо так, чтобы другому человеку было понятно, какие именно изменения вы внесли в данном коммите.

    -c
    Берет описание, и информацию об авторе из переданного коммита, когда создает новый. Открывает редактор, давая возможность отредактировать описание коммита.

    -С
    То же, что и -с , но не открывает редактор. Берет описание переданного коммита неизменяемым.

    Другие флаги
    Что делает
    Создает новый коммит с файлами из индекса.

    # Создаем первый коммит с комментарием Add math hometask

    $ git commit -m «Add math hometask»

    [master 0b1f669] Add math hometask
    11 files changed, 7 insertions(+), 638 deletions(-)
    rewrite .gitignore (99%)
    delete mode 100644 discrete math/hw-3/dm3.pdf

    В нашем репозитории из прошлого пункта мы уже добавили все файлы в индекс, поэтому нам остается только сделать коммит.

     $ git commit -m "Initial commit" [develop (root-commit) 10962e7] Initial commit 2 files changed, 2 insertions(+) create mode 100644 data/alpha.txt create mode 100644 data/num.txt 

    Теперь давайте разберемся, что только что произошло и что это за буквы с цифрами 10962e7 в первой строчке вывода.
    В целом команда git commit делает три шага:

    1. Создает граф (дерево), представляющий содержимое версии проекта, для которой делают коммит.
    2. Создает объект коммита.
    3. Направляет текущую ветку на новый коммит

    Создание коммита. Этап 1. Создание графа.
    

    Git представляет текущее состояние проекта, как древовидный граф, информация для которого читается из индекса. Этот граф записывает расположение и содержание файлов в проекте. Граф — это объект-дерево, о котором упоминалось выше. Каждая строчка любого графа записана по следующему правилу:

    Формат записи внутри объекта Tree

    Разберем все по порядку.

    1. Режим доступа это одно из следующих чисел:
       1. 100644 – обычный файл.
       2. 100755 – исполняемый файл.
       3. 120000 – символическая ссылка (напр. HEAD ).
       Режимы доступа в Git сложно назвать гибкими: указанные три режима – единственные доступные для файлов в Git, хотя существуют и другие режимы, используемые для директорий и подмодулей.
    2. Тип объекта – это строка, которая может принимать значение blob , если объект – это blob-файл , либо tree , если объект – это дерево.
    3. Третье значение – хэш объекта. Это тот самый 40-символьный SHA-1 хэш.
    4. Ну и последнее значение – это имя файла, из которого был создан blob-файл и получен хэш.
    1. Blob-файлы
    2. Tree-файлы , они же деревья.

    Структура репозитория test_repository

     test_repository └───data │ └─alpha.txt │ └─num.txt └─── outer.txt 

    То есть у нас есть вложенная папка data с файлами alpha.txt , num.txt и отдельный файл outer.txt . Граф директории data , созданный при коммите, будет выглядеть так:

    .git/objects/09/d20c0539.

     100644 blob ca87a297fe24e72165a6c462b2e1df12a01cbc34 alpha.txt 100644 blob 81c545efebe5f57d4cab2ba9ec294c4b0cadf672 num.txt 

    Визуализируя его получим:

    

    Команда git commit. Визуализация дерева директории data после коммита.
    А дерево для корневой директории репозитория test_repository будет выглядеть следующим образом:
    .git/objects/c0/d2cc3e13.

     040000 tree 09d20c0539d97b2a60d06db73135cda7dcac4121 data 100644 blob 5ef136008f1e8f921622f7eed1fe1925331c9665 outer.txt 

    Первая строчка – это дерево директории data/ , рассмотренное выше, а вторая – файл outer.txt.

    При этом само это дерево, включающее директорию data/ и файл outer.txt будет иметь хэш c0d2cc3e13d34e7043d2afddb4af8867cc972741 (спойлер: оно пригодится для объекта коммита).

    Визуализируя граф корневой директории test_repository получим следующее:

    

    Команда git commit. Визуализация дерева репозитория после коммита.

    Все эти объекты сохраняются в директорию .git/objects/ по тому же принципу, то есть первые два символа хэша – имя поддиректории в папке .git/objects/ , а остальные 38 – имя файла в этой поддиректории.

    1. Первым шагом в создании коммита является создание древовидных графов.
    2. Древовидный граф — это объект типа tree , который хранится в директории .git/objects/ .
    3. Деревья нужны, чтобы отразить взаимное расположение файлов и директорий в репозитории.
    4. Дерево создается для каждой директории репозитория, в том числе и для корневой.
    5. Каждая строчка файла дерева устроена по следующей схеме: .

    Создание коммита. Этап 2. Создание объекта коммита
    

    После того, как был создан граф репозитория, Git создает объект коммита. Объект коммита – точно такой же текстовый файл в директории .git/objects/ , как деревья и blob-файлы . Объект коммита репозитория из предыдущего примера выглядит так:

    .git/objects/f9/8b4a7891.

     tree c0d2cc3e13d34e7043d2afddb4af8867cc972741 author smartiqa 1606261256 +0300 committer smartiqa 1606261256 +0300 Initial commit 

    Первая строчка записи указывает на дерево корня репозитория, то есть тот самый граф ( test_repository ) с хэшем c0d2cc3…

    Вторая строчка говорит, кто и когда создал коммит, третья – кто и когда записал коммит в репозиторий. Обычно эти две строчки совпадают, но бывают и ситуации, когда один человек записывает в свой репозиторий коммит другого человека, тогда эти строчки будут различаться. Тот, кто запишет коммит к себе будет значится в поле committer , а тот, кто создал этот коммит – в поле author .

    Ну и в последней, четвертой, строчке содержится комментарий коммита. В нашем случае – Initial commit .

    

    Команда git commit. Объект коммита.

    Теперь мы знаем, что коммит – это объект коммита. Хэш этого объекта и есть хэш коммита – уникальный идентификатор, по которому можно найти любой коммит. Обычно хэш не надо писать полностью, достаточно первых 6-8 цифр. Например:

     $ git commit -m “Initial commit” [develop (root-commit) f98b4a7] initial commit 3 files changed, 3 insertions(+) create mode 100644 data/alpha.txt create mode 100644 data/num.txt create mode 100644 outer.txt 

    Здесь f98b4a7 это и есть часть хэша коммита. Git создаст директорию .git/objects/f9 и сохранит в нее объект коммита 8b4a7… , к которому мы потом сможем обращаться.

    1. После создания объектов деревьев для всех директорий репозитория, создается объект коммита.
    2. Объект коммита состоит из:
       2.1. Объекта дерева корневой директории репозитория
       2.2. Информации о том, кто и когда создал коммит
       2.3. Кто и когда записал коммит в историю репозитория
       2.4. Комментария коммита
    3. Обычно пункты 2.2 и 2.3 совпадают, но не всегда.
    4. Имя объекта коммита – его хэш. По этому хэшу можно найти любой коммит. Не обязательно использовать все 40 символов хэша, обычно 6-8 бывает достаточно.

    Создание коммита. Этап 3. Направить ветку на текущий коммит.
    

    В заключение нам нужно сообщить указателю-ветке, что у нас есть новый коммит. Делает это Git следующим образом:

    1. Для начала, нужно посмотреть, на какой ветке мы сейчас работаем (их может быть несколько). Git идет в файл .git/HEAD и видит следующее: ref: refs/heads/develop . Такая запись говорит нам, что HEAD указывает на ветку develop, т. е. ветка, в которой мы сейчас работаем – develop (неудивительно, ведь она единственная).
       Напомню, что HEAD и develop – это ссылки, используемые Git или пользователем для указания на определенный коммит.
    2. Затем Git ищет файл .git/refs/heads/develop , но такого файла не существует, поскольку это был первый коммит в нашем репозитории и до сих пор ветке develop было не на что указывать. Поэтому Git создает файл .git/refs/heads/develop и задает его содержимое – хэш объекта-коммита, который мы получили f98b4a7. .

    

    Команда git commit. Граф репозитория с указателями после первого коммита.
    8
    Делаем второй коммит

    Детально разобравшись с процессами создания коммита, изучим граф после первого и второго коммита.

    Для примера рассмотрим репозиторий со следующей структурой:

    Структура репозитория test_repository

     test_repository └───data └─alpha.txt └─num.txt 

    То есть, как и в предыдущем примере, но без файла outer.txt . Иначе наши графы будут слишком объемными.

    Для начала заметим, что наш индекс снова пуст, поскольку все файлы уже добавлены в коммит, а новых изменений нет:

     git status On branch develop nothing to commit, working tree clean 

    Давайте рассмотрим, как выглядит рабочая копия и индекс нашего репозитория на графе.

    

    Граф с рабочей копией и индексом.

    Выглядит запутанно, но постарайтесь разобраться. Рабочая копия и индекс указывают на одни и те же файлы из первого коммита. Это значит, что изменений в файлах нет. Теперь давайте поменяем содержимое файла alpha.txt и посмотрим индекс снова:

     $ git status On branch develop Changes not staged for commit: (use "git add . " to update what will be committed) (use "git restore . " to discard changes in working directory) modified: data/alpha.txt no changes added to commit (use "git add" and/or "git commit -a") 

    Снова посмотрим на граф.

    

    Граф для измененного файла alpha.txt.

    Как видно, теперь в рабочей копии находится измененный файл alpha.txt , но он еще не проиндексирован. Поэтому индекс указывает на первоначальный файл, а вот в рабочей копии находится уже измененный. Давайте проиндексируем его и посмотрим на статус.

     git add -A git status On branch develop Changes to be committed: (use "git restore --staged . " to unstage) modified: data/alpha.txt 

    Вы наверняка догадываетесь, как будет выглядеть граф теперь, но все же приведем схему:

    

    Граф для измененного и затем проиндексированного файла.

    Теперь рабочая копия указывает на тот же файл, что и индекс, причем этот файл не находится в последнем коммите. Это значит, что у нас есть проиндексированные изменения. Зафиксируем их, то есть сделаем второй коммит.

     $ git commit -m "change alpha.txt" [develop 4117d58] change alpha.txt 1 file changed, 1 insertion(+), 1 deletion(-) 

    Теперь Git создаст новый граф для представления данных из индекса. Старое дерево data/ больше не отражает состояние проиндексированной директории data/ (т.к. файл alpha.txt был изменен), поэтому создается новое. Объект этого дерева(для папки data ) выглядит так:

    Дерево папки data (.git/objects/3b/95bcd6d0. )

     100644 blob 7e74e68b2a782a3aead46d987a63ca1c91091c13 alpha.txt 100644 blob 81c545efebe5f57d4cab2ba9ec294c4b0cadf672 num.txt 

    Поскольку хэш нового дерева data/ отличается от старого, нужно создать новое дерево для всего репозитория. Объект для корневой директории test_repository будет выглядеть так:

    Дерево папки test_repository (.git/objects/22/d4301816. )

     040000 tree 3b95bcd6d0a76177985b5d3b2fd046b48e9110ba data 

    И уже только на основе этого дерева можно создавать объект второго коммита.
    Объект коммита (.git/objects/41/17d584a7. )

     tree 22d4301816880a569417c908ee00b2f6680efb33 parent 0790c287b727b43156de737f5840cb6584261830 author smartiqa 1606271955 +0300 committer smartiqa 1606271955 +0300 change alpha.txt 

    Здесь все, как и в объекте первого коммита, за исключением второй строчки – она новая. Теперь у коммита есть родитель (предок, предшествующий коммит). Чтобы найти родителя, Git проходит в файл .git/refs/heads/develop и смотрит на хэш коммита, который там записан.

    После этого Git меняет содержимое .git/refs/heads/develop на хэш текущего коммита. Графически, наш репозиторий теперь выглядит так:

    

    Граф после второго коммита.

    Заметьте, что мы не меняли num.txt , поэтому Git не стал заново добавлять его в коммит. Вместо этого, в новый коммит вошла ссылка на файл num.txt из прошлого коммита. Такая функция позволяет экономить место и не засорять репозиторий одинаковыми файлами.

    ПРАКТИЧЕСКИЙ БЛОК

    1. Скачать предложенную ниже древовидную структуру из файлов и папок.
    2. На основе этой структуры инициализировать репозиторий Git
    3. Посмотреть, в каком состоянии находятся рабочая директория, индекс и папка .git
       
    4. Внести изменения в один/несколько файлов, добавить их в индекс и затем закоммитить
    5. Посмотреть, как в ответ на эти действия изменяется состояние рабочей директории / индекса / папки .git
    1. Опишем файловую структуру, на основе которой будем формировать условие задания. При желании вы можете использовать собственную.
    2. Дадим условие задания
    3. [ ВИДЕО ] Выполним задание по списку и дадим соответствующие комментарии
    4. Дадим условие для домашнего задания

    1
    Задание. Файловая структура.

    Дана папка, в которой хранятся файлы свежесозданного блога о диких животных. Файловая структура данной директории:

    Структура папки wild_animals

     wild_animals ├── index.html └── pictures ├── elephant.jpg ├── giraffe.jpg └── paw_print.jpg 

    Скачать папку wild_animals

    1. Основная страница блога index.html
    2. Папка pictures , в которой хранятся изображения ( файлы *.jpg ) сайта

    1. Основная страница блога index.html
    Представляет собой файл, который содержит HTML код главной страницы сайта. Ниже приведено его содержимое:

    Файл index.html

          
    Wild Animals
     - Blog about nature - 
     
     
     
    Let's talk about wild animals around the world:
     
    Giraffe
     
    Area: Africa
     
    Weight: 900-1200kg
     
    Height: 6m
     
    Elehant
     
    Area: Africa, Asia
     
    Weight: 4000-7000kg
     
    Height: 3m
      

    Если отрыть данный файл в браузере, то выглядит основная (и пока единственная) страница блога таким образом:

    

    Главная страница сайта о диких животных

    2. Папка с картинками pictures
    Картинки для главной страницы сайта хранятся в папке pictures . Ниже представлена ее структура:

    Структура папки pictures

     pictures ├── elephant.jpg ├── giraffe.jpg └── paw_print.jpg 

    И сами изображения:
    Файл giraffe.jpg
    Файл elephant.jpg
    Файл paw_print.jpg
    2
    Задание. Условие.

    Теперь когда мы познакомились со структурой директории wild_animals , можно переходить непосредственно к условию задачи:

    1) Создайте репозиторий внутри папки wild_animals . Убедитесь, что внутри папки wild_animals появилась папка .git .

    1. Изучите содержимое файла конфигурации Git для текущего репозитория .git/config
    2. Настройте имя и email пользователя для текущего репозитория
    3. Убедитесь, что файл .git/config изменился соответствующим образом
    1. Убедитесь, что отсутствует файл индекса .git/index
    2. Убедитесь, что папка с объектами Git пустая .git/objects
    3. Убедитесь, что указатель HEAD указывает на ветку main
    1. Сделайте файлы папки wild_animals отслеживаемыми
    2. Обратите внимание на файл индекса .git/index и папку с объектами .git/objects
    3. Сделайте коммит
    4. Найдите хэш коммита
    1. Исправьте опечатку в файле index.html (опечатка в слове Elephant )
    2. Добавьте изменения в индекс
    3. Сделайте коммит
    1. Добавьте в файл index.html секцию для еще одного животного (например, для кенгуру)
    2. Добавьте изменения в индекс
    3. Сделайте коммит

    3
    Задание. Решение.
    Наш вариант выполнения предложенного задания смотрите в видео-инструкции:

    Хронометраж

    ТЕОРИЯ
    00:20 План видео
    01:00 Понятия: репозиторий, Индекс, Коммит, Ветка, Указатель
    03:40 Области проекта Git: Рабочая директория(Working Directory), Индекс (Index) и Каталог Git (Git Directory)
    06:00 Перемещение файлов между областями проекта
    08:20 Состояния файлов Git: Untracked, Unmodified, Modified, Staged
    11:15 Команда git status
    11:50 Команда git status и состояния файлов
    13:50 Объекты Git: Blob- и Tree-объекты, объект коммита
    18:40 Добавление файла в индекс
    20:00 Добавление файла в индекс. Команда git add.
    20:50 Добавление файла в индекс. Этап 1. Формирование Blob-файла
    20:55 Добавление файла в индекс. Этап 2. Добавление файла в Индекс.
    24:30 Создание коммита
    24:50 Создание коммита. Команда git commit.
    26:15 Создание коммита. Этап 1. Создание графа.
    26:55 Создание коммита. Этап 2. Формирование объекта коммита
    29:45 Создание коммита. Этап 3. Смещение указателя HEAD.

    ПРАКТИКА
    31:45 Чем будем заниматься
    32:05 Файловая структура для репозитория
    33:20 Задание 1. Создание репозитория
    36:05 Задание 2. Настройка пользователя Git
    38:40 Задание 3. Работа с директорией .git
    45:15 Задание 4. Создание 1-го коммита
    51:10 Задание 5. Создание 2-го коммита
    55:00 Задание 6. Создание 3-го коммита
    59:55 Контакты

    Скачать презентацию «Git: Внутренняя реализация. Индексация. Коммиты.»
    4
    Домашнее задание

    Дана маленькая библиотека, вычисляющая некоторые тригонометрические функции. Она имеет следующую структуру:

    Структура директории mat_lib

     mat_lib ├─docs │ └─math_lib_docs.txt │ └─pyfiles └─factorial.py └─test.py └─trigonometry.py 

    Похожие публикации:

    1. Git как перейти в папку
    2. Как понять не работает
    3. Как узнать свой часовой пояс
    4. Сколько времени занимает публикация приложения в google play