
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Нет! Вилка" и "клон" - это не одно и то же. Пожалуйста, не путайте эти два понятия
Я прекрасно понимаю!
Причина, по которой я хочу использовать "клон", а не "форк", заключается в том, что не Это потому, что я хочу "следить" за оригинальной работой и любыми будущими обновлениями, и получать уведомления о новых "коммитах", которые мне потом нужно будет "вытягивать". Именно по этой причине существует функциональность под названием "клон".
Это объясняется тем, что MetaQuotes не должна продвигать "форк", а затем подтягивать его с помощью "клона". Это должен быть "форк", а затем "pull", а не "clone". Они путают различные функциональные возможности.
EDIT: Если MetaQuotes будет настаивать на внедрении "урезанного" решения Git и называть это "особенностью", то в итоге получится хуже, чем предыдущий метод SVN.
Я имел ввиду, что когда на локальном компьютере делается клонирование (git clone) репозитория, то нет разницы (в составе файлов и истории коммитов) между клонированием из оригинального репозитория или клонированием из свежего форка.
В документации Git описано, как можно получать обновления из оригинального репозитория в клон своего форк этого репозитория. Это требует как минимум базовых навыков по работе с репозиториями через интерфейс командной строки. Таким образом, фактически возможность обновлять локальный клон кода есть. Однако чтобы этот локальный клон создать, используя только MetaEditor, сейчас требуется обязательно создать форк оригинального репозитория в профиле своего пользователя. Только после создания форка его название появится в списке Shared Projects в MetaEditor.
Мне в целом не особо нравится такой подход. Ведь если мы не планируем вносить правки в чужой репозиторий, то нам не нужен форк, достаточно клона оригинального репозитория. Форк в этом случае - это дополнительный "лишний" пункт в списке своих репозиториев. Как я понимаю, форк мы создаём тогда, когда планируем активно вносить изменения в код, взятый из оригинального репозитория, и при этом не рассчитываем, что эти правки будут перенесены из нашего форка в оригинальный репозиторий (хотя такая возможность есть через Pull Request).
Ставя себя на место разработчиков в MetaQuotes, можно было бы, например, для клонов чужих репозиториев добавить ещё одну отдельную папку с фиксированным именем, типа "Other Shared Projects". Но у этого варианта есть свои недостатки, поэтому, скорее всего, он ещё хуже текущего решения. Каких-то более удачных вариантов сходу придумать не получается. Возможно, в будущем функционал MetaEditor будет расширен, и нам представят какое-то вообще другое решение.
Хотелось бы протестировать работоспособность обновления. Поэтому я сделал форк вашего репозитория FMIC, добавил его в список отслеживаемых и в избранное. Буду ждать вашего следующего коммита, чтобы посмотреть, каким образом я смогу о нём узнать, чтобы попробовать обновить форк.
В качестве теста я добавил описание публикации Heikin Ashi в виде файла README в формате Markdown и зафиксировал его в репозитории.
Пожалуйста, проверьте, получили ли вы уведомление об этом изменении и можете ли вы обновить форк.
MetaEditor также не может коммитить файлы изображений JPG или любые другие типы файлов, которые он считает "нераспознаваемыми", но я могу коммитить их с помощью внешнего Git-клиента.
PS! AlgoForge основан на программном обеспечении ForgeJo с открытым исходным кодом.
В качестве теста я добавил описание публикации Heikin Ashi в виде файла README в формате Markdown и зафиксировал его в репозитории.
Пожалуйста, проверьте, получили ли вы уведомление об этом изменении и можете ли вы обновить форк.
В веб-интерфейсе хранилища увидел такое:
Обновить форк попробую позже
В качестве теста я добавил описание публикации Heikin Ashi в виде файла README в формате Markdown и зафиксировал его в репозитории.
Пожалуйста, проверьте, получили ли вы уведомление об этом изменении и можете ли вы обновить форк.
В начале в моём локальном клоне форка пока последнего коммита нет:
Подключаем оригинальный репозиторий, согласно документации Git:
Захожу в веб-интерфейс форка и вижу такое:
Нажимаю кнопку "Sync" после чего в MetaEditor делаю Pull:
Как видно, все ваши коммиты благополучно оказались в форке и затем после Pull в клоне форка на моем локальном компьютере.
На этой странице документации предлагаются ещё способы синхронизации с помощью консольных команд, но их я не проверил, так как все коммиты уже синхронизированы.
Потом поэкспериментирую ещё, как будет вести себя команда Commit и Push в MetaEditor для форка. Интересно, будет ли она пытаться отправить правки и в оригинальный репозиторий?
Во-первых, мой локальный клон форка еще не имеет последнего коммита:
Подключение оригинального репозитория, согласно документации Git:
Я захожу в веб-интерфейс форка и вижу следующее:
Я нажимаю кнопку "Sync", а затем делаю Pull в MetaEditor:
Как видите, все ваши коммиты благополучно попали в форк, а затем после Pull в клон форка на моем локальном компьютере.
На этой странице документации есть и другие способы синхронизации с помощью консольных команд, но я их не тестировал, потому что все коммиты уже синхронизированы.
Все это хорошо, но вы доказали мою точку зрения, что "клон" и "форк" - это не одно и то же, и метод, который приняла MetaQuotes, требует дополнительного вмешательства за пределами MetaEditor только для того, чтобы иметь возможность синхронизировать проект.
Не говоря уже о том, что для "форков" требуется дополнительное место на серверах AlgoForge, в то время как "клон" не требует ни дополнительного места, ни дополнительных шагов.
Я считаю реализацию MetaQuotes слишком "ущербной" для эффективного использования и буду продолжать использовать внешний Git-клиент или VSCode (который прекрасно работает с AlgoForge без проблем).
Я считаю реализацию MetaQuotes слишком "ущербной" для эффективного использования и буду продолжать использовать внешний Git-клиент или VSCode (который прекрасно работает с AlgoForge без проблем).
Мы рады приветствовать вас в нашем сообществе пользователей внешних Git-клиентов! 😁
Я считаю реализацию MetaQuotes слишком "ущербной" для эффективного использования и буду продолжать использовать внешний Git-клиент или VSCode (который прекрасно работает с AlgoForge без проблем).
К сожалению, пока это действительно так. Тоже пока предпочитаю использовать внешний клиент. Но если сравнивать то, что добавили в MetaEditor за последние 5 месяцев, то это заметный прогресс. Просто до этого там вообще не было инструментов работы с новым хранилищем, а теперь хоть такая урезанная версия есть.