LINUX.ORG.RU

Git - несколько вопросов


0

0

Начал пользовать, но кое-что не догоняю:

1. Разработчики A и B берут в доработку базовый проект P. Далее начинают его
курочить, причем каждый по-своему (свои куски), т.е. что-то свое добавлять,
удалять. Как лучше синхронизировать, поддерживать в актуальном состоянии
проект между ними ? Они обмениваются только файлами с исправлениями.

2. Правильно ли я понял, что ветка и merge нужны только для добавления нового
функционала ? Если изменения более существенны, то ведется отдельная ветка ?


> Они обмениваются только файлами с исправлениями.

чё?

anonymous
()

1. Лучше иметь общий репозиторий в сети, работать в локальных копиях, изменения пушить на сервер, и с него же получать чужие изменения. Можно обойтись и без сетевого репозитория, но чейнджи между репозиториями придётся всё равно передавать как-то.

2. Типа того.

mv ★★★★★
()

>Как лучше синхронизировать, поддерживать в актуальном состоянии
проект между ними ?
Лучше всего держать общий репозиторий

Правильно ли я понял, что ветка и merge нужны только для добавления нового функционала ?

Обычно делают так: есть основная ветвь (master) и другие (для тестируемого функционала). Когда тестирование закончено, ветвь объединяется с master. Т.е. в master всегда рабочая версия, а в ветках разрабатываемая.

Можешь почитать это: http://habrahabr.ru/blogs/Git/75990/ (но там достаточно сложно)

Они обмениваются только файлами с исправлениями.

Зачем им обмениваться? Пусть делают пуш в общий репозиторий.

xorik ★★★★★
()
Ответ на: комментарий от mv

> Лучше иметь общий репозиторий в сети

К сожалению, иногда такой возможности нет, только мыло.

но чейнджи между репозиториями придётся всё равно передавать как-то.


Ну по мылу, например. Допустим разраб А отправил измененный файл P1.cpp B.
Как В применить изменения ? Я пробовал так:

на основе master ветки
git branch t1
git checkout t1
Далее, копированием заменяю свой P1.cpp на присланный.
git checkout master
git merge t1

И, конфликт, в общем понятно почему, т.к. присланный P1.cpp имеет как
добавленные, так и удаленные куски. Как правильно синкануться ?

drZlo
() автор топика
Ответ на: комментарий от xorik

> Зачем им обмениваться? Пусть делают пуш в общий репозиторий.

Опять же, бывает, что это не всегда возможно (реально :)

drZlo
() автор топика
Ответ на: комментарий от drZlo

> Допустим разраб А отправил измененный файл P1.cpp B.

Ипануццо. А в этом вашем гите нет чего-то вроде Mercurial'овских bundle?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>А в этом вашем гите нет чего-то вроде Mercurial'овских bundle?

Есть, так и называются: git bundle.

dmitry_vk ★★★
()
Ответ на: комментарий от drZlo

Бесплатные git-хостинги уже отменили?

xorik ★★★★★
()
Ответ на: комментарий от tailgunner

Ипануццо. А в этом вашем гите нет чего-то вроде Mercurial'овских bundle?

Есть, есть.

mv ★★★★★
()

2. вам это потом мержить, так что лучше подумать дважды

yltsrc
()

>Как лучше синхронизировать, поддерживать в актуальном состоянии проект между ними ? Они обмениваются только файлами с исправлениями.

Настроить у себя dyndns и делать hg pull

anonymous
()

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

Первый — это git format-patch/git am. Я надеюсь, вы с разработчиком B именно этим и пользовались при обмене письмами с патчами?

Второй — git bundle. Совершенно изумительный способ. Автоматизирует большинство рутинных операций.

Независимо от способа обмена есть несколько стратегий для формирования изменений сделанных разработчиком.

1. Есть мастер бранч. У каждого он должен быть в идентичном состоянии. Вся разработка ведется в отдельных ветках. Например branchA, branchB, для каждого разработчика. После удачного обмена патчами ветки сливаются в мастер.

- «A» подевелопил в branchA, ему надо передать изменения «B»

- делается git bundle create file.bundle master..branchA или git format-patch master..branchA

- полученный результат передается «B»

- он у себя, в случае бандла, просто делает git pull в master. Или git am, если изменения были сформированы через git format-patch.

- далее «B» мержит master в branchB.

- «B» говорит «A», что все ок, патч принят и A тогда делает слияние branchA в master.

На данном этапе у обоих одинаковый master, на базе которого и будут формироваться дальнейшие дельты изменений.

2. Если проект простой с малым количеством изменений. То можно обойтись только мастер веткой. А в качестве базы для формирования дельты использовать тэги, которые передвигаются на мастер после удачного обмена патчами. Такой подход описан в git bundle --help. Ничто не мешает его использовать с git format-patch.

Удачи.

baverman ★★★
()
Ответ на: комментарий от baverman

Спасибо. Да, bundle круто. А что делать, если в ветке (не мастер) поиспровлял
ошибки, т.е. кое чего удалил, заменил. Тогда с мастер будет конфликт и
просто смержить не получится. Неужели постоянно руками править ?

drZlo
() автор топика
Ответ на: комментарий от drZlo

А что делать, если в ветке (не мастер) поиспровлял ошибки, т.е. кое чего удалил, заменил. Тогда с мастер будет конфликт и просто смержить не получится.

Не обязательно. На практике конфликты достаточно редки. Большинство ситуаций разруливается автоматически. К тому же есть визуальные средства для слияния. Тот же meld, вызываемый через git mergetool. Но повторюсь, конфликты достаточно редкая вещь. Если вы конечно не пилите одну и ту же функцию. Чтобы слияние проходило глаже, могу порекомендовать обмениваться патчами как можно чаще.

baverman ★★★
()
Ответ на: комментарий от drZlo

мержить вручную придется когда разные разработчики правят одно и то же

yltsrc
()
Ответ на: комментарий от baverman

>Не слушай товарищей с SVNом головного мозга, говорящих про единый репозиторий
ОЛОЛО, а теперь сравни:

1. git push mybranch

2.

«A» подевелопил в branchA, ему надо передать изменения «B»

- делается git bundle create file.bundle master..branchA или git format-patch master..branchA


- полученный результат передается «B»


- он у себя, в случае бандла, просто делает git pull в master. Или git am, если изменения были сформированы через git format-patch.


- далее «B» мержит master в branchB.


- «B» говорит «A», что все ок, патч принят и A тогда делает слияние branchA в master.

xorik ★★★★★
()
Ответ на: комментарий от xorik

ОЛОЛО, а теперь сравни:

1. git push mybranch

Эдуард Хиль, перелогинтесь.

ТС не раз указал на невозможность/нежелание иметь общий репозиторий. Что ж вы как заведенные: git push, git push, git push.

Ко многим open source проектам у тебя есть доступ на push? Никто почему-то не парится и спокойненько отправляют патчи мейнтейнеру.

baverman ★★★
()
Ответ на: комментарий от baverman

> - он у себя, в случае бандла, просто делает git pull в master. Или git am, если изменения были сформированы через git format-patch.

А обязательно в master? Можно в другой бранч? Например я хочу что бы B потестил мой branchA, но не сливал его с master.

Eshkin_kot ★★
()
Ответ на: комментарий от Eshkin_kot

А обязательно в master? Можно в другой бранч? Например я хочу что бы B потестил мой branchA, но не сливал его с master.

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

baverman ★★★
()
Ответ на: комментарий от baverman

> На практике конфликты достаточно редки. Большинство ситуаций разруливается автоматически.

А если два разработчика сделали в одном файле изменение, один в начале файла, другой в конце файла? Это разрулится автоматически? Если да, то какая последовательность комманд должна быть чтобы это было автоматом? git push не прокатил, я это тестировал... Надо часто обмениваться патчами в работе над одним проектом...

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

git push не прокатил, я это тестировал...

А git push и не делает слияние на другой стороне. Поэтому и не прокатил.

Cначала надо сделать git pull, чтобы произошел автоматический мержинг, а только потом git push.

baverman ★★★
()
Ответ на: комментарий от baverman

> Cначала надо сделать git pull, чтобы произошел автоматический мержинг, а только потом git push.

Честно, не знал что такой порядок должен быть... Спасиб :) ЗЫ А что если за миллисекунду до моего push но после моего pull произошел большой push от другого? ;) race condition? :)

I-Love-Microsoft ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.