Штробить как: Как и чем штробить стены под проводку: инструктаж по работе

Содержание

Штробление стен: как правильно штробить стены

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

Правила штробления стен

Сам процесс штробления стен не сложен, нарушить технологию трудно. Однако, существуют общие правила штробления стен, а также – частные, касающиеся конкретного места ремонта и цели штробления. Соблюдение подобных основ преследует две цели: безопасность оператора и устойчивость конструкции в дальнейшем. Во время работы используйте защитные средства: очки на глаза спасут от мелкого сора и щепок, а респиратор не даст надышаться пылью, которой в процессе штробления образуется много. Перед началом работы нарисуйте план прокладки труб и проводки, распределите борозды согласно нормативным документам и правилам штробления стен. Получившийся план рекомендую сохранить, он пригодится при следующем ремонте. Если же ремонт в квартире производится не первый раз, сопоставьте план со старой проводкой, используя предыдущую схему или прибор для обнаружения. Не забудьте обесточить старую проводку и перекрыть трубы, чтобы обезопасить себя во время работы.

Как штробить стены

В зависимости от цели штробления, выберите глубину и ширину борозды. Штробление стен под электропроводку производите линиями, паралельными основным конструкциям здания (горизонтальные и вертикальные). Штробление под углом допустимо только в мансардных помещениях. Горизонтальные штробы располагайте близко к потолку или полу, вертикальные штробы – непосредственно под или над розеткой. Длина штробы не превышает 3 м, глубины для электрического кабеля достаточно 25 мм. Поворот кабеля на 90 градусов допустим 1 раз на пути от распределительной коробки к розетке, не считая углов конструкции.

Не пренебрегайте перенесением пути штробления с плана на стену с помощью карандаша, это облегчит работу. По завершении укладки кабеля, тщательно замаскируйте штробу с помощью цементно-песчаной смеси или штукатурки. Штробление стен под трубы отличается параметрами штробы. Кроме того, часто этот вид работ вынуждены выполнять на несущей стене. Чтобы избежать ослабления прочности конструкции, важно соблюдать правила штробления на таких стенах:

  • Глубина штробы не больше 1/3 от ширины стены или не глубже закладки арматуры;
  • Заделка борозды после прокладки труб с особой тщательностью, избегайте пустот.

Способы штробления стен

Способы штробления стен зависят от выбранного инструмента для этого вида работ.

  • Зубило и молоток. Долгий и физический не простой путь. Из плюсов способа – нет необходимости покупать электроинструмент при его отсутствии. Из минусов – затраты времени и сил, кроме того – ровную борозду получить невозможно, материал крошится под ударами.
  • Дрель и зубило. Способ, похожий на предыдущий, только задача упрощается с помощью дрели. Просверлите отверстия одинаковой глубины на пути следования штробы на расстоянии 1-1,5 см друг от друга. С помощью зубило выбейте оставшиеся промежутки.

  • Болгарка. Скорость выполнения работы с болгаркой увеличится в несколько раз. Срез ровный, не осыпающийся. Но и в этом способе имеются недостатки. Штробление стен болгаркой – достаточно пыльная и шумная работа. Каждую борозду придется проходить по 2 раза: сначала одну сторону штробы, затем вторую. И главный минус – нет возможности контролировать глубину борозды, все зависит от ощущений оператора. Для использования болгарки установите алмазный диск на инструмент.

  • Перфоратор. Для штробления стен перфоратором необходимо приобрести специальную насадку – лопатку или штробер. Срез получится не очень ровным, но скорость исполнения – явное преимущество этого способа.
  • Штроборез. Инструмент создавался специально для создания штроб. Штробление стен штроборезом – это быстрая, не пыльная, относительно бесшумная работа, срезы ровные, четко параллельные, заданной глубины. Минус инструмента в высокой цене.

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

16.04.2017

Подписаться на рассылку

Как правильно штробить стены под проводку?

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

Основные правила штробления стен

Перед началом работ необходимо представить и нарисовать план электрической разводки — где будут находиться выводы освещения, выключатели и розетки. К тому же необходимо учесть материал стен и то, каким способом штробление будет производиться. Все основные правила проведения работ можно найти в документе СНиП 3.05.06-85, из которого можно отметить следующие основные моменты:

  1. Штробление обязательно должно производиться параллельно конструкции здания, за исключением являются наклонные стены.
  2. Сведите к минимуму повороты штробы от коробки распределителя до розеток и выключателей. Для этого следует ограничиться одним углом перехода от вертикали к горизонтали.
  3. Вертикальная штроба должна находиться на расстоянии в 10 сантиметров от всех стеновых проемов и углов. От газовой трубы она должна быть сделана не менее чем в 40 сантиметрах.
  4. Горизонтальное штробление можно производить на расстоянии не более чем в 15 сантиметров от плит перекрытия.
  5. Запрещается штробить горизонтальные борозды в несущих конструкциях.
  6. По завершению создания плана проводки по правилам, можно приступать к работе.

Подготовка и разметка стен

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

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

Штробление стен своими руками можно производить, используя следующий инструмент: перфоратор, болгарка, штроборез и зубило.

Штробление стен перфоратором

Для штробления перфоратором следует применять следующие насадки: лопатка, широкий и короткий бур. Первоначально по всей длине намеченных линий проделываются отверстия глубиной в 2.5 сантиметра с шагом в 1-1. 5 сантиметра. После чего, при помощи лопатки, можно приступать к штроблению. Следует отметить, что лопатку не стоит ставить поперек линии штробы, чтобы не захватить лишнее.

Если у Вас еще нет перфоратора и Вы только задумываетесь о его покупке, советуем при выборе обратить внимание на устройства с функцией реверса (обратного хода). Пусть и не часто, но возникает ситуация, когда бур (в особенности длиной более 400 мм) застревает в бетоне. Для этого как раз и пригодится инструмент с обратным ходом.

Штробление стен болгаркой

Если использовать для работы УШМ, то необходимо заранее позаботиться о наличии алмазного диска, который с легкостью справится с кирпичными и бетонными стенами. Первым делом, делаются два параллельных пропила по всей намеченной длине. После чего, при помощи зубила или перфоратора, удаляется весь материал находящийся между этими пропилами. Такой способ аккуратен и будет уместен там, где необходимо максимально сохранить целостность штукатурки. Также, при штроблении стен болгаркой скапливается большое количество пыли.  Чтобы избежать этого вам понадобится помощник, который будет собирать ее при помощи пылесоса. Пылесос лучше выбрать промышленный, так как пыли будет очень много.

Штробление стен штроборезом

Штроборез – специально спроектированный инструмент, представляющий из себя болгарку с двумя режущими дисками, в которой можно регулировать расстояние между ними. Оба круга штробореза закрыты специальными кожухами, с помощью которых можно регулировать глубину реза. К тому же, штроборезы обладают отводом для подключения пылесоса. С его помощью можно создать идеально ровные срезы без пыли. Оставшийся материал между резами следует удалить при помощи зубила или перфоратора.

Штробление стен зубилом и молотком

Сначала при помощи зубила отмечаются углубления по краям будущей штробы. Далее установив зубило поперек выбивается часть стены на небольшую глубину. По завершению производится углубление штробы на необходимую глубину. Однако данный способ не подходит для бетонных стен — они требуют более серьезного оборудования.

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

чем замазать проделанные в стене отверстия после штрорбления в бетонной, деревянной или кирпичной стене

В статье описаны основные правила штробления, рассмотрены особенности проделывания канавок в стенах из различных материалов, перечислены материалы, подходящие для заполнения канавки.

Ровные стены после штробы

Ровно и аккуратно заделать отверстие после работ по замене проводки необходимо для качественного завершения ремонта.

Материал, из которого сделаны стены, определяет последовательность ремонтно-отделочных работ.

Когда потребуется штроба в стенах

Штробление стены требуется при сантехнических работах. Мастер пробивает в стене канавки под провода при необходимости проложить проводку в новостройке или заменить пришедшие в негодность кабеля в старом доме.

Штробление под проводку в стенах: особенности работ на разных поверхностях

Разные поверхности по-разному ведут себя при штроблении. Сложнее всего проделать канавку в бетоне – здесь без перфоратора или штробореза не обойтись! Если же нужно провести проводку в деревянной стене (относительно мягком и податливом материале), линии намечаются болгаркой, канавки же прокладываются молотком и стамеской.

Углубления в пористых бетонах проделываются специальным инструментом (штроборезом). Если стена кирпичная, можно обойтись без выдалбливания канавок, прикрепив проводку дюбелями.

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

Простые правила при штроблении:

  • Вертикальные канавки не должны быть глубже одной трети от общей толщины стены.
  • Горизонтальные канавки делаются глубиной менее одной шестой от толщины стенки.
  • Штробы проводятся по прямой, параллельной линии пола, пересекаться они не должны. Это требование обусловлено здравым смыслом — если штроба слишком глубокая, прочность стены ухудшается. Если канавки пересекаются, страдает монолитность стены.
  • Канавки проводятся или строго вертикально, или строго горизонтально, наклон допустим лишь на непрямых стенах.

В большинстве руководств и инструкций указывается, что штробление несущих конструкций запрещено!

Как заделать дыру после штробления

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

В бетонной стене

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

  • пульверизатора;
  • широкой кисти;
  • губки или куска поролона.

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

Инструмент плотно прижимается к стене. После высыхания замазки поверхность шпаклюется. Для полного высыхания смеси необходимо выждать 6-12 часов.

В кирпичной стене

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

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

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

В монолите

Замазывание штробы в монолитной стене сходно с работами в бетонной стене.

Канавка в монолитной стене заполняется  смесью повышенной вязкости. Раствор забивается в штробы максимально плотно.

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

Чем лучше заделать: лучшие материалы

Выбор материала для заполнения канавки после укладки провода или кабеля — вопрос личного вкуса. Например, строители используют смесь песка и цемента (в соотношении 3:1) для утяжеления замазки.  В то же время эта смесь достаточно пластична. Мастера рекомендуют алебастр, смешанный с клеем ПВА – смесь получается пластичная, повышенной липкости, медленно застывает.

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

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

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

Полезное видео

Как штробить стены под проводку

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

Инструменты для штробления

Если вы ремонтируете только одну из комнат, а в других по прежнему проживаете, то используйте перфоратор и зубило. От штробореза образуется дисперсная пыль, которая проникнет повсюду и может испортить вещи.

Для штробления перфоратором вначале насверлите по размеченной трассе отверстия d-8мм. Расстояния между отверстиями 1см. Затем оденьте на перфоратор насадку для штробления и перейдя в режим удара разбейте между отверстиями штробу.
Безусловно, приобретать штроборез может быть экономически не целесообразно. Однако штробление стен простой болгаркой, довольно опасная работа. Советую даже для работ в одной квартире все же приобрести самый недорогой штроборез. Очень важно, чтобы и для болгарок и для штроборезов использовались качественные диски. В этом случае и на работу уйдет гораздо меньше времени, да и сам процесс работы будет безопаснее

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

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

Если же приобретение комплекта штроборез+пылесос обходится в неподъемную цену, попробуйте взять эти инструменты у профессиональных строителей напрокат. Некоторые умельцы приспосабливают самодельную подачу воды на диски для уменьшения пылеобразования:

Основные нюансы работы при шторблении:

    • перед началом работы удаляйте с поверхности стен все лишнее (старые обои, плакаты) – они могут забить штроборез;
    • перед штроблением проверяйте трассу будущей штробы на отсутствие старой проводки. Сделать это можно специальным инструментом. При возможности запитайте эл.инструмент от соседей, а свою квартиру полностью обесточьте;
    • штроба должна проходить параллельно конструкциям здания – горизонтально или вертикально;
    • вертикальная штроба режется сверху-вниз;
    • расстояние горизонтальной штробы от потолка – не более 40см;
  • расстояние вертикальной штробы от дверей, окон, углов – не менее 10см;
  • максимальная глубина штробы – 2,5см;
  • если наткнулись на арматуру, измените трассу штробы. Вырубая арматуру, Вы нарушаете целостность плит, снижая несущую способность здания;
  • старайтесь нарезать узкие штробы шириной 3-5мм, чтобы поместился один кабель. При укладке нескольких кабелей в одной штробе, ее ширина увеличивается на ширину прокладываемых кабелей.

Ширина штробы

Минусы широкой штробы:

  1. ее нужно прорезать
  2. выбить бетон
  3. насверлить отверстия 6мм под дюбель хомут
  4. прибить кабель
  5. заштукатурить штробу, используя большое количество раствора и времени

Плюсы узкой штробы:

  1. прорезаете штробу
  2. для очистки штробы максимум используете усилие мощной отвертки или узкого зубила
  3. сверлить отверстия и прибивать кабель не нужно
  4. используете минимальное количество цементного раствора
  5. экономите время

Средства защиты

При штроблении не забывайте про технику безопасности. Обязательно используйте:

  • перчатки
  • наушники
  • защитные очки
  • респиратор
  • устойчивые стремянки

По окончании работ очистите штробы от пыли пылесосом или веником.

Посмотреть текущие цены на штроборезы и насадки для штробления под болгарку можно здесь или здесь.

Статьи по теме

Штробление несущих стен: сложности, инструменты, инструкция

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

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

Нюансы при создании штроб в несущих стенах

Штробление несущей стены запрещено, потому что в ней проходит стальная арматура, принимающая на себя значительную нагрузку. Прутья обычно располагаются вертикально и проходят под защитным слоем на некоторой удаленности от поверхности. Это значение составляет 30 мм максимум. Даже если подумать логически, что при штроблении, где паз будет уложен на глубину 3 см и больше, арматуру можно повредить, что снизит несущую способность стены, перекрытия и всего дома. В помещениях такой постройки проживать будет уже небезопасно.

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

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

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

В чем могут быть сложности

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

Если вы хотите ближе ознакомиться с нормами, согласно которым осуществляется распределение проводки в стенах, следует прочесть СНиП 3.05.06-85. Из этих нормативных документов вы сможете узнать, что пазы должны располагаться строго вертикально или горизонтально. Проводка не должна проходить близко к плитам перекрытия, но решить эту проблему можно, удалив ее на 15 см. Если вам во что бы то ни стало нужно осуществить штробление несущих стен, то вы должны помнить, что особенно опасной будет прокладка горизонтальных борозд.

Опасность скрытой прокладки труб

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

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

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

Опасность скрытой укладки проводки

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

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

Инструменты и приспособления для выполнения штроб

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

  • молоток и зубило;
  • дрель;
  • перфоратор;
  • болгарку;
  • штроборез.

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

Особенности и правила штробления

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

Длина одной штробы не должна быть больше 3 м. Если вы работаете в условиях мансарды, то пазы следует располагать параллельно стыку поверхностей. Если в помещении есть газовые трубы, штробление следует начинать, удалившись от них на 40 см. Удалиться от углов и оконных проемов необходимо на 1, 5 м.

