Branch - исправить ошибку gitlab: «вам не разрешено отправлять код в защищенные ветки этого проекта»?

Создаём ветку

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

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

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

1 2	cd foobar git checkout -b fix-protobaz

Вторая команда создаст ветку и перейдёт на неё(сделает checkout).

Если после этого выполнить , он покажет

1 2	On branch fix-protobaz nothing to commit, working directory clean

Эту команду стоит запомнить — когда не понимаете,в каком состоянии репозиторий,
просто выполните её. Чаще всего в её выводе покажет другие команды,
которые делают то,что вы(скорее всего) и хотите сделать.

Необходимость контроля версий

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

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

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

История Кодекс имеет важное значение, и без контроля версий не было бы ни одного

Изменения в производительности

Изменения в CE:

Улучшена производительность отображения страницы group milestones: !6457
Уменьшено количество выполняемых запросов при обработке ссылок Markdown: !6457 и !6545
Sidekiq теперь использует пул связей при работе с кешем Rails: !6468 и !6657
Уменьшено количество обновлений таблицы , благодаря чему уменьшено количество обращений к базе данных: !6537
Немного уменьшено количество выполняемых запросов при пуше коммитов: !6680
Добавлен ежедневный предварительный подсчет рейтинга проектов для страницы trending projects, что повышает ее производительность: !6749
Добавлена асинхронная загрузка diff’ов при создании нового мерж-реквеста: !5844
При изменении timestamp’а последних изменений проекта более не используются временные ссылки (leases) Redis: !6678
Секретный токен для gitlab-shell и API теперь хранится в памяти, а не читается с диска при каждом запросе API: !6599
Уменьшено количество запросов, используемых при проверке политик проекта: !6442
Worker, используемый для истекающих артефактов сборки, теперь эффективнее распределяет задачи и использует более эффективные запросы SQL: !6732
Обновления мерж-реквестов с помощью пушей теперь используют специальный Sidekiq worker: !6767
Хуки конвейера CI теперь обновляются асинхронно: !6824
Метрики конвейера CI теперь обновляются с помощью Sidekiq worker: !6896
Улучшена производительность и использование памяти загрузчика GitHub: !6552
Оптимизировано получение URL для отрисовки эмодзи в обсуждениях.: !6848
При создании проекта мы автоматически создаем соответствующую строку вместо проверки этого (и создания строки при необходимости), когда бы мы ни запрашивали проект из базы данных. Это уменьшает количество запросов к базе данных, когда нам нужно вернуть проект из версии 2 в 1: !6908
Коммиты конвейера CI обновляются только после создания конвейера вместо обновления каждого по-отдельности: !6986
Длительности конвейера CI обновляются только в конце конвейера вместо обновления после каждого изменения состояния: !6987
Обновление кэша проекта теперь происходит каждые 15 минут. Статистика может стать несвежей (например, подсчет коммитов), но существенно уменьшится нагрузка на диск: !7017
Sidekiq теперь использует разные очереди для большого количества разных работников: !7006
Задачи в конвейере CI распределяются умнее, предотвращая назначение нескольких задач с одними и теми же параметрами в одно и то же время: !7005
Кэширование полей markdown в базе данных !6095

Изменения в EE:

Данные об использовании GitLab теперь кэшируются: !779

Изменения в gitlab-shell:

Отслеживание производительности Git теперь может быть включено с помощью переменной окружения: !91
Улучшено перемещение репозиториев между шардами: !97 и !96

GitHub flow – более простой вариант

В противовес сложной модели git flow был разработана модель GitHub flow. В ней есть только и feature-ветки. Это упрощение привело к успешному внедрению GitHub flow множеством компаний. Компания Atlassian предложила похожую стратегию. Но, в отличие от GitHub, они предпочитают делать ребейз (rebase), а не мерж веток в .

Мерж всех изменений в и частое развёртывание позволяют не писать код «в стол», а сразу выпускать изменения. Это соответствует идеям бережливого (lean) производства и непрерывной доставки. Но множество вопросов остаются без ответа: когда именно нужно развёртывать и в каких окружениях, как выпускать релизы, как связать всё это с трекером задач. GitLab flow отвечает на все эти вопросы.

Работа в Git¶

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

Теперь мы можем непосредственно приступить к версионному контролю вашего проекта. Сначала заходим в папку с проектом и выполняем команду инициализации пустого репозитория (если еще не создавали):

$ cd project_dir
$ git init

Кроме того, вы можете не инициализировать репозиторий, а склонировать готовый (адрес которого указан в настройках вашего проекта) и уже туда скопировать файлы вашего проекта:

$ git clone ssh://[email protected]/name-of-repository.git

Адрес репозитория по умолчанию вы можете найти на главной странице вашего проекта на сайте в секции «Main Git Repository»:

Затем индексируем файлы, находящиеся в проекте, чтобы подготовить их к коммиту:

$ git add .

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

$ git status

Теперь вы можете сохранить новую версию вашего кода в Git или, если сказать по другому — закоммитить:

