Как поделиться веткой функции git (или темы) с несколькими разработчиками

Я следую описанному рабочему процессу здесь, поскольку я нашел много ссылок, указывающих на эту страницу как на хороший рабочий процесс. Как упоминалось в статье, ветви "feature" совместно используются разработчиками, но не переходят в центральный репозиторий.

предположим, разработчик " A " запускает новую ветку функций с git checkout -b newfeature develop. Теперь предположим, что разработчик " B " также должен работать над этой функцией. Это моя проблема.

Что Я сделал:

  1. разработчик " B " добавляет машину разработчика A в качестве удаленного
  2. разработчик" B " работает git branch remoteA/newfeature
  3. разработчик " B " работает в этой ветке, совершает свою работу и возвращает изменения в remoteA.

Шаг 3 не работает, прямо сейчас. Я получаю сообщение:

remote: ошибка: по умолчанию обновление текущей ветви в не-голой репозиторий запрещен, потому что он сделает индекс и дерево работы несовместимо с тем, что вы нажали, и потребует "git reset-hard" чтобы сопоставить дерево работы с головой.

remote: ошибка: вы можете установить ' receive.конфигурации denyCurrentBranch' переменная "игнорировать" или "предупреждать" в удаленном репозитории, чтобы разрешить толкать в свою текущую ветвь; однако, это не рекомендуется если вы не договорились обновить его дерево работы, чтобы соответствовать тому, что вы нажали каким-то другим способом.

remote: ошибка: подавить это сообщение и все еще сохранить по умолчанию поведение, набор прием.переменная конфигурации denyCurrentBranch для 'отказать'.

Я уже поставил sharedRepository = true, но это не помогло.

у меня есть 2 вопроса:

  1. как правильно обмениваться ветвями функций между разработчиками?
  2. как я могу отодвинуть изменения в репозитории разработчика B в исходный репозиторий разработчика A?
7
feature-branch git git-branch remote-branch

2 ответов

вы можете нажать, чтобы не голые РЕПО. То, что вы не можете сделать, это нажать на не-голое РЕПО, у которого есть ветвь, которую вы нажимаете, чтобы проверить. Причина этого должна иметь смысл. Изменение файлов, над которыми, возможно, работает кто-то другой, было бы неправильным.

обычно вы хотите нажать на master или какую-либо другую общую общую ветвь. Чтобы избежать этого конфликта, владелец удаленного не-голого РЕПО должен работать на локальном филиале или, по крайней мере, на каком-то другом филиале. Затем вы можете нажать на общую ветку.

использовать ваш пример:

  1. разработчик " B " добавляет машину разработчика A в качестве удаленного
  2. разработчик" B " работает git branch remoteA/newfeature
    1. разработчик " A " работает в локальной ветке. git checkout -b work-newfeature
  3. разработчик " B " работает в этой ветке, совершает свою работу и возвращает изменения в remoteA.
    1. разработчик" A " rebases, чтобы получить новую работу: git rebase newfeature
5

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

Как только ветка функции на пульте больше не нужна, вы можете просто удалить ее, выполнив 

git push <server> :branch

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

Если возможно, вы также можете использовать модель GitHub, где есть один центральный репозиторий на сервере (благословенное основное РЕПО). И помимо этого основного репозитория у каждого разработчика есть "вилка" этого репозитория, где он имеет полный доступ к фиксации и может толкать ветви по своему вкусу.

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

описание модели GitHub можно найти здесь: http://www.eqqon.com/index.php/Collaborative_Github_Workflow

обновление: как отметил комментатор, это хорошая ссылка для начала работы с рабочим процессом централизованной функции:http://nvie.com/posts/a-successful-git-branching-model/

обновление 2: в расширьте свой второй вопрос:

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

причиной этого изменения было то, что всякий раз, когда вы нажимаете на свой репозиторий коллег (который в настоящее время работая над чем - то) - вы манипулируете хранилищем прямо у него под носом. Поэтому он проверяет версию featureA-1 .. начинать работу. . затем вы нажимаете featureA-2 на его РЕПО, и когда он хочет совершить, он сталкивается с проблемами, потому что ветвь, в которой он был, продвинулась на один коммит, который он не видел во время разработки.

потому что это довольно разрушительно-большинство людей приняли понятие локальных репозиториев git (те, где вы активно работаете) должны быть частная пока у вас есть публичное git-repo (вилки), где вы получаете и разделяете изменения. Таким образом, вы никогда не будете прерваны кем-либо еще во время вашей работы (это вся идея децентрализованной модели в любом случае) и можете только включать изменения, которые вы хотите иметь. (Никто не может подтолкнуть что-то к вашей текущей работе).

7