Разговор с экспертами сегодня утром стал отличным опытом для тех, кому посчастливилось присутствовать. Парнем со всей экспертизой был руководитель команды форума SitePoint Том Паркин, и он определенно знает свое дело. Вместо того, чтобы обычным потоком вопросов и ответов, Том провел больше мини-лекций, и даже некоторые из наиболее опытных из нас кое-что узнали.
К сожалению (и более чем немного иронично), сбой GitHub на полпути во время сеанса означал, что доступ каждому, кто пытается войти, был запрещен — мы полагаемся на Gists, чтобы контролировать доступ к чату. Приношу извинения всем, кто не смог присоединиться по этой причине.
Из разговора вышло несколько хороших ресурсов, и я перечислил их ниже для тех, кто не хочет фильтровать всю стенограмму.
Полное руководство для начинающих по Git
Маккалоу и Берглунд об освоении Git
Маккалоу и Берглунд в освоении продвинутого Git
Выучи Git за 15 минут
Том об использовании Git с Dropbox
Как зафиксировать изменения в новой ветке с помощью Git
Если вы хотите узнать, что нас ждет в ближайшие недели, у нас есть расписание предстоящих сессий . Если вы пропустили сегодняшнюю сессию, потому что не знали об этом, вы можете подписаться на напоминания по электронной почте о будущих сессиях .
И для тех, кто хочет увидеть, что произошло сегодня утром, вот полная стенограмма:
[21:53] <ParkinT> Великий ДОБРО ПОЖАЛОВАТЬ всем — особенно тем, кто новичок.
[21:53] <ParkinT> Я призываю вас присоединиться к форумам Sitepoint, где мы активно обмениваемся идеями и советами по веб-разработке и всем связанным дисциплинам.
[21:54] <HAWK> Кто-нибудь из вас уже использует Git в повседневной работе?
[21:54] <scruggs> В чем преимущество использования git над чем-то вроде subversion?
[21:54] <ParkinT> Отличный вопрос, Скрагс.
[21:55] <ParkinT> Обсуждение Source Control часто может стать чем-то вроде «религиозного спора»
[21:55] <ParkinT> Есть много людей, у которых есть предпочтения, и они обычно возникают из-за знакомства с одним конкретным инструментом.
[21:56] <ParkinT> Я использовал многие из наиболее распространенных инструментов, включая SVN. На самом деле, в моей «Дневной работе» я вынужден использовать SVN.
[21:56] <ParkinT> Git имеет несколько явных отличий, которые * я * вижу в качестве преимуществ.
[21:56] <ParkinT> В первую очередь, это МЕСТНОЕ; Это означает, что вам не нужен централизованный сервер.
[21:56] <Triopticon> С тех пор, как я попробовал Git, я должен сказать, что мне это просто нравится!
[21:57] <ParkinT> Основная претензия к Git — это [часто] тупые команды и их синтаксис.
[21:57] <ParkinT> И я не согласен с этим!
[21:57] <ParkinT> Такие системы, как Subversion *, требуют * централизованного сервера и особого внимания для синхронизации с этим сервером.
[21:57] <ParkinT> Git является {более или менее} автономным.
[21:58] <ParkinT> Теперь, это не значит, что вы не можете сотрудничать !!
[21:58] <ParkinT> И Github — самый популярный сайт, представляющий место для размещения Git-репозиториев.
[21:58] <ParkinT> Я думаю, что наиболее распространенное заблуждение (или недоразумение) в Git заключается в том, что Github и Git — это одно и то же.
[21:59] <ParkinT> Bitbucket — еще один популярный сайт, на котором размещаются репозитории Git. Но вы можете разместить централизованное Git-репо где угодно.
[21:59] <HAWK> Да, я много слышал
[21:59] <Velochicdunord> Чем они отличаются?
[21:59] <ParkinT> Несколько лет назад я создал видео, демонстрирующее, как разместить репозиторий Git в Dropbox; когда Dropbox был новым
[21:59] <Triopticon> Мне нравятся Github и Bitbucket.
[22:00] <Velochicdunord> Есть ссылки на это видео?
[22:00] <HAWK> Velochicdunord Github — это сайт, на котором размещаются репозитории Git.
[22:00] <ParkinT> Чтобы ответить на вопрос Велочикунорда (и продолжить мое обсуждение)…
[22:00] <ParkinT> Извините. Я неправильно понял вопрос. Спасибо ястреб
[22:00] <ParkinT> Еще одна особенность Git, которая отличается от Subversion, заключается в том, что вся история живет в локальном хранилище.
[22:01] <ParkinT> При работе в Git у вас есть ВСЕ коммиты (состояния файлов).
[22:02] <ParkinT> На самом деле, у каждого соавтора проекта (в репозитории Git) есть вся история. Таким образом, благодаря этому существует множество избыточных резервных копий.
[22:02] <ParkinT> Способ, которым Git хранит информацию, также эффективен и легок.
[22:02] <HAWK> Добро пожаловать в те из вас, кто только что присоединился.
[22:02] <HAWK> Я выложу полную стенограмму в SitePoint сегодня вечером
[22:03] <HAWK> Но вы можете найти этот документ полезным в то же время http://s3.sitepoint.com/examples/git-project-changes.pdf
[22:03] <HAWK> Привет, Молона
[22:03] <molona> Привет
[22:03] <molona> не говори мне, что я опоздал?
[22:03] <ParkinT> Извините, я начал без вас.
[22:03] <HAWK> мы начали на несколько минут раньше
[22:03] <ParkinT> Я ПРОСТО ТАК ЭНТУЗИАСТИЧЕСКИЙ ОБ ЭТОЙ ТЕМЕ, Я НЕ МОГУ СОДЕРЖАТЬ СЕБЯ !!
[22:04] <molona> Хорошо. На этот раз я прощу тебя … только на этот раз :-p
[22:04] <Jerry> Скажем, я начинаю работать над проектом с некоторой историей и ручным управлением версиями (снимки каталога или серии файлов с номером версии, добавленным к имени файла). Я сейчас начинаю разработку новой версии с чистого git-репозитория. Можно ли создать второй репозиторий для использования в качестве главного архива, создав его
[22:04] <Джерри> вручную, используя доступные файлы, затем со временем объединить текущий репозиторий с мастером?
[22:04] <ParkinT> Спасибо
[22:04] <HAWK> мы говорили о преимуществах Git перед аналогичными инструментами
[22:04] <HAWK> и различие между Git и Github
[22:04] <Jerry> Немного запутанный, но у меня нет времени на создание главного репозитория перед началом текущей работы.
[22:04] <JS> Это очень хорошее начальное руководство по Git. Спасибо Ястреб, я прочитал это сегодня.
[22:04] <molona> Это важно … Спасибо, Хок
[22:05] <ParkinT> «преимущества» немного субъективны. Но я выделил различия * я * считаю преимущества
[22:05] <Carolyn> О, я думала, что бесплатный урок Git начался несколько минут назад. Я потерян?
[22:05] <ParkinT> Гибкость Git означает, что вы можете подойти к этой проблеме различными способами.
[22:05] <scruggs> ParkinT: ваши выводы были проницательными
[22:05] <ParkinT> Если бы я столкнулся с этим, вот как * я * справился бы с этим.
[22:06] <ParkinT> Возьмите текущие рабочие файлы и отправьте их в репозиторий Git. Сохраните предыдущую работу (возможно, на DVD) в виде архива.
[22:06] <HAWK> Привет, Кэролин — нет, ты в правильном месте. 🙂 Мы сейчас говорим о Git. Не стесняйтесь задавать вопросы в любое время. 🙂
[22:06] <ParkinT> Я бы поспорил, что после завершения проекта он будет выглядеть МЕНЬШЕ, как старые файлы, чем сейчас.
[22:06] <HAWK> Я выложу полную стенограмму в SitePoint сегодня вечером
[22:06] <ParkinT> Двигаясь вперед, обязательно внесите свои изменения.
[22:07] <Triopticon> В чем отличия или преимущества / недостатки по сравнению с Mercurial?
[22:07] <ParkinT> Еще одна вещь, которую Git делает ОЧЕНЬ хорошо, это то, что она позволяет вам «экспериментировать» или тестировать.
[22:07] <ParkinT> Используя ветки Git, вы можете вносить радикальные изменения без страха, что вы потеряете свое место (или вам придется отказаться).
[22:07] <ParkinT> Mercurial и Git * очень * похожи.
[22:08] <Кэролайн> Ха. Я понятия не имею, о чем вы говорите, поэтому я хотела пойти на урок, чтобы «выучить Git»!
[22:08] <ParkinT> У меня очень, очень маленький опыт работы с Mercurial. Если бы вы нажали на меня, я бы просто сказал: «Я могу записать это!» LOL
[22:08] <HAWK> Кэролайн — вам может пригодиться этот документ http://s3.sitepoint.com/examples/git-project-changes.pdf
[22:08] <Carolyn> Спасибо, я пойду туда.
[22:08] <HAWK> Держись, если есть время. Мы приветствуем любые вопросы, даже самые простые. 🙂
[22:09] <ParkinT> Документ, на который ссылается HAWK, является отличным ВВЕДЕНИЕМ в git
[22:09] <ParkinT> Если вы не знакомы с концепцией Source Control. Или вы не разработчик, но вам интересно, как этот инструмент может вам помочь.
[22:09] <Triopticon> ParkinT — теперь переживает…: D
[22:09] <ParkinT> Он был тщательно продуман, чтобы быть безопасным, управляемым руководством. Просто достаточно, чтобы ваши ноги промокли.
[22:10] <molona> Итак, ParkinT, вы использовали какое-либо другое программное обеспечение для управления исходным кодом до использования GIT? и если да, то почему ты изменился?
[22:10] <ParkinT> Я использовал SourceSafe (не заводите меня!), И, как я упоминал ранее, моя «дневная работа» заставляет меня использовать Subversion.
[22:11] <molona> Я должен сказать, что это отличный инструмент для тех, кто использует Linux, он немного сложен, когда вы привыкли к Windows: D
[22:11] <Carolyn> Я писатель, и мне нужно выучить несколько CMS, и Git часто упоминается в самом начале. Оооо, очевидно, мне нужно изучить это и ничего не знать об этом. 🙂
[22:11] <ParkinT> Переход на Git был для меня нелегким делом. Это потребовало небольшой корректировки в моей перспективе.
[22:11] <Джерри> Спасибо, Паркин. На самом деле, мы довольно часто ссылаемся на старые файлы в целях поддержки, потому что многие пользователи продукта остаются на старых версиях. Два репозитория, конечно, лучше, чем сейчас, но было бы неплохо, если бы я мог в конечном итоге объединить их
[22:11] <ParkinT> Но, я должен сказать, а) чтение книги ProGit и б) изучение большего количества внутренней работы Git дало мне глубокую признательность за это.
[22:11] <molona> Кэролайн, GIT — это не CMS. Это программное обеспечение для контроля версий
[22:12] <ParkinT> Ах, Джерри, мне это было непонятно. Я вижу вашу дилемму.
[22:12] <HAWK> Я использовал SourceSafe на моей последней работе в ParkinT, так что я вас об этом слышу!
[22:12] <ParkinT> Я проповедовал использование Git «всеми сферами жизни».
[22:12] <molona> Ты сейчас используешь GIT, Хок?
[22:13] <Carolyn> Я понимаю, что GIT — это не CMS. Но когда я начинаю смотреть на EE или Chart и т. Д., Они сразу упоминают Git. Итак, мне нужно узнать об этом.
[22:13] <ParkinT> Одна часть моей «дневной работы» включает в себя техническое обучение, где мне нужно разработать учебные планы. В основном это документы MSWord.
[22:13] <ParkinT> Я использую Git, чтобы помочь мне отслеживать (и пересматривать) свою работу.
[22:13] <molona> Кэролайн, хорошо, извиняюсь. Просто неправильно понял, что ты сказал: D
[22:13] <HAWK> В эти дни я мало занимаюсь кодированием, Молона! Я использую GitHub, но только для функциональности Gist
[22:13] <ParkinT> Кэролайн делает интересное замечание.
[22:14] <Triopticon> Я бы также порекомендовал эти два видео-приседания в «О’Рейли»: «МакКаллоу и Берглунд о мастеринге Git» и «МакКаллоу и Берглунд о мастеринге продвинутого Git»!
[22:14] <ParkinT> Git (вероятно) самая популярная VCS в мире открытого исходного кода
[22:14] <HAWK> Я должен вмешаться и сказать, что если у кого-то есть хорошие ресурсы, не стесняйтесь ссылаться на них
[22:14] <ParkinT> Вы обнаружите, что довольно часто указываете на репозитории Git (многие на Github) для загрузки / установки / использования программного обеспечения
[22:14] <HAWK> Я добавлю их в стенограмму, когда выложу это позже
[22:15] <ParkinT> Спасибо Triopticon. Большие ресурсы.
[22:15] <ParkinT> Code School также имеет курс «Try Git» (я думаю, что у него есть собственный домен «trygit.com»).
[22:15] <molona> Когда я установил GIT, он автоматически подключился к GitHub … но я вынужден использовать GitHub? Что если я захочу использовать какой-нибудь другой репозиторий?
[22:15] <ParkinT> Но его целевая аудитория — разработчики программного обеспечения.
[22:16] <Джеймс> это http://try.github.io/
[22:16] <ParkinT> Существует множество мест для размещения Git-репозитория.
[22:16] <ParkinT> Вот видео, которое я создал много лет назад http://www.youtube.com/watch?v=2bxbzFQEMYM, которое демонстрирует использование Dropbox для вашего репозитория Git
[22:17] <Triopticon> Отлично!
[22:17] <ParkinT> Github просто самый популярный.
[22:17] <molona> Круто, теперь ты мой герой ParkinT
[22:17] <ParkinT> Bitbucket — это еще один из тех, кого я знаю, который поддерживает Git.
[22:17] * Харди шлепает Харди немного с большой форелью
[22:17] <Velochicdunord> Спасибо!
[22:18] <HAWK> Ах, старая форель, а, Харди?
[22:18] <ParkinT> Еще одна вещь, которую Git делает по-другому, но я думаю, что это большое преимущество
[22:18] <Hardy> Хе-хе — просто хотел посмотреть, какой урон я бы нанес;)
[22:18] <ParkinT> — это способ обработки [того, что он называет] патчей. Таким образом, вы можете отправить Delta репозитория по электронной почте в упакованной форме, понятной Git.
[22:19] <ParkinT> Харди, у тебя завтра будет синяк!
[22:19] <Triopticon> Я бы сказал, что Github более приспособлен к социальным аспектам и среде с открытым исходным кодом, даже если вы также можете платить за частные репозитории.
[22:19] <scruggs> «Дельта репозитория», что это значит?
[22:19] <molona> Я не знал, что Dropbox может работать с GIT… приятно!
[22:19] <ParkinT> Правда. Git выставляет счет в «Facebook для разработчиков»
[22:19] <James> Какие-нибудь рекомендуемые учебники, которые подходят для новичков?
[22:19] <jerrac> http://gitlab.org/ это хорошо, если у вас есть ресурсы, чтобы провести его самостоятельно.
[22:20] <ParkinT> Под дельтой я подразумеваю разницу между одним и другим.
[22:20] <scruggs> Хорошо, спасибо за разъяснения.
[22:20] <ParkinT> Github, кстати, с открытым исходным кодом. С помощью веб-хостинга вы можете создать свою собственную версию того, что на Github.com
[22:21] <ParkinT> То, как Git концептуализирует коммит (и древо истории), позволяет ему разветвляться гораздо лучше, чем другие, такие как SVN.
[22:21] <jerrac> Github с открытым исходным кодом? Я никогда не видел места, где можно скачать их исходный код.
[22:21] <ParkinT> Я могу работать над проектом; давайте представим, что это веб-сайт.
[22:22] <ParkinT> Мне пришло в голову, что я хочу попробовать что-нибудь необычное в AJAX. Но я боюсь испортить то, что уже «работает».
[22:22] <ParkinT> Я просто создаю ветку в git. Это дает мне новое место для перехода из моего нынешнего состояния
[22:22] <ParkinT> После экспериментов, если мне не нравятся результаты, я могу просто восстановить (проверить) мастер
[22:23] <ParkinT> Если я сделал удивительное улучшение, я могу объединить свою ветку с мастером.
[22:23] <ParkinT> Теперь вот классная часть.
[22:23] <molona> Означает ли слияние, что вы удалите эту ветку навсегда?
[22:23] <ParkinT> У меня новый набор кода. Но в любое время я могу вернуться прямо в это состояние только с проверкой.
[22:24] <ParkinT> Нет. Ветка не удалена. Вы можете явно удалить ветку.
[22:24] <ParkinT> Но Git работает очень усердно, чтобы не позволить себе выстрелить себе в ногу.
[22:24] <lj> Как мне скачать с ghithub страницы ФИЛИАЛ. Является ли это возможным? Я получаю только мастер-файлы.
[22:24] <ParkinT> Вы не можете удалить ветку, если за ней нет истории.
[22:24] <molona> Не волнуйся. Мне все-таки удастся выстрелить себе в ногу: p
[22:24] <ParkinT> На Github есть выпадающий список, который показывает все ветви.
[22:25] <ParkinT> Многие репозитории имеют только одну (главную) ветку.
[22:25] <lj> Я знаю, но когда я пытаюсь загрузить все файлы из ветки страниц githhub, я не получаю все файлы из этой ветки.
[22:25] <ParkinT> Как я уже говорил, одной из уникальных особенностей Git является то, что хранилище содержит всю историю. Так что, если есть филиалы, они будут включены, когда вы получите репо.
[22:26] <ParkinT> Github добавил множество веб-приложений с графическим интерфейсом, чтобы вы могли просматривать содержимое репозитория. Чтобы получить весь репозиторий Git, вам нужно использовать Git (традиционно в командной строке).
[22:26] <lj> Я могу клонировать на свой собственный github, но я не могу загрузить файлы «github pages» на свой компьютер для работы.
[22:26] <ParkinT> Я подозреваю, что вы просто копируете файлы с сайта.
[22:26] <ParkinT> А, страницы Github не являются частью Git.
[22:27] <ParkinT> Это «особенность» Github. Как Форк и Стар
[22:27] <lj> да, я пытался сжать эти файлы ..
[22:27] <ParkinT> Группа в Github — потрясающие новаторы.
[22:27] <James> Должен ли я сначала отредактировать код, а затем создать ветку? Или создать ветку / оформить заказ и добавить новые коды? чтобы изменения не появлялись в основной ветке?
[22:27] * Codebold слегка ударяет Codebold большой форелью
[22:27] <ParkinT> Отличный вопрос, Джеймс.
[22:28] <ParkinT> Каждый раз, когда вы запускаете команду ‘commit’, все файлы (которые были помечены как отслеживаемые Git) записываются как часть этого коммита.
[22:28] <ParkinT> Текущее СОСТОЯНИЕ всех этих файлов фиксируется, и фиксация — в целом — получает глобальный уникальный идентификатор.
[22:28] <ParkinT> Если вы затем создадите ветку, она будет — в этот момент — содержать все те же файлы.
[22:29] <ParkinT> Затем вы должны взломать эти файлы, и когда вы сделаете еще один коммит, он будет в этой ветке.
[22:29] <ParkinT> Теперь у вас есть две разные версии файлов для ссылки.
[22:29] <ParkinT> Думайте о стволе могучего дуба как о главном хранилище Git.
[22:29] <ParkinT> Каждый раз, когда вы делаете ветку, это конечность, которая выходит из этого растущего дерева в определенный момент времени.
[22:30] <ParkinT> Основная часть дерева продолжает расти самостоятельно.
[22:30] <ParkinT> Основная ветвь может продолжать расти (меняться). И так будет, если вы работаете над совместным проектом.
[22:30] <ParkinT> Потому что ДРУГИЕ взламывают ИХ копию хранилища.
[22:30] <Jerry> Если я работаю с мастером, отредактирую несколько файлов и решу, что мне нужно внести изменения в ветку, как мне это сделать?
[22:31] <ParkinT> В отличие от других систем, процесс синхронизации (слияние) выполняется на каждом отдельном компьютере (копия репо).
[22:31] <ParkinT> Для этого есть команда Git, Джерри.
[22:32] <scruggs> Я думаю, что лучший способ — всегда извлекать нужные вам файлы, вносить изменения, и они фиксируют эти изменения. Информация истории фиксации / изменения полезна при попытке выяснить, где что-то изменилось в главном репо
[22:32] <HAWK> К вашему сведению, ребята, из-за сбоя GitHub, если вы покинете этот чат (обновив страницу), вы не сможете вернуться.
[22:32] <ParkinT> Совершенно верно, Скрагс.
[22:32] <HAWK> Надеюсь, они скоро все уладят! Я полагаюсь на Gists для контроля доступа.
[22:32] <ParkinT> В Git есть еще одна из моих «любимых» команд. «ОСУЖДЕНИЕ»
[22:33] <HAWK> О, ирония
[22:33] <molona> лол хок
[22:33] <ParkinT> Вы можете сослаться на коммит (или файл в коммите) и узнать, кто / когда это изменение произошло
[22:33] <ParkinT> Gist — еще одно новшество умных людей в Github!
[22:33] <ParkinT> Я люблю Гитста
[22:33] <lj> можно ли перенести один каталог репо в локальный с помощью команды терминала? Как вы сказали, «оформите нужные вам файлы»
[22:34] <ParkinT> * даже когда я не могу правильно написать это!
[22:34] <ParkinT> Да, ЖЖ
[22:34] <Джерри> <- затаив дыхание, ожидая названия команды… 🙂
[22:34] <ParkinT> Вы можете «оформить» любую часть коммита, назвав нужные вам файлы.
[22:34] <lj> да, тяжело дыша
[22:35] <ParkinT> Извини, Джерри. Просто оформите с -b новую ветку
[22:35] <scruggs> Может ли администратор git это контролировать?
[22:35] <ParkinT> Затем добавьте, если необходимо, и подтвердите
[22:35] <ParkinT> http://stackoverflow.com/questions/14655816/how-to-commit-changes-to-new-branch
[22:35] <ParkinT> Администратор Git — это ВЫ.
[22:35] <ParkinT> Хранилище на вашем компьютере, и вы контролируете горизонтальное, вы контролируете вертикальное …
[22:35] <Jerry> Не пожалеешь -b жаловаться, если есть незафиксированные изменения?
[22:36] <ParkinT> Как я уже говорил, git был разработан с учетом «человеческих существ».
[22:36] <ParkinT> Это поможет вам избежать глупых ошибок и ненависти к себе.
[22:36] <Triopticon>: p
[22:36] <ParkinT> Но * можно * сделать что угодно
[22:36] <scruggs> Я думаю, что я имею в виду … скажем, у вас есть несколько репозиториев … как dev, test и production. Может ли администратор git установить правила безопасности, чтобы запретить разработчикам совершать какие-либо действия, скажем, в производственном репо?
[22:36] <ParkinT> Многие команды включают ключ -f (это означает «форсировать»).
[22:37] <lj> ОК, так что $ git checkout sass фактически загрузит папку sass на мой локальный компьютер? Извините, я не слишком опытен с этим.
[22:37] <ParkinT> Нет смысла устанавливать разные репозитории для одного и того же проекта.
[22:37] <ParkinT> ВЫ хотите поощрять сотрудничество. С Git на месте НИ ОДИН ЧЕЛОВЕК не может заставить систему умереть с плохим фрагментом кода.
[22:37] <HAWK> Да, мы снова открыты!
[22:37] <ParkinT> Потому что а) вы можете вернуться в историю и б) у каждого соавтора есть копия всего репо на его / ее столе.
[22:38] <Triopticon> Мне нравится эта модель ветвления: http://nvie.com/posts/a-successful-git-branching-model/
[22:38] <lj> Я в замешательстве, когда говоришь
[22:38] <ParkinT> $ git checkout sass перезапишет (при необходимости перезапишет) все файлы, которые являются частью самого последнего коммита git в ветке с именем sass
[22:38] <lj> «рабочий стол» ты имеешь в виду местный или мой собственный git-репо? Потому что я не могу получить копию всего репо
[22:39] <ParkinT> Не думайте о них как о каталогах. Коммит — это ОБЪЕКТ, который содержит целый набор файлов и папок.
[22:39] <lj> sass это не ветка, это каталог
[22:39] <scruggs> Мне нравится твой комментарий о сотрудничестве. Я видел несколько интернет-магазинов, которые настраивали несколько репозиториев как способы показать вещи, которые находятся в стадии разработки, вещи, которые ожидаются в следующем выпуске, и вещи, которые в настоящее время «живы». Просто было любопытно, что вы взяли.
[22:40] <ParkinT> Скраггс, это именно то, как ответвления были / предназначены для использования.
[22:40] <molona> Но я понимаю, что в какой-то момент мне бы хотелось, чтобы кто-то просмотрел некоторые файлы в определенной ветке, но я не хочу, чтобы они что-либо фиксировали
[22:40] <ParkinT> Например, я хочу попробовать новую функцию. Я создаю функциональную ветку, делаю свои изменения, тестирую их, а затем помещаю изменения на тестовый сервер.
[22:40] <molona> Хотя это может быть полезно в качестве процесса пересмотра, если они действительно изменили файлы со своими комментариями, я полагаю
[22:41] <ParkinT> Если они, кажется, работают, мы можем «решить» объединить эту ветку в master и развернуть. Если есть проблема, мы можем взломать ее еще немного.
[22:41] <ParkinT> Хорошая мысль, Молона.
[22:41] <ParkinT> То, как вы это делаете, заключается в том, чтобы: а) зафиксировать изменения в ветке, б) позволить коллаборатору перенести (с вас или с сайта, такого как Github) весь репо на свою машину
[22:42] <Sef> Привет, ребята. это только у меня или у вас все отключились? Извините, что перебиваю
[22:42] <ParkinT> Затем они делают этот коммит частью всей истории, слитым с тем, что ОНИ изменили за это время.
[22:42] <blogjunkie> Говоря о тестировании перед развертыванием, у вас будет контрольный список вещей, которые нужно проверить перед развертыванием в производство? Я работаю с сайтами WordPress специально
[22:42] <HAWK> Sef Ты видишь это?
[22:42] <scruggs> blogjunkie: всегда планируйте и тестируйте!
[22:43] <ParkinT> Традиционно (и я говорю по опыту еще до того, как Интернет), у вас есть список «требований»
[22:43] <Sef> HAWK Да, я сейчас подключен, просто я не мог подключиться в течение получаса
[22:43] <ParkinT> Процесс тестирования должен быть не более чем подтверждением того, что эти требования были выполнены.
[22:43] <HAWK> Да, прости за это. В GitHub произошел сбой (по иронии судьбы), и я использую Gists для контроля доступа.
[22:43] <HAWK> Из всех сеансов, чтобы это произошло!
[22:44] <ParkinT> LOL
[22:44] <ParkinT> Определение иронии, а?
[22:44] <HAWK> Позднее сегодня я опубликую стенограмму всего сеанса в SitePoint, чтобы вы могли увидеть материал, который вы пропустили. В то же время, если у вас есть важные вопросы, не стесняйтесь их задавать
[22:44] <blogjunkie> хорошо, круто. Есть ли список требований, на которые я могу сослаться? в противном случае, я думаю, я мог бы собрать свой собственный и превратить его в полезную запись в блоге
[22:45] <ParkinT> По моему опыту, набор требований выводится (в сотрудничестве с клиентом) перед выполнением любой работы.
[22:46] <ParkinT> В конечном счете, требования должны быть следующими: «когда это будет сделано, я буду считать, что выполнено, и я заплачу вам» от клиента
[22:46] <scruggs> также, это в основном связано с основами решения проблем. в чем проблема и какие шаги необходимы для решения проблемы
[22:46] <Sef> ладно, понятно 🙂 ну, на самом деле я хотел задать пару вопросов. Во-первых, я хотел бы поговорить об автоматическом развертывании сайтов через git. Могу ли я сделать коммит в производственную ветку, чтобы он автоматически запускал некоторые сценарии сборки / тесты / что угодно, и в случае успеха перенести все это на мой сайт?
[22:46] <molona> хороший вопрос, сеф!
[22:46] <ParkinT> Краткий ответ: АБСОЛЮТНО
[22:46] <blogjunkie> спасибо ParkinT и Скрагс
[22:46] <ParkinT> Еще одна интересная особенность Git — это набор «хуков»
[22:46] <molona> хороший ответ ParkinT, но теперь расширите, пожалуйста
[22:47] <Sef> я знаю, что есть куча уроков по этой и непрерывной интеграции, но, может быть, вы знаете некоторые лучшие инструкции и прочее
[22:47] <ParkinT> Github использует их очень умело
[22:47] <ParkinT> С помощью хуков вы можете запускать любое количество автоматических операций.
[22:47] <ParkinT> Я часто работаю в (Ruby on) Rails. И один из моих любимых инструментов (проект с открытым исходным кодом, в который я с гордостью внес вклад) — это Capistrano
[22:48] <ParkinT> Это автоматизированная система, которая в простом объяснении обращается к вашему репозиторию Git (с сервера развертывания) и извлекает последние изменения (или любую указанную вами ветку).
[22:49] <molona> Зависит ли автоматическая работа от того, где находится ваш репозиторий? Я имею в виду, что если я использую GitHub, я могу сделать несколько вещей, но если я использую другой репозиторий, я не смогу это сделать? или я мог бы сам их кодировать?
[22:49] <sewmyheadon> Мы используем Beanstalk для работы с клиентами, потому что он имеет встроенные развертывания, которые легко настраиваются всеми нашими разработчиками.
[22:49] <ParkinT> Нет. У Github есть несколько простых инструментов в графическом интерфейсе, которые помогут вам подключиться ко многим распространенным сервисам.
[22:50] <ParkinT> Но в Git есть хуки, и вы можете использовать их по своему усмотрению; независимо от хозяина.
[22:50] <HAWK> Только голова на все — в этом сеансе осталось 10 минут. Если вы сидите на вопросе, убедитесь, что вы скоро включите его.
[22:50] <molona> можешь ли ты программировать новые хуки, если нужно?
[22:50] <sewmyheadon> Я также видел, как ftploy.com делает развертывания
[22:51] <chris> Еще одна хорошая вещь, которую нужно сделать с ловушкой, — это запустить что-то, чтобы проверить исходный код на соответствие стандарту кодирования перед фиксацией, например, PHP_CodeSniffer.
[22:51] <ParkinT> Отличный момент, Крис
[22:52] <ParkinT> Насколько я знаю, хуки существуют, и вам нужно будет поработать над исходным кодом Git (который находится в публичном репозитории), чтобы внести изменения.
[22:52] <molona> Хорошо, тогда я предполагаю, что вы можете создавать новые хуки… и, возможно, использовать хук, созданный кем-то другим?
[22:52] <ParkinT> Я думаю, они уже включили в себя все, что тебе нужно.
[22:52] <ParkinT> Пойми, что зацепки — триггеры событий в Git.
[22:52] <molona> В моем случае, конечно! Мне просто было любопытно
[22:53] <ParkinT> Происходит только конечное число событий. Вы можете использовать их любым способом по вашему выбору.
[22:53] <molona> да, наверное, мне следовало бы сказать «действие» вместо крючка… Мне было любопытно узнать, может ли Git быть обычным, как-то
[22:53] <ParkinT> Спасибо всем за активное участие. Я надеюсь, что никто не чувствует, что их вопрос привлек должное внимание.
[22:54] <ParkinT> Существует множество инструментов, созданных для использования Git разными способами.
[22:54] <ParkinT> В основном это скрипты-оболочки.
[22:54] <HAWK> Да, это была фантастическая сессия. Больше мини-лекции на самом деле. Ты проделал потрясающую работу благодаря Тому.
[22:54] <Sef> спасибо, ребята, это было интересно, с нетерпением жду полной расшифровки
[22:54] <chris> Спасибо за это!
[22:54] <Triopticon> Мне понравилось! : D
[22:54] <HAWK> Не беспокойся. 🙂
[22:54] <HAWK> Я бегаю по одному каждую неделю. Время немного меняется, поэтому обязательно проверьте расписание
[22:55] <blogjunkie> спасибо всем
[22:55] <ParkinT> Спасибо, HAWk. : краснея:
[22:55] <sewmyheadon> Итак, вот мой тупой вопрос: если у меня есть репозиторий и я создаю ветку объектов, которая содержит все те же файлы, что и оригинал, только в разных состояниях и содержит другой код, когда я переключаюсь на эту ветку все файлы в репозитории «меняются», чтобы имитировать состояние файлов в ветке, которую я использую?
[22:55] <молона> и ястреб, конечно
[22:55] <молона> и остальные
[22:55] <ParkinT> Sewmyheadon, вы абсолютно правы!
[22:56] <sewmyheadon> Спасибо! ParkinT
[22:56] <ParkinT> Лучше всего рассматривать каждый COMMIT как снимок состояния этих файлов.
[22:56] <ParkinT> Момент времени, как на фотографии.
[22:56] <ParkinT> До свидания / ночь / день все