Чому я можу перевірити гілку, видалену на GitHub?

26

У нашому сховищі GitHub співробітник видалив гілку з назвою release. Але коли я біжу git checkout releaseлокально, я завжди отримую видалену гілку release. Те саме, навіть коли я перевірив іншу гілку, видалив releaseгілку git branch -D releaseі знову побіг git checkout release.

Чи потрібно щось виправити у сховищі GitHub, або я мушу щось виправити локально?

git

— Тім
джерело

1

Що дає git branch --remoteрезультат після запуску git fetch? Можливо, вам доведеться обрізати, git fetch -pщоб забути видалені віддалені гілки.

— Стівен Кітт

2

Якщо ця гілка коли-небудь була висунута до GitHub, і ви потягнули за цим, то у вас є і копія гілки. Кожне сховище git є повноцінне саме по собі, якщо ви не використовували дрібний клон чи щось таке.

— muru

@StephenKitt: Дякую git branch --remoteвихід origin/release. Ви хочете запустити git fetch -pбез додаткових аргументів, і чи обріже всі видалені віддалені гілки?

— Тім

1

Так, git fetch -pбез додаткових аргументів обрізати всі видалені віддалені гілки.

— Стівен Кітт

1

Ласкаво просимо у світ управління розподіленими версіями!

— chrylis -на страйк-

24

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

$ git branch -a
[...]
release
remotes/origin/release
[...]

Ви видалили лише "реліз", але не "видаляє / початок / випуск". Видаліть його так:

$ git branch -rd origin/release

Або видаліть усі отримані гілки, які вже не існують на віддаленій стороні:

$ git remote prune origin

— rudimeier
джерело

Спасибі. В git branch -rd origin/release, що -rозначає? Чи -dозначає те саме, що -D? Можна git branch -rd origin/releaseзамінити git branch -d remotes/origin/release?

— Тім

@Tim: З посібника; -r: List or delete (if used with -d) the remote-tracking branches.; -D:Shortcut for --delete --force.

— петля

Спасибі. Можна git branch -rd origin/releaseзамінити git branch -d remotes/origin/release?

— Тім

@Tim не -rстосується віддалених гілок, це потрібно. Місцеві та віддалені відділення зберігаються в різних каталогах, порівнюють ls -l .git/refs/headsі ls -l .git/refs/remotes. Ви могли б також мати місцеве відділення під назвою , remotes/origin/releaseяке було б без видалення -r. Це може здатися заплутаним, але ви можете просто пограти, створити гілки з дивними назвами і подивитися, як це виглядає .git/.

— rudimeier

15

Коли гілки видаляються віддалено, вам потрібно обрізати локальний сховище - це найпростіший спосіб зробити це

git fetch -p

Це оновить ваше локальне сховище з усіма змінами, внесеними до віддаленого сховища, але без оновлення будь-якого з ваших локальних відділень. Виконавши це,

git branch --remote

більше не відображатиме видалену віддалену гілку.

репозиторії git є повноцінними, як у вашій власній системі, так і на сервері. Отже, коли ви вперше клонуєте сховище, ви отримуєте повну копію, і ваш місцевий git "знає" про всі віддалені гілки, а також про ваші місцеві відділення. Ця інформація не синхронізується автоматично, тому коли ваш колега видалив releaseгілку на сервері, ваше місцеве сховище git не втратило поняття про віддалену releaseгілку. Синхронізація з git fetchоновленнями всієї локальної інформації на віддалених гілках, щоб вони відповідали стану на сервері (строго кажучи, віддаленому сховищі, де б це не було), але не видаляючи локальної інформації на віддалених гілках. Обрізка git fetch -p(або git fetch --prune, або git remote prune) видаляє локальну інформацію про віддалені гілки, які були видалені.

— Стівен Кітт
джерело

Спасибі. "оновіть своє місцеве сховище усіма змінами, внесеними до віддаленого сховища, але не оновлюючи жодної з ваших локальних гілок". Що це за оновлення, враховуючи, що це не оновлення моїх місцевих відділень?

— Тім

Це все віддалені оновлення. У вашому локальному сховищі git розрізняють ваші локальні гілки та віддалені гілки, але віддалені гілки не магічно синхронізовані з сервером - вони існують і локально (як у, зберігається у вашому локальному сховищі git). Вилучення синхронізує ваше локальне сховище з віддаленим сховищем та оновлює стан віддалених гілок; за замовчуванням видалені віддалені гілки не видаляються з локальної інформації на віддалених гілках, -p( --prune) примушує це.

— Стівен Кітт

Спасибі. Чому не видалили releaseгілку git branch -D releaseдо git checkout releaseтого, як git checkout releaseзупинити її отримання release?

— Тім

1

Тому що git checkout releaseавтоматично відновлюється гілка, якщо є віддалена гілка з цим іменем.

— Стівен Кітт

Під "віддаленою гілкою" ви маєте на увазі гілку в моєму локальному сховищі або сховищі Github? Якщо раніше git branch -D releaseвона вже видалила releaseгілку в моєму локальному сховищі; Якщо останнє, співробітник видалив releaseгілку на GitHub; Тож я все ще не впевнений, чому "автоматично відновиться гілка, якщо є віддалена гілка з такою назвою"?

— Тім

3

Тім: Git поширюється на VCS, тому коли ви клонуєте репо з віддаленого до локального, він закриває все (історію). Тож, коли ви клонували репо, у нього було відділення, яке називалося випуском. Оскільки ваш колега видалив відділення випуску віддалено, доки ви не зробите чорнослив git fetch -pчи не видалите цю гілку, ваша локальна матиме цю гілку.

— ManiVI
джерело

3

Чим ця відповідь відрізняється від відповідей, які вже є?

— Стівен Рауч

1

Можливо, трохи дотична, але перспектива цього веб-сайту може допомогти зрозуміти загальну тему видалення гілок:

http://railsware.com/blog/2014/08/11/git-housekeeping-tutorial-clean-up-outdated-branches-in-local-and-remote-repositories/

Тут перетинається деяке з того, що вже обговорювалося, але в центрі уваги робиться ведення господарства: видалення гілок, віддалених та локальних, які більше не потрібні в умовах спільної роботи. Зокрема, git branch --mergedкоманда визначає гілки, які безпечно видалити через об'єднання з вашою основною лінією (або будь-якою вашою гілкою). Якщо ви співпрацюєте, деякі модні міні-сценарії на зразок цього представлять речі у приємному, засвоюваному форматі з датами та авторами.

for branch in `comm -12  <(git branch --merged|awk '{print($1)}') <(git branch -r --merged|awk '{print($1)}'|awk -F \/ '{print($2)}')`; do echo -e `git show --format="%ci %cr %an" $branch | head -n 1` \\t$branch; done | sort -r

(На жаль, "приємне, засвоюване" не стосується форматування самих сценаріїв.)

— B Шар
джерело