{"draftJsState":{"blocks":[{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Посмотрим, что происходит, когда вы выполняете git rebase и почему нужно быть внимательным.","type":"unstyled","key":"4hmu1"},{"data":{},"depth":0,"entityRanges":[{"key":0,"length":6,"offset":4},{"key":1,"length":6,"offset":13}],"inlineStyleRanges":[],"text":"Это вторая и третья части гайда по Git из блога Pierre de Wulf.","type":"unstyled","key":"fkttu"},{"data":{"image":{"id":"5efe47ddd70c7529c162ae33"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"ejbhs"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"unstyled","key":"2p7ck"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Суть rebase","type":"header-two","key":"2qv7c"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Как именно происходит rebase:","type":"unstyled","key":"a7bne"},{"data":{"image":{"id":"5efe454c6affc51ae8282570"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"81mi4"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Можно сказать, что rebase — это открепить ветку (branch), которую вы хотите переместить, и подключить ее к другой ветке. Такое определение соответствует действительности, но попробуем заглянуть чуть глубже. Если вы посмотрите документацию, вот что там написано относительно rebase: «Применить коммиты к другой ветке (Reapply commits on top of another base tip)».","type":"unstyled","key":"3vdpn"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":194,"offset":0,"style":"BOLD"}],"text":"Главное слово здесь — применить, потому что rebase — это не просто копипаст ветки в другую ветку. Rebase последовательно берет все коммиты из выбранной ветки и заново применяет их к новой ветке.","type":"blockquote","key":"8bhr2"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Такое поведение приводит к двум моментам:","type":"unstyled","key":"8apiu"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Переприменяя коммиты, Git создает новые коммиты. Даже если они содержат те же изменения, то рассматриваются Git как новые и независимые коммиты.","type":"unordered-list-item","key":"e75vh"},{"data":{},"depth":0,"entityRanges":[{"key":2,"length":34,"offset":233}],"inlineStyleRanges":[],"text":"Git rebase переприменяет коммиты и не удаляет старые. Это значит, что после выполнения rebase ваши старые коммиты продолжат храниться в подпапке /оbjects папки .git. Если вы не до конца понимаете, как Git хранит и учитывает коммиты, почитайте первую часть этой статьи.","type":"unordered-list-item","key":"c3qo7"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Вот более правильная интерпретация того, что происходит при rebase:","type":"unstyled","key":"5lh3g"},{"data":{"image":{"id":"5efe454cc08891495d500d92"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"2dc7n"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Как видите, ветка feature содержит абсолютно новые коммиты. Как было сказано ранее, тот же самый набор изменений, но абсолютно новые объекты с точки зрения Git.","type":"unstyled","key":"fjqaj"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Это также означает, что старые коммиты не уничтожаются. Они становятся просто недоступными напрямую. Если вы помните, ветка — всего лишь ссылка на коммит. Таким образом, если ни ветка, ни тег не ссылаются на коммит, к нему невозможно получить доступ средствами Git, хотя на диске он продолжает присутствовать.","type":"unstyled","key":"bccvu"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Теперь давайте обсудим «Золотое правило».","type":"unstyled","key":"4ni3c"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Золотое правило rebase","type":"header-two","key":"j4dv"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":50,"offset":36,"style":"BOLD"}],"text":"Золотое правило rebase звучит так — «НИКОГДА не выполняйте rebase расшаренной ветки!». Под расшаренной веткой понимается ветка, которая существует в сетевом репозитории и с которой могут работать другие люди, кроме вас.","type":"unstyled","key":"f0vs3"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Часто это правило применяют без должного понимания, поэтому разберем, почему оно появилось, тем более что это поможет лучше понять работу Git.","type":"unstyled","key":"262a3"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Давайте рассмотрим ситуацию, когда разработчик нарушает золотое правило, и что происходит в этом случае.","type":"unstyled","key":"3f13b"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Предположим, Боб и Анна вместе работают над проектом. Ниже представлено, как выглядят репозитории Боба и Анны и исходный репозиторий на GitHub:","type":"unstyled","key":"f80n3"},{"data":{"image":{"id":"5efe454c9189141dc2bc4a9a"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"7ngib"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"У всех пользователей репозитории синхронизируются с GitHub.","type":"unstyled","key":"canqm"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Теперь Боб, нарушая золотое правило, выполняет rebase, и в это же время Анна, работая в ветке feature, создает новый коммит:","type":"unstyled","key":"7prul"},{"data":{"image":{"id":"5efe454c1ca9f05fe6d855d0"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"bid3u"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Вы видите, что произойдет?","type":"unstyled","key":"2lgn1"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Боб пытается выполнить пуш коммита, ему приходит отказ примерно такого содержания:","type":"unstyled","key":"e52i8"},{"data":{"image":{"id":"5efe454c02e2f8540b00ae0b"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"frehq"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Выполнение Git не было успешным, потому что Git не знает, как объединить feature ветку Боба с feature веткой GitHub.","type":"unstyled","key":"29i4o"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Единственным решением, позволяющим Бобу выполнить push, станет использование ключа force, который говорит GitHub-репозиторию удалить у себя ветку feature и принять за эту ветку ту, которая пушится Бобом. После этого мы получим следующую ситуацию:","type":"unstyled","key":"8ib14"},{"data":{"image":{"id":"5efe454ccad1c07c5f6ad117"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"a1d30"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Теперь Анна хочет запушить свои изменения, и вот что будет:","type":"unstyled","key":"cp5tb"},{"data":{"image":{"id":"5efe4552f680973b8b32a789"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"a3p25"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Это нормально, Git сказал Анне, что у нее нет синхронизированной версии ветки feature, то есть ее версия ветки и версия ветки в GitHub — разные. Анна должна выполнить pull. Точно таким же образом, как Git сливает локальную ветку с веткой в репозитории, когда вы выполняете push, Git пытается слить ветку в репозитории с локальной веткой, когда вы выполняете pull.","type":"unstyled","key":"al0b3"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Перед выполнением pull коммиты в локальной и GitHub-ветках выглядят так:","type":"unstyled","key":"erg5f"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"A--B--C--D' origin/feature // GitHub\nA--B--D--E feature // Anna","type":"unstyled","key":"faj5r"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Когда вы выполняете pull, Git выполняет слияние для устранения разности репозиториев. И вот, к чему это приводит:","type":"unstyled","key":"fg1f3"},{"data":{"image":{"id":"5efe455269d51a2f780c7ec5"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"quu2"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Коммит M — это коммит слияния (merge commit). Наконец, ветки feature Анны и GitHub полностью объединены. Анна вздохнула с облегчением, все конфликты устранены, она может выполнить push.","type":"unstyled","key":"5q9ar"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Боб выполняет pull, теперь все синхронизированы:","type":"unstyled","key":"40los"},{"data":{"image":{"id":"5efe4552c5c63c474b93f2bd"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"b71jh"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Глядя на получившийся беспорядок, вы должны были убедиться в важности золотого правила. Также учтите, что подобный беспорядок был создан всего одним разработчиком и на ветке, которая расшарена всего между двумя людьми. Представьте, что будет в команде из десяти человек.","type":"unstyled","key":"6t331"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Одним из многочисленных достоинств Git является то, что можно без проблем откатиться на любое время назад. Но чем больше допущено ошибок, подобных описанной, тем сложнее это сделать.","type":"unstyled","key":"gci1"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Также учтите, что появляются дубликаты коммитов в сетевом репозитории. В нашем случае — D и D’, содержащие одни и те же данные. По сути, количество дублированных коммитов может быть таким же большим, как и количество коммитов в вашей rebased ветке.","type":"unstyled","key":"4mi72"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Если вы все еще не убеждены, давайте представим Эмму — третью разработчицу. Она работает в ветке feature перед тем, как Боб совершает свою ошибку, и в настоящий момент хочет выполнить push. Предположим, что к моменту ее push наш маленький предыдущий сценарий уже завершился. Вот что выйдет:","type":"unstyled","key":"eln07"},{"data":{"image":{"id":"5efe4553e3d8786713f99d38"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Ох уж этот Боб!!!!","type":"atomic:image","key":"6p55v"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Этот текст мог заставить вас подумать, что rebase используют только для перемещения одной ветки на верхушку другой ветки. Это необязательно — вы можете выполнять rebase и на одной ветке.","type":"unstyled","key":"f3n0u"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Красота pull rebase","type":"header-two","key":"3fsn0"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Как вы видели выше, проблем Анны можно было избежать, если бы она использовала pull rebase. Рассмотрим этот вопрос подробнее.","type":"unstyled","key":"6m7t7"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Допустим, Боб работает в ветке, отходящей от мастера, тогда его история может выглядеть вот так:","type":"unstyled","key":"eq2l3"},{"data":{"image":{"id":"5efe4553c5c63c474b93f2be"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"95sc6"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Боб решает, что настало время выполнить pull, что, как вы уже поняли, приведет к некоторым неясностям. Поскольку репозиторий Боба отходил от GitHub, Git спросит делать ли объединение, и результат будет таким:","type":"unstyled","key":"83au5"},{"data":{"image":{"id":"5efe4554cad1c07c5f6ad118"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"44vhq"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Это решение подходит и работает нормально, однако, вам может быть полезно знать, что есть другие варианты решения проблемы. Одним из них является pull-rebase.","type":"unstyled","key":"6coav"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Когда вы делаете pull-rebase, Git пытается выяснить, какие коммиты есть только в вашей ветке, а какие — в сетевом репозитории. Затем Git объединяет коммиты из сетевого репозитория с самым свежим коммитом, присутствующим и в локальном, и в сетевом репозитории. После чего выполняет rebase ваших локальных коммитов в конец ветки.","type":"unstyled","key":"4bbii"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Звучит сложно, поэтому проиллюстрируем:","type":"unstyled","key":"896hd"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Git обращает внимание только на коммиты, которые есть и в вашем, и в сетевом репозитории:","type":"unordered-list-item","key":"596q3"},{"data":{"image":{"id":"5efe4556bdc95a01ba23924a"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"4chuv"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Это выглядит как локальный клон репозитория GitHub.","type":"unstyled","key":"frafl"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Git выполняет rebase локальных коммитов:","type":"unordered-list-item","key":"c1lnu"},{"data":{"image":{"id":"5efe4557828bb93a0ac12ae4"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"50joa"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Как вы помните, при rebase Git применяет коммиты один за одним, то есть в данном случаем применяет в конец ветки master коммит E, потом F. Получился rebase сам в себя. Выглядит неплохо, но возникает вопрос — зачем так делать?","type":"unstyled","key":"c8imm"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"По моему мнению, самая большая проблема с объединением веток в том, что загрязняется история коммитов. Поэтому pull-rebase — более элегантное решение. Я бы даже пошел дальше и сказал, что когда нужно скачать последние изменения в вашу ветку, вы всегда должны использовать pull-rebase. Но нужно помнить: поскольку rebase применяет все коммиты по очереди, то когда вы делаете rebase 20 коммитов, вам, возможно, придется решать один за другим 20 конфликтов.","type":"unstyled","key":"qo79"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Как правило, можно использовать следующий подход: одно большое изменение, сделанное давно — merge, два маленьких изменения, сделанных недавно — pull-rebase.","type":"unstyled","key":"agrog"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Сила rebase onto","type":"header-two","key":"eh0pa"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Предположим, история ваших коммитов выглядит так:","type":"unstyled","key":"51ihg"},{"data":{"image":{"id":"5efe4557d4cd2715b97269a4"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"7t3k9"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Итак, вы хотите выполнить rebase ветки feature 2 в ветку master. Если вы выполните обычный rebase в ветку master, получите это:","type":"unstyled","key":"63fru"},{"data":{"image":{"id":"5efe4558d4cd2715b97269a5"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"6c2tc"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Нелогично выглядит то, что коммит D существует в обоих ветках: в feature 1 и feature 2. Если вы переместите ветку feature 1 в конец ветки мастер, получится, что коммит D будет применен два раза.","type":"unstyled","key":"eabib"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Предположим, что вам нужно получить другой результат:","type":"unstyled","key":"evku6"},{"data":{"image":{"id":"5efe4559868577791bfc056b"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"631gs"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Для реализации подобного сценария как раз и предназначен git rebase onto.","type":"unstyled","key":"sqr5"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Сначала прочтем документацию:","type":"unstyled","key":"b17e9"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"SYNOPSIS\n git rebase [-i | --interactive] [] [--exec ]\n [--onto | --keep-base] [ []]\n git rebase [-i | --interactive] [] [--exec ] \n[--onto ]\n --root []\n git rebase (--continue | --skip | --abort | --quit | --edit-todo\n | --show-current-patch)","type":"blockquote","key":"e30mc"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Нас интересует вот это:","type":"unstyled","key":"5198o"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"OPTIONS\n --onto \n Starting point at which to create the new commits. If the \n--onto option is not specified, the starting point is . May be \nany valid commit, and not just an existing branch name.","type":"blockquote","key":"f4a88"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"С помощью этой опции указывается, в какой точке создавать новые коммиты.\nЕсли эта опция не указана, то стартовой точкой станет .","type":"unstyled","key":"ciete"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Для понимания приведу еще один рисунок:","type":"unstyled","key":"alnqv"},{"data":{"image":{"id":"5efe4559b84d394691ce83c7"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"f67bb"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"То есть ветка master — это , а ветка feature 1 — .","type":"unstyled","key":"94r6d"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Таким образом, если вы хотите получить результат как на последнем рисунке, необходимо выполнить в ветке feature2 git rebase —onto master feature1.","type":"unstyled","key":"d0dpr"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Удачи!","type":"unstyled","key":"89ttj"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Оригинал статьи на Habr.com.","type":"unstyled","key":"6i3k6"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Автор: Денис Романенко ","type":"unstyled","key":"6n9jv"},{"data":{},"depth":0,"entityRanges":[{"key":3,"length":82,"offset":11}],"inlineStyleRanges":[{"length":94,"offset":0,"style":"ITALIC"}],"text":"Источник: https://mcs.mail.ru/blog/rukovodstvo-po-git-zolotoe-pravilo-i-drugie-osnovy-rebase ","type":"unstyled","key":"aqvj4"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":25,"offset":0,"style":"BOLD"}],"text":"Что еще почитать по теме:","type":"blockquote","key":"r9pl"},{"data":{},"depth":0,"entityRanges":[{"key":4,"length":51,"offset":0}],"inlineStyleRanges":[{"length":51,"offset":0,"style":"BOLD"}],"text":"Мой второй год в качестве независимого разработчика","type":"blockquote","key":"951s3"},{"data":{},"depth":0,"entityRanges":[{"key":5,"length":41,"offset":0}],"inlineStyleRanges":[{"length":41,"offset":0,"style":"BOLD"}],"text":"Как технический долг убивает ваши проекты","type":"blockquote","key":"1722r"},{"data":{},"depth":0,"entityRanges":[{"key":6,"length":64,"offset":0}],"inlineStyleRanges":[{"length":65,"offset":0,"style":"BOLD"}],"text":"Простые способы кэширования в GitLab CI: руководство в картинках.","type":"blockquote","key":"8ue0u"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"marker","key":"OuHD8IrHJu4tPpcNAMkQ"}],"entityMap":{"0":{"data":{"href":"https://www.daolf.com/posts/git-series-part-2/","url":"https://www.daolf.com/posts/git-series-part-2/"},"mutability":"MUTABLE","type":"LINK"},"1":{"data":{"href":"https://www.daolf.com/posts/git-series-part-3/","url":"https://www.daolf.com/posts/git-series-part-3/"},"mutability":"MUTABLE","type":"LINK"},"2":{"data":{"url":"https://mcs.mail.ru/blog/rukovodstvo-po-git-chast-odin-pro-katalog-git"},"mutability":"MUTABLE","type":"LINK"},"3":{"data":{"href":"https://mcs.mail.ru/blog/rukovodstvo-po-git-zolotoe-pravilo-i-drugie-osnovy-rebase","url":"https://mcs.mail.ru/blog/rukovodstvo-po-git-zolotoe-pravilo-i-drugie-osnovy-rebase"},"mutability":"MUTABLE","type":"LINK"},"4":{"data":{"href":"https://mcs.mail.ru/blog/moj-vtoroj-god-v-kachestve-nezavisimogo-razrabotchika","url":"https://mcs.mail.ru/blog/moj-vtoroj-god-v-kachestve-nezavisimogo-razrabotchika"},"mutability":"MUTABLE","type":"LINK"},"5":{"data":{"href":"https://mcs.mail.ru/blog/kak-tekhnicheskij-dolg-ubivaet-vashi-proekty","url":"https://mcs.mail.ru/blog/kak-tekhnicheskij-dolg-ubivaet-vashi-proekty"},"mutability":"MUTABLE","type":"LINK"},"6":{"data":{"href":"https://mcs.mail.ru/blog/sposoby-keshirovaniya-v-gitlab-ci-rukovodstvo-v-kartinkah","url":"https://mcs.mail.ru/blog/sposoby-keshirovaniya-v-gitlab-ci-rukovodstvo-v-kartinkah"},"mutability":"MUTABLE","type":"LINK"}}},"mentions":[]}