Español Português
preview
GIT: Но что это?

GIT: Но что это?

MetaTrader 5Примеры | 15 июля 2024, 15:04
81 0
Daniel Jose
Daniel Jose

Введение

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

Основной акцент здесь будет делаться на начинающих специалистах, которые стремятся стать квалифицированными профессионалами. К сожалению, инструмент, который я вам покажу, не так прост в использовании в Windows 11, как в Windows 10, поэтому, если вы пользователь Windows, предпочтительней (по крайней мере на момент написания этой статьи) использовать его в 10 версии.

Этот инструмент — GIT. Изначально разработанный для LINUX, он очень хорош и идеально подходит для тех, кто хочет программировать и разрабатывать новые приложения. Хоть на данный момент редактор MQL5 напрямую с ним не интегрируется, это никоим образом не помешает нам использовать этот инструмент. Итак, есть несколько необходимых шагов, которые нужно сделать для того, чтобы извлечь пользу из GIT.

Если вы с ним уже знакомы или используете в своей работе, статья не добавит к вашим знаниям ничего нового, и может быть интересна разве что из любопытства. Но если вы не знаете GIT и постоянно занимаетесь программированием, рано или поздно вы столкнетесь с ситуацией, которая отобьет у вас желание продолжать разработку определенного приложения. Речь идет об ошибке, случайно допущенной при редактировании кода, которую вы заметили только спустя несколько дней или недель. Поверьте, такого рода вещи встречаются гораздо чаще, чем кажется, и именно GIT может помочь их избежать.


Что же это такое – GIT?

GIT — это программа или, как я называю, инструмент, который позволяет нам простым и весьма эффективным способом отслеживать и каталогизировать версии разрабатываемого приложения. Но это  не руководство по использованию, я не собираюсь делать что-то подобное. В основном потому, что итак уже существует огромное количество обучающих материалов по теме. В подавляющем большинстве такие руководства ориентированы на редакторы, которые изначально интегрируются с GIT, как в случае с Visual Studio. Но поскольку MetaEditor этого не делает, потребуется специальная настройка для того, чтобы можно было корректно работать с GIT совместно с MQL5.

После внесения необходимых изменений, вы сможете воспользоваться любым из существующих руководств по GIT, чтобы узнать больше. Эту статью следовало бы написать раньше, но я просто не предполагал, что среди читателей так много новичков, которые стремятся стать профессионалами. Такие люди испытывают много трудностей в совершенствовании, поскольку не знают нужных методов и средств взять приложение и модифицировать его, одновременно обучаясь в процессе. И главное здесь — отнюдь не модификация приложения, а знание, как документировать процесс, учиться на своих ошибках и таким образом совершенствоваться. Как я уже упоминал, GIT — это очень хороший способ изучать и документировать свой опыт программирования. И способ этот довольно прост и понятен  стоит лишь реализовать шаги, которые я покажу.

Чтобы постичь всю мощь этого инструмента, возьмите любое приложение, например, рассматриваемую систему репликации/моделирования, и модифицируйте ее, чтобы выяснить, работает ваша гипотеза или нет. С течением времени становится сложно понять, что было изменено. Особенно, если изменения должны происходить в различных точках. Сделать это без использования соответствующего инструмента очень сложно. В конечном итоге можно запутаться в этих изменениях и потерять всякое желание учиться и становиться профессионалом. Но GIT сделает это за вас. Можете модифицировать приложение и сразу тестировать все внесенные изменения. Если ваша гипотеза верна, вы сможете получить окончательный документ, в котором точно будет указано, что было изменено. Ну разве это не фантастика? Мне самому на этапе обучения приходилось все делать вручную. Но с GIT можно увидеть все изменения, они будут выделены.

GIT основан на очень простой концепции, похожей, в своей самой простой форме, на связанный список изменений  как ежедневник или дневник. Он создается по мере того, как делаются заметки. Как их делать, мы разберем позже. Но в более широком смысле это будет граф. Будучи графом, он может принимать любую форму, предоставляя нам различные направления в одной и той же реализации. Где каждое из направлений позволит развивать взаимосвязанные идеи. Если вы никогда не видели или не знаете, что такое граф, вы можете получить о нем представление, посмотрев на изображение ниже:

Изображение 00

