LINUX.ORG.RU

Git 2.3.0

 


0

3

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

Push to deploy

Один из способов развёртывания веб-приложений из Git — хранение рабочей копии на сервере. Когда появляется новая версия, на сервере исполняется git pull. С Git 2.3 это стало ещё более удобным.

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

$ git config receive.denyCurrentBranch updateInstead

Более быстрое клонирование путём заимствования объектов из существующих клонов

Клонирование удалённого репозитория может привести к передаче больших объёмов данных. Но если имеется склонированный из этого же хранилища локальный репозиторий, вероятно в нём уже находится большая часть истории. Можно снова использовать объекты этого репозитория, вместо того, чтобы скачивать их из удалённого:

$ git clone --reference ../oldclone --dissociate https://github.com/gitster/git.git

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

Консервативное поведение по умолчанию для git push

Если выполнить git push без аргументов, git будет вести себя более по-старому. Текущая ветка не будет отправляться, пока для неё не будет создана ветка с таким же названием в удалённом репозитории.

Пример:

$ git config branch.autosetupmerge true
$ git checkout -b experimental origin/master
Branch experimental set up to track remote branch master from origin.
Switched to a new branch 'experimental'
$ git commit -a -m 'Experimental changes'
[experimental 43ca356] Experimental changes
$ git push
fatal: The upstream branch of your current branch does not match
the name of your current branch.  To push to the upstream branch
on the remote, use

    git push origin HEAD:master

To push to the branch of the same name on the remote, use

    git push origin experimental

Новое поведение призвано помочь пользователям избежать случайной отправки изменений в неверную ветку. Это можно изменить с помощью опции push.default. Чтобы вернуться к поведению версии 1.x нужно выполнить: git config --global push.default matching

Напоминаем: В декабре прошлого года в Git была исправлена критическая уязвимость. Рекомендуется обновить свой Git клиент как можно быстрее. Новый выпуск 2.3.0 включает в себя это исправление. Оно также доступно в следующих версиях: 1.8.5.6, 1.9.5, 2.0.5, 2.1.4.

>>> Подробности

★★★★★

Проверено: toney ()
Последнее исправление: cetjs2 (всего исправлений: 4)

В какой версии гита push/pull будут выполнять симметричные действия?

anonymous
()

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

Кто на ком стоял?

anonymous
()

Один из способов развёртывания веб-приложений из Git — хранение рабочей копии на вашем сервере.

Интересно, а где-то еще есть аналоги эрланговых релизов?

loz ★★★★★
()

Push to deploy

Я правильно понимаю, что если я из машинки А запушил изменения на сервер, а еще есть машинка Б, в которой настроена работа с сервером и там нет никаких локальных изменений. То оно автоматом сделает «git pull»?

alarm
()

Консервативное поведение по умолчанию для git push

Назад вернули что-ли?

Klymedy ★★★★★
()

OpenNet 06.02.2015 10:36 Выпуск распределенной системы управления исходными текстами Git 2.3.0


LOR 06.02.2015 10:15:14 Git 2.3.0

ЛОР победил?

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 3)

А кэмелКэйсПрямОбязателенВПараметрах?

А вообще, всеми этими доп.опциями будет пользоваться максимум 1% пользователей. Усложняют систему без нужды.

d9d9 ★★★★
()
Ответ на: комментарий от alarm

Git обычно запрещает делать push в текущую ветку non-bare репозитория. Получаем сообщение об ошибке вида:

remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.
remote: error:
remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error:
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.

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

До этого с помощью receive.denyCurrentBranch можно было либо проигнорить это, либо запретить. Теперь ещё можно и автоматом обновить рабочий директорий, если локальных изменений нет.

https://github.com/git/git/commit/72ecc6ef53cb2906f5efab11fa6ab26c1729f233

Kilte ★★★★★
() автор топика

git это <3

anonymous
()
   "git push" into a repository with a working tree normally refuses
   to modify the branch that is checked out.  The command learned to
   optionally do an equivalent of "git reset --hard" only when there
   is no change to the working tree and the index instead, which would
   be useful to "deploy" by pushing into a repository.

я джва года это ждал!

waker ★★★★★
()

Когда появляется новая версия, вы входите на сервер и запускаете git pull

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

thriller ★★
()

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

sehellion ★★★★★
()

Более быстрое клонирование путём заимствования объектов из существующих клонов

Я джва года ждал эту фичу!

gentoo_root ★★★★★
()
Ответ на: комментарий от Kilte

Товарищ Румпельштильцкхен, а почему вы говорите «рабочий директорий», если слово «директория» женского рода и не существет слова «директорий» мужского рода?

mva
()

Один из способов развёртывания веб-приложений из Git — хранение рабочей копии на вашем сервере.

Git хранит не только рабочую копию, но и репозиторий. Если там нужна только рабочая копия - для этого есть rsync.

anonymous
()

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

А если ещё веселее: локально есть исходники, полученные в zip'е, но при этом нет системных файлов .git/* - гит сможет создать репу локально и подцепить существующие файлы?

