Git как механизм сравнения репозиториев

Добрый день, проконсультируйте плииз.

Есть десяток папок с одним одинаковым текстовым файлом в разных проектах.
Любой из владельцев папки может поменять файл (не часто и не значительно).

Хочу "натравить" на них гит, поднять гит-сервер и написать утилиту для поиска отличий.

Задача: отловить отличия файлов и выдать в отчет (на ноде). Нужен ТОЛЬКО "факт отличия" - контроль версий не важен!

Раньше они сидели на одном сервере и отличия вылавливались (отдельной утилитой) по "дате изменения". Даже если поменяли 2е из 10ти в разное время можно было вывести в табличку "прошло с изменений" и у одного получалось 2 дня, у другого 5 дней, а у всех остальных 50 дней - хватало для начала решения конфликтов сравнением построчно.

Теперь надо разнести папки на разные компы и следить через локальную сеть. Где время может "поломаться" и некоторые могут быть оффлайн. После решения/исправления конфликта хочу "залить слепок" в гит и начать "новое отслеживание" не привязанное к дате изменения файлов.

Гит на такое способен? Или это как "из пушки по воробьям" и проще по md5(контрольная сумма) файла сравнивать?

Еще один нюанс: папки УЖЕ созданы(в работе)! Создать в них гит я могу, но не создавать каждому "свежую" папку из главного репозитория(clone)... Можно/тяжело ли "объединить в общую сеть" разные репозитории?

0

Сообщение от andyj Нужен ТОЛЬКО "факт отличия" - контроль версий не важен!

Тогда просто используй diff с ключом -r.
man diff

1

Сообщение от andyj папки УЖЕ созданы(в работе)! Создать в них гит я могу, но не создавать каждому "свежую" папку из главного репозитория(clone)... Можно/тяжело ли "объединить в общую сеть" разные репозитории?

А на это что-нибудь подскажите? Мне не приходилось с подобным сталкиваться и не знаю "как начать". 10 папок. в каждой могу запустить git init и прописать ссылку на главный репозиторий. Смогу я после этого СРАЗУ их начать "сравнивать"? Или еще что-то надо прописать? Пока "с наскока" это не получилось, но возможно руки кривые(опыта мало)... Встречал (СЛОЖНЫЕ) инструкции в гугле по "объединению репозиториев" - это мой случай или это только для "слияния 2х разных проектов в один"?

0

Если вам версии файлов не нужны, то git не нужен.
Вам нужно определить факт изменения файла на ПК? Или факт появления отличия между файлом на ПК и его копией на сервере? Или содержимое файла у всех должно быть одинаковым и отличие надо обнаружить?
Что за файл вообще?

0

Сообщение от Rius Вам нужно определить факт изменения файла на ПК?

да, найти отличия и показать в отчете "не помешало бы их сделать одинаковыми"

Сообщение от Rius Или содержимое файла у всех должно быть одинаковым и отличие надо обнаружить?

да, обнаружить чтобы найти время и "выровнить"

Сообщение от Rius Что за файл вообще?

файл - текстовый "модуль" одинаковый для нескольких (многих) проектов.

p.s. В среднем каждый 6-12 месяцев ищу (>5 лет) готовое решение по этой теме здесь и на других форумах... похоже его не существует... А теперь "поджимает".

ЗАДАЧА:
Десяток-два модулей "частых функций" или "мини-фреймворки" на 3-5 файлов. Например модуль работы с рандомом:

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

