LINUX.ORG.RU

git workflow


0

1

Есть удаленный реп.

Делаю:

git clone
git branch new-stuff
git checkout new-stuff
git add .
git commit -c "New stuff here"
git checkout master
git merge new-stuff
git pull
git push

Так вот при git push ругается:

malyk@vladimir-malyk:/tmp/tmpppp/master$ git push
repository@192.168.0.204's password: 
Counting objects: 7, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 422 bytes, done.
Total 4 (delta 2), reused 0 (delta 0)
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'.
To repository@192.168.0.204:/home/repository/SkyNet/master
 ! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to 'repository@192.168.0.204:/home/repository/SkyNet/master'

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

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

★★★★★

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

> The one-line summary: push into a remote repository that has a detached work tree, and a post-receive hook that runs «git checkout -f».

прелесть то какая, я уж думал что придется на каждый чих мержить руками

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

Да нет, просто делаешь пуш, и на сервере поднимается последняя версия

xorik ★★★★★
()
$ ssh repository@192.168.0.204
$ cd /home/repository/
$ mv SkyNet SkyNet.old
$ mkdir SkyNet && cd SkyNet
$ git init --bare
Jetty ★★★★★
()
Ответ на: комментарий от maxcom

Потому что сырцы мастер ветки с сервера раздаются еще и по NFS - то есть должны присутсвовать как файлы. Мы пилим некий фреймворк, который суть множество классов, разбросанные по каталогам. Эти каталоги я раздаю по NFS. И если кому-то нужно запилить какойнить проект с использованием фреймфорка - он делает в каталоге своего проекта симлинки на подмонтированные nfs шары. Профит в том, что дев постоянно получает актуальные файлы фреймворка, но при этом у него сохраняется возможность заменить nfs-ные симлинки на симлинки, кот смотрят в его локальный git репозиторий фреймворка (напр если он фреймворк дорабатывает).

В итоге получается фреймворк со своей сторией коммитов, и куча проектов вокруг него (для продакшина или юнит тестинга) со своими историями.

зы. хочу добавить что работа в таком режиме не очень задаилась. возможно, действительно запилить на серве bare репозиторий, а у девов пара локальных репозиториев - один для предоставления по симлинкам продакшн веток, второй для предоставления собственных dev веток фреймфорка. либо я вообще выбрал в корне неправильный workflow.

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

> он делает в каталоге своего проекта симлинки на подмонтированные nfs шары

Не проще ли делать обычный clone (через submodules, например)?


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

Ага, и этот процесс он не контролирует. Вот будет весело, когда очередное обновление фреймворка сломает совместимость с текущим кодом разработчика.

Имхо, лучше не использовать подобные танцы с NFS - можно больно удариться об угол.

Впрочем, если хочется продолжать, то вполне возможен вариант с двумя репозиториями. Один (bare) используется для push-ей, второй (не-bare) делает пуллы из него (по cron или через хуки) и раздаёт файлы по NFS. На хабре недавно статья была по похожему flow

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

>И если кому-то нужно запилить какойнить проект с использованием фреймфорка - он делает в каталоге своего проекта симлинки на подмонтированные nfs шары.
Ну это просто tripledacepalm. А поднять локальный Archiva и использовать фреймворк как зависимость не? В очередной раз убеждаюсь, как далеко вперед java ушла от говноязыков с говнотулзами и говнопроцессом разработки. Ужас, просто тихий ужас у вас творится. Скажите название конторы, чтобы не дай бог не попасть.

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

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

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

> А поднять локальный Archiva и использовать фреймворк как зависимость не?

яничегонепонял. поясни мысль.

в целом сабж это попытка раздать в несколько рук то, что раньше писали в одно лицо, со всеми вытекающими проблемами роста. к тому же пишем на плюсах - на том оборудовании кот будет внедряться java is not an option at all

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

это какая-то странная попытка заменить git'ом средства для развертывания и dependency management.

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

Archiva это правильное направление, но я никогда не видел чтобы использовали maven не в Java-окружении

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

>к тому же пишем на плюсах
тогда простите, удаляюсь из треда. Про си ничего не знаю.

JFreeM ★★★☆
()

Как бороть?

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;
kim-roader ★★
()
Ответ на: комментарий от kim-roader

пишут что это чревато - в текущей ветке и номинально на фс будут разные версии болтаться

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

> я никогда не видел чтобы использовали maven не в Java-окружении

Используют, я видел.

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