Множественные переключаемые цепи в едином открытом кабельном канале с Т-образным корпусом кабелепровода для их разветвления

Множественные переключаемые цепи в едином открытом кабельном канале с Т-образным корпусом кабелепровода для их разветвления

Я хочу добавить новое приспособление к каменному потолку гостиной дома открытой планировки.

Текущая настройка

Существующие электрические кабельные каналы ко всем потолочным светильникам выполнены с помощью открытого кабелепровода 1/2 ”, установленного непосредственно на каменном потолке. В обеденной зоне, которая открыта для гостиной, уже есть осветительная арматура с дорожкой, ведущей к ней. Этот кабельный канал берет начало в стандартной квадратной распределительной коробке 4 дюйма в стене коридора и выходит из стены на уровне потолка, где затем простирается на 10-15 футов до прибора. Распределительная коробка содержит выключатель для осветительной арматуры, выключатель для настенной розетки и некоторые другие стыковые соединения для некоммутируемых розеток. Все эти цепи (переключаемый свет, переключаемая розетка, несшитые розетки) подключены к одному и тому же 15-амперному выключателю.

Планируемое добавление

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

Это кажется совершенно логичным, но я не думаю, что видел подобное где-нибудь еще. Все остальные кабельные каналы в доме кажутся выделенными для одной коммутируемой цепи, даже если это означает, что от одной и той же ответвленной цепи физически параллельно на больших расстояниях проложено множество кабелепроводов. Из-за этого я хотел бы знать, есть ли основанная на NEC причина не «разделять» и «разветвлять» такую ​​дорожку качения, особенно с корпусом кабелепровода, а не с новой распределительной коробкой. Может быть, я не вижу его больше нигде, потому что он просто не «выглядит» так хорошо, когда дорожки качения обнажены?

Я подтвердил, что:

• Добавление нового прибора не будет означать превышения рекомендуемого предела 1440 Вт для ответвленной цепи 15 А.
• Совместное использование части кабелепровода (проводники 4×14 AWG — 2 горячих и 2 нейтральных) не приблизилось бы к емкости заполнения кабелепровода 1/2 дюйма. Снижение номиналов также не является фактором, AFAIK.
• В корпусе кабелепровода Т-образного типа не должно быть стыков (я бы потянул отдельные нейтрали для каждого приспособления), поэтому его заполняющая способность будет такой же, как и у канала качения, и, следовательно, находится в определенных пределах.
• Допуск на радиус изгиба для стандартного готового корпуса кабелепровода 1/2 ”Т-образного типа с проводом 14 AWG, по-видимому, находится в установленных пределах.
• Заполнение существующей распределительной коробки по-прежнему будет в допустимых пределах, даже с этими незначительными изменениями.

Есть ли какие-то факторы, которые мне не хватает, или это на самом деле очень распространенная установка?

Эд Бил

Rjacobs

Эд Бил

Rjacobs

Эд Бил

Rjacobs

Rjacobs

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

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

NEC требует снижения номинальных характеристик для 3-х или более проводов в одной кабельной дорожке. Моим первоначальным впечатлением от # 14 THHN было то, что он рассчитан только на 15 ампер, а это значит, что любые требования к снижению номинальных характеристик могут быть проблемой для этой 15-амперной ответвленной цепи. При более глубоком рассмотрении оказывается, что 15 ампер — это только необходимая защита от перегрузки по току для цепей с проводом № 14 (от NEC от 240,4 (D) (4)), и что ток № 14 THHN на самом деле рассчитан немного выше 15 ампер при низких температурах. В моем случае мне нужно было снизить номинальные характеристики на 80% (для 4-6 проводников), а для # 14 THHN при низких температурах это сработало до 80% от 25 ампер = 20 ампер, что все еще кажется вполне нормальным для существующей ответвленной цепи на 15 ампер. с которым я работаю. Этот удобный онлайн-инструмент, и, конечно же, соответствующие таблицы от NEC (из 310.15 (B) (16)) подтвердили это.

Таким образом, похоже, что это запланированное дополнение в порядке, как указано, при условии, что сечение провода <= # 14.

