Введение¶
Git (произн. «гит») — распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux. На сегодняшний день поддерживается Джунио Хамано.
Система спроектирована как набор программ, специально разработанных с учётом их использования в скриптах. Это позволяет удобно создавать специализированные системы контроля версий на базе Git или пользовательские интерфейсы. Например, Cogito является именно таким примером фронтенда к репозиториям Git, а StGit использует Git для управления коллекцией патчей.
Git поддерживает быстрое разделение и слияние версий, включает инструменты для визуализации и навигации по нелинейной истории разработки. Как и Darcs, BitKeeper, Mercurial, SVK, Bazaar и Monotone, Git предоставляет каждому разработчику локальную копию всей истории разработки; изменения копируются из одного репозитория в другой.
Удалённый доступ к репозиториям Git обеспечивается git-daemon, gitosis, SSH- или HTTP-сервером. TCP-сервис git-daemon входит в дистрибутив Git и является наряду с SSH наиболее распространённым и надёжным методом доступа. Метод доступа по HTTP, несмотря на ряд ограничений, очень популярен в контролируемых сетях, потому что позволяет использовать существующие конфигурации сетевых фильтров.
12 ответов
Лучший ответ
Если ветки только локальные, вы можете использовать -d , если ветка была объединена, например
Если ветка содержит код, который вы никогда не планируете объединять, используйте вместо него -D .
Если ветка находится в репозитории восходящего потока (на Bitbucket), вы можете удалить удаленную ссылку с помощью
Кроме того, если вы находитесь на веб-сайте Bitbucket, вы можете удалить созданные вами ветки, перейдя на вкладку Функциональные ветки в разделе Коммиты на сайте. Там вы найдете значок с многоточием. Нажмите на нее, а затем выберите Удалить ветку . Только убедитесь, что вы хотите сбросить туда все изменения!
247
steampowered
20 Мар 2016 в 17:18
Попробуйте эту команду, она очистит все ветки, которые были объединены с веткой .
1
Ehab Al-Hakawati
27 Мар 2019 в 11:51
Я написал этот небольшой скрипт, когда количество веток в моем репо перевалило за несколько сотен. Я не знал о других методах (с CLI), поэтому решил автоматизировать их с помощью селена. Он просто открывает веб-сайт Bitbucket, переходит в раздел «Филиалы», прокручивает страницу до конца и нажимает на каждое меню параметров ветки -> нажимает кнопку «Удалить» -> нажимает «Да». Его можно настроить, чтобы сохранить последние N (100 — по умолчанию) веток и пропустить ветки с определенными именами (master, develop — по умолчанию, может быть больше). Если это вам подходит, вы можете попробовать то же самое.
Все, что вам нужно, — это клонировать репозиторий, загрузить соответствующую версию Chrome-webdriver, ввести несколько констант, таких как URL-адрес, в ваш репозиторий и запустить скрипт.
Код достаточно прост для понимания. Если у вас есть вопросы, напишите комментарии / создайте проблему.
2
Dan
20 Июн 2019 в 17:22
Если вы используете среду разработки pycharm для разработки и уже добавили с ней Git. вы можете напрямую удалить удаленную ветку из pycharm. На панели инструментов VCS -> Git -> Ветви -> Выбрать ветку -> и удалить . Он удалит его с удаленного сервера git.
2
Jyoti Amage
17 Сен 2018 в 07:35
Шаг 1. Войдите в Bitbucket
Шаг 2: Выберите ваш репозиторий в списке репозиториев.
Шаг 3: Выберите ветви в меню слева.
Шаг 4: Курсор на ветке щелкните на трех точках (…) Выберите Удалить (см. Изображение внизу)
4
Nanhe Kumar
4 Авг 2018 в 07:55
В Bitbucket перейдите к веткам в меню слева.
- Выберите ветку, которую хотите удалить.
- Перейдите в столбец действий, нажмите на три точки (…) и выберите удалить.
9
Prashant Sharma
20 Сен 2017 в 06:03
Я мог удалить большую часть своих веток, но одна выглядела так, и я не мог ее удалить:
Оказалось, что кто-то установил под и оттуда снял флажок . Надеюсь, это может кому-то помочь.
Обновление : где находятся настройки из вопроса в комментарии. Войдите в репозиторий, который вы не хотите редактировать, чтобы открыть меню. Чтобы изменить это, вам могут потребоваться права администратора.
10
Ogglas
17 Янв 2018 в 09:49
В дополнение к ответу @Marcus теперь вы также можете удалить удаленную ветку с помощью:
23
philipvr
15 Сен 2017 в 20:33
Для удаления ветки из Bitbucket,
- Перейдите в Обзор (ваш репозиторий> ветки на левой боковой панели)
- Щелкните количество веток (это должно показать вам список веток)
- Нажмите на ветку, которую хотите удалить
- В правом верхнем углу нажмите на 3 точки (кроме кнопки «Объединить»).
- Есть опция «Удалить ветку», если у вас есть права.
45
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
Исходное состояние
В интерфейсе HTMLAcademy создаём репозиторий. Этот репозиторий (он же мастер-репозиторий), будет отправляться на итоговую проверку. Прямо вносить в него изменения нельзя, поэтому нужно создать себе форк (fork — вилка с английского), чтобы была возможность вносить изменения. Этот форк лежит на удаленном сервере у GitHub, и чтобы была возможность работать с ним у себя на компьютере мы должны сделать клон форка к себе на компьютер
В итоге получается 3 репозитория:
- Удаленный (на сервере) мастер-репозиторий от Академии для защиты, в который прямо изменения вносить нельзя
- Удаленный форк мастера. Через него изменения отправляются в мастер-репозиторий через Pull Request.
- Локальный клон форка. Чтобы можно было работать на своем компьютере.
Related Terms
- : Clone (download) a repository that already exists on GitHub, including all of the files, branches, and commits.
- : Always a good idea, this command shows you what branch you’re on, what files are in the working or staging directory, and any other important information.
- : This shows the existing branches in your local repository. You can also use to create a branch from your current location, or to see all branches, both the local ones on your machine, and the remote tracking branches stored from the last or from the remote.
- : Uploads all local branch commits to the remote.
- : Browse and inspect the evolution of project files.
- : Show the associated remote repositories and their stored name, like .
Contribute to this article on GitHub.
Как Клонировать Удалённый Репозиторий?
Чтобы клонировать репозиторий, мы будем использовать команду Git clone. Кроме того, вам также необходимо указать URL-адрес репозитория:
- Вы можете клонировать главную ветку (master branch) из удалённого репозитория с помощью HTTPS или SSH.
Для HTTPS:git clone https://github.com/imia-polzovatelia/imia-vashego-repozitorija.git
Для SSH:
git clone ssh://github.com/imia-polzovatelia/imia-vashego-repozitorija.git
- Чтобы перейти в корень клонированного репозитория, вы можете использовать команду cd:
cd vashi_prilozhenija
- Проверить состояние ветки можно с помощью простой команды Git:
git status
Examples of git pull
Working on a Branch
If you’re already working on a branch, it is a good idea to run before starting work and introducing new commits. Even if you take a small break from development, there’s a chance that one of your collaborators has made changes to your branch. This change could even come from updating your branch with new changes from .
It is always a good idea to run — especially before . Changes that are not committed can be overwritten during a . Or, they can block the portion of the from executing. If you have files that are changed, but not committed, and the changes on the remote also change those same parts of the same file, Git must make a choice. Since they are not committed changes, there is no possibility for a merge conflict. Git will either overwrite the changes in your working or staging directories, or the will not complete, and you will not be able to include any of the updates from the remote.
If this happens, use to identify what changes are causing the problem. Either delete or commit those changes, then or again.
Keep up to date
Keeping the branch up to date is generally a good idea.
For example, let’s say you have cloned a repository. After you clone, someone merges a branch into master. Then, you’d like to create a new branch to do some work. If you create your branch off of before operating , your branch will not have the most recent changes. You could accidentally introduce a conflict, or duplicate changes. By running before you create a brach, you can be sure that you will be working with the most recent information.
Undo A
To effectively «undo» a , you cannot undo the — but you can undo the that changed your local working branch.
To do this, you will need to to the commit you made before you merged. You can find this commit by searching the . The reflog is a log of every place that HEAD has pointed — every place that you have ever been checked out to. This reflog is only kept for 30 to 90 days, depending on the commit, and is only stored locally. (The reflog is a great reason not to delete a repository if you think you’ve made a mistake!)
Run and search for the commit that you would like to return to. Then, run to reset HEAD and your current branch to the SHA of the commit from before the merge.
Force to Overwrite Local Files
If you have made commits locally that you regret, you may want your local branch to match the remote branch without saving any of your work. This can be done using . First, make sure you have the most recent copy of that remote tracking branch by fetching.
ex:
Then, use to move the HEAD pointer and the current branch pointer to the most recent commit as it exists on that remote tracking branch.
ex:
with Rebase
If there have been new commits on both your local branch and the remote branch, a merge commit will be created when you . This recursive merge is the default merge style when there are two splits in history being brought together. But, you may want history on a branch to be only one line.
You can update your local working branch with commits from the remote, but rewrite history so any local commits occur after all new commits coming from the remote, avoiding a merge commit.
This is done with .
Using does not affect the integrity of the changes or the commits, but it does affect how history looks in the commit parent/child relationship.
Как переименовать ветку
Иногда оказывается, что первоначально созданное имя ветки не самое лучшее. Его можно изменить.
Локальную
Если еще не выполнена команда push, то достаточно переименовать локальную ветку.
Чтобы переименовать локальную ветку, выполним команду:
$ git branch -m <old-name> <new-name>
Например, переименуем ветку testing в ветку test:
$ git branch –m testing test
Чтобы переименовать текущую ветку, выполним команду:
$ git branch -m <new-name>
Например, текущая ветка у нас subbranch_of_testing. Переименуем ее в subbranch:
$ git branch –m subbranch
Удаленную
Переименовать удаленную ветку (ветку в удаленном репозитории) нельзя. Можно удалить ее и отправить в репозиторий локальную ветку с новым именем:
$ git push origin :old-name new-name
здесь origin — имя удаленного репозитория (обычно удаленный репозиторий так называется),old-name — имя ветки локальной ветки,new-name — новое имя ветки в удаленном репозитории.
Например, надо переименовать ветку testing в test:
$ git push origin :testing test
Что такое ветки?
Чаще всего ветки (branch — ответвление, ветвь, филиал) бывают тематическими. Например, при общей разработке, когда у всех участников есть право записи в репозиторий. В этом случае ветки используются для отделения изменений, сделанных одним из разработчиков, от общего репозитория. Ветки могут пригодиться и в случае с созданием pull-request’а.
Создание ветки происходит довольно просто. Находясь в каталоге с проектом, наберите следующие команды:
Новые ветки создаются не только из master, берите любую!
Находясь в только что созданной ветке, вы можете приступить к работе. Вносите в код свои изменения, а когда закончите просто переключитесь обратно к своей основной ветке. Вы можете отправить pull request, выбрав ветку или же прежде слить изменения из неё в основную ветку разработки. Рассмотрим это подробнее:
Если нужно отправить в свой удалённый репозиторий вновь созданную ветку (не сливать её с master), делаем следующее:
Не торопитесь сливать изменения. Если что-то не заладилось, созданную ветку можно удалить:
Удалить все локальные ветки, которые были смержены (то есть код которых теперь есть) в ветках develop или master:
git push rejected
Вы сделали новый коммит, пытаетесь запушить его, а git в ответ выдает такое
Написано много, но суть в том, что коммит отклонен, пуш не прошел. Почему?
Git устроен так, что локально мы можем коммитить сколько угодно. Но прежде чем отправить свои коммиты на сервер, то есть запушить, нужно подтянуть новые коммиты с сервера.
Те самые, которые успели сделать наши коллеги. То есть сделать git pull.
Когда мы делаем git push, git сначала проверяет, а нет ли на сервере новых коммитов. Если они есть, то git выдает то самое сообщение — git push rejected.
Значит, нам нужно сначала сделать git pull, а затем снова запушить
Здесь нас подстерегает неожиданность — в терминале выскакивает окно редактирования коммита. Пока просто сохраним, что предложено по умолчанию и закроем редактор.
Вот теперь можно пушить свои коммиты
Все, наши коммиты на сервере. При этом появится странный коммит «Merge branch ‘master’ of github.com:Webdevkin/site-git».
Это так называемый мердж-коммит, о нем чуть ниже.
Если же при попытке пуша новых коммитов на сервере нет, то git push пройдет сразу и отправит наши коммиты на сервер.
Когда использовать Git Pull?
Пользователь может задаться вопросом, когда он должен использовать Git fetch и когда он должен перейти к команде Git pull. Git fetch часто считается более безопасной версией Git Pull, и ее следует использовать, если пользователь новичок в Git. Если пользователь достаточно уверен в себе, он может использовать команду git pull только в чистом рабочем каталоге (без зафиксированных изменений).
Git pull чаще используется, когда кто-то работает в одиночку на ветке. Поскольку нет смысла пересматривать собственные изменения еще раз, вы можете напрямую перенести их в свой репозиторий.
Использование команды Git pull ничем не отличается от использования команды Git merge. Просто имейте в виду, что git pull-это короткий путь к git fetch и git merge. Это означает, что нам не нужно выполнять git fetch и git merge, и изменения будут включены непосредственно.
Git — слияние ветвей (branches)
В предыдущем шаге я создал ветвь , в которую внес “рискованные” изменения, чтобы проверить, “оправдают” ли они себя. Изменениями я доволен и хотел бы добавить их в первоначальную ветку , чтобы потом продолжить развитие проекта уже с этого места.
Фактически, я хочу сделать слияние двух веток — и . Это сделать очень просто — для этого я перехожу в ветку . То есть, я должен находиться в той ветке, в которую я вношу изменения из другой ветки. А затем произвожу само слияние:
Команда слияния проста — я просто указываю имя той ветки (branch), которую хочу слить (merge) с текущей, в которой я нахожусь на данный момент.
При слиянии ветвей зачастую может возникнуть ситуация, когда происходит конфликт между двумя ветвями. Рассмотрение вопроса решения конфликтов при слиянии не рассматривается мною, так как на данный момент еще не освоил этот вопрос до конца.
Давайте снова “заглянем” в окно браузера — что он нам интересного покажет?
Показал он то, что и следовало показать — результат объединения двух ветвей и .
Выполнение заданий
Перед выполнением нового задания, первое, что нужно сделать — это создать новую ветку из ветки master.
Находясь в ветке master выполняем команду
Флаг команды создает новую ветку под названием и тут же переключается на неё.
Если ввести команду , то в консоли будут показаны все доступные ветки, текущая (выбранная) ветка будет с пометкой
Второе, выполняем работу по условию задания.
После завершения задания необходимо зафиксировать изменения — сделать коммит (коммиты можно делать и походу задания, а не один раз в конце задания).
Для этого нам надо проиндексировать изменения.
Командой можно посмотреть текущее состояние в ветке, а именно список с названиями изменённых файлов, если они есть, и те, которые ожидают записи и сохранения (обычно они выделены красным цветом).
Из сообщения команды видно, что файл модифицирован, но не проиндексирован для коммита.
Для того, чтобы проиндексировать изменения нужно воспользоваться командой . После этой команды файл будет уже зеленым цветом (если снова ввести ).
В дальнейшем, когда будет много изменений, проще ввести или . Эта команда проиндексирует все изменения, которые были с момента последнего коммита.
Файлы готовы для коммита, поэтому командой делаем коммит.
Коммит сделан, но пока он находится только на локальной машине, а нам надо его отправить в форк, чтобы в дальнейшем предложить Pull Request.
Для того, чтобы отправить воспользуемся командой . Так же в этой команде нам надо указать куда мы отправляем и в какую ветку.
Если ввести команду консоль покажет все доступные удаленные репозитории. По умолчанию там будет один репозиторий — . Это название по умолчанию для нашего форка. В него то нам и надо отправить изменения.
Если дословно, то отправь изменения в форк (origin) в ветку module1-task1 (если такой ветки нет в форке, git создаст её)
Заходим в форк на GitHub и видим, что ветка появилась. Но в ветке изменений нет. Все верно, поскольку мы работали в ветке , там-то изменения как раз есть.
Ветка master:
Ветка module1-task1:
Теперь создаем Pull Request из ветки нашего форка в ветку нашего мастер-репозитория (академии).
Git — графическое представление ветвей (branches)
Система Git имеет в своем составе возможность графического представления ветвления в репозитории. Причем, такое представление можно сделать даже в консоли, с помощью псевдографики.
Это можно сделать, набрав в консоли команду:
На Stack Overflow я нашел примеры красивых изображений консоли с псевдографическим выводом команды :
На самом деле вариантов использования команды с ключом бесчисленное множество. Поэтому нужно выбирать именно то, что нужно и нравиться именно вам.
Помимо псевдографики, ветви в Git можно визуализировать с помощью настоящего графического приложения. Под Mac OS X и Linux имеется достаточно большое количество таких приложений. Например, под Mac OS X это GitX, под Linux — Gitk или Gitg:
Git fetch
Команда соединена с удаленным репозиторием, берет все изменения и сохраняет их локально. При клонировании репозитория, команда автоматически добавляет удаленный репозиторий под названием . Следственно, вынимает материал, отправленный на сервер после клонирования.
Синхронизация с командой git fetch origin
Чтобы рассмотреть процесс синхронизации локального репозитория с основной веткой, используется команда .
Это отобразит ветки, которые уже были загружены:
ale8fb5..45e66a4 main -> origin/main ale8fb5..9e8ab1c develop -> origin/develop * some-feature -> origin/some-feature
Создание новой ветви в командной строке
Программа Git в командной строке предлагает максимальную мощность и гибкость, но есть чему поучиться. Если вам удобно копаться в man-страницах и активно использовать Git, это отличный вариант.
Используйте команду git branch <branchname>, чтобы создать новую ветку с заданным именем:
Это ответвление от текущей ветви, поэтому убедитесь, что вы переключились на ту, от которой хотите перейти, прежде чем выполнять эту команду.
Вы можете перечислить все ветки и подтвердить, что новая была создана, с помощью git branch без каких-либо аргументов:
Вы можете увидеть дополнительную информацию, в том числе, какую ветвь отслеживает другая, используя флаг -vv :
Если вы попытаетесь создать ветку до первой фиксации, вы получите сообщение об ошибке, например:
Если вы попытаетесь создать ветку с уже существующим именем, вы получите сообщение об ошибке, например:
Команда git branch создает новую ветку, указывающую на тот же коммит, над которым вы сейчас работаете. Однако ваша рабочая копия по-прежнему будет указывать на основную ветку. Чтобы переключиться на новую ветку, которую вы только что создали, используйте git checkout :
Термин « проверка» может сбивать с толку, если вы привыкли к другим системам контроля версий; в Git проверка относится к переключению текущей активной ветки. Поскольку вы обычно хотите переключиться на новую ветку после ее создания, для всего процесса есть ярлык:
Эта команда означает «создать новую ветку под названием« dev »и немедленно переключиться на нее». Это эквивалент:
Фактически, вы даже можете использовать git checkout для создания ветки из любой другой, а не только из той, которая в данный момент проверена. Например, чтобы создать новую ветку с именем another , из ветки с именем dev :
Что Такое Ветка Git?
Git — это распределённая система контроля версий (DVCS), в которой все члены команды имеют доступ к полной версии проекта. Её главная задача — помогать в управлении проектам, сделать процесс разработки эффективным, гибким и безопасным.
Ветки — это отдельные линии развития вашего проекта. Они позволяют работать параллельно с master веткой, при этом не влияя на неё. Когда же ваша часть кода готова, вы можете выполнить слияние, или мерж.
Ветвление Git позволяет создавать, удалять и смотреть другие ветки. Кроме того, ветка действует как указатель на моментальный снимок изменений (snapshot), которые вы внесли или хотите внести в файлы проекта. Это полезно в ситуациях, когда вы хотите добавить дополнительную функцию или устранить баг.
Ветка не только инкапсулирует изменения, но также гарантирует, что нестабильный код не попадёт к файлам основного проекта. Как только вы закончите обновлять код в ветке, вы сможете смержить изменения в ветку master.