Горизонтальные пазы должны быть удалены от плит перекрытия на 15 см. Штробление несущей стены под канализацию и какие-либо другие коммуникации запрещено согласно СНиП. Если трубы у несущих стен все же проложить нужно, их располагают рядом, у пола, закрывают коробом и обкладывают плиткой.

Как должны располагаться каналы

Если возможно, каналы лучше расположить в слое штукатурки, тогда штробление осуществлять и вовсе не придется, тем более, заниматься несущими стенами. Когда работы ведутся с перегородками, допустимыми параметрами углубления являются 30 и 25 мм в ширину и глубину соответственно. При установке кондиционера, углубить коммуникации можно на 50 мм, тогда как ширина штробы должна составить 60 мм максимум.

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

Полезные советы профессионалов

  • До начала работ обязательно следует убедиться в том, что в стене нет скрытой проводки. Для этого используют специальное оборудование. Новый план следует изобразить на чертеже и оставить его на тот случай, если понадобится просверлить стену или осуществить над ней какие-либо действия.
  • Выбор способа проведения работ будет зависеть от финансовых возможностей и наличия инструментов. Наиболее дешевым, но трудоемким подходом окажется применение зубила и молотка. Будущую штробу необходимо разделить на сегменты, пройдясь по намеченным линиям зубилом. Инструмент устанавливается вдоль края. Затем его следует установить поперек, чтобы выбить нужную глубину.
  • Работы пойдут быстрее, если использовать дрель с ударной функцией или перфоратор. С последним можно использовать насадки в виде лопатки или бура. Здесь принцип будет несколько другим. Он заключается в проделывании множества отверстий на глубину до 20 мм. Затем промежутки между отверстиями удаляются лопаткой перфоратора. Ее следует ставить вдоль линии. В противном случае можно столкнуться с выбиванием лишнего материала, что после потребует большего количества смеси для заделки.
  • Если не боитесь пыли, но не хотите тратится на штроборез, в том числе, его аренду, можно воспользоваться углошлифовальной машиной. Она позволяет добиться ровных краев штробы. Такой способ больше всего подходит для того этапа ремонта, когда осуществляются черновые работы, и пыль для помещений не так страшна. Если же манипуляции проводятся на том этапе, когда в других помещениях уже есть чистовой ремонт, вы должны быть готовы к тому, что с образовавшейся пылью сложно будет справиться даже с помощью пылесоса.

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

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

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

Как сделать штробу в бетоне: перфоратором, болгаркой

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

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

Чем и как сделать штробу в бетоне:

  1. Зубило и молоток – просто и дешево, но неудобно и долго. Даже при условии наличия определенных навыков и сноровки штробы получаются кривыми, выполняются трудоемко. Но зато не нужно покупать никакого инструмента, тратиться на расходники и т.д.
  2. Перфоратор – процесс идет быстро, но штроба часто получается с неровными краями.
  3. Болгарка – дает огромное количество пыли, которая потом с трудом убирается даже строительным пылесосом. Зато углубления получаются ровными, работа идет быстро.
  4. Штроборез – самый лучший и дорогостоящий вариант. Для одноразового применения получается очень затратно, зато штробы создаются ровными, без пыли и сильного шума, быстро.

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

Как сделать штробу в бетонной стене

Основным документом, регулирующим особенности выполнения штроб в бетонной стене любым инструментом, является СНиП 3.05.06-85. В нем указаны правила создания электрической проводки, все расстояния и основные требования по безопасности. Проигнорировав их, можно не только поставить под угрозу комфорт и безопасность проживания людей в помещении, но и быть оштрафованным.

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

Нормативные требования СНиП для штробления стен под проводку:

  • Нельзя штробить несущие стены.
  • Каналы нужно прокладывать параллельно конструктивам: горизонтально или вертикально, по диагонали штробить нельзя.
  • Расстояние между потолком и штробой должно составлять минимум 15 сантиметров.
  • До газовой трубы должно быть расстояние минимум 40 сантиметров.
  • Глубина штробы – не более 2.5 сантиметров.
  • Прежде, чем прокладывать новую проводку, нужно проверить стены на наличие старой (если это не новострой).
  • Штробы прокладываются исключительно вертикально/горизонтально, никаких косых линий не допускается. Исключением может стать необходимость прокладки проводки на стенах с уклоном (мансарда, к примеру), когда магистраль можно вести параллельно наклону стены.
  • Поворачивать штробу между двумя точками можно лишь единожды: каждый поворот представляет собой перегиб кабеля, который сильнее греется в таких местах. И если поворотов будет очень много, повышается опасность эксплуатации.
  • По размеру штробы должны быть такими: по ширине 3 сантиметра максимум, по глубине не более 2.6 сантиметров. Общая длина магистрали от распределительной коробки до точки не должна быть больше 3 метров.
  • Оптимальные отступы: от батарей и газовых труб 40 сантиметров, до двери 10 сантиметров, от пола – минимум 5 сантиметров (но лучше 10).
  • Запрещено в процессе штробления касаться железобетонных конструкций, если же это делать, то так, чтобы не задеть арматурный каркас и с минимальной глубиной канавки.
  • Штробить внутренние несущие стены запрещено, на первых этажах работы выполняют очень аккуратно, так как тут стены держат все здание.
  • Штробление в потолке реализуется с расчетом наиболее короткого пути до точки освещения.
  • Прорезать канавки в напольных плитах запрещено. Когда проводят магистраль по полу, то делают ее в бетонную стяжку, которая заливается с учетом необходимости прокладки борозд.
  • В процессе выполнения работ обязательно заботятся о средствах личной защиты – для этих целей подойдут респиратор или маска.

Чем и как сделать штробы в стенах

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

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

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

Болгарка УШМ

Сначала места прохождения штроб размечают, потом начинают работу.

Как сделать штробы болгаркой:

  • Присоединить специальный диск к инструменту, который предназначен именно для резки бетона.
  • Сделать два пропила параллельно один другому на расстоянии примерно 5 миллиметров.
  • Выдолбить канавку между пропилами перфоратором.

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

Перфоратор

Штробление перфоратором создает очень много дисперсной пыли, которая распространяется везде, может портить мебель и вещи. Мастеру нужно использовать средства защиты.

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

Молоток и зубило

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

Как сделать штробу молотком и зубилом:

  • Прорубить вдоль размеченных линий на участке длиной 20-50 сантиметров две канавки глубиной в 2 сантиметра. Зубило нужно ставить перпендикулярно поверхности стены, монолит просто пробивать с усилием.
  • Выбить штробу между канавок, установив под углом будило и просто откалывая по кускам материал.
  • Продолжить таким же образом делать штробы по всем разметкам.

Дрель

Можно штробить и дрелью, если заранее позаботиться про три насадки – лопатку и два бура различной длины. Сначала просверливают отверстия на глубину 2.5 сантиметров по намеченной линии с шагом в 1-1.5 сантиметров. Потом бур меняют на лопатку, идут от точки к точке по борозде, создавая сплошную магистраль нужной ширины и глубины. Некрасивый внешний вид штроб потом аккуратно маскируют шпатлевкой.

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

Штроборез

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

Штроборез оснащен двумя пильными дисками, которые нужно выставить на нужное расстояние друг от друга, по высоте (регулирование глубины пропила). Вертикальные штробы обычно делают сверху вниз, так как инструмент обладает немалым весом. Он пропиливает одновременно две параллельные канавки в стене, потом материал между ними выбивается – и идеально ровные, красивые штробы готовы.

Как проштробить стену под проводку

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

Порядок работ

Сначала составляют подробный план работ, намечают основные этапы, тщательно все рассчитывают и продумывают.

Основные этапы создания штроб для электропроводки:

  • Определение мест расположения розеток, выключателей, подводки проводов освещения и т.д. План рисуют тщательно, отмечая каждый элемент и место его расположения (с учетом вышеперечисленных правил и требований СНиП).
  • Разработка трасс в соответствии с местами расположения основных элементов.
  • Перенос плана на стены маркером или карандашом. Как это сделать: отметить места расположения элементов (светильников, бра, люстр, выключателей, розеток и т.д.), вертикально от них вверх провести линии, не доходя до угла с полотком, отметка мест установки распределительных коробок, которые соединяются горизонтально прямой линией и идут до электрошкафа.
  • Проверка всех мест, где будет проводиться сверление (и штроб, и углублений для подрозетников) на предмет наличия старой проводки с использованием детектора. Если найдены металлический каркас или линии, нужно откорректировать план и обойти их.
  • После того, как план с корректировками перенесен на стену, можно начинать штробление: сначала делают отверстия для распределительных коробок и подрозетников, потом они соединяются штробами.
  • После того, как все сделано, замеряются расстояния и вносятся в план.
  • Далее прокладываются кабели, фиксируются в штробах. Все кабеля должны быть проверены на целостность изоляции до прокладки и после.
  • Штробы заделываются раствором, далее снова проверяют кабеля, монтируют внешние части элементов.

Размечаем стены под штробы

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

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

  • Подготовить инструменты – это могут быть как современные приборы (лазерные, электронные дальномеры), так и обычные средства (маркеры, карандаши или мелки, линейка или рулетка, отвес и уровень, строительный шнур).
  • Обозначение маркером мест расположения светильников на потолке, розеток и выключателей на стене, распределительных щитка/коробок. Измерение указанных на плане расстояний. Желательно очерчивать границы для штробления по образцам кабелей, коробок подрозетников.
  • Выбор ширины штробы в соответствии с кабелем (тут В – это ширина, Н – высота). Для трехпроводного кабеля сечения 0.75-4 миллиметров от коробки до подрозетника штробу делают шириной 1 сантиметр и глубиной 1.5 сантиметра.
  • Возможные отклонения, которые должны учитываться при разметке: высота полов подымается после заливки и настила покрытия, потолки опустятся после установки подвесных/натяжных конструкций, стены могут менять конфигурацию после выравнивания штукатуркой, гипсокартоном. Также стоит делать поправки на кривизну стен, которую нередко можно наблюдать в старых и новых домах.
  • Первый метод выполнения разметки – нанести прямые линии обивочным шнуром: сначала нужно натянуть между двумя точками пропитанный любым цветным порошком строительный шнур на расстоянии 1 сантиметр от стены, потом шнур оттянуть и резко отпустить. Для качественной натяжки можно использовать гвозди, саморезы, дюбеля из стали.
  • Второй метод разметки – отметить 2 контрольные точки с обязательным использованием уровня, провести между точками мелом строго вертикальную/горизонтальную линию.
  • Третий метод разметки – применение лазерных приборов, которые лучами отсвечивают четкие линии в вертикальной/горизонтальной плоскостях.
  • Для нанесения разметки на потолок используют разные методы, но сначала определяют центральную точку на поверхности (проводят 2 прямые линии от углов по диагонали, беря точку их пересечения за центр).

Особенности железобетонных стен

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

Также можно выполнить открытую проводку – сделать в виде ретро или проложить провода в специальные кабель-каналы. Можно привлечь дизайнера, который сделает коммуникации частью интерьера. В Москве и регионах отыскать профессионала не составит труда.

Изготовление борозды по бетону

Для выполнения штроб в бетоне используются различные инструменты – молоток и зубило, болгарка, перфоратор, штроборез. Электроинструмент ускоряет процесс, но понижает уровень безопасности и может провоцировать появление большого количества пыли. Штроборез стоит дорого, но зато позволяет выполнить работы быстро, качественно, беспыльно практически. Каждый мастер выбирает подходящий для него метод создания штроб и реализует поставленную задачу.

Работа по газобетону

Для создания штроб в газобетоне могут использоваться все те же методы, что и для обычного бетона. Но лучше всего выбирать специальный штроборез для пено/газоблоков, который делает сразу две канавки. Единственный минус в работе с газобетоном – появление огромного объема пыли, который в случае с применением штробореза уходит в специальный отсек, в других случаях обязательно использование промышленного пылесоса.

Штробление без пыли

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

Советы мастеров для уменьшения количества пыли:

  • Увлажнять поверхность регулярно в процессе.
  • Применять бытовой пылесос.
  • Использовать штроборез с уже подключенным к нему пылесосом – в устройстве предусмотрен специальный кожух, который закрывает оба диска и изолирует пространство резки, в то время, как пыль вытягивается через отвод пылесоса.
  • Мокрая резка бетона болгаркой – используется шланг, который беспрерывно подает воду на диск, всю площадь резки. Но тут нужно проявлять внимательность, так как если вода попадет на инструмент, она его испортит.

Монтаж кабеля и установка розеток

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

Розетки лучше всего монтировать в одну рамку блоками, туда же могут подсоединяться разъемы для телефона, Интернета, кабельного ТВ. Отверстия для подрозетников, выключателей и других элементов выполняют перфоратором (в ударном режиме) со специальными алмазными коронками нужного диаметра. Потом элементы монтируют по инструкции, заделывают все аккуратно.

Как заделывают углубления перед финишной отделкой:

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

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

Есть ли база данных с git-подобными качествами?

Переполнение стека

  1. Около
  2. Товары

  3. Для команд
  1. Переполнение стека
    Общественные вопросы и ответы

  2. Переполнение стека для команд
    Где разработчики и технологи делятся частными знаниями с коллегами

  3. Вакансии
    Программирование и связанные с ним технические возможности карьерного роста

  4. Талант
    Нанимайте технических специалистов и создавайте свой бренд работодателя

  5. Реклама
    Обратитесь к разработчикам и технологам со всего мира

  6. О компании

Загрузка…

сортировать теги git по дате

Когда вы вводите git tag , он покажет вам все теги репозитория, отсортированные в алфавитном порядке. Но на самом деле имеет смысл видеть теги, отсортированные по дате добавления тегов. К сожалению, в настоящее время нет такой подкоманды git, которая легко справилась бы с этим. Итак, мы напишем свой:

1. Основы

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

  git для каждой ссылки --sort = taggerdate --format '% (тег)'
...
v1.51
v1.52
Версия 1.52.1
v1.53
v1.54
  

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

2. Подробный вывод

Как вы уже, наверное, догадались, параметр –format отвечает за расширение информации. Полный список всех возможных значений можно найти в man git-for-each-ref.

На данный момент мы используем: имя тега, дату тегирования, имя теггера и сообщение тега:

  git for-each-ref --sort = taggerdate --format '% (tag)% (taggerdate: raw)% (taggername)% (subject)' ссылки / теги
...
v1.51 1438592208 +0200 Имя Фамилия Выпуск v1.51
v1. 52 1439215948 +0200 Jane Doe Release v1.52
v1.52.1 14396 +0200 John Doe Release v1.52.1
v1.53 1440673885 +0200 Cytopia Release v1.53
v1.54 1442223780 +0200 Cytopia Release v1.54
  

Теперь у нас есть дополнительная информация, но она не очень ясна.

3. Украсить