3.2 Ветвление в Git — Основы ветвления и слияния

Давайте рассмотрим простой пример рабочего процесса, который может быть полезен в вашем проекте. Ваша работа построена так:

Вы работаете над сайтом.

Вы создаете ветку для новой статьи, которую вы пишете.

Вы работаете в этой ветке.

В этот момент вы получаете сообщение, что обнаружена критическая ошибка, требующая скорейшего исправления. Ваши действия:

Переключиться на основную ветку.

Создать ветку для добавления исправления.

После тестирования слить ветку содержащую исправление с основной веткой.

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

Основы ветвления

Предположим, вы работаете над проектом и уже имеете несколько коммитов.

Вы решаете, что теперь вы будете заниматься проблемой #53 из вашей системы отслеживания ошибок. Чтобы создать ветку и сразу переключиться на нее, можно выполнить команду git checkout с параметром -b :

Это то же самое что и:

Вы работаете над своим сайтом и делаете коммиты. Это приводит к тому, что ветка iss53 движется вперед, так как вы переключились на нее ранее ( HEAD указывает на нее).

Тут вы получаете сообщение об обнаружении уязвимости на вашем сайте, которую нужно немедленно устранить. Благодаря Git, не требуется размещать это исправление вместе с тем, что вы сделали в iss53 . Вам даже не придется прилагать усилий, чтобы откатить все эти изменения для начала работы над исправлением. Все, что вам нужно — переключиться на ветку master .

Но перед тем как сделать это — имейте в виду, что если рабочий каталог либо индекс содержат незафиксированные изменения, конфликтующие с веткой, на которую вы хотите переключиться, то Git не позволит переключить ветки. Лучше всего переключаться из чистого рабочего состояния проекта. Есть способы обойти это (припрятать изменения (stash) или добавить их в последний коммит (amend)), но об этом мы поговорим позже в разделе Припрятывание и очистка главы 7. Теперь предположим, что вы зафиксировали все свои изменения и можете переключиться на ветку master :

С этого момента ваш рабочий каталог имеет точно такой же вид, какой был перед началом работы над проблемой #53, и вы можете сосредоточиться на работе над исправлением. Важно запомнить: когда вы переключаете ветки, Git возвращает состояние рабочего каталога к тому виду, какой он имел в момент последнего коммита в эту ветку. Он добавляет, удаляет и изменяет файлы автоматически, чтобы состояние рабочего каталога соответствовало тому, когда был сделан последний коммит.

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

Вы можете прогнать тесты, чтобы убедиться, что ваше исправление делает именно то, что нужно. И если это так — выполнить слияние ветки hotfix с веткой master для включения изменений в продукт. Это делается командой git merge :

Заметили фразу «fast-forward» в этом слиянии? Git просто переместил указатель ветки вперед, потому что коммит C4 , на который указывает слитая ветка hotfix , был прямым потомком коммита C2 , на котором вы находились до этого. Другими словами, если коммит сливается с тем, до которого можно добраться двигаясь по истории прямо, Git упрощает слияние просто перенося указатель ветки вперед, так как нет расхождений в изменениях. Это называется «fast-forward».

Теперь ваши изменения включены в коммит, на который указывает ветка master , и исправление можно внедрять.

После внедрения вашего архиважного исправления, вы готовы вернуться к работе над тем, что были вынуждены отложить. Но сначала нужно удалить ветку hotfix , потому что она больше не нужна — ветка master указывает на то же самое место. Для удаления ветки выполните команду git branch с параметром -d :

Теперь вы можете переключиться обратно на ветку iss53 и продолжить работу над проблемой #53:

Стоит обратить внимание на то, что все изменения из ветки hotfix не включены в вашу ветку iss53 . Если их нужно включить, вы можете влить ветку master в вашу ветку iss53 командой git merge master , или же вы можете отложить слияние этих изменений до завершения работы, и затем влить ветку iss53 в master .

Основы слияния

Предположим, вы решили, что работа по проблеме #53 закончена и её можно влить в ветку master . Для этого нужно выполнить слияние ветки iss53 точно так же, как вы делали это с веткой hotfix ранее. Все, что нужно сделать — переключиться на ветку, в которую вы хотите включить изменения, и выполнить команду git merge :

Результат этой операции отличается от результата слияния ветки hotfix . В данном случае процесс разработки ответвился в более ранней точке. Так как коммит, на котором мы находимся, не является прямым родителем ветки, с которой мы выполняем слияние, Git придётся немного потрудиться. В этом случае Git выполняет простое трёхстороннее слияние, используя последние коммиты объединяемых веток и общего для них родительского коммита.

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

Теперь, когда изменения слиты, ветка iss53 больше не нужна. Вы можете закрыть задачу в системе отслеживания ошибок и удалить ветку:

Основные конфликты слияния

Иногда процесс не проходит гладко. Если вы изменили одну и ту же часть одного и того же файла по-разному в двух объединяемых ветках, Git не сможет их чисто объединить. Если ваше исправление ошибки #53 потребовало изменить ту же часть файла что и hotfix , вы получите примерно такое сообщение о конфликте слияния:

Git не создал коммит слияния автоматически. Он остановил процесс до тех пор, пока вы не разрешите конфликт. Чтобы в любой момент после появления конфликта увидеть, какие файлы не объединены, вы можете запустить git status :

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

Это означает, что версия из HEAD (вашей ветки master , поскольку именно её вы извлекли перед запуском команды слияния) — это верхняя часть блока (всё, что над ======= ), а версия из вашей ветки iss53 представлена в нижней части. Чтобы разрешить конфликт, придётся выбрать один из вариантов, либо объединить содержимое по-своему. Например, вы можете разрешить конфликт, заменив весь блок следующим:

В этом разрешении есть немного от каждой части, а строки <<<<<<< , ======= и >>>>>>> полностью удалены. Разрешив каждый конфликт во всех файлах, запустите git add для каждого файла, чтобы отметить конфликт как решённый. Добавление файла в индекс означает для Git, что все конфликты в нём исправлены.

Если вы хотите использовать графический инструмент для разрешения конфликтов, можно запустить git mergetool , который проведет вас по всем конфликтам:

Если вы хотите использовать инструмент слияния не по умолчанию (в данном случае Git выбрал opendiff , поскольку команда запускалась на Mac), список всех поддерживаемых инструментов представлен вверху после фразы «one of the following tools». Просто введите название инструмента, который хотите использовать.

Мы рассмотрим более продвинутые инструменты для разрешения сложных конфликтов слияния в разделе Продвинутое слияние главы 7.

После выхода из инструмента слияния Git спросит об успешности процесса. Если вы ответите скрипту утвердительно, то он добавит файл в индекс, чтобы отметить его как разрешенный. Теперь можно снова запустить git status , чтобы убедиться в отсутствии конфликтов:

Если это вас устраивает и вы убедились, что все файлы, где были конфликты, добавлены в индекс — выполните команду git commit для создания коммита слияния. Комментарий к коммиту слияния по умолчанию выглядит примерно так:

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

Legrand: серия Valena и ее популярные механизмы

Сегодня о том, что такое за серия Valena от Legranda. Насколько она интересна для продажи в небольшом магазине электрики, какие механизмы самые популярные, что стоит держать на складе в больших количествах, а что вообще не завозить. Примерные цены поставщиков

Если в вашем новоиспеченном магазине еще нет Валены, то самое время ее завезти. Эта серия электроустановки от Legrand стара как мир и популярна среди обывателей. На рынке она присутствует с 2003 года. За это время ее внешний вид не поменялся ни на йоту. Французская классика среди розеток и выключателей сегодня осталась в той же поре, что и пятнадцать лет назад. Тот случай, когда ле дизайнеры попали таки в точку, угодив массовому потребителю. Подтверждением привлекательности серии может служить и то, что очень похожие варианты стали выпускать китайцы. А это дорогого стоит.

