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

Question

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

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

Что я сделал:

1. разработчик «B» добавляет машину Разработчику как удаленный
2. разработчиков «B» работает git branch remoteA/newfeature
3. разработчик «B» работает в этой ветке, совершать свою работу и толкает изменения обратно на remoteA.

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

remote: error: By default, updating the current branch in a non-bare repository is denied, because it will make the index and work tree inconsistent with what you pushed, and will require 'git reset --hard' to match the work tree to HEAD.

remote: error: You can set 'receive.denyCurrentBranch' configuration variable to 'ignore' or 'warn' in the remote repository to allow pushing into its current branch; however, this is not recommended unless you arranged to update its work tree to match what you pushed in some other way.

remote: error: To squelch this message and still keep the default behaviour, set receive.denyCurrentBranch' configuration variable to 'refuse'.

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

У меня 2 вопроса:

1. , что правильный способ поделиться полнометражной ветвью между разработчиками?
2. Как я могу отменить изменения в репозитории разработчика B для оригинального разработчика разработчика?

Answer 1

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

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

Чтобы использовать пример:

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

Answer 2

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

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

git push <server> :branch 

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

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

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

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

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

Update2: для того, чтобы расширить ваш второй вопрос:

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

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

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