По сути, в каждой точке графа у нас есть значение, известное как УЗЕЛ. Линии, соединяющие эти значения, называются РЕБРА. Это пример простого графа, однако, он может быть гораздо сложнее. Советую изучить теорию графов, оно того стоит, тем более, если вы действительно хотите стать профессионалом. Но не начинайте сразу с графов. Начните со списков, затем изучите деревья и уже потом переходите к изучению графов. Так обучение будет происходить более последовательно.


Начнем с основ

Фактически, самая основная часть — это загрузка последней версии GIT. Для этого нужно перейти по ссылке git-scm.com, и там же вы получите доступ к документации. Большая часть этих материалов уже переведена, но даже если некоторые и нет, можно найти множество людей, объясняющих нужные темы. Просто поищите и изучите. Итак, здесь я просто хочу показать основы для тех, кто не знает GIT.

Если вы пользователь Windows, вам достаточно кликнуть на область, показанную на изображении ниже:

Изображение 01

На момент написания статьи это самая актуальная версия. После загрузки самой последней версии GIT, вам необходимо будет установить ее на свой компьютер. Установка может быть выполнена с дефолтной конфигурацией, однако я вношу небольшое изменение, которое можно увидеть на изображении ниже:

Изображение 02

Вам необязательно это делать. Изменить редактор можно и позже. Но поскольку мне нравится использовать NotePad++, я предписываю GIT использовать его. Если позже вы решите использовать другой редактор, просто измените глобальную переменную GIT. Рассматриваемая переменная  — CORE.EDITOR (более подробную информацию смотрите в документации). Итак, после установки GIT, нужно его настроить. Но не волнуйтесь, это довольно просто, и я все доходчиво объясню, чтобы вы имели представление с чего начать. Когда вы закончите установку GIT, у вас появится доступ к тому, что отмечено на изображении ниже:

Изображение 03

Именно этих двух опций и нет в Windows 11. Вот почему я рекомендую использовать Windows 10. На самом деле эти параметры можно активировать в Windows 11, но потребуется выполнить некоторые действия, выходящие за рамки этой статьи. Нюанс: эти опции нам не понадобятся. Однако их наличие значительно облегчает работу и делает ее более приятной. Если кликнуть на Git GUI Here, появится следующее окно:

Изображение 04

Здесь можно открыть, клонировать или создать репозиторий. Но мы ведь хотим использовать GIT вместе с MQL5, поэтому пока не кликаем никуда. Не беспокойтесь об опции Git Bash Here. Здесь мы уделяем основное внимание GUI, однако есть много ресурсов, объясняющих, как использовать BASH, просто поищите в интернете. Поскольку идея в том, чтобы познакомить вас с GIT, я буду использовать самую простую его часть, то есть графический интерфейс GUI. Однако все, что делается в одном интерфейсе, может быть сделано и в другом, это уже дело привычки. Для начала откройте MetaEditor и нажмите на область, отмеченную на изображении ниже:

Изображение 05

Откроется следующее окно:

Изображение 06

Теперь нужно разрешить отображение скрытых файлов и папок. Это нужно для того, чтобы вы могли сделать локальную резервную копию с помощью GIT. Кроме того, вы можете использовать GITHUB. Но здесь я хочу быть максимально простым. Поэтому воспользуйтесь Проводником и измените следующий параметр:

Изображение 07

Отметьте выделенный вариант, нажмите «Применить», а затем «ОК». Теперь мы можем видеть папку, которая будет создана GIT. Поскольку у нас еще нет репозитория, папка отображаться не будет. Надо еще раз щелкнуть правой кнопкой мыши и выбрать Git GUI Here, затем нажать на Create New Repository и откроется следующее окно:

Изображение 08

Теперь нажмите кнопку Browse и откроется еще одно:

Изображение 09

Здесь просто нажмите на Select Folder и увидите следующее:

Изображение 10

Нажмите Create и получите такой результат:

Изображение 11

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

Изображение 12

Теперь обратите внимание, что в отмеченной области находятся файлы EX5. Эти файлы представляют собой приложения, которые можно запустить в MetaTrader 5. Но мы не хотим, чтобы эти файлы засоряли поиск. Чтобы удалить этот и любой другой тип файлов, нам придется сделать небольшую корректировку. Это для репозитория, который мы настраиваем. Если хотите, можете вносить изменения в глобальной форме, GIT позволяет работать в обоих направлениях. Чтобы очистить эти ненужные файлы, вам не нужно их удалять. Все, что нужно сделать, показано на изображении ниже:

Изображение 13

Обратите внимание на путь и файл, который нужно изменить. Теперь откройте файл, и вы сначала увидите следующее содержимое:

