Версия для печати темы

Автор: Litkevich Yuriy 26.1.2010, 19:49

Тут можно потрепаться на эту тему.
Хотя впрочем преимущества Git'а для меня, УЖЕ, стали очевидны. Помимо самой, нормальной, идеи веток и меток. Обнаружил ещё одно существенное преимущество Git'а - компактность хранилища.

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

SVN-Зеркало весит = 544 649 КиБ
Его Git-клон весит = 144 680 КиБ
т.е. более чем в 3,5 раза меньше.

Автор: Kagami 26.1.2010, 20:39

У git'а проблемы с докачкой...

Автор: Litkevich Yuriy 26.1.2010, 20:45

пока не напарывался.
Однако скорость git svn fetch заметно медленее чем svnsync (обновление зеркала SVN'а), я думаю, это из-за того, что git-svn - это Perl-сценарий, а не бинарь, как svnsync

Автор: Tonal 27.1.2010, 9:04

У git-а под виндой с русскими названиями файлов полная труба.
Опять же где-то читал, что текст в кодировках utf-16, utf-32 он воспринимает как бинарь...
Но скорость, распределённость и удобство ветвлений всё покрывают!

Автор: Litkevich Yuriy 27.1.2010, 10:28

у меня есть единственный файл - misc/протокол_Микродат.txt, проблемы ни какой не заметил

Автор: azure 27.1.2010, 13:17

и в чем же суть проблемы? может, это проблемы сети, что килобайтная дельта не может быть передана без обрывов? Ну и git fsck никто не отменял

Автор: Iron Bug 27.1.2010, 14:25

пока меня и svn устраивал всегда...
а в чём особое удобство ветвлений в git?
вот у меня, к примеру, есть куча кода. много чего в юникоде. бинарники, естессна, не складываю в контроль. свои исходники и папки на компе никогда по-русски не называю.
но есть задача, к примеру: надо поковырять там, поковырять тут, а потом слить обе версии, если и то и другое получилось. либо одну откатить, а вторую объявить основной.
ещё бывает, что надо найти все изменения с какой-то конкретной даты.
в git'e это удобно сделано?

Автор: Litkevich Yuriy 27.1.2010, 15:41

по сравнению с Git'ом в SVN'е это вообще никак не сделано.

на мой нынешний взгляд, SVN у Git' пока выигрывает за счёт интуитивного GUI, Git-gui и Git-tk довольно кривые и неуклюжие

попробую рассказать на примере.
Ветки существуют двух типов:
1) Ветка сопровождения
2) Функциональная ветка
Первая нужна для сопровождения минорных версий программы
Вторая - для эксперементов и т.д.

Теперь рабочий цикл по первому типу веток - Ветка сопровождения:
1) Принимается решение о выпуске новой версии программы, допустим v1.1.0
SVN:
a) trunk копируется в branches с новым именем v1.1.x - это ветка сопровождения;
b ) вновь созданный каталог branches/v1.1.x копируется в tags с именем v1.1.0 - это метка
c) фиксируются изменения в хранилище.
Итого имеем два дубля trunk'а (ну что-то там с экономится сожмётся..., это и так понятно)

GIT:
a) на текущем состоянии ветки master (аналог trunk) делается новая ветка (по сути получается пометка) именем v1.1.x - это ветка сопровождения;
b ) на этойже ветке (v1.1.x) создаётся метка с именем v1.1.0 - это метка (в git'е, метка - просто именованное состояние)
Итого, ничего не фиксируется, только на каждое из перечисленных двух действий создаются служебные записи в хранилище (в Git'е оно локальное)

Идём дальше, исправление ошибок

Работаем над основной веткой (trunk/master).
Предположим, что приняли сообщение об ошибке в выпуске v1.1.0, от пользователя.
Нашли ошибку в ветке сопровождения, исправили. Далее:
SVN:
1) зафиксировали изменения (исправление ошибки) в хранилище (ветка v1.1.x)
2) копируем branches/v1.1.x в tags с именем v1.1.1 - это новая метка (предположим, что сразу выпускаем заплату не накапливая)
3) фиксируем изменения
4) сливаем текущее состояние ветки branches/v1.1.x в trunk (чтобы в главной ветке тоже было исправлено)