Десять лет в строю для каких-то там розеток — это много. С производства снимались лишь некоторые цветные рамки. Основная же линейка механизмов не менялась. К примеру, симпатичный мне леграновский «Suno» ушел в небытие. И Летен туда же. Найти их можно только в складских запасах.

Чьё производство?

Серия производится в России и Португалии. На коробках указана такая информация:

Сделано в России: 1-я розетка с заземлением, 1-я, 2-я и 3-я рамки.

Сделано в Португалии: выключатели и переключатели, двойные розетки, диммеры, кнопки, розетки TV, Rg-45 и Rg-11, рамки на четыре и пять постов.

Механизмы на склад

У Валены есть все, что нужно от выключателей и розеток, до USB и Rg45. Но вот положить на склад практичнее будет только основные позиции. Конкретно такие:

• Выключатели одно — и двухклавишный
• Переключатели
• Одинарные и двойные розетки
• Телевизионные механизмы
• Компьютерные и телефонные розетки
• Рамки от 1 до 5 постов

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

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

Перейду к краткому описанию основных механизмов.

Одноклавишный выключатель, переключатель и перекрестник

Как и большинство бытовых выключателей, все трое рассчитаны на 10 ампер. Подключаются проводом на полтора квадрата. Поставляются без рамки в коробке по 10 штук.

К слову про упаковку. У Валены она самая лучшая, что я видел. Коробки удобные, хорошо складируются друг на друга. Каждый механизм сидит в своей ячейке. У остальных производителей все сложено в кучу, так что собрать на место, это ребус. У АВВ тоже раздельно, но менее аккуратная фасовка.

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

1-кл выкл

Строгие формы, лаконичный внешний вид и кодовое название 774301 или 774401.

При установке сначала делается подключение фазного провода. Для этого потребуются только сильные пальцы, поскольку винтов здесь нет, а присутствуют самозажимные клемники по типу Wago. Сила сжатия у них довольно большая. Если провод из стены выходит короткий, то придется помучиться. Один или два выключателя дадутся безпроблемно, а вот когда их десятки, подушечки пальцев хорошо забиваются.

В подрозетнике механизм крепится с помощью лапок. Чтобы их раздвинуть, нужно снять клавишу. Делается это простым вытаскиванием ее из пазов. Для надежности лучше прикручивать железный каркас на винты, через отверстия по краям.

Прикрутили выключатель, затем ставим рамку. Ее нужно просто защелкнуть. В последнюю очередь ставится клавиша.

1-кл перекл.

Идет под кодом 774306 или 774406. У переключателя внешний вид абсолютно тот же, что и у меньшего брата. Разница таится внутри механизма. Там живут три контакта, тогда как у выключателя их два. Покупаются они обычно в паре. Подключается фазный провод к одиночному контакту первого переключателя. Два других контакта подключаются к двум контактам второго переключателя. От одиночного контакта второго механизма фаза уходит к нагрузке. Будет картинка.

1-кл перекр.перекл.

Самый навороченный одноклавишный собрат из всей тройки. Именуется артикулом 774307 или 774407. У перекрестного переключателя на борту четыре контакта. Он всегда ставится между двумя переключателями. Его предназначение в том, чтобы расширить комбинации клавиш при которых лампочка светит либо не светит. Главное не запутаться. Картинка тоже будет.

Примерные цены у поставщиков: 1-кл по 140 руб., 1-кл перекл. по 190 руб., перекрестник по 320 руб.

Двухклавишный выключатель, переключатель и перекрестник

Подключение и установка двухклавишника точно такая же как и у одноклавишника. Разница лишь в том, что отщелкивать две клавишы и подключить нужно три провода.

Переключатель с двумя клавишами ставится там, где две группы светильников нужно включать с двух мест. Подключение аналогично одинарному.

Двухклавишный перекрестник имеет восемь контактов. Ставится в основном между двумя 2-х клавишными переключателями. С его помощью две группы можно включать и выключать уже с трех мест.

Поставщики отгрузят примерно так: 2-кл выкл. по 320 руб., 2-кл перекл. по 269 руб.

Одинарная розетка