$ git commit -m "Init new project"

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

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

$ git log

Или в более удобном виде:

$ git log --pretty=format:"%h - %an, %ar : %s"

Burndown Charts (EE)

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

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

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

Наша документация расскажет вам больше о .

Навигация и работа в терминале¶

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

$ cd ~   # Переход в домашнюю директорию пользователя
$ cd /   # Переход в корневую директорию
$ cd ..  # Переход из текущей папки на один уровень выше
$ cd project_dir  # Переход из текущей папки в папку с именем project_dir
$ cd ../project_dir  # Сначала переходим на один уровень выше, а потом заходим в папку project_dir

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

Для этого используется команда. Ниже приводятся примеры ее использования

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

$ ls   # Показать содержимое текущей папки
$ ls -la  # Используются специальные ключи l - показать в виде списка со свойствами, a - показать также скрытые файлы
$ ls project_dir  # Показать содержимое папки project_dir

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

Думаю неплохо было бы объяснить понятия домашней и корневой директорий. Для пользователей Windows это довольно сложно к восприятию. Домашняя директория это папка пользователя, которая создается ОС и к ней имеет полный доступ только сам пользователь. В Windows по умолчанию это папка . Разумеется должно заменяться именем вашего пользователя. Собственно говоря, обычно (но не всегда) Git bash именно определяет как домашнюю директорию. Здесь все просто. Корневая директория представляет папку в которую устанавливается ОС Linux. Обозначается она одинарным слэшом /. В Git bash это просто папка, куда установлен сам Git bash.

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

$ cd ~    # Перемещаемся в домашнюю директорию
$ pwd     # Узнаем адрес текущей директории, чтобы точно знать что Git bash подразумевает под домашней директорией
$ ls -l   # Проверяем содержимое директории, чтобы убедиться в своей правоте
$ cd dir  # Начинаем перемещаться по иерархии папок

Если необходимо создать директорию, то используется команда :

$ mkdir dir_name   # Создаем папку с именем dir_name

Здесь можно еще добавить, что если вам необходимо создать новый пустой текстовый файл, то можно воспользоваться следующей командой:

$ touch new.html

Тестирование перед мержем

В старых моделях рабочего процесса сервер непрерывной интеграции (CI server), как правило, запускал тесты только на ветке . Поэтому разработчикам приходилось нести ответственность за то, чтобы не сломать . В GitLab flow разработчики создают свои ветки от , поэтому её всегда нужно поддерживать «зелёной». Поэтому каждый мерж-реквест нужно тестировать, прежде чем мержить. Инструменты CI, такие как GitLab CI или Travis, умеют показывать результаты сборки (build) непосредственно в мерж-реквесте.

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

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

Git flow и его ограничения

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

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

Во-вторых, лишняя сложность появляется из-за веток релизов и хотфиксов. Большинство команд, особенно небольших, может легко обойтись без них. Сегодня большинство организаций придерживается практики непрерывной доставки (continuous delivery), которая предполагает, что код из основной ветки можно развёртывать на продакшен (production, то, что предоставляется пользователям).

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

GitLab Runner

Также, вместе с GitLab 8.13 был выпущен GitLab Runner 1.7. Список самых интересных изменений:

Добавлено использование Go 1.7 — добавляет поддержку Runner на Mac OS X Sierra !323
Добавлена GIT_STRATEGY=none !332
Добавлена поддержка OffPeak для автоскейлинга !345
Введена переменная для включения режима трассировки shell в bash, cmd.exe и powershell.exe !339
В первую очередь загружается конфиг InCluster, если загрузка неудачна — конфиг kubectl !327
Godep: github.com/Sirupsen/logrus обновлен до версии 0.10.0 !344
Добавлено использование и !341
Значение поля runner теперь переводится в нижний регистр для совместимости с ограничениями GCE !297
Добавлена обработка before_script при выполнении команды exec !355
Сборки больше не помечаются как неудавшиеся из-за ошибки кеширования !359
Внесены улучшения в процедуру регистрации !356

Полный список изменений можно посмотреть в чейнджлоге Runner’а.

12 ответов

Лучший ответ

Если ветки только локальные, вы можете использовать -d , если ветка была объединена, например

Если ветка содержит код, который вы никогда не планируете объединять, используйте вместо него -D .

Если ветка находится в репозитории восходящего потока (на Bitbucket), вы можете удалить удаленную ссылку с помощью

Кроме того, если вы находитесь на веб-сайте Bitbucket, вы можете удалить созданные вами ветки, перейдя на вкладку Функциональные ветки в разделе Коммиты на сайте. Там вы найдете значок с многоточием. Нажмите на нее, а затем выберите Удалить ветку . Только убедитесь, что вы хотите сбросить туда все изменения!

247

steampowered
20 Мар 2016 в 17:18

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

Ehab Al-Hakawati
27 Мар 2019 в 11:51

