#git #gitlab #bitbucket
#git #gitlab #bitbucket
Вопрос:
У меня забавная ситуация, когда я работаю с людьми из другого учреждения. У нас обоих есть требования к брандмауэру, которым мы должны соответствовать. У каждого из нас есть свои собственные серверы git. Чтобы сделать работу с одним и тем же репозиторием максимально плавной с обеих сторон, каждый из нас использует свой собственный сервер с копией одного и того же репозитория. Мы обнаружили, что сложно синхронизировать репозитории друг с другом и что нам постоянно приходится выполнять дополнительную работу, чтобы избежать беспорядочных конфликтов.
Есть ли хороший способ автоматически синхронизировать наши два репозитория? Я подумал о создании перехвата перед получением, который проверяет другой сервер на наличие изменений перед проверкой на наличие конфликтов.
Ответ №1:
Предотвращение беспорядочных конфликтов является одним из принципов, на которых был разработан git.
Большинство запутанных конфликтов, разрешаемых в рабочем процессе git, были бы кошмаром без хорошего инструмента VCS, для начала. Может быть, что-то в том, как вы используете git, делает процесс неудобным?
Если все часто коммитят и также часто извлекают удаленные изменения для интеграции, у вас в принципе не так много беспорядочных конфликтов. Что в вашем контексте делает это особенно хуже или неуправляемым?
Если есть веские причины использовать другой тип инструмента, централизованный, такой как SVN или P4, да, стоит подумать о переключении. Но не забудьте сначала проверить, как вы используете git, это может избавить от многих проблем.
Комментарии:
1. Проблема, с которой мы сталкиваемся, заключается в том, что коммиты недостаточно часто передаются с одного пульта на другой. Для синхронизации двух репозиториев требуются дополнительные шаги, а поскольку это ручной процесс, который не требуется для репозиториев, расположенных только на одном пульте, пользователи, как правило, забывают дополнительные шаги. Чего бы я хотел, так это вот чего: когда изменения передаются на удаленный A, удаленный A должен сначала выполнить выборку с удаленного B, затем проверить push на наличие конфликтов, прежде чем принимать push. Это позволило бы выявлять конфликты как можно раньше и как можно чаще, не требуя от пользователей запоминания дополнительных шагов.
2. @Vorticity Мне кажется, что вы пытаетесь скопировать характеристики централизованного VCS с децентрализованным. Но я позволю более опытным пользователям подтвердить.
3. Я думаю, что вы, вероятно, правы здесь. У нас довольно неприятная настройка. Спасибо за комментарии!