Сергей Кореневский, не очень понимаю вопрос.
В любом случае SmartGit это просто графическая надстройка над Git и не может делать больше того, что умеет консольный Git. Он просто делает это более наглядно и удобно.
Что значит синхронизировать подпапку? В Git синхронизируются ветки, которые содержат снимок всего состояния проекта, значит синхронизироваться будет всё дерево папок начиная от корня проекта.
Возможно тебе надо копать в сторону sparse-checkout
Это когда из репозитория распаковывается только часть папок. Сам репозиторий продолжит содержать в себе весь проект. Данная функциональность была заложена в ядро Git уже давно, то удобные команды добавили только с версии 2.25
PanLipton, ну в логе никаких проблем не вижу. Всё сработало хорошо.
Ветка привязалась и твоя main полностью идентична ветке main на гитхабе.
Собственно и до pull она уже была идентична (Already up to date)
Слово master в этой команде это название ветки внешнего репозитория, а не локального. И названия не обязаны совпадать.
Судя по скрину, автор точно находится в локальной ветке master.
Ну тогда руками вычищай в текстовом редакторе. Не знаю чем ты пользуешься, но поиск и замена во всех файлах по шаблону это элементарная операция. Например в VSCode.
Честно говоря не представляю как можно держать в голове все модификации сайта без использования Git.
aleksandrkotov, я же написал. Оба варианта сработают. Перечитай примеры внимательней.
Даже вариант вообще без слешей сработает, но под него может попасть больше файлов и папок чем ты ожидал.
В принципе /node_modules уже достаточно. Так как мы не сможем создать одновременно и файл и папку с именем node_modules
Ещё раз:
Слеш в начале означает абсолютный путь. Объект находится в корне /
Слеш в конце чтобы акцентировать внимание что это папка и не игнорировать файлы с таким же именем.
aleksandrkotov, database/ — любые подпапки с именем database, не только в корне проекта /database/— только содержимое папки database в корне проекта /database— файл или папка с именем database в корне проекта
Конфликты возникают только при слиянии. Если хочется оградить дизайнера от разрешения конфликтов, значит нужно делать слияние самому. Только и всего.
Но дизайнер не сможет обойтись только лишь командами pull и push, понадобится цепочка подлинней: fetch branch add commit push.
1. Дизайнер загружает обновления с главного репозитория git fetch
2. Создаёт новую тематическую ветку на основе актуального состояния проекта
git checkout -b feature123 origin/main
3. Работает, коммитит, отправляет свою ветку в общий репо
4. Если общий репо на гитхабе, то создаёт там Pull Request и идёт курить.
5. Дальше в процесс вступаешь ты. Скачиваешь его ветку себе, разрешаешь конфликты, делаешь слияние в main в общем репо.
Всё. Если дизайнер хочет продолжить работу, то он повторит все пункты заново с созданием новой тематической ветки, так как старая уже не актуальна и её лучше сразу удалить.
Pull тоже не нужен, так как он эквивалентен fetch+merge, что чревато появлением конфликтов, а тебе этого не хочется)