У меня есть аналогичный проект. Я периодически получаю ядро от производителя (библиотечная база данных), допиливаю его своими наработками. И дополнительно делаю на базе моего доработанного ядра отдельные версии для разных библиотек, как как процессы у всех разные. Реализовано всё обычными ветками и никаких других заморочек не требуется.
Твоя регулярка в принципе неправильная.
Звёздочка это квантификатор, её надо экранировать.
Зачем так много плюсов? И скобки тоже не несут никакого смысла.
Почитай про ленивые квантификаторы.
Вот примерно что должно получиться: \*\*\*trash3\*\*\*.+?"
В худшем случае ты получишь конфликты в тех нескольких коммитах, которые после изменённого. Откуда тут бесконечность может взяться? Прояви терпение до доведи ребейз до конца.
Либо ты не разобрался с первым конфликтом и застрял на этом шаге. ))
Кирилл Гусарев, кто сказал что надо хранить проекты в двух аккаунтах? Репозиторий это и есть проект в терминах Git.
Над одним проектом могут работать несколько человек. Не нужно копировать проекты в личные аккаунты.
Права тоже настраиваются. Вы можете создать вспомогательный аккаунт с доступом только на чтение к определённым вашим проектам (репозиториям) и опубликовать пароль в резюме.
Да, так и есть. Ты вместо форка отправляешь в основной репо. Это и пишется в сообщении об ошибке — htmlacademy-adaptive это не твой аккаунт. Туда у тебя нет прав.
Отправляй в свой и снова делай Pull Request, как ты уже сделал с первым заданием.
Антон Михайлов, выдавало ошибку, потому что нет такой команды)) хоть бы почитал ссылку, которую дал. Это сокращение для команды log с дополнительными параметрами. Чтобы заработало, нужно задать этот alias.
Разработчикам платят не за написание кода, а за решение конкретных бизнес-задач.
У вас одноразовые задачи? Тогда комментарии и не нужны. И история проекта не нужна.
Но если проект серьёзный, то возникает необходимость в доработках или исправлении ошибок. И тогда уже вы сами себе скажете спасибо за аккуратную историю и понятные комментарии к ранее сделанной работе. Разработка не заканчивается на релизе, вы всё равно продолжите допиливать проект и доработки будут опираться на предыдущую историю. Баг-трекер это не очень удачное место для хранения истории. А что если завтра вы решите перейти на другую систему? Всю историю придётся забыть? Ссылки на тикеты это хорошо, но они второстепенны в коммите. Важно таки писать в сообщении коммита что он делает. Если у вас практикуется squash-merge, то тогда оформляйте красиво squash-коммиты, так как все остальные уничтожаются при squash.
Алексей Березников, и снова не соглашусь. Merge-коммит в гитхабе подписывается не аккаунтом, а произвольным именем и e-mail, которые указаны на странице профиля. Там мы можем вписать что угодно. А многие вообще забывают вписать там правильные данные и в итоге вместо e-mail в подписи коммитов оказывается ерунда.
Если уже изменил автора локальных коммитов, то отправь их заново через push --force, тогда и Pull Request обновится тоже.
Но смущает сама формулировка вопроса. В Git нет аккаунтов, это утилита командной строки. Коммиты подписываются произвольным именем и e-mail, которые берутся из конфига. Если имелся в виду аккаунт Гитхаба, то он никак не влияет на автора коммитов. Сами коммиты никак не меняются при отправке в вышестоящий репозиторий. Аккаунт виден только в данных пулл-реквеста и не сохраняется в самих коммитах.
Ты пытаешься скачать ветку master, но в репозитории нет такой ветки. Там есть только main.
На этом шаге тебе и выдаёт ошибку, что не найдено искомой ревизии.
Могу ошибаться, но это называется слиянием поддеревьев
Идея в том, чтобы взять историю коммитов из внешнего проекта, и перенаправить её в подкаталог внутреннего. При этом используется стандартный гитовый механизм работы с внешними ветками.
