{"draftJsState":{"blocks":[{"data":{},"depth":0,"entityRanges":[{"key":0,"length":1,"offset":48}],"inlineStyleRanges":[],"text":"3.1 Ветвление в Git - О ветвлении в двух словах #","type":"header-two","key":"fm2ps"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Почти каждая система контроля версий (СКВ) в какой-то форме поддерживает ветвление. Используя ветвление, Вы отклоняетесь от основной линии разработки и продолжаете работу независимо от неё, не вмешиваясь в основную линию. Во многих СКВ создание веток — это очень затратный процесс, часто требующий создания новой копии каталога с исходным кодом, что может занять много времени для большого проекта.","type":"unstyled","key":"fo9an"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Некоторые люди, говоря о модели ветвления Git, называют ее «киллер-фича», что выгодно выделяет Git на фоне остальных СКВ. Что в ней такого особенного? Ветвление Git очень легковесно: операция создания ветки выполняется почти мгновенно, переключение между ветками туда-сюда, обычно, также быстро. В отличие от многих других СКВ, Git поощряет процесс работы, при котором ветвление и слияние выполняется часто, даже по несколько раз в день. Понимание и владение этой функциональностью дает вам уникальный и мощный инструмент, который может полностью изменить привычный процесс разработки.","type":"unstyled","key":"8g1hc"},{"data":{},"depth":0,"entityRanges":[{"key":1,"length":1,"offset":26}],"inlineStyleRanges":[],"text":"О ветвлении в двух словах #","type":"header-two","key":"enihf"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Для точного понимания механизма ветвлений, необходимо вернуться назад и изучить то, как Git хранит данные.","type":"unstyled","key":"cgngh"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Как вы можете помнить из Что такое Git?, Git не хранит данные в виде последовательности изменений, он использует набор снимков (snapshot).","type":"unstyled","key":"7ac84"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Когда вы делаете коммит, Git сохраняет его в виде объекта, который содержит указатель на снимок (snapshot) подготовленных данных. Этот объект так же содержит имя автора и email, сообщение и указатель на коммит или коммиты непосредственно предшествующие данному (его родителей): отсутствие родителя для первоначального коммита, один родитель для обычного коммита, и несколько родителей для результатов слияния двух и более веток.","type":"unstyled","key":"7v41n"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":4,"offset":274,"style":"ITALIC"}],"text":"Предположим, у вас есть каталог с тремя файлами и вы добавляете их все в индекс и создаёте коммит. Во время индексации вычисляется контрольная сумма каждого файла (SHA-1 как мы узнали из Что такое Git?), затем каждый файл сохраняется в репозиторий (Git называет такой файл блоб — большой бинарный объект), а контрольная сумма попадёт в индекс:","type":"unstyled","key":"4o2vu"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git add README test.rb LICENSE\n$ git commit -m 'Initial commit'","type":"unstyled","key":"6f8je"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Когда вы создаёте коммит командой git commit, Git вычисляет контрольные суммы каждого подкаталога (в нашем случае, только основной каталог проекта) и сохраняет его в репозитории как объект дерева каталогов. Затем Git создаёт объект коммита с метаданными и указателем на основное дерево проекта для возможности воссоздать этот снимок в случае необходимости.","type":"unstyled","key":"7trm4"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":6,"offset":101,"style":"ITALIC"},{"length":7,"offset":189,"style":"ITALIC"}],"text":"Ваш репозиторий Git теперь хранит пять объектов: три блоб объекта (по одному на каждый файл), объект дерева каталогов, содержащий список файлов и соответствующих им блобов, а так же объект коммита, содержащий метаданные и указатель на объект дерева каталогов.","type":"unstyled","key":"f557f"},{"data":{"image":{"id":"622cc8c48ae1c12db16b7d57"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 9","type":"atomic:image","key":"4rtn7"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 9. Коммит и его дерево","type":"unstyled","key":"2kn1l"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Если вы сделаете изменения и создадите ещё один коммит, то он будет содержать указатель на предыдущий коммит.","type":"unstyled","key":"4v6oi"},{"data":{"image":{"id":"622cc8c47319027bedfb5bb7"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 10","type":"atomic:image","key":"3dbc4"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 10. Коммит и его родители","type":"unstyled","key":"ujn0"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Ветка в Git — это простой перемещаемый указатель на один из таких коммитов. По умолчанию, имя основной ветки в Git — master. Как только вы начнёте создавать коммиты, ветка master будет всегда указывать на последний коммит. Каждый раз при создании коммита указатель ветки master будет передвигаться на следующий коммит автоматически.","type":"unstyled","key":"b4j0h"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":10,"offset":0,"style":"ITALIC"}],"text":"Примечание Ветка «master» в Git — это не какая-то особенная ветка. Она точно такая же, как и все остальные ветки. Она существует почти во всех репозиториях только лишь потому, что её создаёт команда git init, а большинство людей не меняют её название.","type":"unstyled","key":"5niar"},{"data":{"image":{"id":"622cc8c45903191c13aef1d6"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 11","type":"atomic:image","key":"1ptub"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 11. Ветка и история коммитов","type":"unstyled","key":"7m034"},{"data":{},"depth":0,"entityRanges":[{"key":2,"length":1,"offset":21}],"inlineStyleRanges":[],"text":"Создание новой ветки #","type":"header-three","key":"fholf"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Что же на самом деле происходит при создании ветки? Всего лишь создаётся новый указатель для дальнейшего перемещения. Допустим вы хотите создать новую ветку с именем testing. Вы можете это сделать командой git branch :","type":"unstyled","key":"5degp"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git branch testing","type":"unstyled","key":"7vo79"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"В результате создаётся новый указатель на текущий коммит.","type":"unstyled","key":"12tac"},{"data":{"image":{"id":"622cc8c410f1f97bff65872c"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 12","type":"atomic:image","key":"35dns"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 12. Две ветки указывают на одну и ту же последовательность коммитов","type":"unstyled","key":"a25bh"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":7,"offset":370,"style":"ITALIC"}],"text":"Как Git определяет, в какой ветке вы находитесь? Он хранит специальный указатель HEAD. Имейте ввиду, что в Git концепция HEAD значительно отличается от других систем контроля версий, которые вы могли использовать раньше (Subversion или CVS). В Git — это указатель на текущую локальную ветку. В нашем случае мы все еще находимся в ветке master. Команда git branch только создаёт новую ветку, но не переключает на неё.","type":"unstyled","key":"2lh85"},{"data":{"image":{"id":"622cc8c4ae29be6a2be0133a"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 13","type":"atomic:image","key":"282b5"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 13. HEAD указывает на ветку","type":"unstyled","key":"4rdoe"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Вы можете легко это увидеть при помощи простой команды git log, которая покажет вам куда указывают указатели веток. Эта опция называется --decorate.","type":"unstyled","key":"2pte6"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git log --oneline --decorate\nf30ab (HEAD -> master, testing) Add feature #32 - ability to add new formats to the central interface\n34ac2 Fix bug #1328 - stack overflow under certain conditions\n98ca9 Initial commit","type":"unstyled","key":"b6top"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Здесь можно увидеть указывающие на коммит f30ab ветки: master и testing.","type":"unstyled","key":"4fdrr"},{"data":{},"depth":0,"entityRanges":[{"key":3,"length":1,"offset":19}],"inlineStyleRanges":[],"text":"Переключение веток #","type":"header-three","key":"fjbd4"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Для переключения на существующую ветку выполните команду git checkout. Давайте переключимся на ветку testing:","type":"unstyled","key":"c5s5"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git checkout testing","type":"unstyled","key":"fbalq"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"В результате указатель HEAD переместится на ветку testing.","type":"unstyled","key":"4l9ih"},{"data":{"image":{"id":"622cc8c4f53aef1fff152950"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 14","type":"atomic:image","key":"2c6th"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 14. HEAD указывает на текущую ветку","type":"unstyled","key":"806ln"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Какой в этом смысл? Давайте сделаем ещё один коммит:","type":"unstyled","key":"416ql"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ vim test.rb\n$ git commit -a -m 'made a change'","type":"unstyled","key":"cjmoo"},{"data":{"image":{"id":"622cc8c6998da2772ef3c09b"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 15","type":"atomic:image","key":"3h413"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 15. Указатель на ветку HEAD переместился вперёд после коммита","type":"unstyled","key":"4l912"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Интересная ситуация: указатель на ветку testing переместился вперёд, а master указывает на тот же коммит, где вы были до переключения веток командой git checkout. Давайте переключимся назад на ветку master:","type":"unstyled","key":"cbkef"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git checkout master","type":"unstyled","key":"9pf8q"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Примечание git log не показывает все ветки по умолчанию\n\nЕсли выполнить команду git log прямо сейчас, то в её выводе только что созданная ветка «testing» фигурировать не будет.\n\nВетка никуда не исчезла; просто Git не знает, что именно она вас интересует, и выводит наиболее полезную по его мнению информацию. Другими словами, по умолчанию git log отобразит историю коммитов только для текущей ветки.\n\nДля просмотра истории коммитов другой ветки необходимо явно указать её имя: git log testing Чтобы посмотреть историю по всем веткам — выполните команду с дополнительным флагом: git log --all.","type":"unstyled","key":"aq8s9"},{"data":{"image":{"id":"622cc8c67319027bedfb5f2b"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 16","type":"atomic:image","key":"1bnng"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 16. HEAD перемещается когда вы делаете checkout","type":"unstyled","key":"fmrk6"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Эта команда сделала две вещи: переместила указатель HEAD назад на ветку master и вернула файлы в рабочем каталоге в то состояние, на снимок которого указывает master. Это также означает, что все вносимые с этого момента изменения будут относиться к старой версии проекта. Другими словами, вы откатили все изменения ветки testing и можете продолжать в другом направлении.","type":"unstyled","key":"65ss9"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":10,"offset":0,"style":"ITALIC"}],"text":"Примечание Переключение веток меняет файлы в рабочем каталоге\n\nВажно запомнить, что при переключении веток в Git происходит изменение файлов в рабочем каталоге. Если вы переключаетесь на старую ветку, то рабочий каталог будет выглядеть так же, как выглядел на момент последнего коммита в ту ветку. Если Git по каким-то причинам не может этого сделать — он не позволит вам переключиться вообще.","type":"unstyled","key":"4i8e1"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Давайте сделаем еще несколько изменений и создадим очередной коммит:","type":"unstyled","key":"dhlsj"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ vim test.rb\n$ git commit -a -m 'made other changes'","type":"unstyled","key":"ejs8o"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Теперь история вашего проекта разошлась (см Разветвлённая история). Вы создали ветку и переключились на нее, поработали, а затем вернулись в основную ветку и поработали в ней. Эти изменения изолированы друг от друга: вы можете свободно переключаться туда и обратно, а когда понадобится — объединить их. И все это делается простыми командами: branch, checkout и commit.","type":"unstyled","key":"ccjsj"},{"data":{"image":{"id":"622cc8c6e8bfec1394519c39"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 17","type":"atomic:image","key":"63o0g"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 17. Разветвлённая история","type":"unstyled","key":"53n5h"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Все описанные действия можно визуализировать с помощью команды git log. Для отображения истории коммитов, текущего положения указателей веток и истории ветвления выполните команду git log --oneline --decorate --graph --all.","type":"unstyled","key":"4648s"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git log --oneline --decorate --graph --all\n* c2b9e (HEAD, master) Made other changes\n| * 87ab2 (testing) Made a change\n|/\n* f30ab Add feature #32 - ability to add new formats to the central interface\n* 34ac2 Fix bug #1328 - stack overflow under certain conditions\n* 98ca9 initial commit of my project","type":"unstyled","key":"126ks"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Ветка в Git — это простой файл, содержащий 40 символов контрольной суммы SHA-1 коммита, на который она указывает; поэтому операции с ветками являются дешёвыми с точки зрения потребления ресурсов или времени. Создание новой ветки в Git происходит так же быстро и просто как запись 41 байта в файл (40 знаков и перевод строки).","type":"unstyled","key":"9qe0v"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Это принципиально отличает процесс ветвления в Git от более старых систем контроля версий, где все файлы проекта копируются в другой подкаталог. В зависимости от размера проекта, операции ветвления в таких системах могут занимать секунды или даже минуты, когда в Git эти операции мгновенны. Поскольку при коммите мы сохраняем указатель на родительский коммит, то поиск подходящей базы для слияния веток делается автоматически и, в большинстве случаев, очень прост. Эти возможности побуждают разработчиков чаще создавать и использовать ветки.","type":"unstyled","key":"5o393"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Давайте посмотрим, почему и вам имеет смысл делать так же.","type":"unstyled","key":"eh4a4"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":10,"offset":0,"style":"ITALIC"},{"length":10,"offset":215,"style":"ITALIC"}],"text":"Примечание Одновременное создание новой ветки и переключение на неё\n\nКак правило, при создании новой ветки вы хотите сразу на неё переключиться — это можно сделать используя команду git checkout -b . Примечание Начиная с Git версии 2.23, вы можете использовать git switch вместо git checkout, чтобы:\n\n- Переключиться на существующую ветку: git switch testing-branch.\n- Создать новую ветку и переключиться на нее: git switch -c new-branch. Флаг -c означает создание, но также можно использовать полный формат: --create.\n- Вернуться к предыдущей извлечённой ветке: git switch -.","type":"unstyled","key":"a080a"},{"data":{},"depth":0,"entityRanges":[{"key":4,"length":1,"offset":49}],"inlineStyleRanges":[],"text":"3.2 Ветвление в Git - Основы ветвления и слияния #","type":"header-two","key":"1j3o6"},{"data":{},"depth":0,"entityRanges":[{"key":5,"length":1,"offset":27}],"inlineStyleRanges":[],"text":"Основы ветвления и слияния #","type":"header-two","key":"28lht"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Давайте рассмотрим простой пример рабочего процесса, который может быть полезен в вашем проекте. Ваша работа построена так:","type":"unstyled","key":"3b8ns"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Вы работаете над сайтом.","type":"ordered-list-item","key":"biecl"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Вы создаете ветку для новой статьи, которую вы пишете.","type":"ordered-list-item","key":"etscg"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Вы работаете в этой ветке.","type":"ordered-list-item","key":"9f7nd"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"В этот момент вы получаете сообщение, что обнаружена критическая ошибка, требующая скорейшего исправления. Ваши действия:","type":"unstyled","key":"9n6ol"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Переключиться на основную ветку.","type":"ordered-list-item","key":"af8aj"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Создать ветку для добавления исправления.","type":"ordered-list-item","key":"88v2"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"После тестирования слить ветку содержащую исправление с основной веткой.","type":"ordered-list-item","key":"eetdi"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Переключиться назад в ту ветку, где вы пишете статью и продолжить работать.","type":"ordered-list-item","key":"9p3es"},{"data":{},"depth":0,"entityRanges":[{"key":6,"length":1,"offset":17}],"inlineStyleRanges":[],"text":"Основы ветвления #","type":"header-three","key":"75gl7"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Предположим, вы работаете над проектом и уже имеете несколько коммитов.","type":"unstyled","key":"9f59k"},{"data":{"image":{"id":"622cc8c6b8370032ffad38a5"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 18","type":"atomic:image","key":"6lqe7"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 18. Простая история коммитов","type":"unstyled","key":"41hpp"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Вы решаете, что теперь вы будете заниматься проблемой #53 из вашей системы отслеживания ошибок. Чтобы создать ветку и сразу переключиться на нее, можно выполнить команду git checkout с параметром -b:","type":"unstyled","key":"66ie6"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git checkout -b iss53\nSwitched to a new branch \"iss53\"","type":"unstyled","key":"76hi2"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Это то же самое что и:","type":"unstyled","key":"9890f"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git branch iss53\n$ git checkout iss53","type":"unstyled","key":"6hjiv"},{"data":{"image":{"id":"622cc8c6ae29be6a2be0174c"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 19","type":"atomic:image","key":"3ab2p"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 19. Создание нового указателя ветки","type":"unstyled","key":"8iq59"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Вы работаете над своим сайтом и делаете коммиты. Это приводит к тому, что ветка iss53 движется вперед, так как вы переключились на нее ранее (HEAD указывает на нее).","type":"unstyled","key":"vo2v"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ vim index.html\n$ git commit -a -m 'Create new footer [issue 53]'","type":"unstyled","key":"66lpe"},{"data":{"image":{"id":"622cc8c7c2b0553e20f017cd"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 20","type":"atomic:image","key":"c0o63"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 20. Ветка iss53 двигается вперед","type":"unstyled","key":"2m6kv"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Тут вы получаете сообщение об обнаружении уязвимости на вашем сайте, которую нужно немедленно устранить. Благодаря Git, не требуется размещать это исправление вместе с тем, что вы сделали в iss53. Вам даже не придется прилагать усилий, чтобы откатить все эти изменения для начала работы над исправлением. Все, что вам нужно — переключиться на ветку master.","type":"unstyled","key":"amqr2"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Но перед тем как сделать это — имейте в виду, что если рабочий каталог либо индекс содержат незафиксированные изменения, конфликтующие с веткой, на которую вы хотите переключиться, то Git не позволит переключить ветки. Лучше всего переключаться из чистого рабочего состояния проекта. Есть способы обойти это (припрятать изменения (stash) или добавить их в последний коммит (amend)), но об этом мы поговорим позже в разделе Припрятывание и очистка главы 7. Теперь предположим, что вы зафиксировали все свои изменения и можете переключиться на ветку master:","type":"unstyled","key":"78o6p"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git checkout master\nSwitched to branch 'master'","type":"unstyled","key":"ar7os"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"С этого момента ваш рабочий каталог имеет точно такой же вид, какой был перед началом работы над проблемой #53, и вы можете сосредоточиться на работе над исправлением. Важно запомнить: когда вы переключаете ветки, Git возвращает состояние рабочего каталога к тому виду, какой он имел в момент последнего коммита в эту ветку. Он добавляет, удаляет и изменяет файлы автоматически, чтобы состояние рабочего каталога соответствовало тому, когда был сделан последний коммит.","type":"unstyled","key":"f7fcg"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Теперь вы можете перейти к написанию исправления. Давайте создадим новую ветку для исправления, в которой будем работать, пока не закончим исправление.","type":"unstyled","key":"dmuc7"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git checkout -b hotfix\nSwitched to a new branch 'hotfix'\n$ vim index.html\n$ git commit -a -m 'Fix broken email address'\n[hotfix 1fb7853] Fix broken email address\n 1 file changed, 2 insertions(+)","type":"unstyled","key":"qrnc"},{"data":{"image":{"id":"622cc8c89916f3091a9ac463"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 21","type":"atomic:image","key":"flce4"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 21. Ветка hotfix основана на ветке master","type":"unstyled","key":"9h6rg"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Вы можете прогнать тесты, чтобы убедиться, что ваше исправление делает именно то, что нужно. И если это так — выполнить слияние ветки hotfix с веткой master для включения изменений в продукт. Это делается командой git merge:","type":"unstyled","key":"aemv1"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git checkout master\n$ git merge hotfix\nUpdating f42c576..3a0874c\nFast-forward\n index.html | 2 ++\n 1 file changed, 2 insertions(+)","type":"unstyled","key":"4e7qi"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Заметили фразу «fast-forward» в этом слиянии? Git просто переместил указатель ветки вперед, потому что коммит C4, на который указывает слитая ветка hotfix, был прямым потомком коммита C2, на котором вы находились до этого. Другими словами, если коммит сливается с тем, до которого можно добраться двигаясь по истории прямо, Git упрощает слияние просто перенося указатель ветки вперед, так как нет расхождений в изменениях. Это называется «fast-forward».","type":"unstyled","key":"5qga3"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Теперь ваши изменения включены в коммит, на который указывает ветка master, и исправление можно внедрять.","type":"unstyled","key":"2c1s4"},{"data":{"image":{"id":"622cc8c8a5b41152f48a5fa2"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 22","type":"atomic:image","key":"1pavo"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 22. master перемотан до hotfix","type":"unstyled","key":"dqr7t"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"После внедрения вашего архиважного исправления, вы готовы вернуться к работе над тем, что были вынуждены отложить. Но сначала нужно удалить ветку hotfix, потому что она больше не нужна — ветка master указывает на то же самое место. Для удаления ветки выполните команду git branch с параметром -d:","type":"unstyled","key":"4c3ah"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git branch -d hotfix\nDeleted branch hotfix (3a0874c).","type":"unstyled","key":"6t5pr"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Теперь вы можете переключиться обратно на ветку iss53 и продолжить работу над проблемой #53:","type":"unstyled","key":"bnqkr"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git checkout iss53\nSwitched to branch \"iss53\"\n$ vim index.html\n$ git commit -a -m 'Finish the new footer [issue 53]'\n[iss53 ad82d7a] Finish the new footer [issue 53]\n1 file changed, 1 insertion(+)","type":"unstyled","key":"6981h"},{"data":{"image":{"id":"622cc8c8e8bfec1394519faa"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 23","type":"atomic:image","key":"45df3"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 23. Продолжение работы над iss53","type":"unstyled","key":"n09g"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Стоит обратить внимание на то, что все изменения из ветки hotfix не включены в вашу ветку iss53. Если их нужно включить, вы можете влить ветку master в вашу ветку iss53 командой git merge master, или же вы можете отложить слияние этих изменений до завершения работы, и затем влить ветку iss53 в master.","type":"unstyled","key":"59h1o"},{"data":{},"depth":0,"entityRanges":[{"key":7,"length":1,"offset":15}],"inlineStyleRanges":[],"text":"Основы слияния #","type":"header-three","key":"bemrb"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Предположим, вы решили, что работа по проблеме #53 закончена и её можно влить в ветку master. Для этого нужно выполнить слияние ветки iss53 точно так же, как вы делали это с веткой hotfix ранее. Все, что нужно сделать — переключиться на ветку, в которую вы хотите включить изменения, и выполнить команду git merge:","type":"unstyled","key":"8mtqe"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git checkout master\nSwitched to branch 'master'\n$ git merge iss53\nMerge made by the 'recursive' strategy.\nindex.html | 1 +\n1 file changed, 1 insertion(+)","type":"unstyled","key":"83a1v"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Результат этой операции отличается от результата слияния ветки hotfix. В данном случае процесс разработки ответвился в более ранней точке. Так как коммит, на котором мы находимся, не является прямым родителем ветки, с которой мы выполняем слияние, Git придётся немного потрудиться. В этом случае Git выполняет простое трёхстороннее слияние, используя последние коммиты объединяемых веток и общего для них родительского коммита.","type":"unstyled","key":"btc1b"},{"data":{"image":{"id":"622cc8c9998da2772ef3c254"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 24","type":"atomic:image","key":"3iead"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 24. Использование трёх снимков при слиянии","type":"unstyled","key":"9l57q"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Вместо того, чтобы просто передвинуть указатель ветки вперёд, Git создаёт новый результирующий снимок трёхстороннего слияния, а затем автоматически делает коммит. Этот особый коммит называют коммитом слияния, так как у него более одного предка.","type":"unstyled","key":"9asea"},{"data":{"image":{"id":"622cc8c95e4d0a774ee4d539"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 25","type":"atomic:image","key":"af8ot"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 25. Коммит слияния","type":"unstyled","key":"6prtk"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Теперь, когда изменения слиты, ветка iss53 больше не нужна. Вы можете закрыть задачу в системе отслеживания ошибок и удалить ветку:","type":"unstyled","key":"9bdnu"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git branch -d iss53","type":"unstyled","key":"4uu03"},{"data":{},"depth":0,"entityRanges":[{"key":8,"length":1,"offset":27}],"inlineStyleRanges":[],"text":"Основные конфликты слияния #","type":"header-three","key":"9t8tu"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Иногда процесс не проходит гладко. Если вы изменили одну и ту же часть одного и того же файла по-разному в двух объединяемых ветках, Git не сможет их чисто объединить. Если ваше исправление ошибки #53 потребовало изменить ту же часть файла что и hotfix, вы получите примерно такое сообщение о конфликте слияния:","type":"unstyled","key":"934li"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git merge iss53\nAuto-merging index.html\nCONFLICT (content): Merge conflict in index.html\nAutomatic merge failed; fix conflicts and then commit the result.","type":"unstyled","key":"aj29p"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Git не создал коммит слияния автоматически. Он остановил процесс до тех пор, пока вы не разрешите конфликт. Чтобы в любой момент после появления конфликта увидеть, какие файлы не объединены, вы можете запустить git status:","type":"unstyled","key":"bmgsv"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git status\nOn branch master\nYou have unmerged paths.\n (fix conflicts and run \"git commit\")\n\nUnmerged paths:\n (use \"git add ...\" to mark resolution)\n\n both modified: index.html\n\nno changes added to commit (use \"git add\" and/or \"git commit -a\")","type":"unstyled","key":"61s96"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Всё, где есть неразрешённые конфликты слияния, перечисляется как неслитое. В конфликтующие файлы Git добавляет специальные маркеры конфликтов, чтобы вы могли исправить их вручную. В вашем файле появился раздел, выглядящий примерно так:","type":"unstyled","key":"54svp"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"<<<<<<< HEAD:index.html \n=======\n\n>>>>>>> iss53:index.html","type":"unstyled","key":"djsnl"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Это означает, что версия из HEAD (вашей ветки master, поскольку именно её вы извлекли перед запуском команды слияния) — это верхняя часть блока (всё, что над =======), а версия из вашей ветки iss53 представлена в нижней части. Чтобы разрешить конфликт, придётся выбрать один из вариантов, либо объединить содержимое по-своему. Например, вы можете разрешить конфликт, заменив весь блок следующим:","type":"unstyled","key":"1k3c5"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"unstyled","key":"3nk0t"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"В этом разрешении есть немного от каждой части, а строки <<<<<<<, ======= и >>>>>>> полностью удалены. Разрешив каждый конфликт во всех файлах, запустите git add для каждого файла, чтобы отметить конфликт как решённый. Добавление файла в индекс означает для Git, что все конфликты в нём исправлены.","type":"unstyled","key":"fv5s7"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Если вы хотите использовать графический инструмент для разрешения конфликтов, можно запустить git mergetool, который проведет вас по всем конфликтам:","type":"unstyled","key":"38eav"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git mergetool\n\nThis message is displayed because 'merge.tool' is not configured.\nSee 'git mergetool --tool-help' or 'git help config' for more details.\n'git mergetool' will now attempt to use one of the following tools:\nopendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge\nMerging:\nindex.html\n\nNormal merge conflict for 'index.html':\n {local}: modified file\n {remote}: modified file\nHit return to start merge resolution tool (opendiff):","type":"unstyled","key":"2sosv"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Если вы хотите использовать инструмент слияния не по умолчанию (в данном случае Git выбрал opendiff, поскольку команда запускалась на Mac), список всех поддерживаемых инструментов представлен вверху после фразы «one of the following tools». Просто введите название инструмента, который хотите использовать.","type":"unstyled","key":"2rh1o"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":10,"offset":0,"style":"ITALIC"}],"text":"Примечание Мы рассмотрим более продвинутые инструменты для разрешения сложных конфликтов слияния в разделе Продвинутое слияние главы 7.","type":"unstyled","key":"aopn9"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"После выхода из инструмента слияния Git спросит об успешности процесса. Если вы ответите скрипту утвердительно, то он добавит файл в индекс, чтобы отметить его как разрешенный. Теперь можно снова запустить git status, чтобы убедиться в отсутствии конфликтов:","type":"unstyled","key":"8ou84"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git status\nOn branch master\nAll conflicts fixed but you are still merging.\n (use \"git commit\" to conclude merge)\n\nChanges to be committed:\n\n modified: index.html","type":"unstyled","key":"bc28t"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Если это вас устраивает и вы убедились, что все файлы, где были конфликты, добавлены в индекс — выполните команду git commit для создания коммита слияния. Комментарий к коммиту слияния по умолчанию выглядит примерно так:","type":"unstyled","key":"70e6q"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Merge branch 'iss53'\n\nConflicts:\n index.html\n#\n# It looks like you may be committing a merge.\n# If this is not correct, please remove the file\n# .git/MERGE_HEAD\n# and try again.\n\n\n# Please enter the commit message for your changes. Lines starting\n# with '#' will be ignored, and an empty message aborts the commit.\n# On branch master\n# All conflicts fixed but you are still merging.\n#\n# Changes to be committed:\n# modified: index.html\n#","type":"unstyled","key":"c8sve"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Если вы считаете, что коммит слияния требует дополнительных пояснений — опишите как были разрешены конфликты и почему были применены именно такие изменения, если это не очевидно.","type":"unstyled","key":"8ded6"},{"data":{},"depth":0,"entityRanges":[{"key":9,"length":1,"offset":41}],"inlineStyleRanges":[],"text":"3.3 Ветвление в Git - Управление ветками #","type":"header-two","key":"2biem"},{"data":{},"depth":0,"entityRanges":[{"key":10,"length":1,"offset":19}],"inlineStyleRanges":[],"text":"Управление ветками #","type":"header-two","key":"9f0ba"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Теперь, когда вы уже попробовали создавать, объединять и удалять ветки, пора познакомиться с некоторыми инструментами для управления ветками, которые вам пригодятся, когда вы начнёте использовать ветки постоянно.","type":"unstyled","key":"4ajil"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Команда git branch делает несколько больше, чем просто создаёт и удаляет ветки. При запуске без параметров, вы получите простой список имеющихся у вас веток:","type":"unstyled","key":"4nior"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git branch\n iss53\n* master\n testing","type":"unstyled","key":"38gdk"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Обратите внимание на символ *, стоящий перед веткой master: он указывает на ветку, на которой вы находитесь в настоящий момент (т. е. ветку, на которую указывает HEAD). Это означает, что если вы сейчас сделаете коммит, ветка master переместится вперёд в соответствии с вашими последними изменениями. Чтобы посмотреть последний коммит на каждой из веток, выполните команду git branch -v:","type":"unstyled","key":"9it9l"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git branch -v\n iss53 93b412c Fix javascript issue\n* master 7a98805 Merge branch 'iss53'\n testing 782fd34 Add scott to the author list in the readme","type":"unstyled","key":"acen8"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Опции --merged и --no-merged могут отфильтровать этот список для вывода только тех веток, которые слиты или ещё не слиты в текущую ветку. Чтобы посмотреть те ветки, которые вы уже слили с текущей, можете выполнить команду git branch --merged:","type":"unstyled","key":"qgeg"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git branch --merged\n iss53\n* master","type":"unstyled","key":"4ctk9"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Ветка iss53 присутствует в этом списке потому что вы ранее слили её в master. Те ветки из этого списка, перед которыми нет символа *, можно смело удалять командой git branch -d; наработки из этих веток уже включены в другую ветку, так что ничего не потеряется.","type":"unstyled","key":"5ne4m"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Чтобы увидеть все ветки, содержащие наработки, которые вы пока ещё не слили в текущую ветку, выполните команду git branch --no-merged:","type":"unstyled","key":"ae6if"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git branch --no-merged\n testing","type":"unstyled","key":"2p72h"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Вы увидите оставшуюся ветку. Так как она содержит ещё не слитые наработки, попытка удалить её командой git branch -d приведёт к ошибке:","type":"unstyled","key":"dq7fu"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git branch -d testing\nerror: The branch 'testing' is not fully merged.\nIf you are sure you want to delete it, run 'git branch -D testing'.","type":"unstyled","key":"29fk5"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Если вы действительно хотите удалить ветку вместе со всеми наработками, используйте опцию -D, как указано в подсказке.","type":"unstyled","key":"40ugn"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":7,"offset":138,"style":"ITALIC"}],"text":"ПодсказкаЕсли в качестве аргумента не указан коммит или ветка, то опции --merged и --no-merged покажут что уже слито или не слито с вашей текущей веткой соответственно.\n\nВы всегда можете указать дополнительный аргумент для вывода той же информации, но относительно указанной ветки предварительно не извлекая и не переходя на неё.\n\nconsole
$ git checkout testing
$ git branch --no-merged master
topicA
featureB
","type":"unstyled","key":"4g4sa"},{"data":{},"depth":0,"entityRanges":[{"key":11,"length":1,"offset":21}],"inlineStyleRanges":[],"text":"Переименование ветки #","type":"header-three","key":"9s9kh"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"ВниманиеНе переименовывайте ветки, которые всё ещё используются другими участниками. Не переименовывайте ветку в master/main/mainline, не прочитав раздел «Изменение имени главной ветки».","type":"unstyled","key":"8jtui"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Предположим, у вас есть ветка с именем bad-branch-name, и вы хотите изменить её на corrected-branch-name, сохранив при этом всю историю. Вместе с этим, вы также хотите изменить имя ветки на удалённом сервере (GitHub, GitLab или другой сервер). Как это сделать?","type":"unstyled","key":"46vke"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Переименуйте ветку локально с помощью команды git branch --move:","type":"unstyled","key":"d3pcs"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git branch --move bad-branch-name corrected-branch-name","type":"unstyled","key":"aluri"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Ветка bad-branch-name будет переименована в corrected-branch-name, но это изменение пока только локальное. Чтобы все остальные увидели исправленную ветку в удалённом репозитории, отправьте её туда:","type":"unstyled","key":"aamg9"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git push --set-upstream origin corrected-branch-name","type":"unstyled","key":"dsv23"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Теперь проверим, где мы сейчас находимся:","type":"unstyled","key":"l67k"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git branch --all\n* corrected-branch-name\n main\n remotes/origin/bad-branch-name\n remotes/origin/corrected-branch-name\n remotes/origin/main","type":"unstyled","key":"68lvj"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Обратите внимание, что текущая ветка corrected-branch-name, которая также присутствует и на удалённом сервере. Однако, старая ветка всё ещё по-прежнему там, но её можно удалить с помощью команды:","type":"unstyled","key":"3126s"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git push origin --delete bad-branch-name","type":"unstyled","key":"839lj"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Теперь старое имя ветки полностью заменено исправленным.","type":"unstyled","key":"513mj"},{"data":{},"depth":0,"entityRanges":[{"key":12,"length":1,"offset":30}],"inlineStyleRanges":[],"text":"Изменение имени главной ветки #","type":"header-three","key":"9005q"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":14,"offset":0,"style":"ITALIC"}],"text":"Предупреждение Изменение имени ветки, например master/main/mainline/default, сломает интеграции, службы, вспомогательные утилиты и скрипты сборки, которые использует ваш репозиторий. Прежде чем сделать это, обязательно проконсультируйтесь с коллегами. Также убедитесь, что вы выполнили тщательный поиск в своём репозитории и обновили все ссылки на старое имя ветки в вашем коде или скриптах.","type":"unstyled","key":"bvpm0"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Переименуйте локальную ветку master в main с помощью следующей команды:","type":"unstyled","key":"24nl6"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git branch --move master main","type":"unstyled","key":"f65di"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"После этого, локальной ветки master больше не существует, потому что она была переименована в ветку main.","type":"unstyled","key":"95aac"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Чтобы все остальные могли видеть новую ветку main, вам нужно отправить её в общий репозиторий. Это делает переименованную ветку доступной в удалённом репозитории.","type":"unstyled","key":"ejlf5"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git push --set-upstream origin main","type":"unstyled","key":"f5hpn"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"В итоге, состояние репозитория становится следующим:","type":"unstyled","key":"2c5us"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"git branch --all\n* main\n remotes/origin/HEAD -> origin/master\n remotes/origin/main\n remotes/origin/master","type":"unstyled","key":"ecfeo"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Ваша локальная ветка master исчезла, так как она заменена веткой main. Ветка main доступна в удалённом репозитории. Старая ветка master всё ещё присутствует в удалённом репозитории. Остальные участники будут продолжать использовать ветку master в качестве основы для своей работы, пока вы не совершите ряд дополнительных действий.","type":"unstyled","key":"aeten"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Теперь, для завершения перехода на новую ветку перед вами стоят следующие задачи:","type":"unstyled","key":"958he"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Все проекты, которые зависят от текущего, должны будут обновить свой код и/или конфигурацию.","type":"unordered-list-item","key":"b3ua3"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Обновите конфигурацию всех запускаемых тестов.","type":"unordered-list-item","key":"egsin"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Исправьте скрипты сборки и публикации артефактов.","type":"unordered-list-item","key":"e41l1"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Поправьте настройки репозитория на сервере: задайте новую ветку по умолчанию, обновите правила слияния, а также прочие настройки, которые зависят от имени веток.","type":"unordered-list-item","key":"812bd"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Обновите документацию, исправив ссылки, указывающие на старую ветку.","type":"unordered-list-item","key":"6desm"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Слейте или отмените запросы на слияние изменений, нацеленные на старую ветку.","type":"unordered-list-item","key":"dl9s8"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"После того, как вы выполнили все эти задачи и уверены, что ветка main работает так же, как ветка master, вы можете удалить ветку master:","type":"unstyled","key":"952m8"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git push origin --delete master","type":"unstyled","key":"3omvg"},{"data":{},"depth":0,"entityRanges":[{"key":13,"length":1,"offset":39}],"inlineStyleRanges":[],"text":"3.4 Ветвление в Git - Работа с ветками #","type":"header-two","key":"70h7p"},{"data":{},"depth":0,"entityRanges":[{"key":14,"length":1,"offset":17}],"inlineStyleRanges":[],"text":"Работа с ветками #","type":"header-two","key":"f89l3"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Теперь, когда вы познакомились с основами ветвления и слияния, возникает вопрос: что можно или нужно делать с этим? В этом разделе мы разберём некоторые основные рабочие процессы, ставшие возможными благодаря облегчённой процедуре ветвления, которые вы возможно захотите применить в собственном цикле разработки.","type":"unstyled","key":"d9i56"},{"data":{},"depth":0,"entityRanges":[{"key":15,"length":1,"offset":19}],"inlineStyleRanges":[],"text":"Долгоживущие ветки #","type":"header-three","key":"cne8n"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Так как в Git применяется простое трёхстороннее слияние, ничто не мешает многократно объединять ветки в течение длительного времени. Это значит, что у вас может быть несколько постоянно открытых веток, которые вы используете для разных этапов вашего цикла разработки; вы можете регулярно сливать изменения из одной ветки в другую.","type":"unstyled","key":"beqgv"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Многие разработчики, использующие Git, придерживаются именно такого подхода, оставляя полностью стабильный код только в ветке master — возможно, только тот код, который был или будет выпущен. При этом существует и параллельная ветка с именем develop или next, предназначенная для работы и тестирования стабильности; она не обязательно должна быть всегда стабильной, но при достижении стабильного состояния ее содержимое можно слить в ветку master. Она используется для слияния завершённых задач из тематических веток (временных веток наподобие iss53), чтобы гарантировать, что эти задачи проходят тестирование и не вносят ошибок.","type":"unstyled","key":"4f3n6"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"По сути, мы говорим про указатели, перемещающиеся по линии создаваемых вами коммитов. Стабильные ветки находятся в нижнем конце истории коммитов, а самые свежие наработки — ближе к её верхней части","type":"unstyled","key":"1oa7t"},{"data":{"image":{"id":"622cc8c9e8bfec139451a050"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 26","type":"atomic:image","key":"cj1ur"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 26. Линейное представление повышения стабильности веток","type":"unstyled","key":"8j7b0"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"В общем случае это можно представить в виде накопителей, в которых наборы коммитов перемещаются на более стабильный уровень только после полного тестирования.","type":"unstyled","key":"ofkq"},{"data":{"image":{"id":"622cc8caf53aef1fff153662"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 27","type":"atomic:image","key":"cudlq"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 27. Представление диаграммы стабильности веток в виде многоуровневого накопителя","type":"unstyled","key":"41etr"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Число уровней стабильности можно увеличить. В крупных проектах зачастую появляется ветка proposed или pu (предлагаемые обновления), объединяющая ветки с содержимым, которое ещё не готово к включению в ветки next или master. Идея состоит в том, что каждая ветка представляет собой определённый уровень стабильности; как только он повышается, содержимое сливается в ветку уровнем выше. Разумеется, можно вообще обойтись без долгоживущих веток, но зачастую они имеют смысл, особенно при работе над большими и сложными проектами.","type":"unstyled","key":"eh0go"},{"data":{},"depth":0,"entityRanges":[{"key":16,"length":1,"offset":19}],"inlineStyleRanges":[],"text":"Тематические ветки #","type":"header-three","key":"3pl9b"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"А вот такая вещь, как тематические ветки, полезна вне зависимости от величины проекта. Тематической веткой называется временная ветка, создаваемая и используемая для работы над конкретной функциональной возможностью или решения сопутствующих задач. Скорее всего, при работе с другими СКВ вы никогда ничего подобного не делали, так как там создание и слияние веток — затратные операции. Но в Git это обычное дело — много раз в день создавать ветки, работать с ними, сливать их и удалять.","type":"unstyled","key":"clome"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Пример тематических веток вы видели в предыдущем разделе, когда мы создавали ветки iss53 и hotfix. В каждой из них было создано несколько коммитов, после чего, сразу же после слияния с основной веткой, они были удалены. Такая техника позволяет быстро и полностью осуществлять переключения контекста — так как работа разделена по уровням и все изменения в конкретной ветке относятся к определённой теме, что позволяет легко увидеть что именно было сделано во время процедуры просмотра кода или аналогичной. Ветки с внесёнными в них изменениями можно хранить минуты, дни или даже месяцы, а слияние выполнить только когда это действительно потребуется, вне зависимости от порядка их создания.","type":"unstyled","key":"2v0u3"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Предположим, мы работаем в ветке master, ответвляемся для решения попутной проблемы (iss91), некоторое время занимаемся ею, затем создаём ветку, чтобы попробовать решить эту задачу другим способом (iss91v2), возвращаемся в ветку master и выполняем там некие действия, затем создаём новую ветку для изменений, в результате которых не уверены (ветка dumbidea). Результирующая история коммитов будет выглядеть примерно так:","type":"unstyled","key":"deai0"},{"data":{"image":{"id":"622cc8caacc1c97a923a2955"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 28","type":"atomic:image","key":"96hpo"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 28. Набор тематических веток","type":"unstyled","key":"ae25d"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Предположим, вам больше нравится второй вариант решения задачи (iss91v2), а ветку dumbidea вы показали коллегам, и оказалось, что там содержится гениальная идея. Фактически вы можете удалить ветку iss91 (потеряв коммиты C5 и C6) и слить две другие ветки. После этого история будет выглядеть так:","type":"unstyled","key":"8d9pd"},{"data":{"image":{"id":"622cc8cba5b41152f48a6491"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 29","type":"atomic:image","key":"fpebl"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 29. История после слияния веток dumbidea и iss91v2","type":"unstyled","key":"e10hn"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Более подробно возможные варианты рабочих схем для проектов рассматриваются в главе Распределенный Git, поэтому перед выбором схемы обязательно прочитайте эту главу.","type":"unstyled","key":"f546n"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Важно помнить, что во время всех этих манипуляций ветки полностью локальны. Ветвления и слияния выполняются только в вашем Git репозитории — связь с сервером не требуется.","type":"unstyled","key":"e0vod"},{"data":{},"depth":0,"entityRanges":[{"key":17,"length":1,"offset":38}],"inlineStyleRanges":[],"text":"3.5 Ветвление в Git - Удалённые ветки #","type":"header-two","key":"1v7ug"},{"data":{},"depth":0,"entityRanges":[{"key":18,"length":1,"offset":16}],"inlineStyleRanges":[],"text":"Удалённые ветки #","type":"header-two","key":"63k7t"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Удалённые ссылки — это ссылки (указатели) в ваших удалённых репозиториях, включая ветки, теги и так далее. Полный список удалённых ссылок можно получить с помощью команды git ls-remote или команды git remote show для получения удалённых веток и дополнительной информации. Тем не менее, более распространенным способом является использование веток слежения.","type":"unstyled","key":"a4f8n"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Ветки слежения — это ссылки на определённое состояние удалённых веток. Это локальные ветки, которые нельзя перемещать; Git перемещает их автоматически при любой коммуникации с удаленным репозиторием, чтобы гарантировать точное соответствие с ним. Представляйте их как закладки для напоминания о том, где ветки в удалённых репозиториях находились во время последнего подключения к ним.","type":"unstyled","key":"dtb5"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Имена веток слежения имеют вид /. Например, если вы хотите посмотреть, как выглядела ветка master на сервере origin во время последнего соединения с ним, используйте ветку origin/master. Если вы с коллегой работали над одной задачей и он отправил на сервер ветку iss53, при том что у вас может быть своя локальная ветка iss53, удалённая ветка будет представлена веткой слежения с именем origin/iss53.","type":"unstyled","key":"80s7i"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Возможно, всё это сбивает с толку, поэтому давайте рассмотрим на примере. Скажем, у вас в сети есть свой Git-сервер с адресом git.ourcompany.com. Если вы с него что-то клонируете, команда clone автоматически назовёт его origin, заберёт оттуда все данные, создаст указатель на то, на что там указывает ветка master, и назовёт его локально origin/master. Git также создаст вам локальную ветку master, которая будет начинаться там же, где и ветка master в origin, так что вам будет с чего начать.","type":"unstyled","key":"a6s0u"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":10,"offset":0,"style":"ITALIC"}],"text":"Примечание «origin» — это не специальное название\n\nПодобно названию ветки «master», «origin» не имеет какого-либо специального значения в Git. В то время как «master» — это название по умолчанию для ветки при выполнении git init только потому, что часто используется, «origin» — это название по умолчанию для удалённого сервера, когда вы запускаете git clone. Если вы выполните git clone -o booyah, то по умолчанию ветка слежения будет иметь вид booyah/master.","type":"unstyled","key":"2v50c"},{"data":{"image":{"id":"622cc8cb07b5d639e84b409d"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 30","type":"atomic:image","key":"9buh4"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 30. Серверный и локальный репозитории после клонирования","type":"unstyled","key":"9lltu"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Если вы сделаете что-то в своей локальной ветке master, а тем временем кто-то отправит изменения на сервер git.ourcompany.com и обновит там ветку master, то ваши истории продолжатся по-разному. Пока вы не свяжетесь с сервером origin ваш указатель origin/master останется на месте.","type":"unstyled","key":"dp9h1"},{"data":{"image":{"id":"622cc8cbc2b0553e20f01eda"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 31","type":"atomic:image","key":"99avl"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 31. Локальная и удалённая работа может расходиться","type":"unstyled","key":"bhj5j"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Для синхронизации ваших изменений с удаленным сервером выполните команду git fetch (в нашем случае git fetch origin). Эта команда определяет какому серверу соответствует «origin» (в нашем случае это git.ourcompany.com), извлекает оттуда данные, которых у вас ещё нет, и обновляет локальную базу данных, сдвигая указатель origin/master на новую позицию.","type":"unstyled","key":"4qoaq"},{"data":{"image":{"id":"622cc8cc07b5d639e84b42c4"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 32","type":"atomic:image","key":"c9ja8"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 32. git fetch обновляет ветки слежения","type":"unstyled","key":"5irpv"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Чтобы продемонстрировать, как будут выглядеть удалённые ветки в ситуации с несколькими удалёнными серверами, предположим, что у вас есть ещё один внутренний Git-сервер, который используется для разработки только одной из ваших команд разработчиков. Этот сервер находится на git.team1.ourcompany.com. Вы можете добавить его в качестве новой удалённой ссылки для текущего проекта с помощью команды git remote add, как было описано в главе Основы Git. Назовите этот удалённый сервер teamone — это имя будет сокращением вместо полного URL.","type":"unstyled","key":"59udd"},{"data":{"image":{"id":"622cc8cca5b41152f48a66b8"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 33","type":"atomic:image","key":"b5kf7"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 33. Добавление ещё одного сервера в качестве удалённой ветки","type":"unstyled","key":"6m7en"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Теперь вы можете выполнить команду git fetch teamone для получения всех изменений с сервера teamone, которых у вас нет локально. Так как в данный момент на этом сервере есть только те данные, что содержит сервер origin, Git ничего не получит, но создаст ветку слежения с именем teamone/master, которая будет указывать на тот же коммит, что и ветка master на сервере teamone.","type":"unstyled","key":"4mt2t"},{"data":{"image":{"id":"622cc8cc10f1f97bff659820"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 34","type":"atomic:image","key":"6c05o"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 34. Ветка слежения teamone/master","type":"unstyled","key":"fveq5"},{"data":{},"depth":0,"entityRanges":[{"key":19,"length":1,"offset":19}],"inlineStyleRanges":[],"text":"Отправка изменений #","type":"header-three","key":"58cnv"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Когда вы хотите поделиться веткой, вам необходимо отправить её на удалённый сервер, где у вас есть права на запись. Ваши локальные ветки автоматически не синхронизируются с удалёнными при отправке — вам нужно явно указать те ветки, которые вы хотите отправить. Таким образом, вы можете использовать свои личные ветки для работы, которую не хотите показывать, а отправлять только те тематические ветки, над которыми вы хотите работать с кем-то совместно.","type":"unstyled","key":"390hj"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Если у вас есть ветка serverfix, над которой вы хотите работать с кем-то ещё, вы можете отправить её точно так же, как вы отправляли вашу первую ветку. Выполните команду git push :","type":"unstyled","key":"610gk"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git push origin serverfix\nCounting objects: 24, done.\nDelta compression using up to 8 threads.\nCompressing objects: 100% (15/15), done.\nWriting objects: 100% (24/24), 1.91 KiB | 0 bytes/s, done.\nTotal 24 (delta 2), reused 0 (delta 0)\nTo https://github.com/schacon/simplegit\n * [new branch] serverfix -> serverfix","type":"unstyled","key":"5q31i"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Это в некотором роде сокращение. Git автоматически разворачивает имя ветки serverfix до refs/heads/serverfix:refs/heads/serverfix, что означает «возьми мою локальную ветку serverfix и обнови ей удалённую ветку serverfix». Мы подробно рассмотрим часть с refs/heads/ в главе Git изнутри, но обычно её можно пропустить. Вы также можете выполнить git push origin serverfix:serverfix — произойдёт то же самое — здесь говорится «возьми мою ветку serverfix и сделай её удалённой веткой serverfix». Можно использовать этот формат для отправки локальной ветки в удалённую ветку с другим именем. Если вы не хотите, чтобы на удалённом сервере ветка называлась serverfix, то вместо предыдущей команды выполните git push origin serverfix:awesomebranch, которая отправит локальную ветку serverfix в ветку awesomebranch удалённого репозитория.","type":"unstyled","key":"dnnsp"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":10,"offset":0,"style":"ITALIC"}],"text":"Примечание Не вводите каждый раз свой пароль\n\nЕсли вы используете HTTPS URL для отправки изменений, Git-сервер будет спрашивать имя пользователя и пароль для аутентификации. По умолчанию вам будет предложено ввести эти данные в терминале, чтобы сервер мог определить разрешена ли вам отправка изменений.\n\nЕсли вы не хотите вводить свои данные каждый раз при отправке изменений, вы можете настроить «credential cache». Проще всего держать их в памяти несколько минут, это легко настроить с помощью команды git config --global credential.helper cache.\n\nДля получения более подробной информации о различных вариантах кэша учётных данных обратитесь к разделу Хранилище учётных данных.","type":"unstyled","key":"71c15"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"В следующий раз, когда один из ваших соавторов будет получать обновления с сервера, он получит ссылку на то, на что указывает serverfix на сервере, как удалённую ветку origin/serverfix:","type":"unstyled","key":"7c033"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git fetch origin\nremote: Counting objects: 7, done.\nremote: Compressing objects: 100% (2/2), done.\nremote: Total 3 (delta 0), reused 3 (delta 0)\nUnpacking objects: 100% (3/3), done.\nFrom https://github.com/schacon/simplegit\n * [new branch] serverfix -> origin/serverfix","type":"unstyled","key":"6r3aa"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Необходимо отметить, что при получении данных создаются ветки слежения, вы не получаете автоматически для них локальных редактируемых копий. Другими словами, в нашем случае вы не получите новую ветку serverfix — только указатель origin/serverfix, который вы не можете изменять.","type":"unstyled","key":"3t494"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Чтобы слить эти наработки в свою текущую рабочую ветку, выполните git merge origin/serverfix. Если вам нужна локальная ветка serverfix, в которой вы сможете работать, то вы можете создать её на основе ветки слежения:","type":"unstyled","key":"bqmtm"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git checkout -b serverfix origin/serverfix\nBranch serverfix set up to track remote branch serverfix from origin.\nSwitched to a new branch 'serverfix'","type":"unstyled","key":"c6f3m"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Это даст вам локальную ветку, в которой можно работать и которая будет начинаться там же, где и origin/serverfix.","type":"unstyled","key":"9oa6b"},{"data":{},"depth":0,"entityRanges":[{"key":20,"length":1,"offset":19}],"inlineStyleRanges":[],"text":"Отслеживание веток #","type":"header-three","key":"a3fnh"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Получение локальной ветки из удалённой ветки автоматически создаёт то, что называется «веткой слежения» (а ветка, за которой следит локальная называется «upstream branch»). Ветки слежения — это локальные ветки, которые напрямую связаны с удалённой веткой. Если, находясь на ветке слежения, выполнить git pull, то Git уже будет знать с какого сервера получать данные и какую ветку использовать для слияния.","type":"unstyled","key":"8jjar"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"При клонировании репозитория, как правило, автоматически создаётся ветка master, которая следит за origin/master. Однако, при желании вы можете настроить отслеживание и других веток — следить за ветками на других серверах или отключить слежение за веткой master. Вы только что видели простейший пример, что сделать это можно с помощью команды git checkout -b /. Это часто используемая команда, поэтому Git предоставляет сокращённую форму записи в виде флага --track:","type":"unstyled","key":"61l7a"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git checkout --track origin/serverfix\nBranch serverfix set up to track remote branch serverfix from origin.\nSwitched to a new branch 'serverfix'","type":"unstyled","key":"8bo98"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"В действительности, это настолько распространённая команда, что существует сокращение для этого сокращения. Если вы пытаетесь извлечь ветку, которая не существует, но существует только одна удалённая ветка с точно таким же именем, то Git автоматически создаст ветку слежения:","type":"unstyled","key":"ae8ig"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git checkout serverfix\nBranch serverfix set up to track remote branch serverfix from origin.\nSwitched to a new branch 'serverfix'","type":"unstyled","key":"fbprb"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Чтобы создать локальную ветку с именем, отличным от имени удалённой ветки, просто укажите другое имя:","type":"unstyled","key":"cou0"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git checkout -b sf origin/serverfix\nBranch sf set up to track remote branch serverfix from origin.\nSwitched to a new branch 'sf'","type":"unstyled","key":"3ct0b"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Теперь ваша локальная ветка sf будет автоматически получать изменения из origin/serverfix.","type":"unstyled","key":"4gcmg"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Если у вас уже есть локальная ветка и вы хотите настроить ее на слежение за удалённой веткой, которую вы только что получили, или хотите изменить используемую upstream-ветку, то воспользуйтесь параметрами -u или --set-upstream-to для команды git branch, чтобы явно установить новое значение.","type":"unstyled","key":"46jvm"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git branch -u origin/serverfix\nBranch serverfix set up to track remote branch serverfix from origin.","type":"unstyled","key":"8vci5"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":10,"offset":0,"style":"ITALIC"}],"text":"Примечание Сокращение Upstream\n\nЕсли у вас настроена отслеживаемая ветка, вы можете ссылаться на нее с помощью сокращений @{upstream} или @{u}. Итак, если вы находитесь на ветке master и она следит за origin/master, при желании вы можете использовать git merge @{u} вместо git merge origin/master.","type":"unstyled","key":"d9nb2"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Если вы хотите посмотреть как у вас настроены ветки слежения, воспользуйтесь опцией -vv для команды git branch. Это выведет список локальных веток и дополнительную информацию о том, какая из веток отслеживается, отстаёт, опережает или всё сразу относительно отслеживаемой.","type":"unstyled","key":"d3jkp"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git branch -vv\n iss53 7e424c3 [origin/iss53: ahead 2] Add forgotten brackets\n master 1ae2a45 [origin/master] Deploy index fix\n* serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] This should do it\n testing 5ea463a Try something new","type":"unstyled","key":"13lt8"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Итак, здесь мы видим, что наша ветка iss53 следит за origin/iss53 и «опережает» её на два изменения — это значит, что у нас есть два локальных коммита, которые не отправлены на сервер. Мы также видим, что наша ветка master отслеживает ветку origin/master и находится в актуальном состоянии. Далее мы можем видеть, что локальная ветка serverfix следит за веткой server-fix-good на сервере teamone, опережает её на три коммита и отстает на один — это значит, что на сервере есть один коммит, который мы ещё не слили, и три локальных коммита, которые ещё не отправлены на сервер. В конце мы видим, что наша ветка testing не отслеживает удаленную ветку.","type":"unstyled","key":"5bgdb"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Важно отметить, что эти цифры описывают состояние на момент последнего получения данных с каждого из серверов. Эта команда не обращается к серверам, а лишь говорит вам о том, какая информация с этих серверов сохранена в локальном кэше. Если вы хотите иметь актуальную информацию об этих числах, вам необходимо получить данные со всех ваших удалённых серверов перед запуском команды. Сделать это можно вот так:","type":"unstyled","key":"29pno"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git fetch --all; git branch -vv","type":"unstyled","key":"bvk6b"},{"data":{},"depth":0,"entityRanges":[{"key":21,"length":1,"offset":20}],"inlineStyleRanges":[],"text":"Получение изменений #","type":"header-three","key":"dcub4"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Команда git fetch получает с сервера все изменения, которых у вас ещё нет, но не будет изменять состояние вашей рабочей копии. Эта команда просто получает данные и позволяет вам самостоятельно сделать слияние. Тем не менее, существует команда git pull, которая в большинстве случаев является командой git fetch, за которой непосредственно следует команда git merge. Если у вас настроена ветка слежения как показано в предыдущем разделе, или она явно установлена, или она была создана автоматически командами clone или checkout, git pull определит сервер и ветку, за которыми следит ваша текущая ветка, получит данные с этого сервера и затем попытается слить удалённую ветку.","type":"unstyled","key":"5hvlk"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Обычно, лучше явно использовать команды fetch и merge, поскольку магия git pull может часто сбивать с толку.","type":"unstyled","key":"5r9mv"},{"data":{},"depth":0,"entityRanges":[{"key":22,"length":1,"offset":36}],"inlineStyleRanges":[],"text":"Удаление веток на удалённом сервере #","type":"header-three","key":"72maa"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Скажем, вы и ваши соавторы закончили с нововведением и слили его в ветку master на удалённом сервере (или в какую-то другую ветку, где хранится стабильный код). Вы можете удалить ветку на удалённом сервере используя параметр --delete для команды git push. Для удаления ветки serverfix на сервере, выполните следующую команду:","type":"unstyled","key":"60r6a"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git push origin --delete serverfix\nTo https://github.com/schacon/simplegit\n - [deleted] serverfix","type":"unstyled","key":"av267"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Всё, что делает эта строка — удаляет указатель на сервере. Как правило, Git сервер хранит данные пока не запустится сборщик мусора, поэтому если ветка была удалена случайно, чаще всего её легко восстановить.","type":"unstyled","key":"lajr"},{"data":{},"depth":0,"entityRanges":[{"key":23,"length":1,"offset":38}],"inlineStyleRanges":[],"text":"3.6 Ветвление в Git - Перебазирование #","type":"header-two","key":"b8ft6"},{"data":{},"depth":0,"entityRanges":[{"key":24,"length":1,"offset":16}],"inlineStyleRanges":[],"text":"Перебазирование #","type":"header-two","key":"at3ms"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"В Git есть два способа внести изменения из одной ветки в другую: слияние и перебазирование. В этом разделе вы узнаете, что такое перебазирование, как его осуществлять и в каких случаях этот удивительный инструмент использовать не следует.","type":"unstyled","key":"1c4v6"},{"data":{},"depth":0,"entityRanges":[{"key":25,"length":1,"offset":27}],"inlineStyleRanges":[],"text":"Простейшее перебазирование #","type":"header-three","key":"6m9o9"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Если вы вернётесь к более раннему примеру из Основы слияния, вы увидите, что разделили свою работу и сделали коммиты в две разные ветки.","type":"unstyled","key":"f9bo1"},{"data":{"image":{"id":"622cc8cde881b82d801116ce"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 35","type":"atomic:image","key":"7qdib"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 35. История коммитов простого разделения","type":"unstyled","key":"dboqq"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Как мы выяснили ранее, простейший способ выполнить слияние двух веток — это команда merge. Она осуществляет трёхстороннее слияние между двумя последними снимками сливаемых веток (C3 и C4) и самого недавнего общего для этих веток родительского снимка (C2), создавая новый снимок (и коммит).","type":"unstyled","key":"c537u"},{"data":{"image":{"id":"622cc8cd8b35bd231d257820"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 36","type":"atomic:image","key":"co5d5"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 36. Слияние разделённой истории коммитов","type":"unstyled","key":"364uu"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":16,"offset":140,"style":"ITALIC"}],"text":"Тем не менее есть и другой способ: вы можете взять те изменения, что были представлены в C4, и применить их поверх C3. В Git это называется перебазированием. С помощью команды rebase вы можете взять все коммиты из одной ветки и в том же порядке применить их к другой ветке.","type":"unstyled","key":"61gr7"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"В данном примере переключимся на ветку experiment и перебазируем её относительно ветки master следующим образом:","type":"unstyled","key":"6m6dg"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git checkout experiment\n$ git rebase master\nFirst, rewinding head to replay your work on top of it...\nApplying: added staged command","type":"unstyled","key":"bl0m9"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Это работает следующим образом: берётся общий родительский снимок двух веток (текущей, и той, поверх которой вы выполняете перебазирование), определяется дельта каждого коммита текущей ветки и сохраняется во временный файл, текущая ветка устанавливается на последний коммит ветки, поверх которой вы выполняете перебазирование, а затем по очереди применяются дельты из временных файлов.","type":"unstyled","key":"33iuf"},{"data":{"image":{"id":"622cc8cdacc1c97a923a2eb0"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 37","type":"atomic:image","key":"5vatt"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 37. Перебазирование изменений из C4 поверх C3","type":"unstyled","key":"8vva1"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"После этого вы можете переключиться обратно на ветку master и выполнить слияние перемоткой.","type":"unstyled","key":"a6miu"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git checkout master\n$ git merge experiment","type":"unstyled","key":"aea2r"},{"data":{"image":{"id":"622cc8cea5b41152f48a6b01"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 38","type":"atomic:image","key":"1l83c"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 38. Перемотка ветки master","type":"unstyled","key":"73bhc"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Теперь снимок, на который указывает C4' абсолютно такой же, как тот, на который указывал C5 в примере с трёхсторонним слиянием. Нет абсолютно никакой разницы в конечном результате между двумя показанными примерами, но перебазирование делает историю коммитов чище. Если вы взглянете на историю перебазированной ветки, то увидите, что она выглядит абсолютно линейной: будто все операции были выполнены последовательно, даже если изначально они совершались параллельно.","type":"unstyled","key":"evi09"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Часто вы будете делать так для уверенности, что ваши коммиты могут быть бесконфликтно слиты в удалённую ветку — возможно, в проекте, куда вы пытаетесь внести вклад, но владельцем которого вы не являетесь. В этом случае вам следует работать в своей ветке и затем перебазировать вашу работу поверх origin/master, когда вы будете готовы отправить свои изменения в основной проект. Тогда владельцу проекта не придётся делать никакой лишней работы — всё решится простой перемоткой или бесконфликтным слиянием.","type":"unstyled","key":"3els3"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Учтите, что снимок, на который ссылается ваш последний коммит — является ли он последним коммитом после перебазирования или коммитом слияния после слияния — в обоих случаях это один и тот же снимок, отличаются только истории коммитов. Перебазирование повторяет изменения из одной ветки поверх другой в том порядке, в котором эти изменения были сделаны, в то время как слияние берет две конечные точки и сливает их вместе.","type":"unstyled","key":"9vf6e"},{"data":{},"depth":0,"entityRanges":[{"key":26,"length":1,"offset":29}],"inlineStyleRanges":[],"text":"Более интересные перемещения #","type":"header-three","key":"85br2"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Также возможно сделать так, чтобы при перебазировании воспроизведение коммитов применялось к совершенно другой ветке. Для примера возьмём История разработки с тематической веткой, ответвлённой от другой тематической ветки. Вы создаёте тематическую ветку server, чтобы добавить в проект некоторую функциональность для серверной части, и делаете коммит. Затем вы выполнили ответвление, чтобы сделать изменения для клиентской части, и создали несколько коммитов. Наконец, вы вернулись на ветку server и сделали ещё несколько коммитов.","type":"unstyled","key":"8u6a1"},{"data":{"image":{"id":"622cc8ceae29be6a2be024d0"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 39","type":"atomic:image","key":"98k5n"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 39. История разработки с тематической веткой, ответвлённой от другой тематической ветки","type":"unstyled","key":"96ntp"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Предположим, вы решили, что хотите внести изменения клиентской части в основную линию разработки для релиза, но при этом не хотите добавлять изменения серверной части до полного тестирования. Вы можете взять изменения из ветки client, которых нет в server (C8 и C9), и применить их на ветке master при помощи опции --onto команды git rebase:","type":"unstyled","key":"5t26a"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git rebase --onto master server client","type":"unstyled","key":"f5gcu"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"В этой команде говорится: «Переключись на ветку client, найди изменения относительно ветки server и примени их для ветки master». Несмотря на некоторую сложность этого способа, результат впечатляет.","type":"unstyled","key":"8k728"},{"data":{"image":{"id":"622cc8cf9916f3091a9ace3f"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 40","type":"atomic:image","key":"c35tt"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 40. Перемещение тематической ветки, ответвлённой от другой тематической ветки","type":"unstyled","key":"4boa8"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Теперь вы можете выполнить перемотку (fast-forward) для ветки master (см Перемотка ветки master для добавления изменений из ветки client):","type":"unstyled","key":"cch60"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git checkout master\n$ git merge client","type":"unstyled","key":"caev0"},{"data":{"image":{"id":"622cc8cfb8370032ffad476d"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 41","type":"atomic:image","key":"27g12"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 41. Перемотка ветки master для добавления изменений из ветки client","type":"unstyled","key":"2m2bh"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Представим, что вы решили добавить наработки и из ветки server. Вы можете выполнить перебазирование ветки server относительно ветки master без предварительного переключения на неё при помощи команды git rebase , которая извлечёт тематическую ветку (в данном случае server) и применит изменения в ней к базовой ветке (master):","type":"unstyled","key":"61p8m"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git rebase master server","type":"unstyled","key":"eific"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Это повторит работу, сделанную в ветке server поверх ветки master, как показано на рисунке:","type":"unstyled","key":"314ef"},{"data":{"image":{"id":"622cc8cf8b35bd231d257c9f"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 42","type":"atomic:image","key":"2fnup"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 42. Перебазирование ветки server на вершину ветки master","type":"unstyled","key":"csso9"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"После чего вы сможете выполнить перемотку основной ветки (master):","type":"unstyled","key":"1d5od"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git checkout master\n$ git merge server","type":"unstyled","key":"8lcrq"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Теперь вы можете удалить ветки client и server, поскольку весь ваш прогресс уже интегрирован и тематические ветки больше не нужны, а полную историю вашего рабочего процесса отражает рисунок Окончательная история коммитов:","type":"unstyled","key":"2msbn"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"$ git branch -d client\n$ git branch -d server","type":"unstyled","key":"39pf7"},{"data":{"image":{"id":"622cc8d08b35bd231d257ec7"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 43","type":"atomic:image","key":"dibln"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 43. Окончательная история коммитов","type":"unstyled","key":"33d7v"},{"data":{},"depth":0,"entityRanges":[{"key":27,"length":1,"offset":22}],"inlineStyleRanges":[],"text":"Опасности перемещения #","type":"header-three","key":"5e26f"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Но даже перебазирование, при всех своих достоинствах, не лишено недостатков, которые можно выразить одной строчкой:","type":"unstyled","key":"bf5gj"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":64,"offset":0,"style":"BOLD"}],"text":"Не перемещайте коммиты, уже отправленные в публичный репозиторий","type":"unstyled","key":"evk92"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Если вы будете придерживаться этого правила, всё будет хорошо. Если не будете, люди возненавидят вас, а ваши друзья и семья будут вас презирать.","type":"unstyled","key":"7kike"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":7,"offset":81,"style":"BOLD"}],"text":"Когда вы что-то перемещаете, вы отменяете существующие коммиты и создаёте новые, похожие на старые, но являющиеся другими. Если вы куда-нибудь отправляете свои коммиты и другие люди забирают их себе и в дальнейшем основывают на них свою работу, а затем вы переделываете эти коммиты командой git rebase и выкладываете их снова, то ваши коллеги будут вынуждены заново выполнять слияние для своих наработок. В итоге, когда вы в очередной раз попытаетесь включить их работу в свою, вы получите путаницу.","type":"unstyled","key":"aiq68"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Давайте рассмотрим пример того, как перемещение публично доступных наработок может вызвать проблемы. Предположим, вы клонировали репозиторий с сервера и сделали какую-то работу. И ваша история коммитов выглядит так:","type":"unstyled","key":"cj8fa"},{"data":{"image":{"id":"622cc8d07319027bedfb7082"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 44","type":"atomic:image","key":"2ulq2"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 44. Клонирование репозитория и выполнение в нём какой-то работы","type":"unstyled","key":"eioug"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Теперь кто-то другой внёс свои изменения, слил их и отправил на сервер. Вы стягиваете их к себе, включая новую удалённую ветку, что изменяет вашу историю следующим образом:","type":"unstyled","key":"b2hfo"},{"data":{"image":{"id":"622cc8d05e4d0a774ee4e393"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 45","type":"atomic:image","key":"2em6a"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 45. Извлекаем ещё коммиты и сливаем их со своей работой","type":"unstyled","key":"e7dv2"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Затем автор коммита слияния решает вернуться назад и перебазировать свою ветку; выполнив git push --force, он перезаписывает историю на сервере. При получении изменений с сервера вы получите и новые коммиты.","type":"unstyled","key":"7q1ll"},{"data":{"image":{"id":"622cc8d1ae29be6a2be0283f"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 46","type":"atomic:image","key":"2bg8t"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 46. Кто-то выложил перебазированные коммиты, отменяя коммиты, на которых основывалась ваша работа","type":"unstyled","key":"g5c6"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Теперь вы оба в неловком положении. Если вы выполните git pull, вы создадите коммит слияния, включающий обе линии истории, и ваш репозиторий будет выглядеть следующим образом:","type":"unstyled","key":"8mt3l"},{"data":{"image":{"id":"622cc8d18085b7034ffce481"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 47","type":"atomic:image","key":"6ljip"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 47. Вы снова выполняете слияние для той же самой работы в новый коммит слияния","type":"unstyled","key":"8vgei"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Если вы посмотрите git log в этот момент, вы увидите два коммита с одинаковыми авторами, датой и сообщением, что может сбить с толку. Помимо этого, если вы отправите свою историю на удалённый сервер в таком состоянии, вы вернёте все эти перебазированные коммиты на сервер, что ещё больше всех запутает. Логично предположить, что разработчик не хочет, чтобы C4 и C6 были в истории, и именно поэтому она перебазируется в первую очередь.","type":"unstyled","key":"frukc"},{"data":{},"depth":0,"entityRanges":[{"key":28,"length":1,"offset":28}],"inlineStyleRanges":[],"text":"Меняя базу, меняй основание #","type":"header-three","key":"26hnu"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":3,"offset":297,"style":"BOLD"}],"text":"Если вы попали в такую ситуацию, у Git есть особая магия чтобы вам помочь. Если кто-то в вашей команде форсирует отправку изменений на сервер, переписывающих работу, на которых базировалась ваша работа, то ваша задача будет состоять в определении того, что именно было ваше, а что было переписано ими.","type":"unstyled","key":"185mv"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Оказывается, что помимо контрольной суммы коммита SHA-1, Git также вычисляет контрольную сумму отдельно для патча, входящего в этот коммит. Это контрольная сумма называется «patch-id».","type":"unstyled","key":"4mjss"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Если вы скачаете перезаписанную историю и перебазируете её поверх новых коммитов вашего коллеги, в большинстве случаев Git успешно определит, какие именно изменения были внесены вами, и применит их поверх новой ветки.","type":"unstyled","key":"83f6f"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"К примеру, если в предыдущем сценарии вместо слияния в Кто-то выложил перебазированные коммиты, отменяя коммиты, на которых основывалась ваша работа мы выполним git rebase teamone/master, Git будет:","type":"unstyled","key":"3i3vd"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Определять, какая работа уникальна для вашей ветки (C2, C3, C4, C6, C7)","type":"unordered-list-item","key":"96t5o"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Определять, какие коммиты не были коммитами слияния (C2, C3, C4)","type":"unordered-list-item","key":"8s8j0"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Определять, что не было перезаписано в основной ветке (только C2 и C3, поскольку C4 — это тот же патч, что и C4')","type":"unordered-list-item","key":"f83ap"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Применять эти коммиты к ветке teamone/master","type":"unordered-list-item","key":"7r91c"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Таким образом, вместо результата, который мы можем наблюдать на Вы снова выполняете слияние для той же самой работы в новый коммит слияния, у нас получилось бы что-то вроде Перемещение в начало force-pushed перемещённой работы.","type":"unstyled","key":"fa52m"},{"data":{"image":{"id":"622cc8d29916f3091a9ad21e"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 48","type":"atomic:image","key":"60e6v"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Рисунок 48. Перемещение в начало force-pushed перемещённой работы","type":"unstyled","key":"2q91n"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Это возможно, если C4 и C4' фактически являются одним и тем же патчем, который был сделан вашим коллегой. В противном случае rebase не сможет определить дубликат и создаст ещё один патч, подобный C4 (который с большой вероятностью не удастся применить чисто, поскольку в нём уже присутствуют некоторые изменения).","type":"unstyled","key":"6flak"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Вы можете это упростить, применив git pull --rebase вместо обычного git pull. Или сделать это вручную с помощью git fetch, а затем git rebase teamone/master.","type":"unstyled","key":"e90qj"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Если вы используете git pull и хотите использовать --rebase по умолчанию, вы можете установить соответствующее значение конфигурации pull.rebase с помощью команды git config --global pull.rebase true.","type":"unstyled","key":"22t25"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Если вы рассматриваете перебазирование как способ наведения порядка и работаете с коммитами локально до их отправки или ваши коммиты никогда не будут доступны публично — у вас всё будет хорошо. Однако, если вы перемещаете коммиты, отправленные в публичный репозиторий, и есть вероятность, что работа некоторых людей основывается на этих коммитах, то ваши действия могут вызвать существенные проблемы, а вы — вызвать презрение вашей команды.","type":"unstyled","key":"euucg"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Если в какой-то момент вы или ваш коллега находите необходимость в этом, убедитесь, что все знают, как применять команду git pull --rebase для минимизации последствий от подобных действий.","type":"unstyled","key":"ec4dc"},{"data":{},"depth":0,"entityRanges":[{"key":29,"length":1,"offset":24}],"inlineStyleRanges":[],"text":"Перемещение vs. Слияние #","type":"header-three","key":"ft40l"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Теперь, когда вы увидели перемещение и слияние в действии, вы можете задаться вопросом, что из них лучше. Прежде чем ответить на этот вопрос, давайте вернёмся немного назад и поговорим о том, что означает история.","type":"unstyled","key":"3qo1k"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":40,"offset":87,"style":"BOLD"},{"length":5,"offset":278,"style":"ITALIC"}],"text":"Одна из точек зрения заключается в том, что история коммитов в вашем репозитории — это запись того, что на самом деле произошло. Это исторический документ, ценный сам по себе, и его нельзя подделывать. С этой точки зрения изменение истории коммитов практически кощунственно; вы лжёте о том, что на самом деле произошло. Но что, если произошла путаница в коммитах слияния? Если это случается, репозиторий должен сохранить это для потомков.","type":"unstyled","key":"b36ju"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":39,"offset":75,"style":"BOLD"}],"text":"Противоположная точка зрения заключается в том, что история коммитов — это история того, как был сделан ваш проект. Вы не публикуете первый черновик книги или инструкции по поддержке вашего программного обеспечения, так как это нуждается в тщательном редактировании. Сторонники этого лагеря считают использование инструментов rebase и filter-branch способом рассказать историю проекта наилучшим образом для будущих читателей.","type":"unstyled","key":"4q2g3"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Теперь к вопросу о том, что лучше — слияние или перебазирование: надеюсь, вы видите, что это не так просто. Git — мощный инструмент, позволяющий вам делать многое с вашей историей, однако каждая команда и каждый проект индивидуален. Теперь, когда вы знаете, как работают оба эти приёма, выбор — какой из них будет лучше в вашей ситуации — зависит от вас.","type":"unstyled","key":"32vjt"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"При этом, вы можете взять лучшее от обоих миров: использовать перебазирование для наведения порядка в истории ваших локальных изменений, но никогда не применять его для уже отправленных куда-нибудь изменений.","type":"unstyled","key":"9f6rl"},{"data":{},"depth":0,"entityRanges":[{"key":30,"length":1,"offset":33}],"inlineStyleRanges":[],"text":"3.7 Ветвление в Git - Заключение #","type":"header-two","key":"b07vo"},{"data":{},"depth":0,"entityRanges":[{"key":31,"length":1,"offset":11}],"inlineStyleRanges":[],"text":"Заключение #","type":"header-two","key":"490fi"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Мы рассмотрели базовые функции ветвления и слияния в Git. Вы должны быть способны свободно создавать и переключаться на новую ветку, переключаться между ветками и сливать локальные ветки вместе. Также вы должны уметь выкладывать ветки на общий сервер, работать с другими людьми над общими ветками и перебазировать ваши ветки до того, как они станут доступны другим разработчикам. Далее мы поговорим о том, что вам необходимо для запуска собственного сервера с хостингом для Git-репозитория.","type":"unstyled","key":"cp47c"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"marker","key":"4vr3rZAKzJ65bwx50V6e"}],"entityMap":{"22":{"data":{"href":"https://7xz.ru/docs/book/progit/#%d1%83%d0%b4%d0%b0%d0%bb%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b2%d0%b5%d1%82%d0%be%d0%ba-%d0%bd%d0%b0-%d1%83%d0%b4%d0%b0%d0%bb%d1%91%d0%bd%d0%bd%d0%be%d0%bc-%d1%81%d0%b5%d1%80%d0%b2%d0%b5%d1%80%d0%b5","url":"https://7xz.ru/docs/book/progit/#%d1%83%d0%b4%d0%b0%d0%bb%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b2%d0%b5%d1%82%d0%be%d0%ba-%d0%bd%d0%b0-%d1%83%d0%b4%d0%b0%d0%bb%d1%91%d0%bd%d0%bd%d0%be%d0%bc-%d1%81%d0%b5%d1%80%d0%b2%d0%b5%d1%80%d0%b5"},"mutability":"MUTABLE","type":"LINK"},"23":{"data":{"href":"https://7xz.ru/docs/book/progit/#36-%d0%b2%d0%b5%d1%82%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b2-git---%d0%bf%d0%b5%d1%80%d0%b5%d0%b1%d0%b0%d0%b7%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5","url":"https://7xz.ru/docs/book/progit/#36-%d0%b2%d0%b5%d1%82%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b2-git---%d0%bf%d0%b5%d1%80%d0%b5%d0%b1%d0%b0%d0%b7%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5"},"mutability":"MUTABLE","type":"LINK"},"24":{"data":{"href":"https://7xz.ru/docs/book/progit/#%d0%bf%d0%b5%d1%80%d0%b5%d0%b1%d0%b0%d0%b7%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5","url":"https://7xz.ru/docs/book/progit/#%d0%bf%d0%b5%d1%80%d0%b5%d0%b1%d0%b0%d0%b7%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5"},"mutability":"MUTABLE","type":"LINK"},"25":{"data":{"href":"https://7xz.ru/docs/book/progit/#%d0%bf%d1%80%d0%be%d1%81%d1%82%d0%b5%d0%b9%d1%88%d0%b5%d0%b5-%d0%bf%d0%b5%d1%80%d0%b5%d0%b1%d0%b0%d0%b7%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5","url":"https://7xz.ru/docs/book/progit/#%d0%bf%d1%80%d0%be%d1%81%d1%82%d0%b5%d0%b9%d1%88%d0%b5%d0%b5-%d0%bf%d0%b5%d1%80%d0%b5%d0%b1%d0%b0%d0%b7%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5"},"mutability":"MUTABLE","type":"LINK"},"26":{"data":{"href":"https://7xz.ru/docs/book/progit/#%d0%b1%d0%be%d0%bb%d0%b5%d0%b5-%d0%b8%d0%bd%d1%82%d0%b5%d1%80%d0%b5%d1%81%d0%bd%d1%8b%d0%b5-%d0%bf%d0%b5%d1%80%d0%b5%d0%bc%d0%b5%d1%89%d0%b5%d0%bd%d0%b8%d1%8f","url":"https://7xz.ru/docs/book/progit/#%d0%b1%d0%be%d0%bb%d0%b5%d0%b5-%d0%b8%d0%bd%d1%82%d0%b5%d1%80%d0%b5%d1%81%d0%bd%d1%8b%d0%b5-%d0%bf%d0%b5%d1%80%d0%b5%d0%bc%d0%b5%d1%89%d0%b5%d0%bd%d0%b8%d1%8f"},"mutability":"MUTABLE","type":"LINK"},"27":{"data":{"href":"https://7xz.ru/docs/book/progit/#%d0%be%d0%bf%d0%b0%d1%81%d0%bd%d0%be%d1%81%d1%82%d0%b8-%d0%bf%d0%b5%d1%80%d0%b5%d0%bc%d0%b5%d1%89%d0%b5%d0%bd%d0%b8%d1%8f","url":"https://7xz.ru/docs/book/progit/#%d0%be%d0%bf%d0%b0%d1%81%d0%bd%d0%be%d1%81%d1%82%d0%b8-%d0%bf%d0%b5%d1%80%d0%b5%d0%bc%d0%b5%d1%89%d0%b5%d0%bd%d0%b8%d1%8f"},"mutability":"MUTABLE","type":"LINK"},"28":{"data":{"href":"https://7xz.ru/docs/book/progit/#%d0%bc%d0%b5%d0%bd%d1%8f%d1%8f-%d0%b1%d0%b0%d0%b7%d1%83-%d0%bc%d0%b5%d0%bd%d1%8f%d0%b9-%d0%be%d1%81%d0%bd%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5","url":"https://7xz.ru/docs/book/progit/#%d0%bc%d0%b5%d0%bd%d1%8f%d1%8f-%d0%b1%d0%b0%d0%b7%d1%83-%d0%bc%d0%b5%d0%bd%d1%8f%d0%b9-%d0%be%d1%81%d0%bd%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5"},"mutability":"MUTABLE","type":"LINK"},"29":{"data":{"href":"https://7xz.ru/docs/book/progit/#%d0%bf%d0%b5%d1%80%d0%b5%d0%bc%d0%b5%d1%89%d0%b5%d0%bd%d0%b8%d0%b5-vs-%d1%81%d0%bb%d0%b8%d1%8f%d0%bd%d0%b8%d0%b5","url":"https://7xz.ru/docs/book/progit/#%d0%bf%d0%b5%d1%80%d0%b5%d0%bc%d0%b5%d1%89%d0%b5%d0%bd%d0%b8%d0%b5-vs-%d1%81%d0%bb%d0%b8%d1%8f%d0%bd%d0%b8%d0%b5"},"mutability":"MUTABLE","type":"LINK"},"30":{"data":{"href":"https://7xz.ru/docs/book/progit/#37-%d0%b2%d0%b5%d1%82%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b2-git---%d0%b7%d0%b0%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%bd%d0%b8%d0%b5","url":"https://7xz.ru/docs/book/progit/#37-%d0%b2%d0%b5%d1%82%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b2-git---%d0%b7%d0%b0%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%bd%d0%b8%d0%b5"},"mutability":"MUTABLE","type":"LINK"},"31":{"data":{"href":"https://7xz.ru/docs/book/progit/#%d0%b7%d0%b0%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%bd%d0%b8%d0%b5-2","url":"https://7xz.ru/docs/book/progit/#%d0%b7%d0%b0%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%bd%d0%b8%d0%b5-2"},"mutability":"MUTABLE","type":"LINK"},"10":{"data":{"href":"https://7xz.ru/docs/book/progit/#%d1%83%d0%bf%d1%80%d0%b0%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b2%d0%b5%d1%82%d0%ba%d0%b0%d0%bc%d0%b8","url":"https://7xz.ru/docs/book/progit/#%d1%83%d0%bf%d1%80%d0%b0%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b2%d0%b5%d1%82%d0%ba%d0%b0%d0%bc%d0%b8"},"mutability":"MUTABLE","type":"LINK"},"11":{"data":{"href":"https://7xz.ru/docs/book/progit/#%d0%bf%d0%b5%d1%80%d0%b5%d0%b8%d0%bc%d0%b5%d0%bd%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5-%d0%b2%d0%b5%d1%82%d0%ba%d0%b8","url":"https://7xz.ru/docs/book/progit/#%d0%bf%d0%b5%d1%80%d0%b5%d0%b8%d0%bc%d0%b5%d0%bd%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5-%d0%b2%d0%b5%d1%82%d0%ba%d0%b8"},"mutability":"MUTABLE","type":"LINK"},"12":{"data":{"href":"https://7xz.ru/docs/book/progit/#%d0%b8%d0%b7%d0%bc%d0%b5%d0%bd%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b8%d0%bc%d0%b5%d0%bd%d0%b8-%d0%b3%d0%bb%d0%b0%d0%b2%d0%bd%d0%be%d0%b9-%d0%b2%d0%b5%d1%82%d0%ba%d0%b8","url":"https://7xz.ru/docs/book/progit/#%d0%b8%d0%b7%d0%bc%d0%b5%d0%bd%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b8%d0%bc%d0%b5%d0%bd%d0%b8-%d0%b3%d0%bb%d0%b0%d0%b2%d0%bd%d0%be%d0%b9-%d0%b2%d0%b5%d1%82%d0%ba%d0%b8"},"mutability":"MUTABLE","type":"LINK"},"13":{"data":{"href":"https://7xz.ru/docs/book/progit/#34-%d0%b2%d0%b5%d1%82%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b2-git---%d1%80%d0%b0%d0%b1%d0%be%d1%82%d0%b0-%d1%81-%d0%b2%d0%b5%d1%82%d0%ba%d0%b0%d0%bc%d0%b8","url":"https://7xz.ru/docs/book/progit/#34-%d0%b2%d0%b5%d1%82%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b2-git---%d1%80%d0%b0%d0%b1%d0%be%d1%82%d0%b0-%d1%81-%d0%b2%d0%b5%d1%82%d0%ba%d0%b0%d0%bc%d0%b8"},"mutability":"MUTABLE","type":"LINK"},"14":{"data":{"href":"https://7xz.ru/docs/book/progit/#%d1%80%d0%b0%d0%b1%d0%be%d1%82%d0%b0-%d1%81-%d0%b2%d0%b5%d1%82%d0%ba%d0%b0%d0%bc%d0%b8","url":"https://7xz.ru/docs/book/progit/#%d1%80%d0%b0%d0%b1%d0%be%d1%82%d0%b0-%d1%81-%d0%b2%d0%b5%d1%82%d0%ba%d0%b0%d0%bc%d0%b8"},"mutability":"MUTABLE","type":"LINK"},"15":{"data":{"href":"https://7xz.ru/docs/book/progit/#%d0%b4%d0%be%d0%bb%d0%b3%d0%be%d0%b6%d0%b8%d0%b2%d1%83%d1%89%d0%b8%d0%b5-%d0%b2%d0%b5%d1%82%d0%ba%d0%b8","url":"https://7xz.ru/docs/book/progit/#%d0%b4%d0%be%d0%bb%d0%b3%d0%be%d0%b6%d0%b8%d0%b2%d1%83%d1%89%d0%b8%d0%b5-%d0%b2%d0%b5%d1%82%d0%ba%d0%b8"},"mutability":"MUTABLE","type":"LINK"},"16":{"data":{"href":"https://7xz.ru/docs/book/progit/#%d1%82%d0%b5%d0%bc%d0%b0%d1%82%d0%b8%d1%87%d0%b5%d1%81%d0%ba%d0%b8%d0%b5-%d0%b2%d0%b5%d1%82%d0%ba%d0%b8","url":"https://7xz.ru/docs/book/progit/#%d1%82%d0%b5%d0%bc%d0%b0%d1%82%d0%b8%d1%87%d0%b5%d1%81%d0%ba%d0%b8%d0%b5-%d0%b2%d0%b5%d1%82%d0%ba%d0%b8"},"mutability":"MUTABLE","type":"LINK"},"17":{"data":{"href":"https://7xz.ru/docs/book/progit/#35-%d0%b2%d0%b5%d1%82%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b2-git---%d1%83%d0%b4%d0%b0%d0%bb%d1%91%d0%bd%d0%bd%d1%8b%d0%b5-%d0%b2%d0%b5%d1%82%d0%ba%d0%b8","url":"https://7xz.ru/docs/book/progit/#35-%d0%b2%d0%b5%d1%82%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b2-git---%d1%83%d0%b4%d0%b0%d0%bb%d1%91%d0%bd%d0%bd%d1%8b%d0%b5-%d0%b2%d0%b5%d1%82%d0%ba%d0%b8"},"mutability":"MUTABLE","type":"LINK"},"18":{"data":{"href":"https://7xz.ru/docs/book/progit/#%d1%83%d0%b4%d0%b0%d0%bb%d1%91%d0%bd%d0%bd%d1%8b%d0%b5-%d0%b2%d0%b5%d1%82%d0%ba%d0%b8","url":"https://7xz.ru/docs/book/progit/#%d1%83%d0%b4%d0%b0%d0%bb%d1%91%d0%bd%d0%bd%d1%8b%d0%b5-%d0%b2%d0%b5%d1%82%d0%ba%d0%b8"},"mutability":"MUTABLE","type":"LINK"},"19":{"data":{"href":"https://7xz.ru/docs/book/progit/#%d0%be%d1%82%d0%bf%d1%80%d0%b0%d0%b2%d0%ba%d0%b0-%d0%b8%d0%b7%d0%bc%d0%b5%d0%bd%d0%b5%d0%bd%d0%b8%d0%b9","url":"https://7xz.ru/docs/book/progit/#%d0%be%d1%82%d0%bf%d1%80%d0%b0%d0%b2%d0%ba%d0%b0-%d0%b8%d0%b7%d0%bc%d0%b5%d0%bd%d0%b5%d0%bd%d0%b8%d0%b9"},"mutability":"MUTABLE","type":"LINK"},"0":{"data":{"href":"https://7xz.ru/docs/book/progit/#31-%d0%b2%d0%b5%d1%82%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b2-git---%d0%be-%d0%b2%d0%b5%d1%82%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d0%b8-%d0%b2-%d0%b4%d0%b2%d1%83%d1%85-%d1%81%d0%bb%d0%be%d0%b2%d0%b0%d1%85","url":"https://7xz.ru/docs/book/progit/#31-%d0%b2%d0%b5%d1%82%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b2-git---%d0%be-%d0%b2%d0%b5%d1%82%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d0%b8-%d0%b2-%d0%b4%d0%b2%d1%83%d1%85-%d1%81%d0%bb%d0%be%d0%b2%d0%b0%d1%85"},"mutability":"MUTABLE","type":"LINK"},"1":{"data":{"href":"https://7xz.ru/docs/book/progit/#%d0%be-%d0%b2%d0%b5%d1%82%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d0%b8-%d0%b2-%d0%b4%d0%b2%d1%83%d1%85-%d1%81%d0%bb%d0%be%d0%b2%d0%b0%d1%85","url":"https://7xz.ru/docs/book/progit/#%d0%be-%d0%b2%d0%b5%d1%82%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d0%b8-%d0%b2-%d0%b4%d0%b2%d1%83%d1%85-%d1%81%d0%bb%d0%be%d0%b2%d0%b0%d1%85"},"mutability":"MUTABLE","type":"LINK"},"2":{"data":{"href":"https://7xz.ru/docs/book/progit/#%d1%81%d0%be%d0%b7%d0%b4%d0%b0%d0%bd%d0%b8%d0%b5-%d0%bd%d0%be%d0%b2%d0%be%d0%b9-%d0%b2%d0%b5%d1%82%d0%ba%d0%b8","url":"https://7xz.ru/docs/book/progit/#%d1%81%d0%be%d0%b7%d0%b4%d0%b0%d0%bd%d0%b8%d0%b5-%d0%bd%d0%be%d0%b2%d0%be%d0%b9-%d0%b2%d0%b5%d1%82%d0%ba%d0%b8"},"mutability":"MUTABLE","type":"LINK"},"3":{"data":{"href":"https://7xz.ru/docs/book/progit/#%d0%bf%d0%b5%d1%80%d0%b5%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b2%d0%b5%d1%82%d0%be%d0%ba","url":"https://7xz.ru/docs/book/progit/#%d0%bf%d0%b5%d1%80%d0%b5%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b2%d0%b5%d1%82%d0%be%d0%ba"},"mutability":"MUTABLE","type":"LINK"},"4":{"data":{"href":"https://7xz.ru/docs/book/progit/#32-%d0%b2%d0%b5%d1%82%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b2-git---%d0%be%d1%81%d0%bd%d0%be%d0%b2%d1%8b-%d0%b2%d0%b5%d1%82%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d1%8f-%d0%b8-%d1%81%d0%bb%d0%b8%d1%8f%d0%bd%d0%b8%d1%8f","url":"https://7xz.ru/docs/book/progit/#32-%d0%b2%d0%b5%d1%82%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b2-git---%d0%be%d1%81%d0%bd%d0%be%d0%b2%d1%8b-%d0%b2%d0%b5%d1%82%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d1%8f-%d0%b8-%d1%81%d0%bb%d0%b8%d1%8f%d0%bd%d0%b8%d1%8f"},"mutability":"MUTABLE","type":"LINK"},"5":{"data":{"href":"https://7xz.ru/docs/book/progit/#%d0%be%d1%81%d0%bd%d0%be%d0%b2%d1%8b-%d0%b2%d0%b5%d1%82%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d1%8f-%d0%b8-%d1%81%d0%bb%d0%b8%d1%8f%d0%bd%d0%b8%d1%8f","url":"https://7xz.ru/docs/book/progit/#%d0%be%d1%81%d0%bd%d0%be%d0%b2%d1%8b-%d0%b2%d0%b5%d1%82%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d1%8f-%d0%b8-%d1%81%d0%bb%d0%b8%d1%8f%d0%bd%d0%b8%d1%8f"},"mutability":"MUTABLE","type":"LINK"},"6":{"data":{"href":"https://7xz.ru/docs/book/progit/#%d0%be%d1%81%d0%bd%d0%be%d0%b2%d1%8b-%d0%b2%d0%b5%d1%82%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d1%8f","url":"https://7xz.ru/docs/book/progit/#%d0%be%d1%81%d0%bd%d0%be%d0%b2%d1%8b-%d0%b2%d0%b5%d1%82%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d1%8f"},"mutability":"MUTABLE","type":"LINK"},"7":{"data":{"href":"https://7xz.ru/docs/book/progit/#%d0%be%d1%81%d0%bd%d0%be%d0%b2%d1%8b-%d1%81%d0%bb%d0%b8%d1%8f%d0%bd%d0%b8%d1%8f","url":"https://7xz.ru/docs/book/progit/#%d0%be%d1%81%d0%bd%d0%be%d0%b2%d1%8b-%d1%81%d0%bb%d0%b8%d1%8f%d0%bd%d0%b8%d1%8f"},"mutability":"MUTABLE","type":"LINK"},"8":{"data":{"href":"https://7xz.ru/docs/book/progit/#%d0%be%d1%81%d0%bd%d0%be%d0%b2%d0%bd%d1%8b%d0%b5-%d0%ba%d0%be%d0%bd%d1%84%d0%bb%d0%b8%d0%ba%d1%82%d1%8b-%d1%81%d0%bb%d0%b8%d1%8f%d0%bd%d0%b8%d1%8f","url":"https://7xz.ru/docs/book/progit/#%d0%be%d1%81%d0%bd%d0%be%d0%b2%d0%bd%d1%8b%d0%b5-%d0%ba%d0%be%d0%bd%d1%84%d0%bb%d0%b8%d0%ba%d1%82%d1%8b-%d1%81%d0%bb%d0%b8%d1%8f%d0%bd%d0%b8%d1%8f"},"mutability":"MUTABLE","type":"LINK"},"9":{"data":{"href":"https://7xz.ru/docs/book/progit/#33-%d0%b2%d0%b5%d1%82%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b2-git---%d1%83%d0%bf%d1%80%d0%b0%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b2%d0%b5%d1%82%d0%ba%d0%b0%d0%bc%d0%b8","url":"https://7xz.ru/docs/book/progit/#33-%d0%b2%d0%b5%d1%82%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b2-git---%d1%83%d0%bf%d1%80%d0%b0%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b2%d0%b5%d1%82%d0%ba%d0%b0%d0%bc%d0%b8"},"mutability":"MUTABLE","type":"LINK"},"20":{"data":{"href":"https://7xz.ru/docs/book/progit/#%d0%be%d1%82%d1%81%d0%bb%d0%b5%d0%b6%d0%b8%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5-%d0%b2%d0%b5%d1%82%d0%be%d0%ba","url":"https://7xz.ru/docs/book/progit/#%d0%be%d1%82%d1%81%d0%bb%d0%b5%d0%b6%d0%b8%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5-%d0%b2%d0%b5%d1%82%d0%be%d0%ba"},"mutability":"MUTABLE","type":"LINK"},"21":{"data":{"href":"https://7xz.ru/docs/book/progit/#%d0%bf%d0%be%d0%bb%d1%83%d1%87%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b8%d0%b7%d0%bc%d0%b5%d0%bd%d0%b5%d0%bd%d0%b8%d0%b9","url":"https://7xz.ru/docs/book/progit/#%d0%bf%d0%be%d0%bb%d1%83%d1%87%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b8%d0%b7%d0%bc%d0%b5%d0%bd%d0%b5%d0%bd%d0%b8%d0%b9"},"mutability":"MUTABLE","type":"LINK"}}},"mentions":[]}