matumba ★★★★★
()
Ответ на: комментарий от Harald

ага, сначала оно его запакует в архив, чтобы потом тут же распаковать

Какие то несерьёзные проблемы. Ну сделай git archive | tar -x. Сколько там лишней работы. Сколько делал svn export, всегда потом результат запаковываешь, чтобы отправить куда надо.

Legioner ★★★★★
()
Ответ на: комментарий от alarm

Я правильно понимаю, что если я из машинки А запушил изменения на сервер, а еще есть машинка Б, в которой настроена работа с сервером и там нет никаких локальных изменений. То оно автоматом сделает «git pull»?

Неправильно.

Legioner ★★★★★
()

Более быстрое клонирование путём заимствования объектов из существующих клонов

yo developers I heard you like clones so we put a clone in yo clone so you can clone while u clone

sT331h0rs3 ★★★★★
()
Ответ на: комментарий от matumba

нет, git это прежде всего история, а потом уже исходники

thesame ★★★★
()

Ставить на сервер Git для развёртывания - это как покупать смартфон вместо будильника.

anonymous
()
Ответ на: комментарий от matumba

А если ещё веселее: локально есть исходники, полученные в zip'е, но при этом нет системных файлов .git/* - гит сможет создать репу локально и подцепить существующие файлы?

git init
git add .
git commit -m «Init commit»

Ritmik
()
Ответ на: комментарий от Harald

А чем не угодил чекаут?

git --git-dir=/path/to/repo.git --work-tree=/path/to/checkout checkout -f $revision
alex_ac
()

побежал переводить проект с svn на git!!!

bornbewild
()
Ответ на: комментарий от Kilte

А зачем вообще пушить в non-bare репозиторий? Юзкейс какой-то не очень понятный.

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

anonymous
()
Ответ на: комментарий от anonymous

Ага, кажется понял. Походу это такой Continuous deployment для бедных.

anonymous
()

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

$ git config receive.denyCurrentBranch updateInstead

а дальше что нужно сделать?

можно пополнее инструкцию?

----------

означает ли это что теперь на сервере нет необходимости делать git pull \ git rebase (оно делается автоматически, какбэ?) ? или я не так понял?

user_id_68054 ★★★★★
()
Последнее исправление: user_id_68054 (всего исправлений: 3)
Ответ на: комментарий от Kilte

погоди, погоди, но если я запушу (предположим у меня получится) в не-bare-репозиторий,

то ведь всё равно на сервере придётся выполнять команду git checkout (например git checkout master ) .. ну чтобы распаковать файлы в читаемый вид?

настройка receive.denyCurrentBranch=чтототам  — избавляет нас к тому же ещё и от git checkout master ?

user_id_68054 ★★★★★
()
Последнее исправление: user_id_68054 (всего исправлений: 1)
Ответ на: комментарий от user_id_68054

избавляет нас к тому же ещё и от git checkout master ?

Да

Kilte ★★★★★
() автор топика

Если выполнить git push без аргументов, git будет вести себя более по-старому.

Здесь точно нет опечатки? Такое ощущение, что чего-то не хватает.

vitalikp
()

множество улучшений

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

vitalikp
()

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

Как только не извращаются, лишь бы не делать докачку.

O02eg ★★★★★
()
Ответ на: комментарий от mva

...говорите «рабочий директорий», если слово «директория» женского рода и не существет слова «директорий» мужского рода...

И как только люди не извращаются, чтобы не писать «каталог».

hobbit ★★★★★
()

вести себя более по-старому

Кого-то шаман покусал.

Akamanah ★★★★★
()
Ответ на: комментарий от hobbit

А люди говорят «папка». В контексте «файлов» это более корректный термин, потому что все видели файлы и все видели папки с файлами. А что такое каталог и как он связан с файлами, это большой вопрос.

Legioner ★★★★★
()

Постепенно перестал пользоваться Mercurial в пользу Git. К сожалению. Уже привычнее стало. Но какая же это всё-таки каша! Как попало слепленные куски с невменяемым UI... даже жаль, что это уже де факто стандарт.

amix ★★★
()
Ответ на: комментарий от Legioner

Сколько делал svn export, всегда потом результат запаковываешь, чтобы отправить куда надо.

Часто делаю git archive и далее через rsync. Поэтому флаг для обхода упаковки могли бы и добавить

kiotoze ★★★★
()

быстро же он в арч прилетел

kiotoze ★★★★
()
Ответ на: комментарий от Legioner

«Папка» говорят не люди, а виндузло необразованное. Папка - это элемент интерфейса. То что на файловой системе - каталог или директория, но никак не папка.

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

Куда папка засовывает свое файло называется мамка.

Lucky ★★
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от Legioner

Не надо тут. Я вот папку своего отродясь не видел. Зато видел консоль с командной оболочкой, а в ней — католог файлов, всегда можно ознакомиться если нужную команду ввести. Ещё видел здоровенные талмуты с листиками. Почему их, листики эти никогда так не называли, а с появлением Венды вдруг опомнились — да это же fиlеs!, вот это вопрос так вопрос.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.