Я думаю, и я могу ошибаться, что одна из вещей, которые больше всего неправильно понимают в git, это его распределенная природа. Это сильно отличает способ подрывной работы, хотя вы можете имитировать поведение SVN, если хотите. Проблема в значительной степени подойдет любому рабочему процессу, который хорош, но также вводит в заблуждение.
Если я правильно понимаю разработку ядра (я сосредоточусь на этом), у каждого есть свой собственный git-репозиторий для разработки ядра. Существует один репозиторий, linux-2.6.git, за которым следит Торвальдс, который действует как репозиторий релизов. Люди клонируют отсюда, если они хотят начать разработку функции против ветки "release".
Другие репозитории занимаются разработкой. Идея состоит в том, чтобы клонировать из linux-2.6, разветвлять столько раз, сколько захотите, до такой степени, что вы получите работающую «новую» функцию. Затем, когда все будет готово, вы можете сделать его доступным для кого-то, кому доверяют, который перетянет эту ветку из вашего хранилища в свои и объединит ее с основным потоком. В ядре linux это происходит на нескольких уровнях (доверенные лейтенанты), пока не достигнет linux-2.6.git, после чего оно становится «ядром».
Теперь вот где это сбивает с толку. Имена ветвей вообще не должны быть одинаковыми для всех репозиториев. Поэтому я могу git pull origin master:vanilla-code и получить ветку от мастера origin в ветке в моем хранилище под названием vanilla-code. Если я знаю, что происходит, это на самом деле не имеет значения - оно распространяется в том смысле, что все репозитории являются одноранговыми, а не просто используются несколькими компьютерами, такими как SVN.
Итак, учитывая все это:
- Я думаю, что каждый программист должен делать то, что они делают. Все, что вам нужно, это центральный репозиторий для управления выпусками и т. Д. Магистраль может быть
head. Релизы могут быть тегами или ветвями, а исправления, вероятно, сами по себе являются ветвями. На самом деле, я бы, вероятно, делал релизы как ветки, чтобы вы могли их исправлять.
- Я бы слился, а не перебазировал. Если, например, вы берете репозиторий, клонируете его, разветвляетесь и делаете какое-то dev, затем извлекаете из своего
origin, который вы должны, в своем репозитории, вероятно, сделайте еще одну ветку и объедините последнюю master в yourbranch, чтобы кто-то еще может потянуть ваши изменения с минимальными усилиями, насколько это возможно. По моему опыту, очень редко возникает необходимость по-настоящему перебазировать.
- Я думаю, что это случай понимания того, как работает Git и что он может делать. Это требует времени и много хорошего общения - я действительно начал понимать, что происходит, когда начал использовать git с другими разработчиками и даже сейчас, в некоторых вещах, в которых я не уверен.
- Конфликты слияния полезны. Я знаю, я знаю, вы хотите, чтобы все это работало, но факт - изменения кода, и вам нужно объединить результаты во что-то, что работает. Конфликты слияний на самом деле просто больше программирования. Я никогда не находил простого объяснения, что с ними делать, поэтому вот оно: обратите внимание на файлы, которые имеют конфликты слияния, перейдите и измените их на то, что они должны быть,
git add ., а затем git commit.
- Однако это устраивает. Как я уже сказал, каждый пользовательский репозиторий git является своим собственным, и имена веток не обязательно должны быть одинаковыми . Например, если у вас был промежуточный репозиторий, вы могли бы применить схему именования, но это не требуется для каждого разработчика, только в репозитории релизов.
- Это стадия слияния. Вы объединяетесь только с ветвями релиза и т. Д., Если считаете, что код проверяется / проходит проверку качества.
Надеюсь, это поможет. Я понимаю, что VonC только что опубликовал очень похожее объяснение ... Я не могу набрать достаточно быстро!
Редактировать некоторые дальнейшие мысли о том, как использовать git в коммерческих условиях, поскольку это представляется актуальным для ФП из комментариев:
- Репозиторий релизов, назовем его
product.git, доступен нескольким старшим программистам / техническим специалистам, ответственным за фактическое наблюдение за самим продуктом.Они аналогичны роли сопровождающих в OSS. - Эти программисты, вероятно, также частично ведут разработку новых версий, поэтому они могут также кодировать себя и поддерживать репозитории varios.Они могут управлять промежуточными репозиториями для действительно новых функций, а также могут иметь свои собственные репозитории.
- Ниже находятся программисты, отвечающие за разработку отдельных битов.Например, кто-то может нести ответственность за работу интерфейса.Поэтому они управляют репозиторием UI.git.
- Ниже приведены настоящие программисты, которые разрабатывают эти функции в качестве своей повседневной работы.
Так что же происходит?Ну, все в начале каждого дня извлекают данные из «восходящего» источника, то есть из репозитория релизов (который также, вероятно, будет содержать последние материалы из предыдущих дней разработки).Каждый делает это напрямую.Это пойдет на ветку в их хранилище, возможно, под названием «master» или, может быть, если вы меня назвали «последним».Затем программист выполнит некоторую работу.Эта работа может быть чем-то, в чем они не уверены, поэтому они делают ветку, делают работу.Если это не работает, они могут удалить ветку и вернуться назад.Если это произойдет, им придется объединиться с основной ветвью, над которой они сейчас работают.Мы скажем, что это программист пользовательского интерфейса, работающий над latest-ui, поэтому он делает git checkout latest-ui, а затем git merge abc-ui-mywhizzynewfeature.Затем он говорит своему техническому руководителю (руководству по пользовательскому интерфейсу): «Я выполнил такую задачу, вытащил меня».Таким образом, пользовательский интерфейс делает git pull user-repo lastest-ui:lastest-ui-suchafeature-abc.Затем ведущий пользовательского интерфейса смотрит на него в этой ветке и говорит, что на самом деле это очень хорошо, я объединю его с ui-latest.Затем он может сказать всем, кто ниже его, чтобы он брал у него ветки ui-latest или любое другое имя, которое они им дали, и разработчики изучают эту функцию.Если команда довольна, лидер UI может попросить, чтобы лидер тестирования вытащил его и объединил изменения.Это распространяется на всех (ниже по течению от изменений), которые тестируют его и представляют отчеты об ошибках и т. Д. Наконец, если функция проходит тестирование и т. Д., Один из главных технических руководителей может объединить ее с текущей рабочей копией программы, и в этот моментвсе изменения затем распространяются обратно вниз.И так далее.
Это не «традиционный» способ работы, он разработан для «равноправного управления», а не «иерархического» типа SVN / CVS.По сути, каждый имеет доступ к коммитам, но только локально.Это доступ к репозиторию и тот репозиторий, который вы определили как репозиторий релиза, который позволяет вам использовать иерархию.