#git #workflow #git-merge
#git #рабочий процесс #git-слияние
Вопрос:
На данный момент я не могу использовать сервер git, поэтому я использую одну из моих любимых функций git, которая превращает любой каталог на моем компьютере в репозиторий git (просто git init вещь).
Я использовал для этого, потому что я был единственным, кто писал код, и я мог отслеживать свои собственные вещи. Сейчас все немного изменилось, и я работаю с небольшой командой. Однако некоторые другие вещи не изменились, и у меня по-прежнему не может быть сервера git, поэтому локальные репозитории по-прежнему являются единственным вариантом.
Наиболее простой процедурой было распространение кода среди других пользователей в виде архивирования моего репозитория и отправки его повторно. Когда они заканчивают, они отправляют мне это обратно, и я заменяю исходное репозиторий. Работает вроде как нормально, поскольку у нас почти никогда два человека не работают в одном репозитории из-за того, как организованы проекты.
Теперь я хотел бы сделать что-то более последовательное.. например, объединение всего, что они присылают мне, в мое локальное хранилище. Этот пример позволил бы мне в конечном итоге заставить двух человек работать в одном репозитории (или, возможно, его подмножествах).
Я читал о сценариях исправления git. Но, честно говоря, я чувствовал себя не очень комфортно с решением. Во-первых, потому что в моих первоначальных экспериментах это сработало не сразу (да, я знаю, это просто вопрос лучшего понимания, но все же не такой интуитивный, как остальная часть git), а во-вторых, потому что мои репозитории также будут содержать двоичные файлы, которыми мне также нужно управлять.. не уверен, что исправления могут справиться с этим :/
Какую процедуру вы, ребята, предложили бы для организации этого? есть ли команда, которая позволила бы мне объединить репозитории так, как я описываю?
Спасибо!
f.
Комментарии:
1. На какой операционной системе все работают?
2. хе-хе-хе, все то: P время от времени у нас появляются Linux, Windows и Mac.. хотя в основном Windows. почему?
3. Что ж, если бы у вас была возможность подключаться по SSH к компьютерам друг друга в ограниченной оболочке git, это действительно упростило бы отправку / извлечение данных непосредственно друг от друга. Но я полагаю, что этот сценарий очень сложно реализовать с Windows.
4. На самом деле это был самый близкий вызов, который я получил. Я пытался туннелировать все через Интернет и putty. Но для каждого клиента потребовалось много настроек, и это было немного неумело : (
5. Спасибо за лучшее название Abizern!
Ответ №1:
Как насчет отправки друг другу путей?
git format-patch и git am может соответствовать вашим потребностям. Я использовал его в прошлом, и он работает достаточно хорошо для отправки нечастых изменений.
Комментарии:
1. привет! На самом деле у меня нет огромного репозитория. На самом деле у меня есть много небольших репозиториев, специфичных для разрабатываемой истории.. ну, вроде того. таким образом управлять определенно проще, и это позволяет мне делать то, что я сказал выше. Но на данный момент я хотел бы использовать управляющие ячейки большего размера..
2. Поскольку я комментирую исправления, меня это не очень устраивает… кроме того, как они будут обрабатывать двоичные файлы?
3. Вот почему вы используете format-patch — он обрабатывает все это за вас. Это превращает каждый коммит в отдельный патч и ссылается на коммит, на котором он основан. таким образом вы можете воссоздать удаленный репозиторий в своем собственном репозитории.
4. Хм. интересно… Я проверю выход. Спасибо!
5. Хороший материал. двоичный файл —binary довольно близок. Я все еще провожу некоторые тесты, но кажется довольно крутым
Ответ №2:
Если у вас есть какой-то способ настроить общий каталог, даже если он находится на чьем-то компьютере, вы можете сделать git init там и попросить всех добавить это хранилище в качестве удаленного. Это не так чисто, как использование gitolite или чего-то другого по SSH, но должно работать просто отлично.
Комментарии:
1. meh.. я знаю, это очень раздражает, но ответ отрицательный. мы — смешанная команда консультантов. некоторые из нас находятся в правильном домене, некоторые другие находятся в офисе, но подключены через VPN, а некоторые другие даже не находятся в одной сети : (
2. Это очень плохо; Я тебе сочувствую. В вашем сценарии, вероятно, было бы проще всего оплатить учетную запись GitHub частными репозиториями.
3. лол, ты не поверишь, но даже gitbut не является опцией. Я тоже попробовал это, просто чтобы обнаружить, что у нас очень защищенный прокси, для обхода которого мне потребовалось невероятное количество настроек (хотя очень интересно, как вы можете это сделать, установив свой собственный локальный прокси-сервер для аутентификации …) ну, короче говоря, меня, вероятно, казнили бы, если бы кто-то проверял сетевую безопасность, пока я это делал : (
Ответ №3:
Хорошая особенность распределенного контроля версий в том, что вам не нужен только один сервер, к которому все могут постоянно обращаться. У вас может быть столько серверов, сколько вам нужно. Вы можете настроить сервер или общий каталог внутри брандмауэра компании для всех, у кого есть доступ к использованию, и пусть каждый из ваших сторонних сотрудников настроит свой собственный локальный ssh или что-то, с чего вы можете отправлять и извлекать данные по мере необходимости.
Если вы хотите продолжить рассылку репозиториев в zip-файлах, все, что вам нужно сделать, это вместо замены вашего основного локального репозитория распаковать его в отдельную папку, а затем сделать git pull из этой папки в ваше основное репозиторий, чтобы объединить его. Не так эффективно с точки зрения пропускной способности, как git format-patch , но немного более привычно для вашего конкретного рабочего процесса.