Здравствуйте, Qulac, Вы писали:
Q>Нужна помощь с толкнулся с такой вещью и уже второй раз теряю свои результаты работы с кодом. Вернее результаты ни куда не делись, комит был, только его теперь фиг достанешь в том виде что он был. Короче меня пока не интересуют субмодули и какая от них польза, мне нужно всего лишь их как-то нейтрализовать, что бы они не мешали работать с репозиторием как с единым целым. Так что если кому не лень объясните на пальцах пожалуйста. Вот я склонировал в vs репо, создал новую ветвь от ветки разработки типа task-10, но субмодули при этом остаются в detach состоянии. Что нужно с ними сделать, что бы можно было все закомитить, сделать пуш, а результаты ни куда не делить?
сабмодули — это отдельные репозитории, которые вычекиваются в определенном фиксированном коммите, который фиксируется в коммите главного репа. Надо зайти в каждый, который меняешь, сделать там ветку (возможно от мастера, а не от detached commit), на ней менять, ее коммитить и ее пушить. В главном репе тоже ветка, на ней меняешь код главного репа, а новую ревизию сабмодуля фиксируешь просто добавляя папку сабмодуля (git add). Измненеия в сабмодуле от git add не добавляются. Надо иммено что внутри сделать git add, commit, push. А потом в главном git add submodule-dir.
Есть команды-сокращения для работы с сабами, но сначала надо познать принцип.
Здравствуйте, dmitry_npi, Вы писали:
_>У меня похожая ситуация. Каким-то образом сабмодули (но не все, а два из четырех, хз, почему) застряли в состоянии detached, хотя по факту этот коммит и есть последний коммит в мастере. Visual Studio со своим multi-repo support отказывается даже делать Pull. Я просто хочу вернуться в главном репо на мастер, и в сабах тоже на мастер, локальных изменений у меня нет, че делать-то?
Ну смотри, каждый коммит в главном репе ссылается на какой-то конкретный коммит в сабмодуле.
Нет такого, что ссылка идет на ветку мастер сабмодуля, чтобы каждый конкретный коммит главного репа ссылался на определенную версию, а не как повезет.
_>Ок, зашел в саб репо, сделал git checkout master, потом git pull, git status показывает, что изменений в сабмодуле НЕТ (nothing to commit, etc). Но теперь в главном репо я вижу: modified: my-sub-repo (new commits). Студия показывает это:
Да, теперь у тебя сабмодуль в твоей ветке все еще ссылается на старый коммит, а вычекнут другой коммит. Очевидно, ты поменял ссылку. (Есть изменения в главном репе, а не в сабмодуле).
_>Что это значит, черт побери? Изменений у меня нет, я просто запуллил всё что мог со всех реп. Что он понимает под изменениями и что мне с этим делать? Коммитить? Так зачем, я не собираюсь портить основной мастер ничем. Реверт? Так потом опять выползет.
Если хочешь зафиксировать в своей ветке новую версию сабмодуля, то git add submodule-path / git commit. Иначе ну просто игнорь. Ну а что. Если файл меняешь, тебе же тоже изменения покажет.
_>Пробовал git submodule update --init --recursive, так оно мне потом опять повергает сабрепо в detached.
Конечно, он вычекивает конкретный коммит, на который ссылается твоя ветка. И оно оказывается в detached.
_>Наверно, остается один проверенный путь — нахрен удалить весь каталог и выкачать всё заново. Но лень, потом специфические конфиги по папкам раскладывать.
Ничего не поменяется.
_>
_>---- _>И вопрос, скорее, в КСВ — почему так? зачем мне эти сложности? Я не хотел ничего другого, кроме как выкачать репо с сабрепами, создать ветки для фичи, сделать фичу, закоммитить и вернуться на мастер. Почему для этого необходимо изучать всю подноготную гита, всякие рефы, детачед коммиты? Ну я могу понять, возможно, для разработки ядра линукс такой трэш, где есть сеть независимых репозиториев, где разработка ведется peer-to-peer, а потом еще патчи друг другу шлют — это то что доктор прописал. Но зачем это всё обычным разрабам, кто их всех подсадил на это чудовище?
Здравствуйте, m2user, Вы писали:
П>>>Вот тут не очень понятно, а на какой коммит они ставятся? В .gitmodules вроде нет по дефолту информации о коммите, значит, гит сам выбирает какой коммит мне подсунуть? Самый последний? AD>>Нет, который был последним закомичен в этой ветке.
M>Как модифицируется это поведение в зависимости от того, указана ли опция submodule.<name>.branch ?
Да никак. Она позволяет тебе сделать git submodule update --remote, которая тянет и вычекивает с ремоута ветку submodule.<name>.branch. Это просто для удобства, сути дела не меняет.
То есть, это облегчает обновление на последний master/develop/trunk сабмодуля. Но потом тебе все равно надо сделать git add и git commit в главном репе, чтобы актуализировать новый коммит сабмодуля. И в следующий раз, когда сделаешь git submodule update, всё равно получишь detached head.
M>Из https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.2.txt M>
M> * "git submodule" started learning a new mode to integrate with the
M> tip of the remote branch (as opposed to integrating with the commit
M> recorded in the superproject's gitlink).
AD>>>>В ветке главного проекта, в любой (мастер — это тоже ветка). П>>>Ясно. А что выбирается, когда я только добавил сабмодуль? master/main? AD>>В смысле совсем новый? Не каждый день я сабмодули добавляю... Что вычекнуто, то и добавляется. По идее ремотный HEAD П>Ну, хоть раз в год. В смысле, что вычекнуто? HEAD — он один на всех, или у веток свои?
origin/HEAD — самый свежий коммит на главной ветке репозитория, название ветки может быть всякое. Это то же, что ты получишь, когда сделаешь git clone.
Нужна помощь с толкнулся с такой вещью и уже второй раз теряю свои результаты работы с кодом. Вернее результаты ни куда не делись, комит был, только его теперь фиг достанешь в том виде что он был. Короче меня пока не интересуют субмодули и какая от них польза, мне нужно всего лишь их как-то нейтрализовать, что бы они не мешали работать с репозиторием как с единым целым. Так что если кому не лень объясните на пальцах пожалуйста. Вот я склонировал в vs репо, создал новую ветвь от ветки разработки типа task-10, но субмодули при этом остаются в detach состоянии. Что нужно с ними сделать, что бы можно было все закомитить, сделать пуш, а результаты ни куда не делить?
У меня похожая ситуация. Каким-то образом сабмодули (но не все, а два из четырех, хз, почему) застряли в состоянии detached, хотя по факту этот коммит и есть последний коммит в мастере. Visual Studio со своим multi-repo support отказывается даже делать Pull. Я просто хочу вернуться в главном репо на мастер, и в сабах тоже на мастер, локальных изменений у меня нет, че делать-то?
Ок, зашел в саб репо, сделал git checkout master, потом git pull, git status показывает, что изменений в сабмодуле НЕТ (nothing to commit, etc). Но теперь в главном репо я вижу: modified: my-sub-repo (new commits). Студия показывает это:
Что это значит, черт побери? Изменений у меня нет, я просто запуллил всё что мог со всех реп. Что он понимает под изменениями и что мне с этим делать? Коммитить? Так зачем, я не собираюсь портить основной мастер ничем. Реверт? Так потом опять выползет.
Пробовал git submodule update --init --recursive, так оно мне потом опять повергает сабрепо в detached.
Наверно, остается один проверенный путь — нахрен удалить весь каталог и выкачать всё заново. Но лень, потом специфические конфиги по папкам раскладывать.
----
И вопрос, скорее, в КСВ — почему так? зачем мне эти сложности? Я не хотел ничего другого, кроме как выкачать репо с сабрепами, создать ветки для фичи, сделать фичу, закоммитить и вернуться на мастер. Почему для этого необходимо изучать всю подноготную гита, всякие рефы, детачед коммиты? Ну я могу понять, возможно, для разработки ядра линукс такой трэш, где есть сеть независимых репозиториев, где разработка ведется peer-to-peer, а потом еще патчи друг другу шлют — это то что доктор прописал. Но зачем это всё обычным разрабам, кто их всех подсадил на это чудовище?
Здравствуйте, dmitry_npi, Вы писали:
— _>Но зачем это всё обычным разрабам, кто их всех подсадил на это чудовище?
Я тоже замучался выкачивать qt с подмодулями с помощью git. Потом плюнул и создал один собственный коммит в стиле монорепозитория.
Есть альтернативные способы работы, вроде использования веток. Только вот стиль работы с git выбирают сами разработчики. Если они выбрали подмодули, то для нормальных людей всё становится крайне неудобным.
Проблема не только в выкачивании, какой-нибудь gitweb потом плохо это интерпретирует.
Здравствуйте, andrey.desman, Вы писали:
AD>сабмодули — это отдельные репозитории, которые вычекиваются в определенном фиксированном коммите, который фиксируется в коммите главного репа. Надо зайти в каждый, который меняешь, сделать там ветку (возможно от мастера, а не от detached commit), на ней менять, ее коммитить и ее пушить. В главном репе тоже ветка, на ней меняешь код главного репа, а новую ревизию сабмодуля фиксируешь просто добавляя папку сабмодуля (git add). Измненеия в сабмодуле от git add не добавляются. Надо иммено что внутри сделать git add, commit, push. А потом в главном git add submodule-dir. AD>Есть команды-сокращения для работы с сабами, но сначала надо познать принцип.
А можно как-то сделать, чтобы сабмодуль сам устанавливался например в мастер (или на другую какую-то ветку) и при всех обновлениях не менял состояния? А то задолбало, постоянно на оторванную башку натыкаюсь
П>А можно как-то сделать, чтобы сабмодуль сам устанавливался например в мастер (или на другую какую-то ветку) и при всех обновлениях не менял состояния? А то задолбало, постоянно на оторванную башку натыкаюсь
Взаимоисключающие параграфы. Как это стоять на мастере и не менять состояния?
Ну ладно, не важно. Сабмодули всегда ставятся на конкретный коммит, как раз чтобы не менять состояния, поэтому они всегда вычекиваются в detached head.
Здравствуйте, andrey.desman, Вы писали:
П>>А можно как-то сделать, чтобы сабмодуль сам устанавливался например в мастер (или на другую какую-то ветку) и при всех обновлениях не менял состояния? А то задолбало, постоянно на оторванную башку натыкаюсь
AD>Взаимоисключающие параграфы. Как это стоять на мастере и не менять состояния?
Да я наверное не очень что-то понимаю. Решил я попробовать с ними пожить. Есть у меня либа, я её в проект присунул как сабмодуль. Либа активно развивается вместе с проектом, я особо не заморачиваюсь с ветками мержреквестами и пр, тупо в мастер добавляю изменения, и пушу в ремоут. Да, при обновлении текущая ветка не меняется, если я уже сделал чекаут, тут я соврал, но в новое место когда клонируешь, надо чекаут на ветку сделать, я пару раз накололся.
Состояние не менять — в том плане, что у меня выбрана ветка мастер, и я хочу иметь там самые последние изменения. Ну то есть да, HEAD будет двигаться.
AD>Ну ладно, не важно. Сабмодули всегда ставятся на конкретный коммит, как раз чтобы не менять состояния, поэтому они всегда вычекиваются в detached head.
Вот тут не очень понятно, а на какой коммит они ставятся? В .gitmodules вроде нет по дефолту информации о коммите, значит, гит сам выбирает какой коммит мне подсунуть? Самый последний?
А если я в подмодуле завёл ветки, сделал ветку develop, куда коммичу даже не собирающиеся сорцы, чтобы потом доделать, оттестить, и смержить в мастер? Получится, что сабмодуль будет указывать на нерабочий коммит? Но когда я использую либу, я вообще-то хочу чтобы у меня собиралось с ней. Вот тут как-то не очень понятно
Здравствуйте, пффф, Вы писали:
П>Да я наверное не очень что-то понимаю. Решил я попробовать с ними пожить. Есть у меня либа, я её в проект присунул как сабмодуль. Либа активно развивается вместе с проектом, я особо не заморачиваюсь с ветками мержреквестами и пр, тупо в мастер добавляю изменения, и пушу в ремоут. Да, при обновлении текущая ветка не меняется, если я уже сделал чекаут, тут я соврал, но в новое место когда клонируешь, надо чекаут на ветку сделать, я пару раз накололся.
Не понял...
П>Состояние не менять — в том плане, что у меня выбрана ветка мастер, и я хочу иметь там самые последние изменения. Ну то есть да, HEAD будет двигаться.
Так не получится, двигать надо вручную. А что если захочешь собрать старую версию, а она тебе вычекнет несовместимый новый сабмодуль?
AD>>Ну ладно, не важно. Сабмодули всегда ставятся на конкретный коммит, как раз чтобы не менять состояния, поэтому они всегда вычекиваются в detached head.
П>Вот тут не очень понятно, а на какой коммит они ставятся? В .gitmodules вроде нет по дефолту информации о коммите, значит, гит сам выбирает какой коммит мне подсунуть? Самый последний?
Нет, который был последним закомичен в этой ветке.
А хранит внутри дерева https://stackoverflow.com/questions/5033441/where-does-git-store-the-sha1-of-the-commit-for-a-submodule
Представь, что сабмодуль — это софтлинк, который ссылается на конкретное имя mysuperlib-0.0.3. В разных ветках, в разных коммитах эта ссылка может быть разной. Она автомагически не будет меняться на другие имена.
Чтобы обновить версию сабмодуля в ветке, ты идешь в сабмодуль, вычекиваешь нужную версию (можно и мастер, не важно, азпоминаться бущет именно коммит). Потом идешь обратно в главный реп, делаешь git add submodule-path, git commit. Всё, теперь в твоей ветке новая версия. Мержишь свою ветку в мастер главного репа, и оппа, теперь в мастере новая версия.
П>А если я в подмодуле завёл ветки, сделал ветку develop, куда коммичу даже не собирающиеся сорцы, чтобы потом доделать, оттестить, и смержить в мастер? Получится, что сабмодуль будет указывать на нерабочий коммит? Но когда я использую либу, я вообще-то хочу чтобы у меня собиралось с ней. Вот тут как-то не очень понятно
Делаешь ветку в главном репе, делаешь ветку в сабмодуле (можешь их даже одинаково назвать). В ветку главного репа вычекиваешь в сабмодуле свою ветку сабмодуля, делаешь git add submodule-path, git commit. Можно пушить и делать автобилд. Другие ветки и мастер это не затронет.
Здравствуйте, andrey.desman, Вы писали:
П>>Да я наверное не очень что-то понимаю. Решил я попробовать с ними пожить. Есть у меня либа, я её в проект присунул как сабмодуль. Либа активно развивается вместе с проектом, я особо не заморачиваюсь с ветками мержреквестами и пр, тупо в мастер добавляю изменения, и пушу в ремоут. Да, при обновлении текущая ветка не меняется, если я уже сделал чекаут, тут я соврал, но в новое место когда клонируешь, надо чекаут на ветку сделать, я пару раз накололся.
AD>Не понял...
Хм, а что именно я непонятно изложил? Попробую попонятнее, только я пока не пойму, что тебе не понятно
П>>Состояние не менять — в том плане, что у меня выбрана ветка мастер, и я хочу иметь там самые последние изменения. Ну то есть да, HEAD будет двигаться.
AD>Так не получится, двигать надо вручную. А что если захочешь собрать старую версию, а она тебе вычекнет несовместимый новый сабмодуль?
AD>>>Ну ладно, не важно. Сабмодули всегда ставятся на конкретный коммит, как раз чтобы не менять состояния, поэтому они всегда вычекиваются в detached head.
П>>Вот тут не очень понятно, а на какой коммит они ставятся? В .gitmodules вроде нет по дефолту информации о коммите, значит, гит сам выбирает какой коммит мне подсунуть? Самый последний? AD>Нет, который был последним закомичен в этой ветке.
В какой ветке?
AD>Представь, что сабмодуль — это софтлинк, который ссылается на конкретное имя mysuperlib-0.0.3. В разных ветках, в разных коммитах эта ссылка может быть разной. Она автомагически не будет меняться на другие имена. AD>Чтобы обновить версию сабмодуля в ветке, ты идешь в сабмодуль, вычекиваешь нужную версию (можно и мастер, не важно, азпоминаться бущет именно коммит). Потом идешь обратно в главный реп, делаешь git add submodule-path, git commit. Всё, теперь в твоей ветке новая версия. Мержишь свою ветку в мастер главного репа, и оппа, теперь в мастере новая версия.
П>>Вот тут не очень понятно, а на какой коммит они ставятся? В .gitmodules вроде нет по дефолту информации о коммите, значит, гит сам выбирает какой коммит мне подсунуть? Самый последний? AD>Нет, который был последним закомичен в этой ветке.
Как модифицируется это поведение в зависимости от того, указана ли опция submodule.<name>.branch ?
* "git submodule" started learning a new mode to integrate with the
tip of the remote branch (as opposed to integrating with the commit
recorded in the superproject's gitlink).
Здравствуйте, пффф, Вы писали:
П>>>Да я наверное не очень что-то понимаю. Решил я попробовать с ними пожить. Есть у меня либа, я её в проект присунул как сабмодуль. Либа активно развивается вместе с проектом, я особо не заморачиваюсь с ветками мержреквестами и пр, тупо в мастер добавляю изменения, и пушу в ремоут. Да, при обновлении текущая ветка не меняется, если я уже сделал чекаут, тут я соврал, но в новое место когда клонируешь, надо чекаут на ветку сделать, я пару раз накололся. AD>>Не понял... П>Хм, а что именно я непонятно изложил? Попробую попонятнее, только я пока не пойму, что тебе не понятно
Да не понятно, кто на ком стоял. В чей мастер пушатся изменения и чья текущая ветка не меняется.
П>А, кажись я понял. Я после git pull репы делаю П>
Ага, это тебе вычекнет последний "мастер" твоего сабмодуля (merge тут лишний). Но это будет локально у тебя, мастере твоего главного проекта хер знает что вычекнется если ты периодически не обновляешь ссылку на сабмодуль.
То есть, нормальные люди для нормального чекаута будут делать git submodule update --init и получат фигу.
По сути у тебя нет нормальной истории, потому как нет связей между главным репом и сабмодулем.
П>>>Вот тут не очень понятно, а на какой коммит они ставятся? В .gitmodules вроде нет по дефолту информации о коммите, значит, гит сам выбирает какой коммит мне подсунуть? Самый последний? AD>>Нет, который был последним закомичен в этой ветке. П>В какой ветке?
В ветке главного проекта, в любой (мастер — это тоже ветка).
Здравствуйте, andrey.desman, Вы писали:
П>>>>Да я наверное не очень что-то понимаю. Решил я попробовать с ними пожить. Есть у меня либа, я её в проект присунул как сабмодуль. Либа активно развивается вместе с проектом, я особо не заморачиваюсь с ветками мержреквестами и пр, тупо в мастер добавляю изменения, и пушу в ремоут. Да, при обновлении текущая ветка не меняется, если я уже сделал чекаут, тут я соврал, но в новое место когда клонируешь, надо чекаут на ветку сделать, я пару раз накололся. AD>>>Не понял... П>>Хм, а что именно я непонятно изложил? Попробую попонятнее, только я пока не пойму, что тебе не понятно
AD>Да не понятно, кто на ком стоял. В чей мастер пушатся изменения и чья текущая ветка не меняется.
В мастер сабмодуля добавляю изменения, коммичу, и пушу
П>>А, кажись я понял. Я после git pull репы делаю П>>
AD>Ага, это тебе вычекнет последний "мастер" твоего сабмодуля (merge тут лишний). Но это будет локально у тебя, мастере твоего главного проекта хер знает что вычекнется если ты периодически не обновляешь ссылку на сабмодуль. AD>То есть, нормальные люди для нормального чекаута будут делать git submodule update --init и получат фигу. AD>По сути у тебя нет нормальной истории, потому как нет связей между главным репом и сабмодулем.
Похоже ссылка обновляется, потому что я когда коммичу изменения в сабмодуле, то в основном проекте он становится модифицированным и фиксируется при следующем коммите
AD>В ветке главного проекта, в любой (мастер — это тоже ветка).
Ясно. А что выбирается, когда я только добавил сабмодуль? master/main?
Здравствуйте, пффф, Вы писали:
AD>>По сути у тебя нет нормальной истории, потому как нет связей между главным репом и сабмодулем.
П>Похоже ссылка обновляется, потому что я когда коммичу изменения в сабмодуле, то в основном проекте он становится модифицированным и фиксируется при следующем коммите
А, ну да. Если в основном ты делаешь git add -u или явно git add submodule-path, то коммит зафиксируется.
AD>>В ветке главного проекта, в любой (мастер — это тоже ветка). П>Ясно. А что выбирается, когда я только добавил сабмодуль? master/main?
В смысле совсем новый? Не каждый день я сабмодули добавляю... Что вычекнуто, то и добавляется. По идее ремотный HEAD
Здравствуйте, andrey.desman, Вы писали:
AD>>>По сути у тебя нет нормальной истории, потому как нет связей между главным репом и сабмодулем.
П>>Похоже ссылка обновляется, потому что я когда коммичу изменения в сабмодуле, то в основном проекте он становится модифицированным и фиксируется при следующем коммите
AD>А, ну да. Если в основном ты делаешь git add -u или явно git add submodule-path, то коммит зафиксируется.
Так я так не делаю. Может, конечно, за меня это делает тортилка, посмотрю внимательнее при случае, что она делает
AD>>>В ветке главного проекта, в любой (мастер — это тоже ветка). П>>Ясно. А что выбирается, когда я только добавил сабмодуль? master/main?
AD>В смысле совсем новый? Не каждый день я сабмодули добавляю... Что вычекнуто, то и добавляется. По идее ремотный HEAD
Ну, хоть раз в год. В смысле, что вычекнуто? HEAD — он один на всех, или у веток свои?
Выглядит так, что поведение несколько переусложнено.
Т.е. то, что конкрентная ревизия проекта связана с конкрентной ревизией зависимости, это конечно правильно.
Но зачастую избыточно.
Если все эти проекты разрабатываются внутри одной организации (т.е. зависимости не внешняя), то обычно достаточно связи на уровне веток (stable — stable, dev — dev)/
Т.е. если я хочу на билд-сервере (или на машине разработчика) собирать dev-ветку проекта всегда с последней версией dev-ветки субмодуля, то как это организовать?
Здравствуйте, m2user, Вы писали:
M>Выглядит так, что поведение несколько переусложнено. M>Т.е. то, что конкрентная ревизия проекта связана с конкрентной ревизией зависимости, это конечно правильно. M>Но зачастую избыточно. M>Если все эти проекты разрабатываются внутри одной организации (т.е. зависимости не внешняя), то обычно достаточно связи на уровне веток (stable — stable, dev — dev)/
Даже так не очень. Это вот пффф выше, который сам сабмодуль пилит, и тут же в мастер подливает, ему ок.
А возьми более-менее корпорат, когда какой-то модуль разрабатывает другая команда, периодически вносит туда баги и/или ломающие изменения и/или добавляют зависимости, которые у тебя не настроены, то....
M>Т.е. если я хочу на билд-сервере (или на машине разработчика) собирать dev-ветку проекта всегда с последней версией dev-ветки субмодуля, то как это организовать?
Это зависит от CI системы. Обычно есть возможность управлять процессом вычекивания и задавать свои команды для этого.
На машине локально git clone --recurse-submodules --remote-submodules, на апдейт git pull && git submodule update --remote
Здравствуйте, пффф, Вы писали:
П>Здравствуйте, andrey.desman, Вы писали:
П>>>А можно как-то сделать, чтобы сабмодуль сам устанавливался например в мастер (или на другую какую-то ветку) и при всех обновлениях не менял состояния? А то задолбало, постоянно на оторванную башку натыкаюсь
AD>>Взаимоисключающие параграфы. Как это стоять на мастере и не менять состояния?
П>Да я наверное не очень что-то понимаю. Решил я попробовать с ними пожить. Есть у меня либа, я её в проект присунул как сабмодуль. Либа активно развивается вместе с проектом, я особо не заморачиваюсь с ветками мержреквестами и пр, тупо в мастер добавляю изменения, и пушу в ремоут. Да, при обновлении текущая ветка не меняется, если я уже сделал чекаут, тут я соврал, но в новое место когда клонируешь, надо чекаут на ветку сделать, я пару раз накололся.
Я в подобном случае подключал свою либу как nuget пакет. Мне кажется, что использование средств доставки кода, куда удобней чем использование субмодулей.
Здравствуйте, Qulac, Вы писали:
Q>Я в подобном случае подключал свою либу как nuget пакет. Мне кажется, что использование средств доставки кода, куда удобней чем использование субмодулей.
AD>origin/HEAD — самый свежий коммит на главной ветке репозитория, название ветки может быть всякое. Это то же, что ты получишь, когда сделаешь git clone.
Ещё про голову вопрос.
Есть модуль,, используется в разных проектах, обычно я с каким проектом работаю, туда подсасываю новую версию, и коммичу, Но в разных проектах состояние может быть разным, где-то последняя версия, где-то не очень, где-то я сделал checkout main/master, где-то нет.
Вопрос такой. Я прохожусь по всем проектам в батнике, и делаю там
с толкнулся с такой вещью и уже второй раз теряю свои результаты работы с кодом. Вернее результаты ни куда не делись, комит был, только его теперь фиг достанешь в том виде что он был. Короче меня пока не интересуют субмодули и какая от них польза, мне нужно всего лишь их как-то нейтрализовать, что бы они не мешали работать с репозиторием как с единым целым. Так что если кому не лень объясните на пальцах пожалуйста. Вот я склонировал в vs репо, создал новую ветвь от ветки разработки типа task-10, но субмодули при этом остаются в detach состоянии. Что нужно с ними сделать, что бы можно было все закомитить, сделать пуш, а результаты ни куда не делить?
Что вычекнуто, то и добавляется. По идее ремотный HEAD