Бежевая 774320 и белая 774420. Подключается без Wago, через винты, проводом на 2.5 квадрата. Сначала снимается лицевая панель. Она на одном винте. Подключаются фазный (L), нулевой (N) и земляной (PE) проводники. Розетка ставится в подрозетник. Прикладвается рамка и прикручивается лицевая панель.

Цена поставщика в районе 140 руб.

Двойная

Бежевая 774370 и белая 774470. Внешний вид при первом взгляде может показаться монстроватым. Но альтернативы мало. Такие же ужасные розетки есть, например, у Этюда (обоих видов) и АBB. Причем внешне очень похожи. Многим не нравится большой выступ от стены. Тут конкуренцию по красоте составят турецкий Nilson и китайский Lezard. А так Валеновские двушечки вполне себе розеточки. Но я себе взял все же Nilson.

Закупка в районе 370 руб.

ТВ-розетки

Оконечные и проходные братья шифруются под кодами 774329, 774330 и 774331. Первые две тупиковые, разница только в затухании сигнала, третья дает возможность ответвиться и пойти дальше.

Слабое место этих розеток это их лицевая панель. Если заказывать по нескольку штук, то велика вероятность, что они придут без родной упаковки и будут все поцарапаны. Поэтому советую брать кратно упаковке, то есть по десять штук.

Цена закупки около 370 руб.

Информационные розетки

Плюсы: быстрый монтаж без специнструментов, лицевые панели взаимозаменяемы — можно взять с другого цвета, цветовая маркировка; минус — высокая цена.

У поставщика 1-я компьютерная стоит примерно по 430 руб.

Рамки

Самая разнообразная часть серии. Часто добавляются новые расцветки. Но нам для начала будут интересны три цвета: белый, бежевый (слоновая кость) и алюминий. Из них самыми ходовыми будут однушки и двушки. За них и нужно зацепиться. Все, что выше двушек пользуется меньшим спросом, поэтому их можно держать по минималу или на заказ.

Одинарные и двойные рамки пакуются по десять в коробку. Трешки по две. Остальные по одной.

Отзывы покупателей о серии Valena

За десять лет продажи валеновских механизмов я ни разу не слышал негатива в их адрес. Брак по ним можно пересчитать по пальцам. Поэтому надежность один из козырей этой серии.

Большинство предпочитает цвет «Слоновая кость». Видимо из-за его универсальности. Дизайнеры охотно работают с цветными рамками. Вот только родной каталог не дает полного представления о цвете. Поэтому интересные цвета хорошо бы держать в наличии.

Записки программиста

Некоторое время назад я открыл для себя Git. И знаете, я проникся. То есть, по-настоящему проникся. Теперь я использую Git не только на работе (где я с ним, собственно, познакомился), но и для своих проектиков, которые я стал хранить на BitBucket. Последний начал поддерживать Git относительно недавно. В отличие от GitHub, BitBucket позволяет совершенно бесплатно создавать как открытые, так и закрытые репозитории.

В чем состоит отличие Git от Subversion?

Главное отличие Git от Subversion заключается в том, что Git — распределенная система контроля версий. Звучит ужасающе, но на практике это означает очень простую вещь. Каждый разработчик держит у себя на диске отдельный репозиторий. Обратите внимание — не копию репозитория, не некоторые бранчи, а тупо отдельный и при этом абсолютно полноценный репозиторий.

Пока мы работаем в рамках своего репозитория, все происходит в точности, как в Subversion. Мы коммитим и откатываем изменения, создаем, мержим и удаляем бранчи, разрешаем конфликты и тд. Помимо этого, предусмотрены команды для работы с репозиториями на удаленных машинах. Например, «git push» означает мерж локальных изменений в удаленный репозиторий, а «git pull» — наоборот, мерж изменений из удаленного репозитория в локальный. Обмен данными по сети обычно происходит с использованием протокола SSH.

В результате имеем:

• Git присущи все те же преимущества от использования VCS, что мы получаем в Subversion.
• Git дает нам нормальное шифрование «из коробки», безо всяких танцев с бубнами, как в случае с Subversion.
• Если сервер с «главным» репозиторием, куда пушат свои изменения все разработчики (хотя формально в Git нет никакого «главного» репозитория), вдруг прилег — ничего страшного. Делаем коммиты в локальный репозиторий и ждем, когда сервер вернется.
• Даже если сервер доступен, все равно удобнее сделать пяток локальных коммитов, а затем отправить их на сервер одним пушем.
• Сервер вообще не нужен. Вы можете использовать Git только локально. И не обязательно для работы с исходниками. Например, можно использовать Git для того, чтобы иметь возможность откатиться к предыдущим версиям файлов (каких-нибудь электронных таблиц) или вернуть случайно удаленные.
• Git не раскидывает по каталогам служебную информацию (помните «.svn»?) , вместо этого она хранится только в корне репозитория.
• Git нынче очень моден (хотя это далеко не единственная распределенная система контроля версий, например, есть Mercurial и Darcs), в связи с чем растет число разработчиков, использующих его. Как следствие, используя Git, легче получить помощь на каком-нибудь форуме или собрать команду разработчиков, знакомых с этой VCS.
• Существует множество полезных утилит для работы с Git — Qgit, gitk, gitweb и другие. «Из коробки» есть импорт и экспорт в/из Subversion/CVS.
• Git поддерживают многие хостинги репозиториев (GitHub, BitBucket, SourceForge, Google Code, … ) — есть из чего выбрать.
• Большой популярностью пользуется GitHub. Используя Git, вы увеличиваете вероятность того, что кто-то захочет безвозмездно написать патч для вашего open source проекта.

Пример использования Git

Я использовал Git при написании программы из заметки Генерация почти осмысленных текстов на Haskell, сидя под своей любимой FreeBSD. Вот как примерно выглядела моя работа с Git.

В первую очередь необходимо поставить Git:

Затем создаем пару ssh ключей, если не создавали ее ранее:

Заходим на БитБакет, создаем git-репозиторий под новый проект, а в свойствах аккаунта прописываем свой открытый ssh-ключ. Затем клонируем репозиторий:

/ projects / haskell
git clone git @ bitbucket.org:afiskon / hs-textgen.git
cd hs-textgen

Делаем какие-то изменения:

Добавляем новый файл в репозиторий и делаем коммит:

Поскольку я не указал описание коммита, запускается редактор VIM, с помощью которого я и ввожу описание. Затем я отправляю все сделанные мною изменения на БитБакет:

Допустим, теперь я хочу сделать некоторые изменения в проекте, но не уверен, выйдет ли из этого что-то хорошее. В таких случаях создается новая ветка:

Работаем с этой веткой. Если ничего хорошего не вышло, возвращаемся к основной ветке (она же «trunk» или «ствол»):

Если вышло что-то хорошее, мержим ветку в master (о разрешении конфликтов рассказано в следующем параграфе):

Не забываем время от времени отправлять наш код на BitBucket:

Если мы правим код с нескольких компьютеров, то перед началом работы не забываем «накатить» в локальный репозиторий последнюю версию кода:

Работа в команде мало чем отличается от описанного выше. Только каждый программист должен работать со своей веткой, чтобы не мешать другим программистам. Одна из классических ошибок при начале работы с Git заключается в push’е всех веток, а не только той, с которой вы работали. Вообще я бы советовал первое время перед выполнением каждого push делать паузу с тем, чтобы подумать, что и куда сейчас уйдет. Для большей безопасности советую при генерации ssh-ключей указать пароль. Тогда каждый запрос пароля со стороны Git будет для вас сигналом «Эй, ты делаешь что-то, что затронет других».

Для работы с Git под Windows можно воспользоваться клиентом TortoiseGit. Если память не подводит, для работы ему нужен Git for Windows. Для генерации ключей можно воспользоваться утилитой PuTTyGen. Только не забудьте экспортировать открытый ключ в правильном формате, «Conversions → Export OpenSSH key».

Следует отметить, что мне лично TortoiseGit показался не слишком удобным. Возможно, это всего лишь дело привычки, но мне кажется намного удобнее работать с Git из консоли, чем с помощью контекстного меню в Проводнике.

