Проблемы с использованием одной папки git clone несколькими пользователями (окнами)?

Есть множество вопросов о совместном использовании папки git clone между несколькими пользователями, но, похоже, все для Linux (две ссылки приведены ниже). У меня такая же проблема, но для машины с Windows. Я надеюсь, что другие сделали это и получили рекомендуемый процесс.

Была надежда, что, поскольку у каждого пользователя есть собственный логин, у каждого будут свои учетные данные в диспетчере учетных данных Windows и собственная папка .ssh для ключей. Этого было бы достаточно, если бы каждый пользователь клонировал свою собственную версию репозитория для выполнения работы.

Что, однако, произойдет, если пользователь A клонирует каталог и выходит из системы, затем пользователь B входит в систему и пытается выполнить извлечение (для извлечения / слияния новых коммитов с пульта дистанционного управления), внести некоторые изменения и отправить новое изменение в пульт? Я бы хотел, чтобы это было успешным, с отдельной информацией о фиксации (информацией об авторе) для каждого пользователя.

Полезен ли --shared в этом случае? Есть ли способ применить глобальную конфигурацию git (имя / адрес электронной почты, которые будут разными для каждого входа в систему) по сравнению с информацией пользователя A (из исходного клона git в .git / config)? Это вообще возможно?

[править]
Добавление подробностей о сценарии использования. Об этом просили в комментариях.

У меня есть процесс сборки, который я довольно много автоматизировал с помощью скриптов. Для этого требуется правильно настроенный компьютер (несколько компиляторов, патчей и т. Д.) И несколько сторонних компонентов. Сборка включает в себя клонирование ~ 50 различных репозиториев, создание файлов make, make, make install (в определенном порядке в репозиториях), а затем выполнение дополнительных шагов упаковки / сборки. Это занимает часы, умноженные на несколько конфигураций сборки для чистой сборки. Чтобы ускорить процесс, сценарии будут генерировать эвристику, которая определяет, нужно ли выполнять шаги в цепочке (т. Е. Make может определить, нужно ли его запускать повторно, но это не помогает с make install или последующими шагами). Конечный результат - установщик. У нас есть полные перестройки с интервалом ~ 6 месяцев для новых версий (где мы можем обновлять конфигурацию (компилятор и т. Д.)), И у нас есть второстепенные выпуски, которые включают обновление и / или настройку подмножества репозиториев (push и pull). Сценарии также могут нуждаться в модификации, они находятся в собственном репозитории git.

Хотя сценарий делает задачу чем-то, что я могу выполнить, не занимая слишком много полосы пропускания, я хотел бы позволить нескольким другим членам команды выполнить эти шаги. В этом заключается дилемма. «Простое» решение - иметь общую учетную запись, но это на самом деле усложняет работу с git (ключи ssh, токены github) и имеет много других недостатков. Было бы «лучше» хранить несколько экземпляров этой среды, по одному для каждого разработчика, но это создает новую проблему синхронизации машинной среды. Это также означает, что один разработчик не может «помочь» другим, запустив для них длительные процессы (они должны запускаться каждой отдельной учетной записью / машиной). Лучшим компромиссом казалось разрешение нескольким разработчикам использовать разные учетные записи, но работать на одном компьютере и в рамках одной и той же структуры папок.

По сути, настоящая проблема - это среда сборки. Хотя есть способы решить эту проблему (шеф-повар, репозитории артефактов и т. Д. И т. Д.), Ручная настройка среды сборки и совместное использование репозиториев git («исключительное» использование git) казалось разумным в этом случае, если это возможно. Таким образом, вопрос.
[/ edit]

[1] Git - несколько пользователи, использующие один и тот же рабочий каталог: проблемы с разрешениями в метафайлах .git

[2] https://serverfault.com/questions/26954/how-do-i-share-a-git-repository-with-multiple-users-on-a-machine