После безуспешных поисков готового git/svn решения собрал "костыль" в 1С7.7 за пару часов (за годы работы развил в целый "комбаин") - база(таблица) проектов(больше 10), база таких модулей(намного больше 10), база модулей проекта("соответствия", с автоматическим поиском/заполнением по папке проекта), отчеты, поиск "измененных", механизм простой замены(с сохранением до 3х старых копий), механизм построчного сравнения/исправления (подключена внешняя утилита из TotalCommander'a). При переносе проекта лишь в таблице прописывал новый путь. Сравнение шло по "старшенству" файлов (дата изменения) - красиво подкрашивалось в отчете и предлагало оптимальные пути по обновлению и инструменты решения конфликтов.

Сейчас (через месяц-два-три) часть проектов надо вынести на другие компы, включая не виндовые и хочу переписать на нечто мультиплатформенное и опенсорсное. С 1С7.7(удобное, но платное и только-виндовое) на node(ядро)+web(общий интерфейс, отчеты) + nwjs(локальный интерфейс в tray и "следилка") + git(сравнение, архивы, "транспорт" через сеть). Почему бы не подключить git для хранения ПОЛНОЙ истории версий вместо последних 3х (my.js~1, my.js~2, my.js~3)... За последние >5 лет необходимости "поднять" ранние версии не было(а если надо, то либо в гите каждого "основного" проекта сохранялась, либо в архивных копиях 7zip), но было бы круто изучить/просмотреть/визуализировать(gource) историю каждого такого "универсального модуля".

Думал о git-"модулях", но все эти "универсальные" модули скинуты в одну общую папку(от 1 до 30 на проект), а не каждый в своей папке и подключение/обновление сложное. Знаю (проверил, не сложно) что гит можно "натравить" на любой файл закинув .git и рабочий файл в разные папки... но сначала хочу "выработать методику" простой замены (раньше это делал в 1-5 кнопок удобного интерфейса без строчки в консоли). Хочу сделать ТО-ЖЕ но на методиках гита... или прийдется писать "межкомпьютерный" модуль поиска отличий через md5 и синхронизации... Естественно все должно работать в интерфейсе "обновляльщика", а не в консольных командах - поэтому хотелось бы нодой получать "результат выполнения" команд гита и парсить их, а не "вычитывать" консольный отчет на команду гита на 2-3 страницы/экрана в поиске "отличий не обнаружено".

...готов выслушать ЛЮБЫЕ советы!

0

Сообщение от andyj Знаю (проверил, не сложно) что гит можно "натравить" на любой файл закинув .git и рабочий файл в разные папки..

Ага, --git-dir.
Если хотите git, можно так:

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

1

Сообщение от Rius хорошо бы в самих файлах хранить какой-то идентификатор версии.

Это как? Или зачем?

У меня мало опыта с ГИТом (особенно на несколько разработчиков). Поэтому мне тонкости приходится "с нуля" изучать и тестировать...

Главное что беспокоит:

1) Папки с файлами УЖЕ есть! Уже раскиданы по винчестерАм. Хочу "провернуть" простой набор команд и "включить их в систему" гит-репозиториев. Пробую БАТниками подобрать оптимальный набор алгоритмов для создания и связывания репозиториев (потом перенесу их в ноду). Пробовал создать в test1/my.js и в test2/my.js 2 репозитория и их "связать" - не получилось! Это "руки кривые" и надо копать дальше или это не предусмотрено ГИТом и надо все ветки от "единого предка" делать?
Или изначально прийдется сравнивать/выравнивать вручную, а потом "пересоздавать" в папках методом clone?

Изначально задумка была такой:

Исходники:
test1/my.js
test2/my.js

Создаю: (git init c кучей параметров)
my_git_1/test1/.git
my_git_1/test2/.git
одного из них назначаю "главным", остальные к нему "подчиненные"

потом провожу "первичную синхронизацию" и выравниваю версии commit'ов - чтобы у всех последняя была.
потом пишу батники для разных методик синхронизации... и алгоритмы решения конфликтов...

2) еще не могу придумать, нужно ли в моем случае создавать "ветки"? или все могут работать в master? Проектов может быть сотни (некоторые создаю только для отладки/тестирования подобных модулей, но остальные "вспомогательные" модули надо держать актуальными) и без "менеджера веток" я запутаюсь...
Если честно, хотелось бы обойтись одной веткой... конфликты возникают крайне редко! из 20 проектов обычно 1меняет, реже 2...

0

вроде разобрался с основами...

..."кривые руки" были! 2 независимо-созданных репа можно "сливать" в один общий. И ветки плодить не обязательно - вполне все можно делать в master ("не по феншую", но можно).

Последний вопрос: Кому-нибудь из ВАС подобная система интересна? Могу попробовать (не сразу) сделать этот проект опенсорсным и выложить ни гитхаб, но за последние 3-5 лет не встречал особого энтузиазма у окружающих (ответы типа "меня и обычная ГИТ вполне устраивает").

Суть системы - поддержка между разными независимыми проектами "одинаковости" единичных/"именных" файлов - одинаковых мини-библиотек, батников(bat, sh), настроек (ini, inf, "одинаковый .gitignore для всех моих ноде проектов"), файлов лицензий, файлов отвечающих за "любимый дизайн"(xml в андроиде, png, css, scss - например либа создания закругленных уголков в одну команду). А так-же ведение реестра проектов (можно будет коментарий задать - когда мини-проектов уже больше 30-50 я не могу вспомнить ни когда, ни кому подобное делал, ни название "той папки").

0

0

0

0

Спасибо! Пожалуй закрываю тему! буду писать "для себя"...

0

0