Шпаргалка по командам

В этом параграфе приведена сухая шпаргалка по командам Git. Я далеко не спец в этой системе контроля версий, так что ошибки в терминологии или еще в чем-то вполне возможны. Если вы видите в этом разделе ошибку, отпишитесь, пожалуйста, в комментариях.

Создать новый репозиторий:

Если вы планируете клонировать его по ssh с удаленной машины, также скажите:

… иначе при git push вы будете получать странные ошибки вроде:

Клонировать репозиторий с удаленной машины:

Если хотим пушить один код в несколько репозиториев:

Добавить файл в репозиторий:

Текущее состояние репозитория (изменения, неразрешенные конфликты и тп):

Сделать коммит, введя его описание с помощью $EDITOR:

Замержить все ветки локального репозитория на удаленный репозиторий (аналогично вместо origin можно указать и remotename, см выше):

Аналогично предыдущему, но делается пуш только ветки master:

Запушить текущую ветку, не вводя целиком ее название:

Замержить все ветки с удаленного репозитория:

Аналогично предыдущему, но накатывается только ветка master:

Накатить текущую ветку, не вводя ее длинное имя:

Скачать все ветки с origin, но не мержить их в локальный репозиторий:

Аналогично предыдущему, но только для одной заданной ветки:

Начать работать с веткой some_branch (уже существующей):

Создать новый бранч (ответвится от текущего):

Переключиться на другую ветку (из тех, с которыми уже работаем):

Получаем список веток, с которыми работаем:

Просмотреть все существующие ветви:

Замержить some_branch в текущую ветку:

Удалить бранч (после мержа):

Просто удалить бранч (тупиковая ветвь):

История изменений в обратном порядке:

История конкретного файла:

Аналогично предыдущему, но с просмотром сделанных изменений:

История с именами файлов и псевдографическим изображением бранчей:

Изменения, сделанные в заданном коммите:

Посмотреть, кем в последний раз правилась каждая строка файла:

Удалить бранч из репозитория на сервере:

Откатиться к конкретному коммиту (хэш смотрим в «git log»):

Аналогично предыдущему, но файлы на диске остаются без изменений:

Попытаться обратить заданный commit:

Просмотр изменений (суммарных, а не всех по очереди, как в «git log»):

Используем vimdiff в качестве программы для разрешения конфликтов (mergetool) по умолчанию:

Отключаем диалог «какой mergetool вы хотели бы использовать»:

Отображаем табы как 4 пробела, например, в «git diff»:

Разрешение конфликтов (когда оные возникают в результате мержа):

Удаление untracked files:

«Упаковка» репозитория для увеличения скорости работы с ним:

Иногда требуется создать копию репозитория или перенести его с одной машины на другую. Это делается примерно так:

Следует отметить, что Git позволяет использовать короткую запись хэшей. Вместо «d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4» можно писать «d8578edf» или даже «d857».

Дополнение: Также в 6-м пункте Мини-заметок номер 9 приводится пример объединения коммитов с помощью git rebase , а в 10-м пункте Мини-заметок номер 11 вы найдете пример объединения двух репозиториев в один без потери истории.

Работа с сабмодулями

Более подробно сабмодули и зачем они нужны объясняется в заметке Простой кроссплатформенный OpenGL-проект на C++. Здесь упомянем самое главное.

Обновление сабмодулей, например, если после git pull поменялся коммит, на который смотрит сабмодуль:

Удаление сабмодуля производится так:

1. Скажите git rm —cached имя_сабмодуля ;
2. Удалите соответствующие строчки из файла .gitmodules;
3. Также грохните соответствующую секцию в .git/config;
4. Сделайте коммит;
5. Удалите файлы сабмодуля;
6. Удалите каталог .git/modules/имя_сабмодуля;

Дополнительные материалы

В качестве источников дополнительной информации я бы рекомендовал следующие:

Как обычно, любые замечания, дополнения и вопросы категорически приветствуются. И кстати, с наступающим вас!