person Brett Stottlemyer    schedule 20.04.2018    source источник
comment
Почему, ну почему ты хочешь это сделать? Что плохого в каждом клоне?   -  person Biffen    schedule 20.04.2018
comment
Подавляющее большинство работы выполняется, когда каждый разработчик работает со своими собственными клонами в своей собственной среде. У нас есть особые крайние случаи, когда это было бы чрезвычайно полезно.   -  person Brett Stottlemyer    schedule 20.04.2018
comment
Есть ли причина, по которой вопросы о Linux действительны, но версия для Windows отклонена?   -  person Brett Stottlemyer    schedule 20.04.2018
comment
Во-первых, оба эти вопроса касаются ограниченного использования общего репо; первый даже наклоняется назад, чтобы сказать, что я знаю, что git используется не так, но вот что мы делаем. Во-вторых, при этом нет причин, по которым они действительны, в то время как ваш голос отклоняется; в том, что они тоже должны были быть отвергнуты.   -  person Mark Adelsberger    schedule 20.04.2018
comment
@MarkAdelsberger Спасибо за разъяснения. Но в этом ли смысл ТАК? Получены ответы и проголосованы только вопросы о передовой практике? Куда обращаться за помощью с исключениями?   -  person Brett Stottlemyer    schedule 20.04.2018
comment
Меня беспокоит, что если я объясню свой вариант использования, обратная связь будет сосредоточена на том, является ли этот вариант использования допустимым. И это не поможет другим, у которых могут быть похожие (но не совсем одинаковые) варианты использования. Если ответ таков, что никто никогда и ни при каких мыслимых обстоятельствах не должен делать то, о чем я прошу, я был бы признателен за это в качестве ответа с объяснением.   -  person Brett Stottlemyer    schedule 20.04.2018
comment
Я не знаю, что тебе сказать. Как я уже сказал, я бы отклонил любой вопрос о том, что несколько пользователей совместно используют дерево работы, не потому, что это не лучшая практика, а потому, что это явно работает против модели инструмента. Спросите, как лучше всего использовать молоток для ввинчивания винта, вы, скорее всего, получите отрицательный голос. Для протокола: я не голосовал по вашему вопросу, а это значит, что по крайней мере 6 человек думают так же.   -  person Mark Adelsberger    schedule 20.04.2018
comment
Может ли объяснение явно работает против модели инструмента еще немного? Я имею в виду это искренне, так как я не поверил, что это было так, когда задавал свой вопрос. --shared - официально поддерживаемая часть инструмента, не так ли? Это подразумевает некоторый уровень признания моих потребностей, по крайней мере, для меня.   -  person Brett Stottlemyer    schedule 20.04.2018
comment
--shared - это обмен файлами между копиями репозитория в одной локальной системе, он не имеет ничего общего с совместным использованием файлов с несколькими людьми. Идея Git заключается в том, что каждый разработчик работает над своей собственной копией, а затем отправляет изменения обратно в родительские репозитории. Что касается нежелания объяснять свой вариант использования, похоже, вы уже знаете, что это плохой вариант использования. Объяснение этого может привести к тому, что люди предложат лучший способ справиться с тем, что вы пытаетесь сделать.   -  person Ilion    schedule 21.04.2018


Ответы (1)


То, что вы здесь делаете, буквально противоречит и противоречит самой сути распределенной системы контроля версий. Вы и ваша команда ищете программное обеспечение, которое поможет управлять вашим репозиторием и позволит вам и вашей команде легко клонировать и публиковать в нем изменения.

В зависимости от того, что вы ищете, вы можете использовать:

  • Gitolite бесплатен, и его можно более просто настроить с разрешениями.
  • GitHub всегда существует в качестве опции; вы можете купить рабочее пространство частного репозитория и разрешить всем вашим разработчикам публиковать в нем публикации.

Ваш вариант использования описывает потребность в системе сборки (например, Jenkins), но это не имеет отношения к основной цели вашего главный вопрос.

person Makoto    schedule 22.04.2018
comment
Я видел, как сказано, что задавать хорошие вопросы - это искусство, и я думаю, что я нахожусь на уровне рисования пальцами. Какая часть моего вопроса привела вас к такому выводу? У меня есть много клонированных репозиториев для этого процесса с удаленных github и gerrit. Все изменения обновлены. Проблема в том, что клонирование, построение и особенно настройка среды сложны. Учитывая связанные решения для Linux, я спрашивал, есть ли что-то сопоставимое для моей среды. Прогнозы по другим вопросам заставили меня подумать, что попробовать это было правильно. - person Brett Stottlemyer; 22.04.2018
comment
Ваш первоначальный вопрос (без контекста) относился к базовому процессу клонирования, фиксации и публикации в удаленном репозитории Git. Похоже, вам нужно что-то для управления этим. Если ваш вопрос касается исключительно процесса сборки, я рекомендую вам удалить этот вопрос и задать его. Но прежде чем вы это сделаете, я бы посоветовал вам изучить инструменты автоматизации сборки, такие как Jenkins, которые, похоже, будут делать именно то, что вы ищете. - person Makoto; 22.04.2018
comment
Вы явно отнесли это к категории xy-проблем (что может быть подходящим). Но в какой-то момент прагматизм не вступает в игру? Разве не разумно хотя бы спрашивать об использовании git неортодоксальным образом вместо того, чтобы делать сброс рабочего процесса сборки? К вашему сведению, мы уже используем jenkins, но я утверждаю, что вы не можете автоматизировать то, что не можете запустить вручную, поэтому сначала должна быть ручная сборка. Это то, для чего эта среда, последние настройки, чтобы убедиться, что интеграция всех частей работает правильно. - person Brett Stottlemyer; 22.04.2018