GIT:
1) зафиксировали изменения (исправление ошибки) в хранилище (ветка v1.1.x), с этого момента в хранилище появляется фактическая ветка которая содержит diff относительно точки ветвления
2) на этойже ветке (v1.1.x) создаётся метка с именем v1.1.1 (это по прежнему просто именованное состояние)
3) ---
4) сливаем текущее состояние ветки branches/v1.1.x в master (чтобы в главной ветке тоже было исправлено)

Итого ручной работы минимум, дубликатов минимум, а слияние в Git'е более наглядное/интуитивное.
Плюс Git отслеживает не только перемещения файлов по каталогам, но и функций из одного файла в другой (когда такое обнаруживается можно увидеть соответствующую пометку вместо полного diff'а)

Теперь рабочий цикл по второму типу веток - Функциональная ветка:
Необходимо провести эксперимент, нужно создать ветку от главной
SVN:
1) trunk копируется в branches с новым именем foo - это функциональная ветка;
2 ) рабочая копия переключается на эту ветку (опционально, зависит от стратегии работы с рабочей копией)
3) делаются изменения, фиксируются в хранилище (многократно).
4) Принимается решение на слияние, осуществляется слияние
5) фиксируются изменения
6) функциональная ветка удаляется за не надобностью
7) фиксируются изменения
Итого имеем уже не нужную ветку в истории хранилища (оно пухнет)

GIT:
1) на текущем состоянии ветки master (аналог trunk) делается новая ветка именем foo - это функциональная ветка;
2 ) рабочий каталог переключается на эту ветку (обязательно)
3) делаются изменения, фиксируются в хранилище (многократно).
4) Принимается решение на слияние, переключают рабочий каталог на master
5) осуществляется слияние выбранной ветви (из списка ветвей) с master'ом (история правок самой функциональной ветви копируется при слиянии)
6) функциональная ветка удаляется за не надобностью
7) запускам сборщик мусора git gc, после этого удалённые ветви не востановить, т.к. они полностью удаляются из хранилища (опционально)
Итого, функциональные ветви, как коротко живущие можно полностью удалять из хранилища. А так как фнкциональные ветки явление частое и, можно сказать, основное, то они вносят наибольший вклад в вес.
Сверх того, отсутствие или перебои связи на твою работу вообще никак не влияют.

Автор: Iron Bug 27.1.2010, 20:36

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

Автор: Litkevich Yuriy 27.1.2010, 21:03

Я не сказал, но это может быть важно, Git в сравнении с SVN:
1)
В Git'е есть понятия веток и меток, это сущности встроенные в сам Git.
В SVN'е нет такого понятия, это человек для себя определил, что вот в этом каталоге я буду складывать копии другого каталога, например trunk. Т.е. понятие веток реализуется самим человеком.

2)
В Git'е версионному контролю подлежат только файлы, по сути он следит только за полным именем файла и изменением пути в этом полном имени.
В SVN'е под контроль версий можно добавлять и каталоги.
(попользовавшись Git'ом у меня на корню испарилась нужда добавлять под контроль версий каталоги)

3)
Я, до сих пор, не нашёл способа экспортировать правку/файл из Git-хранилища в произвольный каталог.
В SVN'е это делается элементарно.

4)
Git'у не принципиальны такие понятия, как переименование/копирование файла. При обнаружении изменений он показывает % соответствия одного файла другому, например так:

Т.е. на практике нужды в ручном (версионированном) переименовании, как в SVN'е, нет.

Вот снимок окна gitk:

Здесь жёлтенькие ярлычки - это метки (имена)
Зелёненькие - ветки (имена)
Ярлычки содержащие бледно красный текст "remotes/..." - это ветки/метки во внешнем хранилище, когда я принимаю из внешнего хранилища данные, то они не мешают основным, но я могу их в любой момент слить в нужную локальную ветку, или сделать от них (в любом их месте) новую локальную ветку.


П.С. это SVN-хранилище клонированное с помощью git-svn

Автор: Tonal 28.1.2010, 8:18

И меня подобных много - клиенты присылают документы с русскими названиями.
Все они при импорте из svn стали называться как-то так (цифры от болды):
\x56\x98\x21\x74\x54.doc
Это на винде. На Linux-е проблем действительно нет.


