Цитата(WolfAlone @ 8.12.2011, 03:46  ) |
| Я понимаю, что что-то я делаю не так... Только вот никак не могу понять, что именно? Подскажите пожалуйста! |
я бы начал с документации. или с пошагового описания действий своих рук.
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Программное обеспечение под *NIX системы > Git over SSH |
| Автор: WolfAlone 8.12.2011, 04:46 | ||||||
| Доброе утро! Установил на сервер под управлением Debian 6: GIT, что бы познакомиться с ним получше... Далее: 1. Скачал несколько клиентов *под Windows (среди которых TortoiseGit и SmartGit) 2. Создал репозиторий
3. Создал текстовый файл 4. Добавил текстовый файл
5. Закоммитил всё это дело...
Подключился по SSH с помощью клиента (пробовал как и с помощь RSA-ключа, так и с помощью логин+пароль - соединение проходит успешно!), сделал клон репозитория, и началось самое интересное... Вот уже примерно 5 часов, пытаюсь любым возможным способом запихать изменения в "центральный" репозиторий. Но, все попытки тщетны. Последняя ошибка, на которой я остановился звучала примерно так: " 'master' rejected (non-fast-forward) ". Для проверки решил зарегистрироваться на GitGub... Зарегистрировался. Все те же самые действия, но, всё работает! Я понимаю, что что-то я делаю не так... Только вот никак не могу понять, что именно? Подскажите пожалуйста! Добавлено через 1 минуту и 14 секунд Забыл добавить! PULL проходит успешно! С правами доступа к файлам всё ок! |
| Автор: bilbobagginz 8.12.2011, 22:10 | ||
я бы начал с документации. или с пошагового описания действий своих рук. |
| Автор: WolfAlone 8.12.2011, 23:50 | ||||||||||
| Пошаговое описание действий моих рук, максимально подробное. Случилось всё это, в один прекрасный осенний день... Я в очередной раз зашёл на сайт NetBeans, что бы узнать... не появилась ли там случайно новая версия этой замечательной среды! И какого же было мою удивление, когда я узнал, что появилась! Вышла новая NetBeans 7.1 RC. Которая уже более адекватно стала поддерживать CSS, и так же, там появилась полная и я бы даже сказал очень "умная" поддержка GIT (не сравнить с версией 7.0, где поддержка GIT была реализована в виде "костыля"). Моей радости не было предела. Особенно меня вдохновило изучением документации и возможностей это системы! Ну, и конечно же лицензия, совместимость с Mercurial, "считывалка" SVN, поддержка кучи протоколов без "костылей" на подобии "TortoiseHG" для быстрой связки NetBeans + Mercurial в среде Win*, среди которых в т.ч. и "git+ssh", авторизация по ключу и самое главное - всё это УЖЕ встроено в NetBeans и, чисто теоретически - отлично работает. Мои дальнейшие практические действия: 1. На всякий случай (от греха подальше), нашёл в Интернете руководство по установке GIT на Linux Debian 2. Создал в облаке 2 виртуальных сервера, с "голым" Debian 6. 3. На одном из них, из серверов, запускаю примерно следующую команду:
3.1 На втором сервере делаю всё в точности с инструкцией:
4. На обоих серверах успешно установлены абсолютно идентичные версии ПО (в чём разница между моим вариантом "git" и вариантом из инструкции "git-core" - я честно говоря не понял, но, не суть) 5. Далее, ознакомившись с основными (ключевыми командами) - создаю репозиторий (на обоих серверах, одинаково):
6. В итоге, у нас получается 2 идентичных, пустых, не "голых" (bare) репозитория, в которых ничего нет. 7. Все попытки сделать что-то из NetBeans не привели к желаемому результату, в виду чего мной было принято решение скачать специализированный GIT-клиент, SmartGit, а заодно и TortoiseGit (среди прочих) 8. Далее, для проверки работоспособности всего этого "добра", я решил добавить в репозиторий какой-нибудь файл и закоммитить его... Добавляем:
9. Появляется окно текстового редактора "Nano", где просят вписать комментарий для коммита. Вписываем, сохраняем, всё ok. 10. Для того, что бы убедиться, что всё работает "как надо" - удаляю из рабочего каталога ранее созданный файл и делаю "апдейт" рабочего каталога
всё прекрасно работает! 11. Запускаем клиент, SmartGit, настраиваем подключение root'a с помощью ключа (без ввода пароля) и делаем Project > Clone. Выбираем куда мы хотим клонировать проект, после чего происходит успешное клонирование проекта по указанному пути (на всякий случай, путь для клона выбран без пробелов и русских символов) 12. Откраваем файл demo_file.txt в текстовом редакторе и вносим в него незначительные изменения. 13. Делаем "commit" 14. Commit проходит успешно, пытаемся делать PUSH 15. Программа запрашивает, в какую ветку будем PUSH? Так как никаких других, кроме как ветки по умолчанию "master" не создавалось - PUSH'им в ветку "master" 16. ИТОГ: Получаем ошибку: " 'master' rejected (non-fast-forward) ". P.S. Я конечно понимаю, что "Git это вам не Mercurial" и так далее... Но, не ужели всё настолько "круто" и сложно, что такое банальное действие как "проталкивание" требует каких-то нестандартных действий? |
| Автор: bilbobagginz 10.12.2011, 11:42 |
| опять "ту мач информейшен". я не понял зачем ты 2 РАЗА сделал git init ты сделал чекаут с одного, а пуш в другой. так не делают: в пункте 6, у тебя не получилось "2 идентичных репозитория", а "2 репозитория, файловый контент которых идентичен" у каждого из них есть свой график хэшей. с разными значениями. для того, чтобы как-то их соединить, нужно сделать слияние (мерж), аккуратно. но так не делают. кстати если я правильно понял, то и в меркюриал у тебя бы не получился пуш нормальным. если бы были файлы, тебе бы пришлось КАЖДЫЙ файл мержить. вручную, т.к. нет общей истории слияний. нужно было создать один, потом клОнить/чекаутить другой (я бы клОнил), и тогда хэши бы были идентичными, и у копий были бы отношения "родитель->пасынок". и тогда ... было бы лучше. я так думаю. |
| Автор: WolfAlone 10.12.2011, 13:24 | ||||||||
| Прошу прощения, видимо где-то я упустил 1 момент... Дело происходит примерно так, вкратце: Два репозитория были созданы автономно друг от и между собой связи никакой не имеют. Оба они располагаются на разных Debian-based серверах, и были созданы исключительно для тестов, оба. Причиной тому стало, то, что в какой-то момент мне показалось, что команды:
и
дают разный эффект. В последствии выяснилось, что это не так, по этому у нас получилось просто два одинаковых репозтория на разных серверах, с каждый из которых, не зависимо друг от друга я пытаюсь наладить "контакт" из ОС Windows 7 (это очень важно, так как большинство из будущих пользователей репозитория(-ев) имеют на борту именно эту ОСь.
С mercurial в плане пушей и пр. - всё просто замечательно! К нему вообще претензий нет  Претензии пожалуй есть только к NetBeans, за то, что для GIT'a всё есть "из коробки", а для Mercurial только базовый функционал. Но, это я так, к слову.Я забыл упомянуть ещё один, видимо, очень важный момент. Если я создаю "голый" репозиторий:
то, все выше описанные проблемы куда-то деваются сами собой! Всё прекрасно пушится/пуллится/коммитится! |
| Автор: WolfAlone 10.12.2011, 13:45 |
| Что-то мне на глаза стали попадаться какие-то странные материалы, которые гласят нечто вроде "пушить в 'НЕ_ГОЛЫЙ' репозиторий не стоит! В него можно только пуллить". И везде приводиться система связки двух репозиториев, при этом один из них получается нечто вроде "прокси-репозиторий". Это меня наводит на мысль о том, что в репозиторий у которого есть рабочий каталог - вообще нельзя пушить? |
| Автор: bilbobagginz 10.12.2011, 18:21 |
| не работал настолько плотно с гитом, чтобы говорить из опыта. но интуитивно, думаю что проблема более в философии использования, а не в технической невозможности: когда у тебя есть файлы, ты их ненароком можешь изменить, а потом и закоммитить. проблема возникает в распределенной коммандной кооперации: то, что ты закоммитил, кто-то мог вытянуть, и отнестись к этому коду как к рабочему. и тогда есть целая процедура как делать rebase. имхо, во избежание этих ситуаций, они не рекоммендуют использовать общак с рабочей копией. |
| Автор: WolfAlone 10.12.2011, 19:20 |
| Хорошо, хоть Mercurial не наделили такой философией... Вот сколько работаем, ещё такой "философской проблемы" не возникало. Нет, бывает конечно, что ставиться отдельный так сказать "главный" репозиторий, в который (с помощью панели управления) сливаются наиболее удачные (функциональные, и/или обладающие ещё каким-то крайне полезным/нужным свойством) версии исходников (*я бы назвал это "мажор релизы"), но что бы отделить "продакшн-репу" от "воркинг-репы", это для меня наверное навсегда останется загадкой... Получилась, распределённо-распределённая система контроля версий, которая в случае каких-то конфликтов, насколько я понимаю, потребует вмешательства "администратора продакшн-репозитория". Я конечно могу заблуждаться, но на данный момент всё это выглядит (для меня) именно так. Но, для меня вопрос "пуша" в репозиторий с рабочим каталогом по прежнему остаётся открыт. Может быть есть какая-нибудь волшебная команда, типа "я общеаю GIT'у, что не буду изменять файлы в рабочем каталоге"? Ну или какой-нибудь другой способ пушить в репозиторий с рабочим каталогом без каких либо дополнительных цепочек типа "репо -> репо"? |
| Автор: bilbobagginz 11.12.2011, 22:00 |
| ты не проникся. читай мануалы ;) |
| Автор: WolfAlone 15.12.2011, 02:12 | ||
Почитал, проникся! Как выяснилось, судя по всему, сказивается изначальное назначение GIT - контроль иходников ядра LINUX. Судя по всему, именно по этой причине GIT изначально как бы вообще не предусматривает такого понятия, как "обновление рабочего каталога", к тому же, сам по себе, рабочий каталог в "головном" репозитории он тоже не предусматривает. В какой-то степени это правильно, зачем для СИ-кода рабочий каталог в "головном" репозитори... Как выяснилось несколько позже, GIT оснащён несколько большим функционалом в области ХУКОВ, чем Mercurial (*решение принято на основе найденной документации), например, переменных передаваемых в обработчик ХУКа, в GIT я насчитал поболее... |
| Автор: powerfox 22.12.2011, 00:58 | ||||
Не проникся. |