Создание git репозитория, состоящего из разных папок

#git #git_submodule

                    
Только осваиваю git, возник вопрос, на который я не могу найти в поисковике ответ.
Возможно, я не правильно формулирую саму задачу.

Есть такая структура в папке моего локального веб-сервера

server_folder  
--my_project_logic  
--localhost  
----my_project_webresource  
----othersite1  
----othersite2  
----...


Мне надо создать один репозиторий с 2 папками my_project_logic и my_project_webresource,
которые находятся на разных уровнях вложенности.

Подскажите, пожалуйста, где лучше инициализировать репозиторий?

Пока придумалось только одно решение - инициализировать репозиторий на папку server_folder,
и в .gitignore прописать исключение на все, кроме этих двух папок. Есть ли решения
поизящнее?
    

Ответы

Ответ 1

Я правильно понимаю, что othersite1 - это совсем другой проект и мешать с Вашим его
не нужно, а папка server_folder находиться в папке вебсервера? Это чревато проблемами
в будущем. К примеру, захотите делать деплой через git (просто сделав pull),  а это
очень плохо - даже yandex на это натыкался.

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

Но если пойти ещё дальше, то лушче сделать так. Под проект заводиться виртуальное
окружение (lxc, docker, rocket или просто virtualbox). В результате на одно окружение
будет один проект и не будет никаких проблем.

Как удалить субмодуль?

#git #git_submodule

Имеется субмодуль в git репозитории. Добавлялся так:
git submodule add  libs/

Теперь он перестал быть нужным, как его удалить?    

Ответы

Ответ 1

Встроенных средств для удаления субмодулей нету. Нужно сделать седующее:

Удалить (отредактировав) упоминание о модуле из .gitmodules;
Удалить из .git/config;
Выполнить git rm --cached ;
Закомитить и удалить файлы модуля.

Так же можно воспользоватся следующей командой
git config -f .git/config --remove-section submodule.
git config -f .gitmodules --remove-section submodule.

Работа с модулями в GIT

#git #git_submodule

Есть внешний репозиторий в котором реализован базовый функционал по работе с бд,
в дальнейшем буду называть его DAL — слой доступа к данным).

Создаю новый проект, подключаю DAL в качестве модуля:

git submodule add ../Projects/DataAccessLayer DAL


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

Как правильно организовать/сделать такую работу?

UPD.:

На текущий момент я построил свою работу так:


Создаю новую ветку: git checkout -b НоваяВетка;
Делаю необходимые мне изменения: добавляю новые классы, реорганизую, ну и т.п.;
Индексирую изменения, комичу: git add ... -> git commit -m 'Здесь какой то текст';
Вливаю изменения в главную ветку: git checkout master -> git merge НоваяВетка;
Повторяю с начала списка по мере рефакторинга, добавления нового функционала;


UPD2

Master v.0.1
   | \
   |  \
   |   \
   |    \
   |   v.0.1
   |    /
   |  dal
   |  /
   | /
Master


т.е. я подключаю модуль в ветке dal, улучшения модуля dal делаем в ветках которые
пойдут от dal

я правильно понял?
    

Ответы

Ответ 1

Вариант 1.

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

Вариант 2. 

Сделайте в субмодуле новую ветку, специфическую для этого проекта. Вносите изменения
в нее. Если вы внесете какие-то общие изменения в DAL и захотите обновить их в репозитории,
то вам нужно будет обновить master, а потом сделать rebase ваших изменений на новый
последний коммит. 

Было:

master    feature
        Y
        |
    C   X
    | /
    B
    | 
    A


Станет:

master    feature
        Y'
        |
        X'
      /
    C
    |
    B
    | 
    A

Создание git репозитория, состоящего из разных папок

Только осваиваю git, возник вопрос, на который я не могу найти в поисковике ответ. Возможно, я не правильно формулирую саму задачу.
Есть такая структура в папке моего локального веб-сервера
server_folder --my_project_logic --localhost ----my_project_webresource ----othersite1 ----othersite2 ----...
Мне надо создать один репозиторий с 2 папками my_project_logic и my_project_webresource, которые находятся на разных уровнях вложенности.
Подскажите, пожалуйста, где лучше инициализировать репозиторий?
Пока придумалось только одно решение - инициализировать репозиторий на папку server_folder, и в .gitignore прописать исключение на все, кроме этих двух папок. Есть ли решения поизящнее?

Ответ

Я правильно понимаю, что othersite1 - это совсем другой проект и мешать с Вашим его не нужно, а папка server_folder находиться в папке вебсервера? Это чревато проблемами в будущем. К примеру, захотите делать деплой через git (просто сделав pull), а это очень плохо - даже yandex на это натыкался.
Хорошо сделать так. В домашнем каталоге делается папка с проектом, где все хранится. В результате развернуть там git не будет проблем - все будет только от одного проекта. А дальше делается скрипт, который с помощью rsync или других утилит копирует файлы по местам. Понятно, что для разработчика все копировать постоянно - накладно, поэтому, можно просто создать две симлинки (собственно это скрипт также может делать).
Но если пойти ещё дальше, то лушче сделать так. Под проект заводиться виртуальное окружение (lxc, docker, rocket или просто virtualbox). В результате на одно окружение будет один проект и не будет никаких проблем.

Работа с модулями в GIT

Есть внешний репозиторий в котором реализован базовый функционал по работе с бд, в дальнейшем буду называть его DAL — слой доступа к данным).
Создаю новый проект, подключаю DAL в качестве модуля:
git submodule add ../Projects/DataAccessLayer DAL
В текущем проекте мне необходимо его немного допилить напильником, данные изменения уникальны в рамках текущего проекта, в основном репозиторий DAL они мне не нужны.
Как правильно организовать/сделать такую работу?
UPD.:
На текущий момент я построил свою работу так:
Создаю новую ветку: git checkout -b НоваяВетка Делаю необходимые мне изменения: добавляю новые классы, реорганизую, ну и т.п.; Индексирую изменения, комичу: git add ... -> git commit -m 'Здесь какой то текст' Вливаю изменения в главную ветку: git checkout master -> git merge НоваяВетка Повторяю с начала списка по мере рефакторинга, добавления нового функционала;
UPD2
Master v.0.1 | \ | \ | \ | \ | v.0.1 | / | dal | / | / Master
т.е. я подключаю модуль в ветке dal, улучшения модуля dal делаем в ветках которые пойдут от dal
я правильно понял?

Ответ

Вариант 1.
Подумайте, можно ли допиливание осуществить за счет конфигурации? Например, вынести разные константы в отдельный конфиг. В составе субмодуля у вас будет один конфиг с дефолтными значениями, а в конкретном проекте — второй, в котором некоторые из значений могут быть переопределены. Тогда необходимость вносить изменения в субмодуль исчезнет.
Вариант 2.
Сделайте в субмодуле новую ветку, специфическую для этого проекта. Вносите изменения в нее. Если вы внесете какие-то общие изменения в DAL и захотите обновить их в репозитории, то вам нужно будет обновить master, а потом сделать rebase ваших изменений на новый последний коммит.
Было:
master feature Y | C X | / B | A
Станет:
master feature Y' | X' / C | B | A