Я написал этот небольшой скрипт, когда количество веток в моем репо перевалило за несколько сотен. Я не знал о других методах (с CLI), поэтому решил автоматизировать их с помощью селена. Он просто открывает веб-сайт Bitbucket, переходит в раздел «Филиалы», прокручивает страницу до конца и нажимает на каждое меню параметров ветки -> нажимает кнопку «Удалить» -> нажимает «Да». Его можно настроить, чтобы сохранить последние N (100 — по умолчанию) веток и пропустить ветки с определенными именами (master, develop — по умолчанию, может быть больше). Если это вам подходит, вы можете попробовать то же самое.

Все, что вам нужно, — это клонировать репозиторий, загрузить соответствующую версию Chrome-webdriver, ввести несколько констант, таких как URL-адрес, в ваш репозиторий и запустить скрипт.

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

Dan
20 Июн 2019 в 17:22

Если вы используете среду разработки pycharm для разработки и уже добавили с ней Git. вы можете напрямую удалить удаленную ветку из pycharm. На панели инструментов VCS -> Git -> Ветви -> Выбрать ветку -> и удалить . Он удалит его с удаленного сервера git.

Jyoti Amage
17 Сен 2018 в 07:35

Шаг 1. Войдите в Bitbucket

Шаг 2: Выберите ваш репозиторий в списке репозиториев.

Шаг 3: Выберите ветви в меню слева.

Шаг 4: Курсор на ветке щелкните на трех точках (…) Выберите Удалить (см. Изображение внизу)

Nanhe Kumar
4 Авг 2018 в 07:55

В Bitbucket перейдите к веткам в меню слева.

Выберите ветку, которую хотите удалить.
Перейдите в столбец действий, нажмите на три точки (…) и выберите удалить.

Prashant Sharma
20 Сен 2017 в 06:03

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

Оказалось, что кто-то установил под и оттуда снял флажок . Надеюсь, это может кому-то помочь.

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

Ogglas
17 Янв 2018 в 09:49

В дополнение к ответу @Marcus теперь вы также можете удалить удаленную ветку с помощью:

philipvr
15 Сен 2017 в 20:33

Для удаления ветки из Bitbucket,

Перейдите в Обзор (ваш репозиторий> ветки на левой боковой панели)
Щелкните количество веток (это должно показать вам список веток)
Нажмите на ветку, которую хотите удалить
В правом верхнем углу нажмите на 3 точки (кроме кнопки «Объединить»).
Есть опция «Удалить ветку», если у вас есть права.

lealceldeiro
25 Июл 2019 в 11:11

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

MJ Montes
28 Авг 2020 в 04:36

Если вам нравится веселье, вы можете просто перейти на страницу со списком ваших веток (например, объединенных) и просто запустить в консоли javascript:

КАК ЭТО УСТРОЕНО

Сначала нам нужна страница с токеном CSRF в источнике страницы, поэтому я выбираю:

Затем для каждой ветки (в списке веток) он получает токен CSRF и удаляет эту ветку.

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

Это НЕ удалит основную ветку.

ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ

Вы должны быть авторизованы.

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

turkus
3 Июл 2019 в 11:19

В Android Studio параметры в правом углу среды IDE:

Изменить / оформить заказ в другом местном филиале
Удалите ненужные локальные ветки (например, v0.0.1 …)
Удалить нежелательные удаленные ветки (например, origin / v0.0.1 …) — на этом шаге будут удалены ветки в BitBucket, если удаление ветвей не запрещено и они не являются ГЛАВНЫМ ВЕТВОМ .

Tim Long
9 Ноя 2015 в 23:20

Одиночный разработчик, единственная ветвь

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

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

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

Вы также хотели бы знать, что вы сделали, и то, над чем вы работали в последнее время. Это означает, что вы должны описывать каждый набор изменений (каждый фиксатор).
Аннотировать файл/просмотр истории. Если у вас нет идеальной памяти, иногда вам нужно знать, почему (и когда, и в случае, когда есть несколько разработчиков, и кто), вы написали заданный набор строк. Комментарии не всегда достаточно. Для этого вы можете использовать (если ваша система управления версиями предоставляет) линейные аннотации истории файлов ( или ) или другие аналогичные инструменты, такие как так называемый поиск “pickaxe” в Git, где вы выполняете поиск/просмотреть историю для коммитов, которые ввели или удалили заданную строку.

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

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

Метки, задающие контекст

(PREMIUM, ULTIMATE, SILVER, GOLD)

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

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

Или представим, что у вас есть метки , и для представления этапов рабочего процесса в вашей команде. Если у задачи уже стоит метка и разработчик хочет продвинуть задачу в , он может просто добавить новую метку, а старая будет удалена автоматически. Такое поведение уже существует при переносе задач между списками меток на доске задач (в русской локализации GitLab «доска обсуждений»), представляющей ваш рабочий процесс, а теперь такие изменения смогут вносить те пользователи, которые не работают с доской задач напрямую — через метки задачи.

и оригинальный тикет.