# git ls-files --others --exclude-from=.git/info/exclude
# Lines that start with '#' are comments.
# For a project mostly in C, the following would be a good set of
# exclude patterns (uncomment them if you want to use them):
# *.[oa]
# *~

Исходное содержимое файла exclude

Вы можете удалить это содержимое, поскольку оно состоит только из комментариев. Но в любом случае вам нужно будет добавить в него несколько строк. В данном случае мы хотим, чтобы все файлы с расширением EX5 не отображались, также как и многое другое. Поэтому измените файл, как показано ниже. Более подробную информацию смотрите в документации. И сохраните файл.

Изображение 14

Таким образом мы сообщаем GIT, что в этом репозитории некоторые типы файлов следует игнорировать. Но фильтр должен быть там, где я показал. Система фильтрации располагает множеством возможностей, поэтому советую изучить документацию. Чем лучше будет фильтрация, тем легче пройдет следующий этап. После сохранения файла вернитесь в окно GIT GUI и нажмите кнопку RESCAN, которая выделена на изображении ниже. Обратите внимание, что файлы с расширением EX5 больше не отображаются. Прокрутите экран и сравните с тем, что было до редактирования файла.

Изображение 15

Пока мы ничего особенного не сделали. Мы лишь сообщили GIT, где будет находиться репозиторий и что он должен фильтровать. Важное замечание: когда вы будете что-то сохранять, вам не нужно будет сохранять все, что находится в папке MQL5. Достаточно сохранить папку .GIT, и все, за чем следит GIT, будет сохранено. Это экономит много места. Но, как уже было сказано, вы можете сохранить все в облаке через GITHUB. Сохраненный контент и будет репозиторием в папке .GIT.

Итак, когда же мы начнем сохранять что-то в GIT? Спокойствие, мой дорогой читатель, мы почти у цели. Осталось еще настроить несколько мелких деталей. Чтобы сделать эти последние настройки, нужно выбрать то, что выделено на изображении ниже:

Изображение 16

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

Изображение 17

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


Создаем первый COMMIT

Теперь, когда базовая настройка завершена, вам нужно кое-что понять. Есть три основных состояния, в которых файл может находиться в GIT.

  • Первое называется COMMITTED  когда файл со всеми его данными надежно хранится в репозитории.
  • Второе состояние  MODIFIED, когда файл был модифицирован, но сделанные изменения еще не сохранены в репозитории.
  • Третье и последнее состояние — STAGED, когда мы сообщаем GIT, что файл готов к сохранению в репозитории.

Чтобы лучше понять, что означает каждое из указанных состояний, обратите внимание на изображение ниже. У нас есть файл ExpertMACD.mq5, который находится в состоянии UNSTAGED, то есть GIT его не отслеживает.

Изображение 18

Давайте сделаем так, чтобы GIT начал отслеживать изменения в этом файле. Для этого нужно на него кликнуть. Обратите внимание, что в правой области мы видим текущее содержимое файла:

Изображение 19

В верхней части содержимого файла есть слово UNTRACKED, что означает, что файл еще не отслеживается GIT. Чтобы GIT просмотрел файл, нужно воспользоваться следующей опцией:

Изображение 20

С ее помощью или с помощью сочетания клавиш CTRL+Т, мы получим то, что показано на изображении ниже:

Изображение 21

Посмотрите, как все изменилось. Теперь вверху содержимого файла появилось слово STAGED FOR COMMIT, то есть он находится в третьем состоянии и готов к сохранению. Если нет необходимости добавлять этот файл, достаточно его выбрать и нажать CTRL+U, что приведет к выходу из режима STAGED и возврату в режим UNTRACKED. Отмечу, что файл можно удалить и другими способами, более подробно об этом – в документации. Здесь же я хочу, чтобы все было как можно более простым.

Итак, давайте добавим к этому файлу его заголовочные файлы, и получим то, что можно увидеть на изображении ниже:

Изображение 22

Теперь уже можно создать первый COMMIT, просто нажав на одноименную кнопку. Однако рекомендуется, и будет чрезвычайно уместным, присвоить коммиту какое-нибудь сообщение перед нажатием кнопки COMMIT,  в дальнейшем это упростит поиск и понимание сделанных изменений.

Изображение 23

На изображении выше показано, каким может быть присвоенное сообщение. После этого можно нажимать кнопку COMMIT, и GIT начнет отслеживать указанные файлы. Результатом будет то, что показано ниже:

Изображение 24

В отмеченной области показано, что GIT успешно удалось создать COMMIT, и теперь он начнет отслеживать эти файлы. Теперь можно закрыть окно GIT GUI. Работайте над кодом, тестируйте его и изменяйте по своему вкусу, а когда закончите и получите стабильную версию, нужно будет попросить GIT обновить репозиторий. Чтобы не путаться, давайте рассмотрим это в другой теме.


Обновляем репозиторий

Обновлять репозиторий во многих случаях гораздо проще с помощью BASH, но я покажу, как это делается через GIT GUI. Для этого используйте кнопку, показанную на изображении ниже:

Изображение 25

После ее нажатия GIT проверит, где и что было изменено в отслеживаемом файле. И это снова будет отображаться как UNSTAGED, как и показано на изображении выше. Обратите внимание, что файл находится в состоянии MODIFIED, и в окне с содержимым файла GIT показывает нам, что было изменено. Это выделяется зеленым цветом. При желании, этот цвет в настройках можно изменить, но поскольку я здесь касаюсь только основ, внесение подобных изменений оставляю на ваше усмотрение.

Теперь только вам решать, принять и сохранить текущую модификацию или проигнорировать ее. Потому что да, если нужно, GIT может вернуть файл в предыдущее состояние. Думайте об этом как о возможностях, присутствующих в Windows, например таких, как точки восстановления. По этой причине важно каждый новый COMMIT сопровождать поясняющим сообщением.

Теперь давайте примем изменения и сохраним их. Смотрите, что произойдет после присвоения соответствующего сообщения и нажатия на кнопку COMMIT:

Изображение 26

Почему так? Причина в том, что изменения не находятся в состоянии STAGED, то есть еще не готовы для документирования GIT, а находятся в состоянии MODIFIED. Чтобы добавить файлы, находящиеся в состоянии MODIFIED, в состояние STAGED, просто нажмите CTRL+I. Но есть один нюанс, см. изображение ниже:

Изображение 27

Если нажать кнопку YES, все файлы, в данном случае все 403 файла, будут добавлены в состояние STAGED. Но поскольку мы хотим, чтобы добавлялись только те файлы, которые отслеживаются и которые были изменены, нужно нажать кнопку NO. И мы получим следующий результат:

Изображение 28

Теперь можно нажать на кнопку COMMIT, чтобы GIT задокументировал изменения, которые ранее сделать не удалось. Теперь должно быть понятно, что GIT документирует в репозитории только файлы, находящиеся в состоянии STAGED. Все остальные будут игнорироваться. Отлично, эта тема была легкой. Но что, если мы захотим отменить изменения, потому что код оказался запутанным? Как GIT может помочь нам это сделать? Об этом – в следующей теме.


Отменяем изменения...

Отменить уже внесенные изменения и восстановить то, что GIT задокументировал в репозитории, очень просто. Нужно выполнить те же самые действия, которые были описаны в предыдущем разделе. Итак, мы должны увидеть изменения, как показано на изображении ниже:

Изображение 29

Обратите внимание, что у нас есть новое изменение, и оно выделено. Но мы хотим его отменить, и просим GIT сделать это. Запрос выполняется с помощью сочетания клавиш CTRL+J или, если удобнее, так, как показано ниже:

Изображение 30

После GIT обязательно запросит подтверждение того, что должно быть сделано. Это можно увидеть на изображении ниже:

Изображение 31

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


Возврат кода к более стабильной версии

Возможно, это одна из самых полезных вещей — возврат к версии, в которой код был гораздо более стабильным. Сделать это без использования GIT очень сложно, а в некоторых случаях — невозможно, из-за чего приходится удалять весь код и начинать с нуля. Однако с GIT все очень просто и понятно. Для возврата можно воспользоваться одной из опций, отмеченных ниже:

Изображение 32

После этого откроется вот такое окно:

Изображение 33

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

Изображение 34

Как только это будет сделано, откроется новое окно. Но здесь нужно быть осторожными. Если вы НЕ ХОТИТЕ что-либо удалять из репозитория, выберите вариант, показанный ниже:

Изображение 35

В результате этого действия получаем следующее:

Изображение 36

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

Изображение 37

При этом весь код, находящийся в верхней части репозитория, который теперь является более старой версией, будет перемещён в соответствующие файлы. Нюанс: если какой-то файл был удален, GIT воссоздаст его заново. Вот почему так важно понимать, что такое вершина репозитория, без этого, вы не сможете вернуться к предыдущей версии. Но прежде чем изменения будут применены, это нужно будет подтвердить, как показано ниже:

Изображение 38

Отлично, теперь мы знаем, как вернуться к предыдущей версии. Но что если вы откатили слишком далеко? Как вернуться к более новой версии? Чтобы не путаться, давайте рассмотрим это в новой теме.


Возврат к более новой версии внутри репозитория

Иногда, при откате к более стабильной версии, мы заходим слишком далеко и нам приходится выполнять возврат к версии более новой. Чтобы проиллюстрировать это, давайте создадим третий уровень. Так как используя всего два уровня, понять, как это сделать через GUI, не получится. При помощи BASH это можно сделать напрямую, просто отправив команду в GIT, но я хочу показать, как это сделать через GUI. Итак, предположим, у нас есть следующий сценарий, приведенный ниже.

Изображение 39

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

Изображение 40

Представьте, что вот в этом месте мы слишком откатили назад. Тогда нужно подняться на второй уровень, чтобы проверить, подойдет ли код. Как действовать в этом случае? Это интересно, и есть несколько способов действия, никогда не стоит паниковать. Итак, прежде чем мы узнать, как это сделать, давайте рассмотрим небольшую деталь, которая может оказаться важной. Если заглянуть в папку .GIT, можно отметить наличие файла, которого раньше там не было. Посмотрим на изображении ниже.

Изображение 41

Содержимое этого файла представляет собой HASH, полезный для восстановления в случае серьезной ошибки данных, имеющихся в репозитории GIT. HASH можно увидеть, посмотрев на содержимое в выделенном фрагменте ниже:

Изображение 42

Не будем здесь вдаваться в подробности использования HASH-файлов, поскольку все это есть в документации, а также в интернете есть множество подробных руководств, и вернемся к вопросу, как получить данные, находящиеся на втором уровне. Выбрав второй уровень, нужно сделать его вершиной репозитория. Это всегда так. Однако будьте осторожны, чтобы ошибочно не выбрать режим HARD, всегда отдавайте предпочтение использованию SOFT-режима. Как показано на изображении ниже.

Изображение 43

Правильно выбрав параметры, мы получим вот такой результат:

Изображение 44

Это позволяет получить доступ к самому последнему коду. Именно так можно перемещаться между версиями, которые GIT хранит в нашем репозитории. Но допустим, нам нужно удалить и отказаться от последних изменений. Для этого следует воспользоваться опцией, показанной ниже:

Изображение 45

Полученный результат будет таким:

Изображение 46

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

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


Заключительные выводы

В этой статье я показал самые основные аспекты, необходимые для использования GIT. Я надеюсь, что эта статья послужит стимулом для дальнейшего обучения и самосовершенствования. Инструменты существуют, но не стоит ждать, пока кто-нибудь придет и покажет, как их использовать. Нужно всегда быть готовым учиться новому. И не думайте, что GIT — это только то, что я здесь показал. Это гораздо больше и он сильно может помочь вам в работе. По крайней мере, я скромно надеюсь, что смог пробудить у вас интерес к GIT.

Перевод с португальского произведен MetaQuotes Ltd.
Оригинальная статья: https://www.mql5.com/pt/articles/12516

Особенности написания Пользовательских Индикаторов Особенности написания Пользовательских Индикаторов
Написание пользовательских индикаторов в торговой системе MetaTrader 4
Нейросети в трейдинге: Пространственно-временная нейронная сеть (STNN) Нейросети в трейдинге: Пространственно-временная нейронная сеть (STNN)
В данной статье мы поговорим об использовании пространственно-временных преобразований для эффективного прогнозирования предстоящего ценового движения. Для повышения точности численного прогнозирования в STNN был предложен механизм непрерывного внимания, который позволяет модели лучше учитывать важные аспекты данных.
Особенности написания экспертов Особенности написания экспертов
Написание и тестирование экспертов в торговой системе MetaTrader 4.
Проблема разногласий: объяснимость и объяснители в ИИ Проблема разногласий: объяснимость и объяснители в ИИ
В этой статье мы будем говорить о проблемах, связанных с объяснителями и объяснимостью в ИИ. Модели ИИ часто принимают решения, которые трудно объяснить. Более того, использование нескольких объяснителей часто приводит к так называемой "проблеме разногласий". А ведь ясное понимание того, как работают модели, является ключевым для повышения доверия к ИИ.