Войти
ПрограммированиеФорумОбщее

Хватит это терпеть. Структуризация домашних проэктов. (2 стр)

Страницы: 1 2 3 4 5 Следующая »
#15

Такая же беда, только у меня пол сотни проектов и где-то чуть больше десятка живых. Собираюсь вот-вот тупо все в один репозиторий затолкать и на bitbucket/github его. Ничего умнее пока не придумал.

27 окт. 2018 (Правка: 10:45)

#16

Suslik
> мне хочется уметь делать чекаут репозитория вместе со всеми зависимостями.
Если это прям такой насущный вопрос (что кажется странным), то довольно прагматичный вариант - скрипт с git pull / checkout на каждую зависимость.

27 окт. 2018

#17

Suslik
> Сейчас я заметил, что каждый раз, когда я обновляю свою наколеночную библиотеку
> с векторной математикой, я её копирую вручную в как минимум десяток проэктов,
> которые от неё зависят
Я забил. Просто решил считать что у каждого проекта своя отдельная версия либы. Обновления делаю только если нашёл фатальный баг, что бывает не чаще чем раз в год. Если просто добавил какую-то не сильно крутую фичу, то пофиг. Вот когда она понадобитcя в том другом прокте, тогда и сделаю merge.

27 окт. 2018 (Правка: 10:58)

#18

Suslik
Используй сабмодули. Это стандартное решение для SDK и прочего многократно используемого кода.

27 окт. 2018

#19

alexey.ch
я копал-копал и нашёл проблему. она оказалась в gitkraken'е. я могу через командную строку запушить изменения из сабмодуля в local remote non-bare repo, если пушу изменения не в ту ветку, которая в нём выбрана текущей активной. но если попытаться сделать то же самое через гиткракен, он выдаёт ошибку, что нельзя пушить в локальный non-bare repo. раздражает.

27 окт. 2018

#20

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

Алгоритм такой:
1) Комитим изменения в сабмодулях. Пушим.
2) Комитим изменения в проекте, включая состояния измененных сабмодулей. Пушим.

И проблем не будет.

Если ты привык работать методом Ctrl+A - комит, то от этой привычки придется отказаться. С сабмодулями приходится смотреть что и куда ты комитишь.

Сабмодули автоматизируют  контроль версии твоей библиотеки. Таким образом разные проекты могут использовать разные версии твоей библиотеки. Это существенно облегчает жизнь.

Да, и совет. Держи папки сабмодулей в корневой папке проекта либо в одной из его папок, не разбрасывай из по всему проекту. Так будет проще мониторить изменения и в целом работать с ними.

27 окт. 2018 (Правка: 12:59)

#21

alexey.ch
> 1) Комитим изменения в сабмодулях. Пушим.
проблема в том, что gitkraken выдаёт ошибку при попытке запушить в локальный репозиторий. командная строка — нет.

27 окт. 2018

#22

Suslik
> проблема в том, что gitkraken выдаёт ошибку при попытке запушить в локальный
> репозиторий. командная строка — нет.
Тогда гугли. Это проблема гиткракена.

Я пользуюсь смартгитом. У него такой проблемы нет.

27 окт. 2018

#23

Я вот раньше тоже всё старался расшарить, а теперь наоборот храню дубликаты в каждом проекте. Тому шо, если я во фреймворке что-то поменяю неудачно - сломается абсолютно повезде. И что в этом хорошего?
Да копии это не так удобно, но это более надёжно.

27 окт. 2018

#24

g-cont
как бы версии у сабмодулей для того и нужны. не хочешь — не обновляй. хочешь — откатись на предыдущую.

27 окт. 2018

#25

Suslik
> Как это сделать? Сейчас я заметил, что каждый раз, когда я обновляю свою
> наколеночную библиотеку с векторной математикой, я её копирую вручную в как
> минимум десяток проэктов, которые от неё зависят. Что-то мне подсказывает, что
> это не нормально.
Напиши свой наколеночный менеджер пакетов. Кроме шуток.

27 окт. 2018

#26

Sbtrn. Devil
> Напиши свой наколеночный менеджер пакетов. Кроме шуток.
И свой гит заодно :)

27 окт. 2018

#27

Можно инвертировать проблему.
Т.е. не библиотечка прикручивается к проэкту, а проэкт к коллекции библиотечек ("движку").
Как показывает практика, очень даже жизнеспособный вариант -- проэкты всегда юзают актуальные версии библиотечек (и библиотечки всегда в рабочем состоянии,ибо не хочется ломать ничего).

Унреал юзал такой подход давно, например.
Или вот если погуглить "google perforce single source of truth" там товарищи из гугла рассказывали как они манаджат всю свою кодобазу, в едином репо.

27 окт. 2018

#28

alexey.ch
> Алгоритм такой:
> 1) Комитим изменения в сабмодулях. Пушим.
> 2) Комитим изменения в проекте, включая состояния измененных сабмодулей. Пушим.
Комитим и сразу пушим? Так это ж свн!

27 окт. 2018

#29

skalogryz
> Комитим и сразу пушим? Так это ж свн!
SVN прошел мимо меня, так что не могу разделить вместе с тобой твой восторг.

27 окт. 2018 (Правка: 21:50)

Страницы: 1 2 3 4 5 Следующая »
ПрограммированиеФорумОбщее