LINUX.ORG.RU

Синхронизация веток двух разных репозиториев

 , ,


0

0

Приветствую ребята, недавно нашёл работу.

Суть: у нас есть 2 репозитория с двумя одинаковыми ветками, нужно написать скрипт, который будет отслеживать изменения в этих ветках и в случае изменеия, допустим, ветки на repo1 - сразу же изменялась и ветка на repo2. Нюанс: аккаунты, которые пушили в ту или другую ветку должны переноситься.

Кажется задача не сложная: отслеживание можно релизовать через webhook-и github-а (именно на github-е будут репозитории), переносить аккаунты можно через git config –local user.email и «всё в шоколаде», но:

bug1: Я первоначально думал merge проводить над ветками, потом понял, что удаление файлов проходить не будет, то есть если я удалю foo.cpp на repo1, то аналогичный файл на repo2, созданный немного раньше, не удалиться из-за merge. Может у вас есть какая-нибудь идея как реализовать это без merge, чтобы не переносить файлы из одной директории в другую и потом git add . && git commit -am ?

bug2: Я всё же написал скрипт, но в ходе использования понял, что на repo, который должен будет автоматически обновиться, совершается один лишний коммит, при merge и перед ним, т.к иначе merge срывается, что не подходит для самой цели программы, которую я опустил. Может это можно сделать иначе?

Цель поста: если у вас уже был такой опыт или есть идея, как исправить баги, то подскажите.

P.S Я раньше никогда не писал посты на каких-либо форумах, надеюсь всё более чем понятно, я бы мог ещё расписать и цель, и что, и за сколько, но это выходит за цель поста.



Последнее исправление: xaizek (всего исправлений: 2)

То, что ты делаешь это же push, не? Но лорчую комментатора выше, может есть способ получше.

goingUp ★★★★★
()
Ответ на: комментарий от untitl3d

Идея в том, чтобы разделить репозитории на «чистые», с минимальным количеством лишних веток, и «грязные», с любым количеством лишних веток. К «грязным» можно подпускать начинающих разработчиков, а к «чистым» уже профессионалов, насколько было написано в ТЗ.

Все мои инструменты: git (именно утилита, в коде приходилось уходить на мультипроцессоринг), github-api. До другого не дошёл.

Drandulet
() автор топика
Ответ на: комментарий от goingUp

У меня 2 репозитория: repo1 и repo2. @ Через webhook мне приходит уведомление о пуше в repo1

@ Я перехожу на локальный repo1

@ git pull

@ git remote add foo repo2

@ git push -u repo2 master:master

@ git remote remove foo

Вы это имеете ввиду? Если сработает круто, но разве не должно быть конфликтов с коммитами?

Drandulet
() автор топика
Ответ на: комментарий от Drandulet

Вы это имеете ввиду? Если сработает круто, но разве не должно быть конфликтов с коммитами?

Да. При вашей схеме работы конфликты неизбежны и ее надо менять) Но если делать пуши быстро после коммита, то конфликтов будет минимум.

goingUp ★★★★★
()
Ответ на: комментарий от goingUp

Мм, я вас понял и поменял тут немного.

Суть в том, что в самом начале с помощью pull-ов репы объединяются под одним локальным репозиторием, а после, при появлении уведомления о push-е в один из них - мы делаем pull и пушим в каждый реп, тут и коммиты сохраняются, и авторы, и всё-всё работает без ошибок, т.к сводится к pull и push.. Я проверил, всё работает.

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

Drandulet
() автор топика
Ответ на: комментарий от Drandulet

всё-всё работает без ошибок, т.к сводится к pull и push

Если «профессионалы» и «любители» одновременно поменяют один и тот же код, все равно будет конфликт.

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

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

goingUp ★★★★★
()
Ответ на: комментарий от Drandulet

Причина всех страданий это желания. Извращенные желания вызывают еще большие страдания.

минимальным количеством лишних веток

А лишние ветки чем мешают? :)

urxvt ★★★★★
()
Ответ на: комментарий от Drandulet

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

В том же Github это делается так:
* запрещают напрямую комитить в master (разрешается только через PR) — новички уже его не сломают
* перед слиянием PR в master требуется подтверждение кого-то из группы старичков

В итоге, новички могут создавать сколько-угодно веток (собственно для этого Гит и придумали) и стабильный master не сломают.

urxvt ★★★★★
()
Последнее исправление: urxvt (всего исправлений: 1)
Ответ на: комментарий от urxvt

Причина всех страданий это желания. Извращенные желания вызывают еще большие страдания.

Чтож тут поделать
Drandulet
() автор топика

Но всё же, я сделал тут какой-то скрипт, юзаю те же webhook и мультипроцессоринг, разве что пришлось изменить алгоритм работы.

Задачу можно считать решённой.

Спасибо за ваши комментарии!

Drandulet
() автор топика

«грязные», с любым количеством лишних веток

Пусть локально хоть стопицот веток создают, но пушат в строго определенные. Тут надо workflow или порядок работы с репозиториями прописать.

LongLiveUbuntu ★★★★★
()
Ответ на: комментарий от Drandulet

У нас такая херня была. В итоге непонятно- ветка еще в работе или можно выкидывать, постоянно конфликты, постоянно проблемы на ровном месте.

LongLiveUbuntu ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.