Прежде чем мы сможем применить нашу командную строку-fu к вышеприведенному выводу, мы поставим четкую цель:

  • Выровнять каждый столбец по вертикали
  • Показать дату в удобочитаемой форме

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

  • Тег может иметь переменную длину
  • Имя теггера также разделяется пробелами

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

Итак, первым делом нужно отделить все остальное чем-то другим, кроме пространства, что в некотором роде уникально:

  git for-each-ref --sort = taggerdate --format '% (tag) _ ,,, _% (taggerdate: raw) _ ,,, _% (taggername) _ ,,, _% (тема) 'ссылки / теги
. ..
v1.51 _ ,,, _ 1438592208 +0200 _ ,,, _ Имя Фамилия _ ,,, _ Выпуск v1.51
v1.52 _ ,,, _ 1439215948 +0200 _ ,,, _ Jane Doe Plocke _ ,,, _ Выпуск v1.52
v1.52.1 _ ,,, _ 14396 +0200 _ ,,, _ John Doe _ ,,, _ Выпуск исправления v1.52.1
v1.53 _ ,,, _ 1440673885 +0200 _ ,,, _ Cytopia _ ,,, _ Выпуск v1.53
v1.54 _ ,,, _ 1442223780 +0200 _ ,,, _ Cytopia _ ,,, _ Выпуск v1.54
  

Выглядит более машиночитаемым. И теперь мы можем применить к нему некоторую магию awk:

  git for-each-ref --sort = taggerdate --format '% (tag) _ ,,, _% (taggerdate: raw) _ ,,, _% (taggername) _ ,,, _% (тема) 'ссылки / теги \
  | awk 'BEGIN {FS = "_ ,,, _"}; {printf "% -20s% -18s% -25s% s \ n", $ 2, $ 1, $ 4, $ 3} '
...
1438592208 +0200 v1.51 Release v1.51 FirstName LastName
1439215948 +0200 v1.52 Выпуск v1.52 Джейн Доу
14396 +0200 v1.52.1 Hotfix Release v1.52.1 John Doe
1440673885 +0200 v1.54 Выпуск v1.53 Cytopia
1442223780 +0200 v1.55 Выпуск v1.54 Cytopia
  

Так что он делает?

с FS мы устанавливаем разделитель полей для awk на тот, который мы добавили в раздел –format в git.

  'НАЧАТЬ {FS = "_ ,,, _"}' ...
  

Нет, мы переупорядочиваем и печатаем столбцы.Printf comm

Понимание Git (часть 1) — объясните, как будто я пятерка

Непонятный беспорядок веток. Фото Брэндона Грина.

→ Понимание Git (часть 1) — Объясни, как будто я пять
Понимание Git (часть 2) — Участие в команде
Понимание Git (часть 3) — Разрешение конфликтов (следите за обновлениями!)

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

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

Зачем нужен еще один гид?

Уже существует множество «руководств по git», но большинство из них просто говорят вам копировать / вставлять определенные вещи для выполнения разовых задач. Любой, у кого есть клавиатура, может копировать / вставлять; Чтобы действительно понять, как работает git и что он может для вас сделать, вам нужно немного более глубокое понимание.

Они также склонны кидаться в вас словарями, не объясняя, что эти слова на самом деле означают.

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

Что такое git?

Прежде всего, GitHub — это , а не git. Многие люди по понятным причинам путают их. GitHub — это веб-сайт для размещения проектов, которые используют git.

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

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

Git — не единственная существующая система контроля версий, но, безусловно, самая популярная. Многие разработчики программного обеспечения используют git ежедневно, и понимание того, как им пользоваться, может существенно улучшить ваше резюме.

В сложных проектах, где несколько человек могут одновременно вносить изменения в одни и те же файлы, легко попасть в странное состояние. Это может подтвердить любой, кто имел дело с «конфликтами слияния» и сбивающими с толку символами >>>>>>> ======= <<<<<<< .

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

Как получить git

Git устанавливается по умолчанию во многих системах. Если у вас его еще нет:

  • Вы можете загрузить интерфейс командной строки (CLI) git здесь. Я рекомендовал это как новичкам, так и опытным пользователям.
  • Если вы предпочитаете вместо этого использовать модный графический интерфейс пользователя (GUI), попробуйте GitHub Desktop (для Windows и Mac).Так будет проще использовать, но будет сложнее увидеть, что происходит.

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

ℹ️ Для использования интерфейса командной строки введите терминал . Если вы не знакомы с терминалами, ничего страшного - сначала попробуйте это (или поищите помощь в Google).

Общие команды

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

Примечания:

  • Любой жаргон будет выделен жирным шрифтом при первом описании. Не стесняйтесь искать эти термины в официальном глоссарии git или справочном руководстве для получения более подробной информации.
  • Это упрощенное руководство. Он пытается быть максимально точным, избегая при этом некоторых беспорядочных деталей.В конце есть ссылки для более подробной информации.
  • ✨ В описаниях будут новые идеи, поэтому обязательно продолжайте читать.

Вот некоторые из наиболее распространенных команд, примерно в том порядке, в котором вы их будете встречать:

Запустите свой собственный репозиторий с нуля (в любой существующей папке на вашем компьютере):

Это создаст скрытый . Папка git внутри вашей текущей папки - это «репозиторий» (или репо ), где git хранит все свои внутренние данные отслеживания.Любые изменения, внесенные вами в любые файлы в исходной папке, теперь можно будет отслеживать.

✨ Исходная папка теперь называется вашим рабочим каталогом , в отличие от репозитория (папка .git ), который отслеживает ваши изменения. У вас , работа в рабочем каталоге. Просто!

Клонировать существующее репо:

Это загрузит репозиторий .git из Интернета (GitHub) на ваш компьютер и извлечет последний снимок репо (все файлы) в ваш рабочий каталог.По умолчанию все это будет сохранено в папке с тем же именем, что и репо (в данном случае emoji-commit-messages ).

✨ Указанный здесь URL-адрес называется удаленным источником (место, откуда были загружены файлы , откуда были загружены файлы ). Этот термин будет использоваться позже.

Просмотр текущего статуса вашего проекта:

Будет напечатана некоторая основная информация, например, какие файлы были недавно изменены.

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

Создайте новую ветку имя:

 git branch  

Вы можете думать об этом как о создании локальной «контрольной точки» (технически называемой ссылкой ) и присвоении ей имени. Это похоже на команду Файл> Сохранить как… в текстовом редакторе; новая создаваемая ветка является ссылкой на текущее состояние вашего репо. Как вы скоро увидите, имя ветки можно будет использовать в других командах.

Подобно ветвлению, чаще вы сохраняете каждую контрольную точку по мере продвижения в виде коммитов (скоро см. git commit ниже).

Коммиты - это особый тип контрольной точки, называемый ревизией . Имя будет представлять собой случайный хэш цифр и букв, например e093542 . Затем этот хеш можно использовать в различных других командах, например в именах веток.

✨ Это действительно основная функция git: сохранять контрольные точки (версии) и делиться ими с другими людьми.Все вращается вокруг этой концепции.

Если вы когда-либо создавали контрольную точку для чего-либо, вы сможете вернуться к ней позже, если ваша папка .git не повреждена. Это волшебно. См. git reflog , если вы хотите узнать больше.

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

Проверить конкретную ветку:

 git checkout  

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

⚠️ Имейте в виду, что любые изменения в вашем рабочем каталоге будут сохраняться. См. git stash , если вас интересует простой способ избежать головной боли.

😎 Вы можете использовать флаг -b как ярлык для создать новую ветку, а затем проверить ее за один шаг. Это довольно часто:

 git checkout -b <имя новой ветки> 

Просмотр различий между контрольными точками:

 git diff <имя ветки> <имя другой ветки> 

После редактирования некоторых файлов , вы можете просто ввести git diff , чтобы просмотреть список внесенных вами изменений.Это хороший способ перепроверить свою работу перед ее фиксацией.

Для каждой группы изменений вы увидите, как файл , использовавшийся до , выглядел (с префиксом и окрашен красным), а затем то, как он выглядит сейчас (с префиксом + и окрашен в зеленый цвет).

Более сложные примеры этой команды см. Ниже.

Этап ваши изменения для подготовки к их фиксации:

После редактирования некоторых файлов эта команда пометит все внесенные вами изменения как «подготовленные» (или «готовые к фиксации»).

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

Если вы не уверены, просто введите git status еще раз, чтобы узнать, что происходит. Вы увидите сообщение «Изменения, которые необходимо зафиксировать:», а затем имена файлов, отмеченные зеленым цветом. Ниже вы увидите сообщение «Изменения, не предназначенные для фиксации:», а затем имена файлов, выделенные красным.Они еще не поставлены.

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

 git add README.md app / *. Txt 

Это добавит файл README.md , а также каждый файл в папке app , заканчивающийся на .txt . Обычно вы можете просто ввести git add --all , чтобы добавить все, что изменилось.

Зафиксируйте ваши поэтапные изменения:

Это откроет текстовый редактор командной строки по умолчанию и попросит вас ввести сообщение фиксации .Как только вы сохраните и выйдете, ваша фиксация будет сохранена локально.

Сообщение о фиксации важно, чтобы помочь другим людям понять, что было изменено и почему вы это изменили. Здесь есть краткое руководство, объясняющее, как писать полезные сообщения о фиксации.

😎 Вы можете использовать флаг -m как ярлык для написания сообщения. Например:

 git commit -m «Добавить новую функцию» 

Нажмите на свою ветку, чтобы загрузить ее в другое место:

 git push origin <имя-ветки> 

Это загрузит вашу ветку на удаленный с именем origin (помните, что это URL-адрес, изначально определенный во время клона ).

После успешного нажатия на ваши товарищи по команде смогут потянуть вашу ветку, чтобы просмотреть ваши коммиты (см. git pull ниже).

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

✨ Как упоминалось ранее, все в git можно рассматривать как контрольную точку.Вот список типов контрольных точек, о которых вы знаете сейчас (опять же, они технически называются «ссылками» и «исправлениями»):

  • HEAD
  • , например master
  • , например e093542d01d11c917c316bfaffd6c4e5633aba58 (или e093542 для краткости)

