Самый простой способ поделиться ветвями объектов - просто перенести их в центральное хранилище, чтобы любой мог их извлечь.Таким образом, вы можете просто использовать уже имеющуюся инфраструктуру для своего основного хранилища и легко обмениваться кодом.
Когда ветвь функций на пульте больше не нужна, вы можете просто удалить ее, выполнив
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 (те, над которыми вы активно работаете) должно быть private , в то время как у вас есть публичный git-репо ( fork ), где вы получаете и делитесь изменениями.Таким образом, вы никогда не будете прерваны кем-то еще во время вашей работы (такова вся идея децентрализованной модели в любом случае), и вы можете включать только те изменения, которые вы хотите внести.(Никто не может что-то толкнуть на вашу текущую работу).