Как DVCS используется в больших командах?
Просто некоторые надстройки после того, как вы прочитали java-учебник оракула в классах и объектах. Это может помочь, если вы знаете модель памяти Java для внутреннего класса и статического вложенного класса. Пожалуйста, прочитайте следующие три вопроса, чтобы понять, почему внутренний класс и статический вложенный класс разработаны Java таким образом. И тогда вы можете знать, когда использовать внутренний класс и когда использовать статический вложенный класс.
Как внутренний объект класса находится в памяти?
Управление памятью - Внутренний статический класс в Java
Когда в него загружается статический вложенный класс (и статические члены)?
Тогда прочитайте это, чтобы сравнить внутренний класс и статический вложенный класс.
В чем преимущество создания внутреннего класса как статического с Java?
6 ответов
Моя команда из моего предыдущего работодателя использовала Git, и это хорошо сработало для нас. Мы были не такими уж большими (возможно, 16 или около того, возможно, с 8 действительно активными коммиттерами?), Но у меня есть ответы на ваши вопросы:
- N-Way слияния не очень распространены. Мы придумали некоторые соглашения об именах ветвей, которые позволили нам написать сценарии, которые облегчили " нам нужно было установить некоторые соглашения (имена веток и тегов, места репо, скрипты и т. д., процесс), иначе это могло бы быть немного хаотично. Как только мы создали соглашения, гибкость, которую мы имели, была просто фантастической.
Обновление: наши соглашения были в основном такими:
- каталог на нашем NFS-сервере, в котором размещались все центральные репозитории
- , у нас было несколько общих проектов компонентов, поэтому мы разбили их на библиотеки, по сути, с их собственными репозиториями, и поставляемые проекты просто включили их как подмодули git.
- были строки версий и имена выпусков, навязанные нам сверху, поэтому мы просто использовали варианты из них как имена ветвей
- , аналогично, для тегов они следовали за именами релизов, продиктованными процессом
- , в поставляемых проектах содержался файл свойств, который я читал в сценарии оболочки, и это позволило мне написать один сценарий для управления процессом выпуска для всех проектов, даже несмотря на то, что у каждого были небольшие вариации процесса - эти изменения были учтены в этих файлах свойств.
- Я написал сценарии, которые перестраивали бы результат пакет из любого тега
- с помощью git позволил нам контролировать доступ с помощью PAM и / или обычных пользовательских разрешений (ssh и т. д.)
- Существовали и другие соглашения, которые сложнее поместить в маркированный список, например, когда должно происходить слияние. На самом деле, я и еще один парень были своего рода «мерзавцами-гуру», и мы помогли всем понять, как использовать ветви и когда объединяться.
- Заставить людей совершать небольшие куски, а не сбрасывать различий в бомбы. главная ветвь была проблемой. Один парень вложил около двух недель работы в один коммит, и в итоге нам пришлось все это разгадать. огромная трата времени и разочарование для всех.
- информативные и подробные комментарии к коммитам
Были и другие вещи, которые вы изучаете, когда ваша команда приобретает опыт и учится работать друг с другом , но этого было достаточно, чтобы начать работу.
Обновление : любой, кто следит за такими вещами, уже знает об этом, но Винсент Дрейссен написал твердое и довольно исчерпывающее (но не исчерпывающее) описание разработка ветвлений и релизов с использованием Git . Я очень рекомендую использовать его процесс в качестве отправной точки, потому что по двум причинам:
- многие команды делают это таким образом или используют какой-то близкий вариант (включая Linux, Git и многие другие команды проекта OSS), что означает этот метод был протестирован и настроен для достижения успеха в большинстве случаев. Вы вряд ли столкнетесь с проблемой, с которой не сталкивались и не решали в рамках ограничений этой модели.
- из-за вышеизложенного, почти любой инженер с опытом работы с Git поймет, что происходит. Вам не нужно будет писать подробную документацию о фундаментальной природе вашего процесса выпуска; вам нужно будет только документировать вещи, относящиеся только к вашему проекту или команде.
Схема рабочего процесса из whygitisbetterthanx :
(источник: whygitisbetterthanx.com )
Чтобы расширить это до еще большего числа разработчиков вы просто добавляете еще один слой «доверенных лейтенантов» между менеджером по интеграции и разработчиками.
Я работаю в течение нескольких лет с команда Glasgow Haskell Compiler , использующая Darcs . Я недавно (несколько месяцев) начал использовать git для своей копии репо, как для повышения квалификации, так и для улучшения моего образования.
Как вы справляетесь с N-way слияниями?
Нет N-way слияний. Каждый разработчик создает поток исправлений, и потоки объединяются по одному в каждом репо. Поэтому, если N разработчики вносят изменения одновременно, они объединяются попарно.
Используете ли вы один центральный авторитетный репозиторий?
Абсолютно. Это единственный способ узнать, что такое GHC, а что нет.
Часто ли разработчики проталкивают и извлекают код друг из друга или все идет через центральное хранилище?
Я думаю, что это зависит от разработчиков и VCS вы используете. В проекте GHC почти все натяжения и толчки, которые я вижу, проходят через центральное хранилище. Но на толчках к центральному репо есть тяжеловесный (самоуправляемый) привратник, и если у коллеги есть исправление ошибки, которое мне нужно сейчас , я вытащу его прямо из его репо. С darcs очень легко вытащить всего один патч (а не целое состояние, как в git), и я знаю, что мои коллеги-разработчики, которые имеют больше опыта с darcs, используют эту функцию гораздо чаще, чем я - и им это очень нравится.
С
git, когда я работаю в тесном контакте с одним другим разработчиком, я часто буду создавать новую ветку только для того, чтобы поделиться ею с другим человеком. Эта ветвь никогда не попадет в центральное репо.
Довольно известная «Tech Talk: Линус Торвальдс на Git» объясняет, как она используется для Linux (примерно такой же большой, как команда, насколько я могу представить)
Если я правильно помню, это Использование было уподоблено военной цепочке команд - у каждого модуля есть сопровождающий, который обрабатывает запросы на извлечение от разработчиков, а затем есть несколько «наиболее доверенных» людей, которые занимаются извлечением данных из сопровождающих модулей в официальный git для kernel.org репозиторий.
«Linux: управление источником ядра с помощью« git »» также объясняет это, хотя, опять же, это вряд ли краткое объяснение ..
Here is one example (by no mean a "universal" one)
We have central VCS (ClearCase or SubVersion, depending on the different projects), and we are using them for "official" developments efforts (dev, patches, fixes), where the number of branches is limited and well-identified.
However, for refactoring developments involving a lot of intermediate state, where nothing works, and where many developers needs to have their own activity-based branch or branches, some Git repositories are set up between those developers, in a P2P way.
Как только работа достигает некоторой стабильности 0,1, а слияния уменьшаются, она повторно импортируется в VCS, где работа может продолжаться «упорядоченно» центральным образом.
Поскольку Git на Windows работает хорошо (MSysGit), нам удается быстро выполнить небольшие начальные разработки таким образом.
Мы все еще оцениваем Git для полномасштабной разработки проекта.
Вероятно, лучше всего посмотреть, как работают разработчики ядра Linux. У них довольно сложный рабочий процесс, в котором изменения отправляются из многих источников, а затем доверенные разработчики для каждого подсистемы (называемые лейтенантами) извлекают изменения, а когда они счастливы, отправляют их Линусу, который в конечном итоге либо тянет их в свое дерево, либо отвергает их. Конечно, это сложнее, но это общий обзор.