Также есть:

  • <имя-тега> , например v1. , ~ и @ {} .Они весьма полезны; узнать больше здесь.

    Получить последнюю информацию о репо:

    Это загрузит последнюю информацию о репо из происхождения (например, все различные ветки, хранящиеся на GitHub).

    Он не изменяет ни один из ваших локальных файлов - просто обновляет данные отслеживания, хранящиеся в папке .git .

    Объединить с изменениями от кого-то еще:

     git merge  

    Это примет все коммиты, существующие в ветке other-branch-name , и интегрирует их в вашу текущую ветку.

    ⚠️ При этом используются данные о ветвях, хранящиеся локально, поэтому убедитесь, что вы сначала выполнили git fetch , чтобы загрузить последнюю информацию.

    Например, если кто-то еще добавляет несколько коммитов в ветку master из origin , вы можете сделать следующее, чтобы загрузить их изменения и обновить свою локальную ветку master :

     git checkout master # Убедитесь, что ты на правильной ветке.  
    git fetch # Загрузить любую новую информацию из источника.
    git merge origin / master # Слить ветку 'origin / master'
    с вашей текущей веткой.

    ✨ Имя origin / master здесь буквально означает контрольную точку origin / master на вашем компьютере. Git использует эту нотацию, чтобы различать одноименные ветки (например, master ), расположенные в разных местах (например, ваши собственные ветки по сравнению с ветвями origin ).

    😎 В качестве ярлыка вы можете использовать команду pull для fetch и merge все за один шаг.Это чаще, чем слияние вручную, как указано выше:

    Здесь мы разделяем слова origin и master (без косой черты, как указано выше). Мы не хотим использовать контрольную точку origin / master на нашем собственном компьютере, потому что она хранится в автономном режиме и, вероятно, устарела. Вместо этого мы хотим получить данные непосредственно из master ветки удаленной конечной точки с именем origin . Не спускайте глаз; разница важна!

    Для более глубокого понимания того, как работает слияние и как разрешаются конфликты (с забавными изображениями и графиками), см. Официальную документацию по слиянию.Это также будет подробно рассмотрено в части 3 этой серии.

    Пример из реальной жизни

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

     git clone https://github.com/cooperka/emoji-commit-messages.git 
    cd emoji-commit-messages
    git status
    git checkout -b my-new-feature
    echo «Это классный новый файл. »> Мой файл.txt
    git status
    git add --all
    git status
    git diff HEAD
    git commit -m «Добавить my-file.txt»
    git status
    git log
    git push origin HEAD
    git checkout master
    git pull

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

    Что теперь?

    Теперь вы знаете все, что нужно знать о git!

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

    Как только вы разберетесь с этими основными командами, вы можете и должны продолжать изучать больше на веб-сайте git или в этом более продвинутом руководстве.

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

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

    Связанные
    Теги

    Присоединяйтесь к Hacker Noon

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

    О компании - Git

    1. Ветвление и слияние
    2. Маленький и быстрый
    3. Распространено
    4. Гарантия данных
    5. Плацдарм
    6. Бесплатный и открытый исходный код
    7. Товарный знак

    Ветвление и объединение

    Особенность Git, которая действительно отличает его от почти всех других SCM, - это модель ветвления.

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

    Это означает, что вы можете делать такие вещи, как:

    • Простое переключение контекста . Создайте ветку, чтобы опробовать идею, сделайте несколько коммитов, вернитесь туда, откуда вы разветвились, примените патч, вернитесь туда, где вы экспериментируете, и объедините его.
    • Кодекс на основе ролей . Имейте ветку, которая всегда содержит только то, что идет в производство, другую, в которую вы объединяете работу для тестирования, и несколько меньших веток для повседневной работы.
    • Рабочий процесс на основе функций . Создавайте новые ветви для каждой новой функции, над которой вы работаете, чтобы вы могли легко переключаться между ними, а затем удаляйте каждую ветку, когда эта функция будет объединена с вашей основной строкой.
    • Одноразовые эксперименты .Создайте ветку, чтобы поэкспериментировать, понять, что она не будет работать, и просто удалите ее, отказавшись от работы, и никто больше ее не увидит (даже если вы тем временем подтолкнули другие ветки).

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

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

    Маленький и быстрый

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

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

    Контрольные точки

    Давайте посмотрим, как общие операции складываются с
    Subversion, общая централизованная система контроля версий, похожая на
    в CVS или Perforce. Меньше значит быстрее.

    Для тестирования большие инстансы AWS были настроены в одной зоне доступности.
    На обеих машинах были установлены Git и SVN, репозиторий Ruby скопирован на
    как на серверах Git, так и на SVN, и на обоих выполнялись общие операции.

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

    Все это время в секундах.

    Журнал) истории одного файла (array.c - 483 оборотов)

    Эксплуатация Git SVN
    Файлы фиксации (A) Добавление, фиксация и отправка 113 измененных файлов (2164+, 2259-) 0,64 2,60 4x
    Изображения фиксации (B) Добавление, фиксация и отправка тысяча изображений размером 1 кБ 1,53 24.70 16x
    Diff Current Diff 187 измененных файлов (1664+, 4859-) по сравнению с последней фиксацией 0,25 1,09 4x
    Diff Последние Diff против 269 Diff против 26 изменено / 3609 +, 6898-) 0,25 3,99 16x
    Различия тегов Различия двух тегов друг против друга (v1. 9.1.0 / v1.9.3.0) 1,17 83,57 71x
    Журнал (50) Журнал последних 50 коммитов (19 КБ вывода) 0.01 0,38 31x
    Журнал (все) Журнал всех коммитов (26,056 коммитов - 9,4 МБ вывода) 0,52 169,20 325x
    Журнал (Файл 0,60 82,84 138x
    Обновление Сценарий Pull of Commit A (изменено 113 файлов, 2164+, 2259-) 0,90 2.82 3x
    Автор Строчная аннотация одного файла (array.c) 1,91 3,04 1x

    Обратите внимание, что это лучший сценарий для SVN - сервер без нагрузки с
    гигабитное подключение к клиентской машине. Почти все эти
    времена были бы еще хуже для SVN, если бы это соединение было медленнее, в то время как
    многие времена Git не будут затронуты.

    Очевидно, что во многих из этих распространенных операций управления версиями Git является
    на один-два порядка быстрее, чем SVN
    , даже в идеальных условиях
    для SVN.

    Одно место, где Git работает медленнее, - это начальная операция клонирования.
    Здесь Git загружает всю историю, а не только последние
    версия. Как видно из приведенных выше диаграмм, для операции это не намного медленнее.
    это выполняется только один раз.

    Эксплуатация Git * Git SVN
    Клон Клон и неглубокий клон (*) в Git и проверка в SVN 21.0 107,5 14,0
    Размер (МБ) Общий размер данных и файлов на стороне клиента после клонирования / извлечения (в МБ) 181,0 132,0

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

    Распределенный

    Одна из самых приятных особенностей любой распределенной SCM, включая Git, - это то, что она распределенная. Это означает, что вместо «проверки» текущей части исходного кода вы выполняете «клонирование» всего репозитория.

    Несколько резервных копий

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

    Любой рабочий процесс

    Благодаря распределенному характеру Git и превосходной системе ветвления можно относительно легко реализовать почти бесконечное количество рабочих процессов.

    Рабочий процесс в стиле Subversion

    Централизованный рабочий процесс очень распространен, особенно у людей, переходящих из централизованной системы. Git не позволит вам нажимать, если кто-то нажал sin

    git (1) - страница руководства Linux

    git (1) - страница руководства Linux


    GIT (1) Руководство Git GIT (1)
     

    НАЗВАНИЕ сверху

           git - тупой трекер контента
     

    ОБЗОР наверх

             git  [--version] [--help] [-C ] [-c  = ]
               [--exec-path [= ]] [--html-path] [--man-path] [--info-path]
               [-p | --paginate | -P | --no-pager] [--no-replace-objects] [--bare]
               [--git-dir = <путь>] [--work-tree = <путь>] [--namespace = <имя>]
               [--super-prefix = <путь>]
               <команда> [<аргументы>]
     

    ОПИСАНИЕ вверху

           Git - это быстрая, масштабируемая, распределенная система контроля версий с
           необычно богатый набор команд, обеспечивающий как высокоуровневые операции
           и полный доступ к внутреннему устройству.См. Gittutorial (7), чтобы начать работу, затем см.  Giteveryday (7)
           полезный минимальный набор команд. Руководство пользователя Git    [1] содержит дополнительные
           углубленное введение.
    
           После того, как вы усвоили базовые концепции, вы можете вернуться на эту страницу
           чтобы узнать, какие команды предлагает Git. Вы можете узнать больше о
           отдельные команды Git с помощью «git help command». gitcli (7) руководство
           страница дает вам обзор синтаксиса командной строки.
    
           Отформатированная копия последней документации Git с гиперссылками может
           можно посмотреть на  https: // git.github.io/htmldocs/git.html   или
             https://git-scm.com/docs  .
     

    ОПЦИИ вверху

           --версия
               Печатает версию пакета Git, из которой пришла программа  git .
    
           --Помогите
               Печатает синопсис и список наиболее часто используемых
               команды. Если задана опция  --all  или  -a , тогда все доступные
               команды печатаются.  Если команда Git названа, этот параметр будет
               откройте страницу руководства для этой команды.Доступны и другие параметры для управления отображением страницы руководства.
               отображается. См. Git-help (1) для получения дополнительной информации, потому что  git 
                 --help ...  внутренне преобразуется в  git help ... .
    
           -C <путь>
               Запускать так, как если бы git был запущен в  <путь>  вместо текущего
               рабочий каталог. Если указано несколько вариантов  -C , каждый
               последующий неабсолютный  -C   интерпретируется относительно
               предшествующий  -C <путь> .Если  <путь>  присутствует, но пуст, например  -C "" ,
               тогда текущий рабочий каталог остается неизменным.
    
               Этот параметр влияет на параметры, которые ожидают имя пути, например  --git-dir 
               и  - work-tree  в том, что их интерпретация имен путей
               будет сделано относительно рабочего каталога, вызванного  -C 
               вариант.  Например, следующие вызовы эквивалентны:
    
                   git --git-dir = а.git --work-tree = b -C c статус
                   git --git-dir = c / a.git --work-tree = c / b статус
    
           -c <имя> = <значение>
               Передайте команде параметр конфигурации. Приведенное значение
               переопределит значения из файлов конфигурации. <Имя>
               ожидается в том же формате, который указан в  git config  (подключи
               разделенные точками).
    
               Обратите внимание, что можно опустить  =  в  git -c foo.bar ...  и
               устанавливает  foo.bar  в логическое истинное значение (точно так же, как  [foo] bar  будет
               в файле конфигурации). Включая равные, но с пустым значением
               (например,  git -c foo.bar = ... ) устанавливает  foo.bar  в пустую строку, которая
                 git config --type = bool  преобразует в  false .
    
           --exec-path [= <путь>]
               Путь к месту, где установлены ваши основные программы Git.  Это может
               также управляться установкой среды GIT_EXEC_PATH
               переменная.Если путь не указан,  git  распечатает текущую настройку
               а затем выйти.
    
           --html-путь
               Выведите путь без косой черты, где HTML-код Git
               документация установлена ​​и выходит.
    
           --человек-путь
               Распечатайте путь к руководству (см. Man (1)), чтобы найти справочные страницы для этой версии.
               Git и выйдите.
    
           --info-путь
               Распечатайте путь, по которому находятся файлы Info, документирующие эту версию
               Git устанавливается и завершается.
    
           -p, --paginate
               Передать весь вывод в  минус  (или, если установлен, $ PAGER), если стандартный вывод
               это терминал.Это отменяет пейджер .  конфигурация 
               параметры (см. раздел «Механизм настройки» ниже).
    
           -P, --no-pager
               Не перенаправляйте вывод Git на пейджер.
    
           --git-dir = <путь>
               Задайте путь к репозиторию (каталог ". git"). Это также может
               управляться установкой переменной окружения  GIT_DIR . Это может
               быть абсолютным путем или относительным путем к текущей работе
               каталог.
    
               Указание местоположения ".git ", используя эту опцию
               (или  GIT_DIR переменная среды ) отключает репозиторий
               обнаружение, которое пытается найти каталог с подкаталогом ".git"
               (вот как репозиторий и верхний уровень рабочего
               tree) и сообщает Git, что вы находитесь на верхнем уровне
               рабочего дерева. Если вы не находитесь в каталоге верхнего уровня
               рабочего дерева, вы должны указать Git, где находится верхний уровень
               рабочее дерево с параметром  --work-tree =   (или
                 GIT_WORK_TREE  переменная среды)
    
               Если вы просто хотите запустить git, как если бы он был запущен в   , тогда
               используйте  git -C  .--work-tree = <путь>
               Задайте путь к рабочему дереву.  Это может быть абсолютный путь или
               путь относительно текущего рабочего каталога. Это также может быть
               контролируется установкой переменной окружения GIT_WORK_TREE и
               переменная конфигурации core.worktree (см. core.worktree в
               git-config (1) для более подробного обсуждения).
    
           --namespace = <путь>
               Задайте пространство имен Git. Подробнее см. Gitnamespaces (7).
               Эквивалентно установке переменной окружения  GIT_NAMESPACE .--super-prefix = <путь>
               В настоящее время только для внутреннего использования. Установите префикс, указывающий путь
               сверху репозитория до его корня. Одно использование - дать
               контекст подмодулей о суперпроекте, который его вызвал.
    
           - голый
               Рассматривайте репозиторий как чистый репозиторий. Если среда GIT_DIR
               не установлен, он установлен в текущий рабочий каталог.
    
           --no-replace-objects
               Не используйте заменяющие ссылки для замены объектов Git. Увидеть
               git-replace (1) для получения дополнительной информации.
    
           --literal-pathspecs
               Относитесь к pathspec буквально (то есть без подстановки, без магии pathspec).
               Это эквивалентно установке  GIT_LITERAL_PATHSPECS 
               переменная окружения на  1 .
    
           --glob-pathspecs
               Добавьте магию "glob" ко всем указателям пути. Это эквивалентно установке
               переменная среды  GIT_GLOB_PATHSPECS  на  1 . Отключение
               подстановка на отдельные pathspecs может быть выполнена с помощью pathspec magic
               ": (буквально)"
    
           --noglob-pathspecs
               Добавьте «буквальную» магию ко всем pathspec.Это эквивалентно
               установка переменной среды  GIT_NOGLOB_PATHSPECS  на  1 .
               Включение подстановки по отдельным путям можно сделать с помощью
               pathspec magic ": (glob)"
    
           --icase-pathspecs
               Добавьте магию icase ко всем указателям пути. Это эквивалентно установке
               переменная среды  GIT_ICASE_PATHSPECS  на  1 . 
    
           --no-optional-locks
               Не выполняйте дополнительные операции, требующие блокировок.Это
               эквивалентно установке  GIT_OPTIONAL_LOCKS  на  0 .
    
           --list-cmds = группа [, группа ...]
               Список команд по группам. Это внутренний / экспериментальный вариант
               и может быть изменен или удален в будущем. Поддерживаемые группы:
               встроенные команды, parseopt (встроенные команды, использующие параметры анализа),
               main (все команды в каталоге libexec), другие (все остальные
               команды в  $ PATH  с префиксом git-), list-  (см.
               категории в списке команд.txt), nohelpers (исключить помощник
               команды), псевдоним и конфигурация (получить список команд из конфигурации
               переменная завершение. команды)
     

    GIT КОМАНДЫ вверху

           Мы делим Git на команды высокого уровня («фарфор») и команды низкого уровня.
           ("сантехника") команды.
     

    КОМАНДЫ ВЫСОКОГО УРОВНЯ (ФАРФОР) вверху

           Мы разделяем фарфоровые команды на основные и некоторые
           вспомогательные пользовательские утилиты. 
    
         Главные фарфоровые команды 
           git-add (1)
               Добавить содержимое файла в index.git-am (1)
               Примените серию патчей из почтового ящика.
    
           git-архив (1)
               Создайте архив файлов из именованного дерева.
    
           git-bisect (1)
               Используйте двоичный поиск, чтобы найти фиксацию, в которой была обнаружена ошибка.
    
           git-branch (1)
               Список, создание или удаление веток.
    
           git-bundle (1)
               Перемещать объекты и ссылки архивом.
    
           git-checkout (1)
               Переключайте ветви или восстанавливайте файлы рабочего дерева.
    
           мерзавец-вишня-выбор (1)
               Примените изменения, внесенные некоторыми существующими коммитами.гит-цитоол (1)
               Графическая альтернатива git-commit.
    
           git-clean (1)
               Удалите неотслеживаемые файлы из рабочего дерева.
    
           git-clone (1)
               Клонируйте репозиторий в новый каталог.
    
           git-commit (1)
               Запишите изменения в репозиторий. 
    
           git-describe (1)
               Дайте объекту удобочитаемое имя на основе доступной ссылки.
    
           git-diff (1)
               Показать изменения между коммитами, фиксацией и рабочим деревом и т. Д.
    
           git-fetch (1)
               Скачать объекты и ссылки из другого репозитория.git-формат-патч (1)
               Подготовьте исправления для отправки по электронной почте.
    
           git-gc (1)
               Очистите ненужные файлы и оптимизируйте локальный репозиторий.
    
           git-grep (1)
               Распечатайте строки, соответствующие шаблону.
    
           git-gui (1)
               Портативный графический интерфейс для Git.
    
           git-init (1)
               Создайте пустой репозиторий Git или повторно инициализируйте существующий.
    
           git-журнал (1)
               Показать журналы фиксации.
    
           git-обслуживание (1)
               Выполняйте задачи для оптимизации данных репозитория Git.git-merge (1)
               Объедините две или более историй развития вместе.
    
           git-mv (1)
               Переместите или переименуйте файл, каталог или символическую ссылку. 
    
           git-notes (1)
               Добавьте или проверьте примечания к объекту.
    
           мерзавец (1)
               Получение и интеграция с другим репозиторием или локальным
               филиал.
    
           git-push (1)
               Обновите удаленные ссылки вместе со связанными объектами.
    
           git-range-diff (1)
               Сравните два диапазона фиксации (например, две версии ветки).git-rebase (1)
               Повторное нанесение фиксируется поверх другого базового наконечника.
    
           git-reset (1)
               Сбросить текущий HEAD в указанное состояние.
    
           git-restore (1)
               Восстановить рабочие файлы дерева.
    
           git-revert (1)
               Отменить некоторые существующие коммиты.
    
           git-rm (1)
               Удалите файлы из рабочего дерева и из индекса.
    
           git-shortlog (1)
               Обобщите вывод  git log .
    
           git-show (1)
               Покажите различные типы объектов.
    
           git-sparse-checkout (1)
               Инициализировать и изменить sparse-checkout.git-stash (1)
               Уберите изменения в грязный рабочий каталог. 
    
           git-status (1)
               Показать статус рабочего дерева.
    
           git-submodule (1)
               Инициализировать, обновить или проверить подмодули.
    
           git-переключатель (1)
               Переключить ветки.
    
           git-tag (1)
               Создание, перечисление, удаление или проверка объекта тега, подписанного с помощью GPG.
    
           git-worktree (1)
               Управляйте несколькими рабочими деревьями.
    
           гитк (1)
               Браузер репозитория Git.
    
         Вспомогательные команды 
           Манипуляторы:
    
           git-config (1)
               Получить и установить репозиторий или глобальные параметры.git-fast-экспорт (1)
               Экспортер данных Git.
    
           git-fast-import (1)
               Бэкэнд для быстрых импортеров данных Git.
    
           git-фильтр-ветка (1)
               Перепишите ветки.
    
           git-mergetool (1)
               Запустите инструменты разрешения конфликтов слияния, чтобы разрешить конфликты слияния.
    
           git-pack-refs (1)
               Упакуйте заголовки и теги для эффективного доступа к репозиторию. 
    
           мерзавец-чернослив (1)
               Удалите все недостижимые объекты из базы данных объектов.
    
           git-reflog (1)
               Управляйте информацией рефлога.git-удаленный (1)
               Управляйте набором отслеживаемых репозиториев.
    
           git-repack (1)
               Упаковать распакованные объекты в репозиторий.
    
           git-replace (1)
               Создание, список, удаление ссылок для замены объектов.
    
           Следователи:
    
           git-annotate (1)
               Аннотируйте строки файла информацией о фиксации.
    
           мерзавец (1)
               Показать, какая редакция и автор последний раз изменяли каждую строку файла.
    
           git-bugreport (1)
               Соберите информацию, чтобы пользователь мог отправить отчет об ошибке.git-count-объекты (1)
               Подсчитайте количество распакованных объектов и их дисковое потребление.
    
           git-difftool (1)
               Показать изменения с помощью обычных инструментов сравнения.
    
           git-fsck (1)
               Проверяет возможность подключения и действительность объектов в
               база данных. 
    
           git-help (1)
               Показать справочную информацию о Git.
    
           git-instaweb (1)
               Мгновенно просматривайте свой рабочий репозиторий в gitweb.
    
           git-merge-tree (1)
               Показать трехстороннее слияние, не касаясь указателя.git-rerere (1)
               Повторно используйте записанное разрешение конфликтующих слияний.
    
           git-шоу-ветка (1)
               Показать ветки и их коммиты.
    
           git-verify-commit (1)
               Проверьте подпись GPG коммитов.
    
           git-verify-tag (1)
               Проверьте подпись тегов GPG.
    
           git-whatchanged (1)
               Показывать журналы с разницей, вводимой каждой фиксацией.
    
           gitweb (1)
               Веб-интерфейс Git (веб-интерфейс для репозиториев Git).
    
         Взаимодействие с другими 
           Эти команды предназначены для взаимодействия с иностранным SCM и другими людьми.
           через патч по электронной почте.git-archimport (1)
               Импортируйте репозиторий GNU Arch в Git.
    
           git-cvsexportcommit (1)
               Экспортируйте одиночный коммит в проверку CVS. 
    
           git-cvsimport (1)
               Спасите свои данные из другого SCM, которого люди любят ненавидеть.
    
           git-cvsserver (1)
               Эмулятор сервера CVS для Git.
    
           git-imap-send (1)
               Отправьте коллекцию патчей со стандартного ввода в папку IMAP.
    
           git-p4 (1)
               Импорт из репозиториев Perforce и отправка в них.
    
           git-quiltimport (1)
               Применяет набор заплат quilt к текущей ветке.git-request-pull (1)
               Создает сводку ожидающих изменений.
    
           git-send-email (1)
               Отправить коллекцию патчей по электронной почте.
    
           git-svn (1)
               Двунаправленная операция между репозиторием Subversion и Git.
    
         Сброс, восстановление и возврат 
           Есть три команды с похожими названиями:  git reset ,  git restore 
           и  git revert .
    
           • git-revert (1) предназначен для создания новой фиксации, которая отменяет
               изменения, сделанные другими коммитами.• git-restore (1) предназначен для восстановления файлов в рабочем дереве из
               либо индекс, либо другой коммит.  Эта команда не обновляется
               ваша ветка. Команду также можно использовать для восстановления файлов в
               index из другого коммита.
    
           • git-reset (1) обновляет вашу ветку, перемещая подсказку в
               чтобы добавить или удалить коммиты из ветки. Эта операция
               изменяет историю коммитов.
    
                 git reset  также можно использовать для восстановления индекса, перекрывая
                 git восстановить .

    КОМАНДЫ НИЗКОГО УРОВНЯ (САНТЕХНИКА) вверху

           Хотя Git включает свой собственный слой фарфора, его низкоуровневые команды
           достаточны для поддержки разработки альтернативных фарфоров.
           Разработчики таких фарфора могут начать с чтения о
           git-update-index (1) и git-read-tree (1).
    
           Интерфейс (ввод, вывод, набор параметров и семантика) для
           эти низкоуровневые команды должны быть намного более стабильными, чем
           Команды уровня фарфора, потому что эти команды в первую очередь
           использование по сценарию. С другой стороны, интерфейс к командам Porcelain
           могут быть изменены с целью повышения удобства работы конечных пользователей.
    
           В следующем описании низкоуровневые команды делятся на
           команды, управляющие объектами (в репозитории, индексе и
           рабочее дерево), команды, которые опрашивают и сравнивают объекты, и
           команды, перемещающие объекты и ссылки между репозиториями.
    
         Команды манипуляции 
           git-apply (1)
               Примените патч к файлам и / или к индексу.git-checkout-index (1)
               Скопируйте файлы из индекса в рабочее дерево.
    
           git-commit-graph (1)
               Напишите и проверьте файлы Git commit-graph.
    
           git-commit-tree (1)
               Создайте новый объект фиксации.
    
           git-hash-объект (1)
               Вычислить идентификатор объекта и, при необходимости, создать большой двоичный объект из файла.
    
           git-index-pack (1)
               Создайте индексный файл пакета для существующего упакованного архива.
    
           git-merge-файл (1)
               Запустите трехстороннее слияние файлов. 
    
           git-merge-index (1)
               Выполните слияние для файлов, нуждающихся в слиянии.git-mktag (1)
               Создает объект тега.
    
           git-mktree (1)
               Создайте объект-дерево из текста в формате ls-tree.
    
           git-multi-pack-index (1)
               Напишите и проверьте многопакетные индексы.
    
           git-pack-объекты (1)
               Создать упакованный архив объектов.
    
           git-prune-упакованный (1)
               Удалите лишние объекты, которые уже есть в файлах пакета.
    
           git-читать-дерево (1)
               Считывает информацию о дереве в индекс.
    
           git-symbolic-ref (1)
               Чтение, изменение и удаление символических ссылок.git-unpack-objects (1)
               Распаковать объекты из запакованного архива.
    
           git-update-index (1)
               Зарегистрируйте содержимое файла в рабочем дереве в индексе.
    
           git-update-ref (1)
               Безопасно обновите имя объекта, хранящееся в ссылке.
    
           git-дерево записи (1)
               Создайте объект дерева из текущего индекса. 
    
         Команды опроса 
           git-cat-файл (1)
               Предоставьте информацию о содержимом или типе и размере для репозитория
               объекты.
    
           мерзавец-вишня (1)
               Найдите коммиты, которые еще не были применены к апстриму.git-diff-файлы (1)
               Сравнивает файлы в рабочем дереве и индексе.
    
           git-diff-index (1)
               Сравните дерево с рабочим деревом или индексом.
    
           git-diff-tree (1)
               Сравнивает содержимое и режим BLOB-объектов, найденных через два дерева
               объекты.
    
           git-для-каждой-ссылки (1)
               Вывести информацию по каждому исх.
    
           git-get-tar-commit-id (1)
               Извлечь идентификатор фиксации из архива, созданного с помощью git-archive.
    
           git-ls-файлы (1)
               Показать информацию о файлах в индексе и рабочем дереве.git-ls-remote (1)
               Список ссылок в удаленном репозитории.
    
           git-ls-tree (1)
               Перечислите содержимое древовидного объекта.
    
           git-merge-base (1)
               Найдите как можно более хороших общих предков для слияния. 
    
           git-name-rev (1)
               Найдите символические имена для заданных оборотов.
    
           git-pack-избыточный (1)
               Найдите избыточные файлы пакетов.
    
           git-rev-list (1)
               Списки фиксируют объекты в обратном хронологическом порядке.
    
           git-rev-parse (1)
               Подберите и помассируйте параметры.git-show-index (1)
               Показать индекс упакованного архива.
    
           git-show-ref (1)
               Перечислите ссылки в локальном репозитории.
    
           git-распаковать-файл (1)
               Создает временный файл с содержимым большого двоичного объекта.
    
           git-var (1)
               Показать логическую переменную Git.
    
           git-verify-pack (1)
               Проверьте упакованные архивные файлы Git.
    
           Как правило, команды опроса не касаются файлов в
           рабочее дерево.
    
         Синхронизация репозиториев 
           git-daemon (1)
               Действительно простой сервер для репозиториев Git.git-fetch-pack (1)
               Получить недостающие объекты из другого репозитория. 
    
           git-http-backend (1)
               Реализация Git через HTTP на стороне сервера.
    
           git-send-pack (1)
               Перенести объекты по протоколу Git в другой репозиторий.
    
           git-update-server-информация (1)
               Обновите вспомогательный информационный файл, чтобы помочь немым серверам.
    
           Ниже приведены вспомогательные команды, используемые вышеупомянутым; конечные пользователи
           обычно не используют их напрямую.
    
           git-http-fetch (1)
               Загрузите из удаленного репозитория Git по HTTP.git-http-push (1)
               Отправлять объекты через HTTP / DAV в другой репозиторий.
    
           git-parse-удаленный (1)
               Подпрограммы, помогающие анализировать параметры доступа к удаленному репозиторию.
    
           git-receive-pack (1)
               Получите то, что помещено в репозиторий.
    
           git-shell (1)
               Ограниченная оболочка входа для доступа по SSH только Git.
    
           git-upload-архив (1)
               Отправить архив обратно в git-archive.
    
           git-upload-pack (1)
               Отправьте упакованные объекты обратно в git-fetch-pack.  Внутренние вспомогательные команды 
           Это внутренние вспомогательные команды, используемые другими командами; конечные пользователи
           обычно не используют их напрямую.
    
           git-check-attr (1)
               Показать информацию о gitattributes.
    
           git-check-ignore (1)
               Отладка файлов gitignore / exclude.
    
           git-check-mailmap (1)
               Показывать канонические имена и адреса электронной почты контактов.
    
           git-check-ref-format (1)
               Гарантирует правильность формирования ссылочного имени.
    
           git-столбец (1)
               Отображать данные в столбцах.git-credential (1)
               Получить и сохранить учетные данные пользователя.
    
           git-credential-cache (1)
               Помощник для временного хранения паролей в памяти.
    
           git-credential-store (1)
               Помощник для хранения учетных данных на диске.
    
           git-fmt-merge-msg (1)
               Создайте сообщение фиксации слияния.
    
           git-интерпретатор-трейлеры (1)
               Добавьте или проанализируйте структурированную информацию в сообщениях фиксации. 
    
           git-mailinfo (1)
               Извлекает исправление и авторство из одного сообщения электронной почты.git-mailsplit (1)
               Простая программа-разделитель mbox для UNIX.
    
           git-merge-один файл (1)
               Стандартная вспомогательная программа для использования с git-merge-index.
    
           git-patch-id (1)
               Вычислить уникальный идентификатор патча.
    
           git-sh-i18n (1)
               Код настройки i18n от Git для сценариев оболочки.
    
           git-sh-setup (1)
               Стандартный код установки сценария оболочки Git.
    
           git-stripspace (1)
               Удалите ненужные пробелы.
     

    НАПРАВЛЯЮЩИЕ наверх

           Следующие страницы документации содержат руководства по концепциям Git.gitattributes (5)
               Определение атрибутов для каждого пути.
    
           gitcli (7)
               Интерфейс командной строки Git и соглашения.
    
           gitcore-учебник (7)
               Основное руководство по Git для разработчиков.
    
           gitcredentials (7)
               Предоставление логинов и паролей Git. 
    
           gitcvs-миграция (7)
               Git для пользователей CVS.
    
           gitdiffcore (7)
               Тонкая настройка вывода diff.
    
           giteveryday (7)
               Полезный минимальный набор команд для Everyday Git.
    
           gitfaq (7)
               Часто задаваемые вопросы об использовании Git.gitglossary (7)
               Глоссарий Git.
    
           githooks (5)
               Хуки, используемые Git.
    
           gitignore (5)
               Указывает намеренно неотслеживаемые файлы, которые следует игнорировать.
    
           gitmodules (5)
               Определение свойств подмодуля.
    
           gitnamespaces (7)
               Пространства имен Git.
    
           gitremote-помощники (7)
               Программы-помощники для взаимодействия с удаленными репозиториями.
    
           gitrepository-layout (5)
               Макет репозитория Git.
    
           gitrevisions (7)
               Указание ревизий и диапазонов для Git.gitsubmodules (7)
               Монтирование одного репозитория внутри другого.
    
           gittutorial (7)
               Введение в Git. 
    
           gittutorial-2 (7)
               Введение в Git: часть вторая.
    
           gitworkflows (7)
               Обзор рекомендуемых рабочих процессов с Git.
     

    КОНФИГУРАЦИОННЫЙ МЕХАНИЗМ вверху

           Git использует простой текстовый формат для хранения настроек, которые
           репозиторий и рассчитаны на пользователя. Такой файл конфигурации может выглядеть как
           этот:
    
               #
               # A '#' или ';' символ обозначает комментарий.#
    
               ; основные переменные
               [core]
                       ; Не доверяйте файловым режимам
                       filemode = false
    
               ; личность пользователя
               [пользователь]
                       name = "Джунио Си Хамано"
                       email = "[email protected]"
    
           Различные команды читают из файла конфигурации и корректируют свои
           работа соответственно. См. Git-config (1) для списка и более подробной информации.
           о механизме настройки.
     

    ИДЕНТИФИКАТОР ТЕРМИНОЛОГИЯ верх

           <объект>
               Указывает имя объекта для любого типа объекта.
               Указывает имя объекта большого двоичного объекта.
    
           <дерево>
               Указывает имя объекта дерева.
    
           
               Указывает имя объекта фиксации.
    
           <дерево-дерево>
               Указывает имя объекта дерева, фиксации или тега. Команда, которая требует
               аргумент  в конечном итоге хочет работать с 
               объект, но автоматически разыменовывает объекты  и 
               эта точка на <дереве>.
               Указывает имя объекта фиксации или тега. Команда, которая требует
               Аргумент  в конечном итоге хочет работать с 
               объект, но автоматически разыменовывает объекты , которые указывают на
               <совершить>.
    
           <тип>
               Указывает, что требуется тип объекта. В настоящее время один из:
                 blob ,  tree ,  commit  или  tag .
    
           <файл>
               Указывает имя файла - почти всегда относительно корня
               описывает древовидную структуру  GIT_INDEX_FILE .

    СИМВОЛИЧЕСКИЕ ИДЕНТИФИКАТОРЫ вверху

           Любая команда Git, принимающая любой <объект>, также может использовать следующие
           символическое обозначение:
    
           ГОЛОВА
               указывает на голову текущей ветви.
    
           <тег>
               допустимый тег , имя  (т.е. ссылка  refs / tags /  ).
    
           
               действительное имя  головы  (то есть ссылка  refs / Heads /  ).
    
           Более полный список способов написания имен объектов см.
           Раздел «УКАЗАНИЕ ИЗМЕНЕНИЙ» в gitrevisions (7).

    СТРУКТУРА ФАЙЛА / КАТАЛОГА наверх

           См. Документ gitrepository-layout (5).
    
           Прочтите githooks (5) для получения более подробной информации о каждом хуке.
    
           SCM более высокого уровня могут предоставлять дополнительную информацию и управлять ею в
           файл  $ GIT_DIR .
     

    ТЕРМИНОЛОГИЯ наверх

           См. Gitglossary (7).
     

    ПЕРЕМЕННЫЕ ОКРУЖАЮЩЕЙ СРЕДЫ top

           Различные команды Git используют следующие переменные среды:
    
         Репозиторий Git 
           Эти переменные среды применяются ко всем  всем основным командам Git .Nb: это
           Стоит отметить, что они могут быть использованы / отменены системой SCMS, расположенной выше
           Git, поэтому будьте осторожны, если используете сторонний интерфейс.
    
             GIT_INDEX_FILE 
               Эта среда позволяет указать альтернативный индекс
               файл. Если не указано, используется значение по умолчанию  $ GIT_DIR / index .
    
             GIT_INDEX_VERSION 
               Эта переменная среды позволяет указать индекс
               версия для новых репозиториев. Это не повлияет на существующий индекс
               файлы.По умолчанию используется индексный файл версии 2 или 3. Увидеть
               git-update-index (1) для получения дополнительной информации.
    
             GIT_OBJECT_DIRECTORY 
               Если каталог хранилища объектов указан через эту среду
               переменная, то под ней создаются каталоги sha1 -
               в противном случае используется каталог по умолчанию  $ GIT_DIR / objects .
    
             GIT_ALTERNATE_OBJECT_DIRECTORIES 
               Из-за неизменной природы объектов Git старые объекты могут быть
               архивируются в общие каталоги, доступные только для чтения.Эта переменная
               указывает список Git, разделенный ":" (в Windows ";")
               каталоги объектов, которые можно использовать для поиска объектов Git.
               Новые объекты в эти каталоги записываться не будут.
    
               Записи, начинающиеся с  " (двойные кавычки), будут интерпретироваться как
               Пути в кавычках в стиле C, удаление начальных и конечных двойных кавычек
               и соблюдая экранирование обратной косой черты. Например, значение
                 "path-with - \" - and -: - in-it ": vanilla-path  имеет два пути:
                 путь-с - "- и -: - в нем  и  ванильный путь . GIT_DIR 
               Если установлена ​​переменная среды  GIT_DIR , то она указывает
               путь для использования вместо  по умолчанию .git  для базы
               репозиторий. Параметр командной строки  --git-dir  также устанавливает это
               значение.
    
             GIT_WORK_TREE 
               Задайте путь к корню рабочего дерева. Это также может быть
               управляется параметром командной строки  --work-tree  и параметром
               ядро.Переменная конфигурации рабочего дерева.
    
             GIT_NAMESPACE 
               Установите пространство имен Git; подробнее см. gitnamespaces (7). В
                 --namespace  параметр командной строки также устанавливает это значение.
    
             GIT_CEILING_DIRECTORIES 
               Это должен быть список абсолютных путей, разделенных двоеточиями. Если установлено,
               это список каталогов, в которые Git не должен загружать
               при поиске каталога репозитория (полезно для исключения
               медленно загружающиеся сетевые каталоги).Это не исключает
               текущий рабочий каталог или GIT_DIR, установленный в командной строке или
               в окружающей среде. Обычно Git должен читать записи в этом
               перечислить и разрешить любые символические ссылки, которые могут присутствовать, чтобы
               сравните их с текущим каталогом. Однако если даже это
               доступ медленный, вы можете добавить пустую запись в список, чтобы сообщить
               Git, что последующие записи не являются символическими ссылками и не должны быть
               решено; например,
                 GIT_CEILING_DIRECTORIES = / возможно / символическая ссылка :: / очень / медленно / не / символическая ссылка .
    
             GIT_DISCOVERY_ACROSS_FILESYSTEM 
               При запуске в каталоге, в котором нет репозитория ".git"
               каталог, Git пытается найти такой каталог в родительском
               каталоги, чтобы найти вершину рабочего дерева, но по умолчанию
               он не пересекает границы файловой системы. Эта среда
               переменной можно присвоить значение true, чтобы Git не останавливался на файловой системе
               границы.Как и  GIT_CEILING_DIRECTORIES , это не повлияет на
               явный каталог репозитория, установленный через  GIT_DIR  или по команде
               линия.
    
             GIT_COMMON_DIR 
               Если для этой переменной задан путь, файлы, не относящиеся к рабочему дереву,
               обычно $ GIT_DIR будет взят из этого пути.
               Файлы, относящиеся к рабочему дереву, такие как HEAD или index, берутся из
               $ GIT_DIR. См. Gitrepository-layout (5) и git-worktree (1) для
               Детали.Эта переменная имеет более низкий приоритет, чем другой путь
               переменные, такие как GIT_INDEX_FILE, GIT_OBJECT_DIRECTORY ...
    
             GIT_DEFAULT_HASH 
               Если эта переменная установлена, алгоритм хеширования по умолчанию для новых
               репозитории будут установлены на это значение. Это значение в настоящее время
               игнорируется при клонировании; настройка удаленного репозитория
               вместо этого. По умолчанию - «sha1». ЭТА ПЕРЕМЕННАЯ
               ЭКСПЕРИМЕНТАЛЬНАЯ! См.  --object-format  в git-init (1). Git фиксирует 
             GIT_AUTHOR_NAME 
               Удобочитаемое имя, используемое в личности автора при создании
               зафиксировать или пометить объекты, или при написании рефлогов. Отменяет
                 имя пользователя  и  имя автора  параметры конфигурации.
    
             GIT_AUTHOR_EMAIL 
               Адрес электронной почты, использованный для идентификации автора при создании
               зафиксировать или пометить объекты, или при написании рефлогов. Отменяет
                 пользователь.электронная почта  и  автор. электронная почта  параметры конфигурации.
    
             GIT_AUTHOR_DATE 
               Дата, используемая для идентификации автора при создании фиксации или тега
               объекты, или при написании рефлогов. См. Git-commit (1) для допустимости
               форматы.
    
             GIT_COMMITTER_NAME 
               Удобочитаемое имя, используемое в идентификаторе коммиттера, когда
               создание коммитов или объектов тегов, или при написании рефлогов.
               Переопределяет  user.name  и  коммиттера.имя  конфигурация
               настройки.
    
             GIT_COMMITTER_EMAIL 
               Адрес электронной почты, использованный для идентификации автора при создании
               зафиксировать или пометить объекты, или при написании рефлогов. Отменяет
                 user.email  и  committer.email  параметры конфигурации.
    
             GIT_COMMITTER_DATE 
               Дата, используемая для идентификации коммиттера при создании фиксации или
               объекты тегов, или при написании рефлогов. См. Git-commit (1) для допустимости
               форматы. ЭЛЕКТРОННАЯ ПОЧТА 
               Адрес электронной почты, используемый в личности автора и коммиттера, если
               нет другой соответствующей переменной среды или параметра конфигурации
               был установлен.
    
         Git Diffs 
             GIT_DIFF_OPTS 
               Допустимая настройка - "--unified = ??" или "-u ??" установить номер
               контекстных строк, отображаемых при создании унифицированного сравнения. Это требует
               приоритет перед любым значением параметра "-U" или "--unified"
               в командной строке Git diff. GIT_EXTERNAL_DIFF 
               Когда установлена ​​переменная среды  GIT_EXTERNAL_DIFF ,
               названная им программа вызывается для генерации различий, а Git не
               использовать его встроенную систему различий. Для добавляемого пути
               удалено или изменено,  GIT_EXTERNAL_DIFF  вызывается с 7
               параметры:
    
                   путь старый-файл старый-шестнадцатеричный старый-режим новый-файл новый-шестнадцатеричный новый-режим
    
               где:
    
           <старый | новый> -файл
               файлы, которые GIT_EXTERNAL_DIFF может использовать для чтения содержимого
               <старый | новый>,
    
           <старый | новый> -hex
               - хэши SHA-1 из 40 шестнадцатеричных цифр,
    
           <старый | новый> -режим
               являются восьмеричным представлением режимов файла.Параметры файла могут указывать на рабочий файл пользователя (например,
                 новый файл  в "git-diff-files"),  / dev / null  (например,  старый файл , когда
               добавляется новый файл) или временный файл (например,  старый файл  в
               индекс).  GIT_EXTERNAL_DIFF  не следует беспокоиться об отключении
               временный файл --- он удаляется при выходе из  GIT_EXTERNAL_DIFF .
    
               Для пути, который не объединен,  GIT_EXTERNAL_DIFF  вызывается с 1
               параметр, <путь>.Для каждого пути  вызывается GIT_EXTERNAL_DIFF , два окружения
               переменные, установлены  GIT_DIFF_PATH_COUNTER,  и  GIT_DIFF_PATH_TOTAL .
    
             GIT_DIFF_PATH_COUNTER 
               Счетчик, отсчитываемый от 1, увеличивается на единицу для каждого пути.
    
             GIT_DIFF_PATH_TOTAL 
               Общее количество путей.
    
         другое 
             GIT_MERGE_VERBOSITY 
               Число, контролирующее объем вывода, отображаемый рекурсивным
               стратегия слияния.Переопределяет merge.verbosity. См. Git-merge (1)
    
             GIT_PAGER 
               Эта переменная среды заменяет  $ PAGER . Если он установлен на
               пустую строку или значение «cat», Git не запустит пейджер.
               См. Также параметр  core.pager  в git-config (1).
    
             GIT_PROGRESS_DELAY 
               Число, определяющее, сколько секунд нужно отложить до показа
               дополнительные индикаторы прогресса. По умолчанию 2.
    
             GIT_EDITOR 
               Эта переменная среды переопределяет  $ EDITOR  и  $ VISUAL .это
               используется несколькими командами Git, когда в интерактивном режиме редактор
               должен быть запущен. См. Также git-var (1) и параметр  core.editor 
               в git-config (1).
    
             GIT_SEQUENCE_EDITOR 
               Эта переменная среды переопределяет настроенный редактор Git
               при редактировании списка задач интерактивной перебазировки. Смотрите также
               linkit :: git-rebase [1] и параметр  sequence.editor  в
               linkit :: git-config [1]. GIT_SSH ,  GIT_SSH_COMMAND 
               Если установлена ​​одна из этих переменных среды, то  git fetch 
               и  git push  будет использовать указанную команду вместо  ssh , когда
               им необходимо подключиться к удаленной системе. Командная строка
               параметры, передаваемые настроенной команде, определяются
               вариант ssh. Подробнее см. Параметр  ssh.variant  в git-config (1).
    
                 $ GIT_SSH_COMMAND  имеет приоритет над  $ GIT_SSH  и является
               интерпретируется оболочкой, что позволяет
               включены. $ GIT_SSH  с другой стороны, должен быть просто путем к
               программа (которая может быть сценарием оболочки-оболочки, если
               нужны аргументы).
    
               Обычно любые желаемые параметры проще настроить через
               ваш личный файл  .ssh / config . Проконсультируйтесь со своим ssh
               документация для получения дополнительных сведений.
    
             GIT_SSH_VARIANT 
               Если эта переменная среды установлена, она переопределяет Git's
               автоопределение  GIT_SSH / GIT_SSH_COMMAND / core.sshCommand 
               обратитесь к OpenSSH, plink или tortoiseplink. Эта переменная имеет приоритет над
               параметр конфигурации  ssh.variant , который служит той же цели.
    
             GIT_ASKPASS 
               Если эта переменная среды установлена, то команды Git, которые нуждаются в
               для получения паролей или кодовых фраз (например, для HTTP или IMAP
               аутентификация) вызовет эту программу с подходящей подсказкой как
               аргумент командной строки и прочтите пароль из его STDOUT.Увидеть
               также параметр  core.askPass  в git-config (1).
    
             GIT_TERMINAL_PROMPT 
               Если для этой переменной среды установлено значение  0 , git не будет запрашивать
               терминал (например, при запросе HTTP-аутентификации).
    
             GIT_CONFIG_NOSYSTEM 
               Следует ли пропускать настройки чтения из общесистемной
                 $ (префикс) / etc / gitconfig  файл. Эта переменная среды может быть
               используется вместе с  $ HOME  и  $ XDG_CONFIG_HOME  для создания
               предсказуемая среда для придирчивого скрипта, или вы можете установить его
               временно, чтобы избежать использования ошибочного файла  / etc / gitconfig , пока
               ждем, пока кто-то с достаточными правами исправит это. GIT_FLUSH 
               Если для этой переменной среды установлено значение «1», то такие команды, как
                 git blame  (в инкрементальном режиме),  git rev-list ,  git log ,  git 
                 check-attr  и  git check-ignore  принудительно сбросят выходные данные
               поток после того, как каждая запись была сброшена. Если эта переменная
               установлено значение «0», вывод этих команд будет выполняться с использованием
               полностью буферизованный ввод / вывод.Если эта переменная среды не установлена,
               Git выберет буферизованную или ориентированную на запись очистку на основе
               перенаправляется ли stdout в файл или нет.
    
             GIT_TRACE 
               Включает общие сообщения трассировки, например расширение псевдонима, встроенное
               выполнение команд и выполнение внешних команд.
    
               Если для этой переменной установлено значение «1», «2» или «истина» (сравнение
               нечувствительный), сообщения трассировки будут напечатаны в stderr.
    
               Если для переменной задано целочисленное значение больше 2 и
               ниже 10 (строго), то Git интерпретирует это значение как
               открыть дескриптор файла и попытается записать сообщения трассировки
               в этот файловый дескриптор.В качестве альтернативы, если для переменной задан абсолютный путь
               (начиная с символа /), Git интерпретирует это как файл
               path и попытается добавить к нему сообщения трассировки.
    
               Отмена установки переменной или установка ее на пустое значение, "0" или "false"
               (без учета регистра) отключает сообщения трассировки.
    
             GIT_TRACE_FSMONITOR 
               Включает сообщения трассировки для расширения монитора файловой системы. Увидеть
                 GIT_TRACE  для доступных опций вывода трассировки. GIT_TRACE_PACK_ACCESS 
               Включает сообщения трассировки для всех обращений к любым пакетам. Для каждого
               доступа, записывается имя файла пакета и смещение в пакете.
               Это может быть полезно для устранения неполадок, связанных с некоторыми пакетами.
               проблемы с производительностью. См.  GIT_TRACE  для доступного вывода трассировки
               параметры.
    
             GIT_TRACE_PACKET 
               Включает сообщения трассировки для всех пакетов, входящих или исходящих
               данная программа.Это может помочь с согласованием объекта отладки или
               другие проблемы протокола. Отслеживание отключается при запуске пакета
               с "PACK" (но см.  GIT_TRACE_PACKFILE  ниже). См.  GIT_TRACE  для
               доступные параметры вывода трассировки.
    
             GIT_TRACE_PACKFILE 
               Включает отслеживание пакетов, отправленных или полученных данной программой.
               В отличие от других выходных данных трассировки, эта трассировка дословно: без заголовков,
               и отсутствие цитирования двоичных данных.Вы почти наверняка хотите
               прямо в файл (например,  GIT_TRACE_PACKFILE = / tmp / my.pack ), а
               чем отображать его на терминале или смешивать с другим графиком
               выход.
    
               Обратите внимание, что в настоящее время это реализовано только на стороне клиента.
               клонов и выборок.
    
             GIT_TRACE_PERFORMANCE 
               Включает сообщения трассировки, связанные с производительностью, например полное исполнение
               время каждой команды Git. См.  GIT_TRACE  для доступной трассировки
               варианты вывода. GIT_TRACE_REFS 
               Включает сообщения трассировки для операций с базой данных ref. Увидеть
                 GIT_TRACE  для доступных опций вывода трассировки.
    
             GIT_TRACE_SETUP 
               Включает сообщения трассировки, распечатывающие .git, рабочее дерево и
               текущий рабочий каталог после того, как Git завершил настройку
               фаза. См.  GIT_TRACE  для доступных опций вывода трассировки.
    
             GIT_TRACE_SHALLOW 
               Включает сообщения трассировки, которые могут помочь отладить выборку / клонирование
               неглубоких хранилищ.См.  GIT_TRACE  для доступного вывода трассировки
               параметры.
    
             GIT_TRACE_CURL 
               Включает curl full trace dump всех входящих и исходящих данных,
               включая описательную информацию о транспортном протоколе git.
               Это похоже на выполнение команды curl  --trace-ascii  в командной строке.
               См.  GIT_TRACE  для доступных опций вывода трассировки.
    
             GIT_TRACE_CURL_NO_DATA 
               Когда трассировка скручивания включена (см.  GIT_TRACE_CURL  выше), не
               данные дампа (то есть только информационные строки и заголовки дампа). GIT_TRACE2 
               Включает более подробные сообщения трассировки из библиотеки "trace2".
               Вывод из  GIT_TRACE2  - это простой текстовый формат для человека.
               читаемость.
    
               Если для этой переменной установлено значение «1», «2» или «истина» (сравнение
               нечувствительный), сообщения трассировки будут напечатаны в stderr.
    
               Если для переменной задано целочисленное значение больше 2 и
               ниже 10 (строго), то Git интерпретирует это значение как
               открыть дескриптор файла и попытается записать сообщения трассировки
               в этот файловый дескриптор.В качестве альтернативы, если для переменной задан абсолютный путь
               (начиная с символа /), Git интерпретирует это как файл
               path и попытается добавить к нему сообщения трассировки. Если путь
               уже существует и является каталогом, сообщения трассировки будут
               записывается в файлы (по одному на процесс) в этом каталоге с именем
               в соответствии с последним компонентом SID и необязательным
               счетчик (чтобы избежать конфликтов имен файлов).Кроме того, если для переменной установлено значение
                 af_unix: [:]  , Git попытается открыть
               путь как сокет домена Unix. Тип розетки может быть либо
                 поток  или  dgram .
    
               Отмена установки переменной или установка ее на пустое значение, "0" или "false"
               (без учета регистра) отключает сообщения трассировки.
    
               См. Подробную информацию в документации  Trace2   [2].
    
             GIT_TRACE2_EVENT 
               Этот параметр записывает формат на основе JSON, который подходит для
               машинная интерпретация.См.  GIT_TRACE2  для доступного вывода трассировки
               options и документация  Trace2   [2] для получения полной информации.
    
             GIT_TRACE2_PERF 
               В дополнение к текстовым сообщениям, доступным в  GIT_TRACE2 ,
               этот параметр записывает формат на основе столбцов для понимания
               районы гнездования. См.  GIT_TRACE2  для доступного вывода трассировки
               options и документация  Trace2   [2] для получения полной информации. GIT_TRACE_REDACT 
               По умолчанию, когда трассировка активирована, Git редактирует значения
               файлы cookie, заголовок "Авторизация:" и
               Заголовок «Прокси-авторизация:». Установите для этой переменной значение  0 , чтобы предотвратить
               эта редакция.
    
             GIT_LITERAL_PATHSPECS 
               Установка этой переменной на  1  приведет к тому, что Git обработает все пути
               буквально, а не в виде глобусов. Например, бег
                 GIT_LITERAL_PATHSPECS = 1 git log - '*.c ' будет искать коммиты
               которые касаются пути  * .c , а не любых путей, которым соответствует glob  * .c .
               Вам может понадобиться это, если вы вводите буквальные пути в Git
               (например, пути, ранее данные вам  git ls-tree ,  --raw  diff
               вывод и т. д.).
    
             GIT_GLOB_PATHSPECS 
               Установка этой переменной на  1  приведет к тому, что Git обработает все пути
               как шаблоны глобусов (также известные как «магия глобусов»). GIT_NOGLOB_PATHSPECS 
               Установка этой переменной на  1  приведет к тому, что Git обработает все пути
               как буквальное (также известное как «буквальная магия»).
    
             GIT_ICASE_PATHSPECS 
               Установка этой переменной на  1  приведет к тому, что Git обработает все пути
               без учета регистра.
    
             GIT_REFLOG_ACTION 
               Когда ссылка обновляется, создаются записи журнала для отслеживания
               причины, по которой ссылка была обновлена ​​(обычно это
               имя высокоуровневой команды, обновившей ссылку), кроме того
               к старым и новым значениям исх.Авторский фарфор
               команда может использовать вспомогательную функцию set_reflog_action в  git-sh-setup 
               установить имя этой переменной, когда она вызывается как верхняя
               команда уровня конечным пользователем, которая должна быть записана в теле
               рефлог.
    
             GIT_REF_PARANOIA 
               Если установлено значение  1 , включить сломанные или неверно названные ссылки при повторении
               над списками исх. В нормальном, неповрежденном репозитории это
               ничего не делает.Однако его включение может помочь git обнаруживать и
               прервать некоторые операции при неработающих ссылках. Git наборы
               эта переменная автоматически при выполнении деструктивного
               такие операции, как git-prune (1). Вам не нужно устанавливать его
               себя, если вы не хотите быть параноиком насчет того, чтобы
               операция коснулась каждой ссылки (например, потому что вы клонируете
               репозиторий для резервного копирования).
    
             GIT_ALLOW_PROTOCOL 
               Если установлен список протоколов, разделенных двоеточиями, вести себя как если бы
                 протокол.разрешить  установлено значение , никогда не , и каждый из перечисленных протоколов
               имеет протокол .  .allow  установлен на  всегда  (перекрывая любые существующие
               конфигурация). Другими словами, любой не упомянутый протокол будет
               быть запрещенным (т.е. это белый список, а не черный список). Увидеть
               описание протокола . разрешите  в git-config (1) для получения дополнительной информации
               Детали.
    
             GIT_PROTOCOL_FROM_USER 
               Установите значение 0, чтобы предотвратить использование протоколов fetch / push / clone, которые
               настроен на состояние  пользователя .Это полезно для ограничения
               рекурсивная инициализация подмодуля из ненадежного репозитория
               или для программ, которые передают потенциально ненадежные URL-адреса в git
               команды. См. Git-config (1) для получения более подробной информации.
    
             GIT_PROTOCOL 
               Только для внутреннего использования. Используется для подтверждения проводного протокола.
               Содержит список разделенных двоеточием :  ключей с дополнительными значениями
                 ключ [= значение] . Наличие неизвестных ключей и значений следует игнорировать. GIT_OPTIONAL_LOCKS 
               Если установлено значение  0 , Git выполнит любую запрошенную операцию без
               выполнение любых необязательных подопераций, требующих выполнения
               замок. Например, это предотвратит обновление  git status 
               индекс как побочный эффект. Это полезно для запущенных процессов
               в фоновом режиме, которые не хотят вызывать конфликт блокировки с
               другие операции с репозиторием. По умолчанию  1 . GIT_REDIRECT_STDIN ,  GIT_REDIRECT_STDOUT ,  GIT_REDIRECT_STDERR 
               Только для Windows: разрешить перенаправление стандартного ввода / вывода / ошибки
               обрабатывает пути, указанные переменными среды. Это
               особенно полезно в многопоточных приложениях, где
               канонический способ передать стандартные дескрипторы через  CreateProcess ()  не
               вариант, потому что это потребует маркировки ручек
               наследуемый (и, следовательно,  каждый порожденный процесс  будет наследовать
               их, возможно, блокируя обычные операции Git).Главная
               предполагаемый вариант использования - использовать именованные каналы для связи (например,
                 \\. \ Pipe \ my-git-stdin-123 ).
    
               Поддерживаются два специальных значения:  off  просто закроет
               соответствующий стандартный дескриптор, и если  GIT_REDIRECT_STDERR 
                 2> & 1 , стандартная ошибка будет перенаправлена ​​на тот же дескриптор, что и
               стандартный вывод.
    
             GIT_PRINT_SHA1_ELLIPSIS  (устарело)
               Если установлено значение  да , выведите многоточие после (сокращенного) SHA-1
               значение.Это влияет на индикацию отсоединенных ГОЛОВ (-
               git-checkout (1)) и необработанный вывод diff (git-diff (1)). Печать
               многоточие в упомянутых случаях больше не рассматривается
               адекватный и поддержка для него, вероятно, будет удалена в
               обозримое будущее (вместе с переменной).
     

    ДИСКУССИЯ top

           Более подробная информация о следующем доступна из  Git Concept 
             глава руководства пользователя   [3] и gitcore-tutorial (7).Проект Git обычно состоит из рабочего каталога с расширением ".git".
           подкаталог на верхнем уровне. Каталог .git содержит, среди
           другие вещи, сжатая база данных объектов, представляющая полную
           история проекта, "индексный" файл, который связывает эту историю с
           текущее содержимое рабочего дерева и именованные указатели на
           эта история, такая как теги и заголовки веток.
    
           База данных объектов содержит объекты трех основных типов: капли,
           которые содержат данные файла; деревья, которые указывают на капли и другие деревья,
           создавать иерархии каталогов; и коммиты, каждая из которых ссылается на
           одно дерево и некоторое количество родительских коммитов.Коммит, эквивалентный тому, что другие системы называют «набором изменений» или
           "версия" представляет собой шаг в истории проекта, и каждый
           parent представляет собой непосредственно предшествующий шаг. Совершает больше
           чем один родитель представляет собой слияние независимых линий развития.
    
           Все объекты именуются хешем SHA-1 их содержимого, обычно
           записывается в виде строки из 40 шестнадцатеричных цифр. Такие имена глобально уникальны.
           За всю историю, предшествующую фиксации, может поручиться
           подписывая только этот коммит.Предоставляется четвертый тип объекта, тег.
           для этого.
    
           При первом создании объекты хранятся в отдельных файлах, но для
           эффективность может быть позже сжата вместе в «файлы упаковки».
    
           Именованные указатели, называемые refs, отмечают интересные моменты в истории. Ссылка
           может содержать имя SHA-1 объекта или имя другого ref.
           Ссылки с именами, начинающимися с  ref / head / , содержат имя SHA-1
           самая последняя фиксация (или «голова») разрабатываемой ветки.SHA-1
           имена интересующих тегов хранятся в каталоге  ref / tags / . Специальный исх.
           named  HEAD  содержит имя текущей извлеченной ветви.
    
           Индексный файл инициализируется списком всех путей и для каждого
           путь, объект blob и набор атрибутов. Объект blob
           представляет содержимое файла как заголовок текущего
           филиал. Берутся атрибуты (время последнего изменения, размер и т. Д.)
           из соответствующего файла в рабочем дереве.Последующие изменения
           к рабочему дереву можно найти, сравнив эти атрибуты. В
           index может быть обновлен новым контентом, и могут быть созданы новые коммиты
           из содержимого, хранящегося в индексе.
    
           Индекс также может хранить несколько записей (называемых
           "этапы") для заданного пути. Эти этапы используются для проведения
           различные несвязанные версии файла во время слияния.
     

    ДОПОЛНИТЕЛЬНАЯ ДОКУМЕНТАЦИЯ наверх

           См. Ссылки в разделе "Описание", чтобы начать использовать
           Git.Следующее, вероятно, является более подробным, чем необходимо для
           впервые пользователь.
    
           Глава , посвященная концепциям Git, в руководстве пользователя   [3] и
           gitcore-tutorial (7) знакомят с базовым Git.
           архитектура.
    
           См. Gitworkflows (7) для обзора рекомендуемых рабочих процессов.
    
           См. Также несколько полезных примеров в справочных документах , ,  [4].
    
           Внутреннее устройство описано в документации  Git API   [5].Пользователи, переходящие с CVS, могут также захотеть прочитать gitcvs-migration (7).
     

    АВТОРЫ наверх

           Git был запущен Линусом Торвальдсом и в настоящее время поддерживается
           Джунио С. Хамано. Многочисленные материалы поступили из рассылки Git.
           список < [email protected]   [6]>.
             http://www.openhub.net/p/git/contributors/summary   дает вам больше
           полный список участников.
    
           Если у вас есть клон git.сам git, вывод git-shortlog (1)
           и git-blame (1) может показать вам авторов отдельных частей
           проект.
     

    СООБЩЕНИЕ ОБ ОШИБКАХ top

           Сообщайте об ошибках в список рассылки Git < [email protected]   [6]> где
           в первую очередь выполняется разработка и сопровождение. Ты не должен
           подписаться на список, чтобы отправлять туда сообщения. Посмотреть список
           архив на  https://lore.kernel.org/git   для предыдущих отчетов об ошибках и
           другие обсуждения.Вопросы, относящиеся к безопасности, следует раскрывать в частном порядке
           список рассылки Git Security < [email protected]   [7]>.
     

    СМОТРИТЕ ТАКЖЕ top

           gittutorial (7), gittutorial-2 (7), giteveryday (7),
           gitcvs-migration (7), gitglossary (7), gitcore-tutorial (7), gitcli (7),
             Руководство пользователя Git   [1], gitworkflows (7)
     

    Верхняя часть GIT

           Часть пакета git (1)
     

    ПРИМЕЧАНИЯ вверху

            1.Руководство пользователя Git
               файл: ///usr/local/share/doc/git/user-manual.html
    
            2. Документация Trace2
               файл: ///usr/local/share/doc/git/technical/api-trace2.html
    
            3. Глава, посвященная концепциям Git, в руководстве пользователя.
               файл: ///usr/local/share/doc/git/user-manual.html#git-concepts
    
            4. как
               файл: ///usr/local/share/doc/git/howto-index.html
    
            5. Документация по Git API.
               файл: ///usr/local/share/doc/git/technical/api-index.html
    
            6. git @ vger.kernel.org
               mailto: [email protected]
    
            7. [email protected]
               mailto: [email protected]
     

    КОЛОФОН верх

           Эта страница является частью  git  (распределенная система контроля версий Git)
           проект. Информацию о проекте можно найти на сайте
           ⟨Http: //git-scm.com/⟩. Если у вас есть отчет об ошибке для этой страницы руководства,
           см. «http://git-scm.com/community». Эта страница была получена из
           исходный репозиторий Git проекта ⟨https: // github.com / git / git.git⟩ на
           2020-11-01. (На тот момент дата последнего коммита,
           был найден в репозитории 2020-10-30.) Если вы обнаружите
           проблемы с отображением в этой HTML-версии страницы, или вы считаете
           есть лучший или более свежий источник для страницы, или у вас есть
           исправления или улучшения информации в этом COLOPHON
           (это , а не  часть исходной страницы руководства), отправьте письмо по адресу
           [email protected]
    
    
     

    Страницы, которые ссылаются на эту страницу:
    мерзавец (1),
    git-add (1),
    git-am (1),
    git-annotate (1),
    git-apply (1),
    git-archimport (1),
    git-архив (1),
    git-bisect (1),
    git-blame (1),
    git-branch (1),
    git-bugreport (1),
    git-bundle (1),
    git-cat-файл (1),
    git-check-attr (1),
    git-check-ignore (1),
    git-check-mailmap (1),
    git-checkout (1),
    git-checkout-index (1),
    git-check-ref-format (1),
    мерзавец-вишня (1),
    git-cherry-pick (1),
    гит-цитоол (1),
    git-clean (1),
    git-clone (1),
    git-столбец (1),
    git-commit (1),
    git-commit-graph (1),
    git-commit-tree (1),
    git-config (1),
    git-count-objects (1),
    git-credential-cache (1),
    git-credential-cache - демон (1),
    git-credential-store (1),
    git-cvsexportcommit (1),
    git-cvsimport (1),
    git-cvsserver (1),
    git-daemon (1),
    git-describe (1),
    git-diff (1),
    git-diff-файлы (1),
    git-diff-index (1),
    git-difftool (1),
    git-diff-tree (1),
    git-fast-export (1),
    git-fast-import (1),
    git-fetch (1),
    git-fetch-pack (1),
    git-filter-branch (1),
    git-fmt-merge-msg (1),
    git-for-each-ref (1),
    git-format-patch (1),
    git-fsck (1),
    git-fsck-objects (1),
    git-gc (1),
    git-get-tar-commit-id (1),
    git-grep (1),
    git-gui (1),
    git-hash-объект (1),
    git-help (1),
    git-http-backend (1),
    git-http-fetch (1),
    git-http-push (1),
    git-imap-send (1),
    git-index-pack (1),
    git-init (1),
    git-init-db (1),
    git-instaweb (1),
    git-интерпретатор-трейлеры (1),
    гитк (1),
    git-log (1),
    git-ls-файлы (1),
    git-ls-remote (1),
    git-ls-tree (1),
    git-mailinfo (1),
    git-mailsplit (1),
    git-обслуживание (1),
    git-merge (1),
    git-merge-base (1),
    git-merge-файл (1),
    git-merge-index (1),
    git-merge-one-file (1),
    git-mergetool (1),
    git-mergetool - библиотека (1),
    git-merge-tree (1),
    git-mktag (1),
    git-mktree (1),
    git-multi-pack-index (1),
    git-mv (1),
    git-name-rev (1),
    git-notes (1),
    git-p4 (1),
    git-pack-objects (1),
    git-pack-redundant (1),
    git-pack-refs (1),
    git-parse-remote (1),
    git-patch-id (1),
    git-prune (1),
    git-prune-pack (1),
    git-pull (1),
    git-push (1),
    git-quiltimport (1),
    git-range-diff (1),
    git-read-tree (1),
    git-rebase (1),
    git-receive-pack (1),
    git-reflog (1),
    git-relink (1),
    git-remote (1),
    git-remote-ext (1),
    git-remote-fd (1),
    gitremote-helpers (1),
    git-remote-testgit (1),
    git-repack (1),
    git-replace (1),
    git-request-pull (1),
    git-rerere (1),
    git-reset (1),
    git-restore (1),
    git-revert (1),
    git-rev-list (1),
    git-rev-parse (1),
    git-rm (1),
    git-send-email (1),
    git-send-pack (1),
    git-series (1),
    git-shell (1),
    git-sh-i18n (1),
    git-sh-i18n - envsubst (1),
    git-shortlog (1),
    git-show (1),
    git-show-branch (1),
    git-show-index (1),
    git-show-ref (1),
    git-sh-setup (1),
    git-sparse-checkout (1),
    git-stage (1),
    git-stash (1),
    git-status (1),
    git-stripspace (1),
    git-submodule (1),
    git-svn (1),
    git-переключатель (1),
    git-symbolic-ref (1),
    git-tag (1),
    git-unpack-file (1),
    git-unpack-objects (1),
    git-update-index (1),
    git-update-ref (1),
    git-update-server-info (1),
    git-upload-archive (1),
    git-upload-pack (1),
    git-var (1),
    git-verify-commit (1),
    git-verify-pack (1),
    git-verify-tag (1),
    gitweb (1),
    git-web - просмотр (1),
    git-whatchanged (1),
    git-worktree (1),
    git-write-tree (1),
    gitattributes (5),
    гитхуки (5),
    gitignore (5),
    gitmodules (5),
    gitrepository-layout (5),
    gitweb.conf (5),
    gitcli (7),
    gitcore-tutorial (7),
    gitcredentials (7),
    gitcvs-migration (7),
    gitdiffcore (7),
    giteveryday (7),
    gitfaq (7),
    гитглоссарий (7),
    gitnamespaces (7),
    gitremote-helpers (7),
    gitrevisions (7),
    gitsubmodules (7),
    gittutorial-2 (7),
    gittutorial (7),
    gitworkflows (7)


    Управляйте версиями файлов, как программист, с помощью Git

    Если вы когда-либо работали с коллегами над документом, вы знаете эту боль: кто-то берет первый проход ( document.doc ), а затем отправит его всем по электронной почте. Следующий человек делает то же самое, что и третий, каждый прикрепляет ревизию ( document_rev3.doc ) к имени файла. Менеджеру нравится то, что она видит, и она помечает это как завершенное ( document_final.doc ) ... до тех пор, пока не появятся изменения в последнюю минуту ( document_final_Aaron changes_reviewed_by_Bob_now_really_final.doc ).

    А теперь представьте такие изменения в десятках файлов исходного кода.Для решения этой проблемы программисты создали системы контроля версий (VCS). Они носят технический характер, но могут быть полезны и опытным пользователям. Давайте посмотрим на основы управления версиями с использованием топовой системы сегодня, Git .


    Что такое Git и почему вы должны использовать контроль версий, если вы разработчик

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

    Обзор используемого контроля версий

    Основная цель VCS - захват версии (также называемой ревизией ) файла с течением времени.Это означает, что нельзя полагаться на грубые методы, подобные описанному выше. В этих системах, когда вы открываете «document.doc», вы по умолчанию работаете с самой последней версией. Но вы также можете вернуться в историю файла и получить предыдущие версии. Системы, созданные специально для управления версиями файлов, начали с разработки программного обеспечения, но также нашли свое применение в более «массовых» приложениях.

    Эволюция контроля версий в разработке программного обеспечения

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

    Хотя эти системы второго поколения все еще широко используются, отрасль переходит на системы третьего поколения.Основная характеристика этих систем заключается в том, что они распределены по на , что означает отсутствие центрального репозитория. Скорее, у каждого пользователя есть собственная полная копия репозитория (включая все предыдущие версии). Но любые изменения (даже полные версии) являются «локальными» до тех пор, пока он не «выталкивает» их в другой репозиторий. Затем этот пользователь может вытащить клон, чтобы внести изменения и повторить процесс.

    Контроль текущих версий для непрограммистов

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

    Операционные системы могут сохранять историю файлов и папок.Это может происходить автоматически при каждом сохранении файла или по расписанию. Некоторые настольные приложения также позволяют захватывать версии или моментальные снимки файлов. Например, LibreOffice предоставляет функцию «Сохранить версию» (как показано на верхнем изображении ниже), которая позволяет сохранять несколько версий документа в одном файле. Наконец, веб / облачные приложения, такие как Google Drive, ownCloud и т. Д., Также сохранят прошлые итерации файла или документа (как показано для Документов Google на нижнем изображении ниже) либо за кулисами, либо по вашей экспресс-команде.

    Зачем тогда использовать ориентированный на программирование контроль версий?

    Поскольку все эти параметры на уровне ОС или приложения уже существуют, зачем возиться с этими занудными инструментами для программирования? У перечисленных выше методов есть несколько недостатков, в том числе:

    • Некоторые операционные системы сохраняют все изменения, внесенные вами в файл, в новой версии.Это не только займет ненужное место в хранилище, но и затруднит определение конкретной точки восстановления для файла.
    • Эти решения могут также использовать файл как базовую единицу для управления. Но системы контроля версий обычно работают на уровне каталогов (включая подкаталоги). VCS позволяет легко увидеть, какой файл был изменен и когда.
    • Эти же решения в большинстве случаев также не дают возможности маркировать итерации.Это также затрудняет поиск файла с отрывком текста, который вы перезаписали в какой-то момент, прежде чем вы осознали, насколько он великолепен.
    • Управление версиями операционными системами и приложениями, такими как Word, также создает единые точки отказа. Для Word это сам файл (если он поврежден, попрощайтесь со всеми своими прошлыми копиями). Для операционной системы это жесткий диск, если вы не являетесь ответственным пользователем и регулярно выполняете резервное копирование.
    • Природа веб-сервисов означает, что ваши старые версии могут находиться в облаке. Например, если вы попытаетесь просмотреть историю файла Dropbox в Linux (как показано на изображении ниже), вы будете перенаправлены на веб-сайт.

    Если какая-либо из этих проблем или все они заставляют вас хотеть большего, ознакомьтесь со следующим разделом, в котором мы решаем их с помощью Git .

    Контроль версий с помощью Git

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

    1.Настройка репозитория Git

    Если на вашем компьютере не установлен git (Mac, как и некоторые дистрибутивы Linux), вы можете либо загрузить установщик Windows со страницы загрузки проекта, либо установить его в Linux с помощью команды (специфичной для вашего дистрибутива), например:

      sudo apt install git  

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

      git init  

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

    2.Добавьте и зафиксируйте свой первый файл

    Следующим шагом будет создание некоторого контента (файлов) в вашем проекте.Это могут быть файлы любого типа, поскольку большинство программных проектов состоят из кода (текст) и ресурсов, таких как графика (двоичный). После создания выполните следующие действия в командной строке, все еще находясь в каталоге проекта:

      git статус  

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

      git -a. 

    Флаг «-a» означает «добавить», а точка относится к текущему каталогу.По сути, он говорит: «добавить все файлы в мой коммит». Теперь, чтобы совершить фиксацию, введите следующее:

      git commit -m "WHOOP, моя первая фиксация!"  

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

      git log --all --decorate --oneline --graph  

    Это покажет вам красивую временную шкалу вашего коммита с самым последним наверху.

    3.Создайте ответвление для эксперимента

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

      git branch эксперимент1 
    git checkout эксперимент1

    Вторая команда переключит вас на ветку «эксперимент1».Вы можете переключиться обратно, заменив его на «master». Когда вы начнете работать над своим текстом, обратите внимание на разницу между файлом и из каждой ветки. Во-первых, ветка "эксперимент1" с вашим новым текстом:

    Сравните это с оригиналом:

    Теперь, поработав некоторое время (заканчивая новым коммитом), лучшее, что вы могли придумать, - это «Lorem ipsum dolor sit amet...? "Что это? Это ерунда, и ее следует немедленно удалить из вашего проекта. Вы можете удалить свою ветку с помощью следующей команды (" -D "для принудительного удаления):

      ветка git -D эксперимент1  

    Теперь запустите еще одну ветку и добавьте что-нибудь умное вместе с изображениями:

      git ветка эксперимент2 
    git checkout эксперимент2 git add.git commit -m "Еще текст, добавленные изображения"

    4.Объедините ваши изменения

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

      git merge эксперимент 2  

    Теперь у вас будет ревизия, которая сочетает в себе последнюю версию "master" и последнюю версию "эксперимента2"."На этом этапе вы можете избавиться от эксперимента (в конце концов, он был успешным) с помощью следующего:

      git ветка -d эксперимент2  

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

    5. Переместите в безопасное место

    Наконец, Git - это распределенная система , что означает, что вы можете иметь несколько копий своего репозитория и синхронизировать их.Например, создайте новый репозиторий на сервере, к которому вы можете подключиться по SSH, с помощью этой команды:

      git init --bare  

    Флаг «--bare» настраивает его как своего рода репозиторий только для чтения, в котором вы не можете напрямую изменять файлы.Затем вы можете установить это как удаленную копию вашего локального репозитория следующим образом (первая команда гарантирует, что новые локальные ветки создаются удаленно):

      git config push.соответствие по умолчанию 
    git remote add central ssh: // [имя пользователя] @ [URL] / путь / к / репозиторию git push --set-upstream central master

    Настройка управления версиями и резервного копирования с помощью Git

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

    1. Внесите изменения в файлы проекта.
    2. Ошибка "git add." чтобы добавить все изменения в коммит.
    3. Выполните «git commit -m [некоторое сообщение]», чтобы зафиксировать изменения в локальном репозитории . Повторите с самого начала.
    4. Введите команду «git push», чтобы регулярно фиксировать изменения в удаленном репозитории.
    5. Выдать "git clone ssh: // [username] @ [URL] / path / to / repository" с другого компьютера на

    Интересуют ли преимущества систем контроля версий? Или достаточно ли приложений резервного копирования, не связанных с разработкой, для ваших нужд? Поделитесь с нами своими мыслями в комментариях ниже!

    Изучите кодирование из дома с помощью этого полного курса разработки

    Начните свою карьеру в области ИТ, изучив языки программирования с помощью курсов по C #, JavaScript, HTML5, CSS3, SQL и Python.

    Об авторе

    Аарон Питерс
    (Опубликовано 31 статья)

    Аарон глубоко разбирался в технологиях в качестве бизнес-аналитика и менеджера проектов на протяжении пятнадцати лет и был лояльным пользователем Ubuntu почти столько же (со времен Breezy Badger).Его интересы включают открытый исходный код, приложения для малого бизнеса, интеграцию Linux и Android, а также вычисления в текстовом режиме.

    Ещё от Aaron Peters

    Подпишитесь на нашу рассылку новостей

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

    Еще один шаг…!

    Подтвердите свой адрес электронной почты в письме, которое мы вам только что отправили.

Want to say something? Post a comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *