Как работать с Git в параллельной среде

Question

Итак, мы переходим от CVSNT к Perforce или Git, и я изучаю их функции в последние недели, и для меня ясно, что Perforce на самом деле немного более похожее, поскольку оно централизовано.

Git кажется быстрым, но мы являемся компанией, где все разработчики остаются в той же комнате, несмотря на то, что есть более 100 разработчиков, до сих пор все компьютеры, подключенные к серверу CVSNT ...

По этой причине, я не могу понять, как я мог бы адаптировать Git к работе, а также Perforce сделал бы.

Для того, чтобы быть в автономном режиме, когда один клонит репозиторий Git, он скопирует историю и все об этом репозитории, чтобы он работал в автономном режиме , однако, работая одновременно, кажется странным, что у вас есть история локального файла, например ...

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

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

Может ли кто-нибудь объяснить мне лучше, как на самом деле Git может работать одновременно? без необходимости знать, когда другой фактически нажимает на сервер и т. д.?

Другое дело, я не мог найти хороший Граф ревизий на Git, я нашел в Tortoise Git, но его больше похож на ветви графа, чем графа о пересмотре в ..

Answer 1

Обычный рабочий процесс с DVCS, как git, не полагается на вас, угадывая, кто-то нажал или нет.

Вы просто нажимаете, и если кто-то еще нажал перед вами, your action will be, by default, denied (как бы не «перемотка вперед»).

Тогда тянешь:

• в идеале, вы git pull --rebase для того, чтобы повторить работу на вершине самых последних фиксаций этой отрасли).
• проверить, если Everthing еще работает
• вы оттеснить

Что касается пересмотра графика, simple git log --graph может помочь вам увидеть, что происходит (я like this alias).

Answer 2

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

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

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

Answer 3

Обычный сценарий (очень упрощенным) имеет следующий вид:

1. проверяет разработчик из главной ветви к своей машине (AKA «ствол» в SVN, место с самыми последними фиксаций).
2. Он отворачивается от него и создает локальную ветвь.
3. В этом местном отделении он создает необходимые коммиты.
4. Он создает «тянущий запрос» из этой ветви (другими словами, просит, чтобы он был объединен с мастером).
5. Тот, кто отвечает за ведущую ветку, рассматривает изменения и объединяет их в мастера.

Основная ветка может измениться с момента разветвления разработчика, но если новые изменения не пересекают изменения, внесенные в главную ветвь, слияние выполняется автоматически. Таким образом, главная ветвь блокируется только в течение незначительного времени, когда git выполняет слияние.

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

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

Очень хороший процесс разработки с Git описан в Git Flow.