В смысле из удалённого репа выдернуть файлы без образования рабочий копии?
Если реп локальный, то вроде как просто копируешь нужное в нужный каталог...
Ну ежели часто нужно, можно и скриптик написать - будет выдёргивать нужное и складывать куда указал - git`е ведь всё напрочь скриптуется.

Автор: Litkevich Yuriy 28.1.2010, 11:41

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

а где ты такие имена видишь?

Автор: igor_bogomolov 28.1.2010, 11:57

git show дает возможность просмотреть тебе любой файл из любой ревизиий любого бранча. Что мешает перенаправить этот поток в нужное тебе место.

Автор: Iron Bug 28.1.2010, 12:18

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

Автор: Litkevich Yuriy 28.1.2010, 14:23

одним файлом, т.е. там могут быть кучи файлов из разных каталогов

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

Почему это не удобно:
если проект большой, то после возвращения к основному состоянию (например, HEAD master), мне придётся пересобирать весь проект, т.к. файлы изменились. Вроде можно Git'а заставить корректировать дату изменения файла, но пока я в этом направлении не экспериментировал.

Если ещё учесть то, что я пользуюсь qmake и не использую shadow build (теневую сборку, т.е. сборка в отдельном каталоге как обычно делается в CMake). То извлекая некое состояние и собирая его, потом, вернувшись к основному, мне всё равно придётся всё пересобирать, т.к. объектники чужие.



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

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

Автор: Iron Bug 28.1.2010, 15:37

вот невозможность извлечь версию в любое место меня напрягает.
вообще, пока я вижу, что самая всё-всё-всё умеющая реализация сорц-контроля - это IBM/Rational ClearCase. но это монстр, неудобный для домашнего содержания. и интерфейс у него крайне специфический. однако, вот там было вообще всё, о чём можно мечтать и ещё куча мелких фич, даже непонятно зачем вообще существующих. я с ним работала на одной работе. в общем, замечательная штуковина, если привыкнуть к странному интерфейсу (впрочем, у IBM он часто весьма загадочен).

Автор: Kagami 28.1.2010, 16:08

Можно придумать небольшой костыль по извлечению определенной ревизии в определенное место:
1. Переходим в нужное место.
2. Делаем git clone /path/to/repo (минус: появляется еще одна поддиректория repo)
3. Заходим в эту директорию
4. Делаем git checkout нужная_ревизия
5. Удаляем папочку .git (так как она одна, то не нужно лазить по всей структуре каталогов как в svn)
6. ???
7. PROFIT!

При желании это легко скриптуется на любом удобном языке.

Автор: igor_bogomolov 28.1.2010, 16:29

Есть вариант попроще

git archive --format=tar HEAD^ | (mkdir -p test && cd test && tar xf -)

man git-archive

Как делать патчи тоже нашел
man git-format-patch

Автор: AD 28.1.2010, 17:29

Git(ом) не пользовался, а вот SVN-ом пользуюсь. Но посмотрев Юрины картинки интерфейса Git(а), испугался. Уж какой-то он мудреный! Юра об этом уже упоминал, но все-таки. Собственно такой вопрос: если основными действиями, которыми я занимаюсь с SVN - это:

• commit(выложить в хранилище обновленную версию)
• update(взять версию из хранилища)
• регистрация проекта в хранилище
• сравнение файлов
• откат до какой-либо старой версии

Юра, можешь рассказать, судя по тем простым действиям, что совершаю с хранилищем, как Git улучшит, поможет в этих действиях? И, пожалуйста, поясни по поводу веток и меток: я не очень понял, как так, что в Git нет регистрации каталогов, а только файлов?

Автор: Litkevich Yuriy 28.1.2010, 18:28

ни как. Описанное тобой, больше напоминает процесс работы с простыми текстовыми файлами, а не разработку программ (тут без веток ни как)

Автор: AD 28.1.2010, 18:30

Каких именно программ? Прости, что туплю....

Автор: Litkevich Yuriy 28.1.2010, 18:32

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

любых

Автор: AD 28.1.2010, 18:36

Аа. Понял. У нас этим другие люди занимаются. Мы просто фиксируем какую-то версию. А дальше - дело других людей. Стянуть из других проектов нужные файлы получается либо копированием, либо update(ом). Функцией merge пользоваться не приходилось.

P.S. За разъяснение про файлы и каталоги - спасибо. Понял!

Автор: Litkevich Yuriy 28.1.2010, 18:46

я сейчас почти так и делаю, только не клонирую, а тяну сразу нужную ветку, например, ветка master из хранилища git://labs.trolltech.com/qt/all вытягивается так:

git init
git remote add origin git://labs.trolltech.com/qt/all
git pull origin master

Автор: Litkevich Yuriy 28.1.2010, 19:42

ещё один минус Git'а (на виндовозе! )
черз Git-GUI не смог прикрутить внешнюю программу сравнения (WinMerge)

Автор: Tonal 29.1.2010, 9:11

В проводнике и в фаре. Это известный старый http://code.google.com/p/msysgit/issues/detail?id=80-а.
Мой http://code.google.com/p/msysgit/issues/detail?id=318 посчитали его клоном.
Хотя последнее сообщение обнадёживает.

Автор: Litkevich Yuriy 29.1.2010, 15:09

Видимо всё таки не в проводнике а в Git Bash.
Вот у меня в проводнике:

А вот в Git Bash я просто немогу вводить не латиницу

П.С.
$ git --version
git version 1.6.3.msysgit.0

Автор: Tonal 1.2.2010, 9:30

И в Фаре, и в проводнике.
Ну да похоже таки починили - давно пробовал.

Сейчас текущая:
C:\Lang\Projects\Save\2003-09-15>git --version
git version 1.6.5.1.1367.gcd48
Сейчас в основном сижу под Kubuntu. Дойдут руки - потестю.

Таки косяки...:

C:\...Projects\Promsoft\filin\git_test>git svn clone svn://eol/filin/main/filin/Sankaran
Initialized empty Git repository in c:/Lang/Projects/Promsoft/filin/git_test/Sankaran/.git/
W: Ignoring error from SVN, path probably does not exist: (160013): Filesystem h
as no item: File not found: revision 100, path '/main/filin/Sankaran'
W: Do not be alarmed at the above message git-svn is just searching aggressively
 for old history.
This may take a while on large repositories
Checked Ahrough РЎР>Р?Р?Р°_С?С?С?.ods
        A       РЎР>Р?Р?Р°.mdb
        A       РЎР>Р?Р?аШаР?РєР°С?Р°Р?Р°.ods
r163 = ab153c0cfc3c33794f09aa1b05b73ac4ef6da5c5 (refs/remotes/git-svn)
r385 = cf4d6b272fbff0b5a5c2fb94210231939eb0bb77 (refs/remotes/git-svn)
r409 = abe7ec14912b73c6c1dc3eba2b21f230721990ed (refs/remotes/git-svn)
Checked out HEAD:
  svn://eol/filin/main/filin/Sankaran r409

C:\...Projects\Promsoft\filin\git_test>cd Sankaran
C:\...Promsoft\filin\git_test\Sankaran>

C:\...Promsoft\filin\git_test\Sankaran>dir
\320\241\320\273\320\276\320\262\320\260.mdb
\320\241\320\273\320\276\320\262\320\260_\321\200\321\203\321\201.ods
\320\241\320\273\320\276\320\262\320\260\320\250\320\260\320\275\320\272\320\260
\321\200\320\260\320\275\320\260.ods

C:\...Promsoft\filin\git_test\Sankaran>ls
??????????.mdb  ??????????_??????.ods  ????????????????????????????.ods

Как выглядит в Фаре и эксплорере:

..                │
.git              │
Слова.mdb    │
Слова_рус.}
СловаШанк}

Та же фигня, если через Баш пускать.
Реальные имена файлов в свине:
Слова.mdb Слова_рус.ods СловаШанкарана.ods

Автор: Litkevich Yuriy 1.2.2010, 15:02

Tonal, я здесь всё таки эксплорера не вижу, а только командную строку. Ну и Git-bash, да, он крив полностью. Но запусти Git-gui, там всё путём кодировка локальная учитывается.
Плюс я ещё переменные окружения заводил HOME - иначе с авторизацией на gitorius'е проблемы. И LANG, чтобы GUI был на русском.

Автор: Tonal 3.2.2010, 8:41

В экплопёре то же самое.
Такое впечатление, что git получает имена в utf8 и скармливает их без перекодировки в Ansi-шные WinApi функции работы с файлами...
Может нужно клонировать через Git-gui?
Ты как клонировал?

Автор: Litkevich Yuriy 3.2.2010, 11:54

обычно клонирую через консоль (GIT Bash).

Но при работе с флэшкой (как раз там в одном из проектов имя файла на русском) стал использовать такой подход:
в каталоге на флэшке делаю git init (в GIT Bash)
А потом через GIT GUI делаю pash из хранилища на стационарной машине во флэшку (предварительно добавив в ./git/config путь к хранилищу на флэшке).

П.С. в начале использования git'а иногда пользовался им от имени "Администратор", при этом в Documents and Settings создавался каталог с не читаемым именем. И Git никогда не запоминал настройки, видимо создать каталог он создал, а вот прочитать его не мог.
Потом завёл себе переменную окружения HOME и настроил её в каталог без кирилицы, Git стал хранить свои хахаряшки в нём. И всё стало нормально работать.

Автор: Litkevich Yuriy 1.4.2010, 16:52

тут обнаружил, что SVN теперь стал подпроект Апача:
http://subversion.apache.org/
на родном http://subversion.tigris.org/ так написано

Автор: Iron Bug 10.10.2010, 17:03

поставила я ради эксперимента GIT.
что сразу не понравилось: нет репозитория как такового: то бишь, фактически, нет защиты от самого себя: случайно удалил папку - и привет: все твои версии вместе с ней канули в Лету. это есть очень плохо. переносимость копированием папок - совсем мелкий плюс. а вот отстутствие защиты данных - это очень фигово. вариант решения: создавать репозиторий из-под другого юзера и коммитить от его имени, но крайне осторожно... но это гемор, в работе это неудобно. а другого я пока не придумала.
кроме того, не нашла ни одного приемлемого графического интерфейса для работы с ним пока что: те, которые есть, либо падают и дико не дружат с иксами (до падения некоторых фич экрана, хотя у меня экспериментальный деб с наворотами, может быть, от этого их пучит), либо слишком убоги и не дают никаких преимуществ по сравнению с работой из командной строки. а когда надо, например, закоммитить с полсотни файлов, то вручную это делать через текстовый редактор, снимая дурацкие комменты в файле коммита - это гемор. может, есть что-то приличное для гнома по управлению GIT'ом?
а так, в общем, пока особых плюсов не вижу. надо посмотреть на возможности ветвления. может, там что-то полезное есть...

Автор: igor_bogomolov 10.10.2010, 18:52

В качестве еще одного варианта, могу предложить поднять git server. Лучше на удаленном компьютере, например на том, где у вас сейчас стоит svn. Хотя можно и на локальном

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

У меня нет большого опыта использования svn, поэтому так подробно сравнить не могу. Одно знаю точно, git значительно удобнее при совместной разработке.

Автор: Iron Bug 10.10.2010, 19:00

я пока всё же останусь на SVN. привычнее, работа с большим количеством файлов организована удобней и нет риска запортачить весь свой труд случайно нажав не ту кнопку в каком-нить коммандере всё-таки один репозиторий легче контролировать, охранять и бэкапить, чем разбросанное по всему компу программное хозяйство. у меня и проекты, и сайты, и собственные патчи к стандартным библиотекам... всё это в разных местах и слить в одно нет никакой возможности. а репозиторий в одном месте и всегда можно за ним следить. мы разрабатывали совместно софт под SVN - никто вроде не жаловался. я тоже не вижу причин: там ещё и подкаталоги можно вытаскивать, а не весь проект. нафига весь проект тащить, если человек правит одну мелкую библиотечку, например? дело не в скорости доступа (по сравнению с разработкой это вообще ноль), а в удобстве и надёжности. в SVN я могу раздавать права для юзеров и следить, кто где напакостил, если проект вдруг покривел. в общем, мне всё же привычнее в SVN работать.

Автор: Kagami 10.10.2010, 20:57

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

Автор: igor_bogomolov 17.6.2011, 8:43

http://2byt.es/posts/1
http://rezwyi.github.com/whygitisbetter/#everything-is-local

Автор: panter_dsd 17.6.2011, 9:21

igor_bogomolov, хорошие статейки. Отправлю начальству на прочтение, а то этот svn на работе уже достал.

Автор: panter_dsd 17.6.2011, 9:22

igor_bogomolov, хорошие статейки. Отправлю начальству на прочтение, а то этот svn на работе уже достал.

Что за глюк с двойным ответом? Уже второй раз так.

Это если нажимать Ctrl+Enter.

Автор: Litkevich Yuriy 17.6.2011, 10:12

дважды нажимаешь отправить

Автор: ufna 17.6.2011, 10:38

Не люблю GIT. Локальные копии и т.п. - это гуд когда работа идет на опен сорс. Когда работа идет над проектом в сжатые сроки, мне нужны все изменения в централизованном хранилище.

Автор: panter_dsd 17.6.2011, 10:52

ufna, почаще push.

Автор: Iron Bug 17.6.2011, 12:42

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

Автор: Litkevich Yuriy 17.6.2011, 17:43

+1

Автор: Litkevich Yuriy 10.9.2011, 20:53

Тему разделил: http://www.forum.crossplatform.ru/index.php?showtopic=7492

Автор: Litkevich Yuriy 23.1.2013, 4:13

Полезность.

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

Всё что исправляю - заливаю на сайт, так как на сайте git-хранилища нет, то возникла необходимость заливать на сайт файлы которые изменились.

Как такое сделать?

А вот так:
git diff-tree -r 41735 929ff --no-commit-id --name-only --diff-filter=ACMRT | xargs tar -rf files_to_Site.tar

где:
41735 - ИД последней правки залитой на сайт (в примере 5 первых цифр SHA1)
929ff - ИД самой последней правки

получится архив files_to_Site.tar содержащий изменившиеся файлы.
Замечание:
В рабочем каталоге должна быть ветка содержащая последнюю правку (иначе некоторых файлов в ней может не быть.
Командуется, разумеется в Git Bash (в виндовозе), чтобы xargs был доступен.

работу с хранилищем организовал так:
master - основная рабочая ветка
toSite - ветка отличающаяся от мастера тем, что содержит всякие метрики (Яндекс.Метрика, Google analitics, на кнопки навешаны сценарии отслеживающие поведения пользователей - "цели" в терминах метрик).

Работа:
делаю функциональную ветку от mastr-а, работаю, проверяю на локальной машине. Когда уверен в результате поступаю так (изменения разумеется сохранил):
1) переключаюсь на master
2) сливаю функциональную ветку в master.
3) переключаюсь на toSite
4) сливаю функциональную ветку в toSite
5) git diff-tree ...
6) распаковываю архив (из п. 5) на сайт.

Тем самым master и toSite идентичны, за исключением оговоренного выше отличия.

Автор: Iron Bug 24.1.2013, 11:44

а нельзя ли это сделать через SVN и апачевские модули svn и dav_svn? может, и для git есть такие же модули, просто я не в курсе, ибо не юзаю его.

Автор: Litkevich Yuriy 25.1.2013, 21:12

На сайт не могу ничего кроме типового (файлы, исполняемые php-сценарии) держать.
Т.к. у хостера всё жутко строго, они сказали, что если мне нужно что-то не типовое, то бери либо выделенный сервер, либо виртуальный выделеный сервер.
Даже нет возможности подключатся с не localhost-а к БД

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

Автор: Iron Bug 26.1.2013, 12:45

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

Автор: alexy 1.2.2013, 19:48

Забрел на эту тему, все не прочитал, но могу рассказать свою грустную историю

Я пользовался SVN и все было прекрасно... Но однажды меня обокрали. Украли ноут какую-то дребедень и флешку ))) Ума не приложу кому она могла поандобится, но вот так вышло. Наверное им было просто лень сортировать. Один проект пропал полностью. Я его заново переписал потом (что пошло ему на огромную пользу

Но после этого пользуюсь только Bazaar'om и не тужу: там есть все, что мне нужно.

Автор: Iron Bug 1.2.2013, 20:44

какая-то совершенно неочевидная связь. всё равно что сказать "я носил адидас, но однажды облился чаем". какбэ одно из другого никак не вытекает и никак не влияет
не храните свой код где попало - это раз. делайте бэкапы - это два.
сейчас много серверов для хранения кода. тот же sourceforge, например. кто мешает там хранить? я давно пользуюсь и всё нормально. кроме того, даже если на флэшке хранить, то бэкап никто не отменял: флэшка может накрыться сама по себе, без всякой кражи.