GIT и конфликты
 |
Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
|
| ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
| [18.221.154.151] |
|
|
| Страницы: (2) [1] 2 все ( Перейти к последнему сообщению ) |
GIT и конфликты
|
Сообщ.
#1
,
|
|
|
|
Читаю документацию по ГИТ в виде мастера и тут не могу воссоздать конфликт http://githowto.com/resolving_conflicts
Что бы не делать все те 30 шагов что в руководстве опишу на пальцах: Шаг 1. имеем файл 1.txt с таким содержанием (две пронумерованные строки) Цитата 1. 2. Шаг 2. делаем отдельную Ветку "тест" и правим строку 1 пишем туда слово first , комитим Шаг 3. возвращаемся в ветку "мастер" и правим файл дописывая во вторую строку слово second и коммитим Шаг 4. возвращаемся в ветку "Тест" и делаем   git merge master Вопрос: ГИТ стал такой умный что разные строки в файле сам совмещает и нет конфликта или я делаю что-то не так? |
|
Сообщ.
#2
,
|
|
|
|
в книге этой тут аналогичный конфликт
Цитата Конфлик в разных строках и ГИТ слил файлы без конфликта <<<<<<< HEAD <!-- Author: Marina Pushkova (marina@githowto.com) --> <html> <head> <link type="text/css" rel="stylesheet" media="all" href="style.css" /> </head> <body> <h1>Hello, World!</h1> </body> </html> ======= <!-- Author: Marina Pushkova (marina@githowto.com) --> <html> <head> </head> <body> <h1>Hello,World! Life is great!</h1> </body> </html> >>>>>>> master |
|
Сообщ.
#3
,
|
|
  |
Если в первом случае я бы ещё засомневался можно-ли их безопасно совместить, то во втором даже у банального patch проблем не возникнет.
Добавлено Цитата orb @ Никогда не понимал, зачем сливать мастер к другой ветке. git merge master |
|
Сообщ.
#4
,
|
|
|
|
Цитата Dark Side @ почему тогда http://githowto.com/resolving_conflicts есть конфиликт?то во втором даже у банального patch проблем не возникнет. у автора старая версия ГИТа? |
|
Сообщ.
#5
,
|
|
|
|
или это просто пример
Добавлено на самом деле там увидеть проблему нереально. Надо смотреть как минимум вывод различий Добавлено Смоделировал первый пример - выдал конфликт, как я и ожидал. Кстати, про то что написано про разрешение конфликтов по той ссылке - забудь и не вспоминай. git mergetool - наше всё. Только настроить надо - не у всех хватает нервов работать с дефолтным vimdiff. |
|
Сообщ.
#6
,
|
|
|
|
Цитата Dark Side @ а что там не так? Кстати, про то что написано про разрешение конфликтов по той ссылке - забудь и не вспоминай |
|
Сообщ.
#7
,
|
|
|
|
Для тех, кому нравится именно такой способ разруливать конфликты - ничего. А любителям vimdiff, tortoisediff и прочих интерактивных такой метод может показаться вполне себе через опу. Для меня всё в большинстве случаев сводится к git mergetool (запускается сравнивалка из tortoise), del /s *.orig и далее по интересам: commit, rebase --continue и т.п. Я даже не особо смотрю, какие файлы файлы просили слить.
Добавлено Пробежался по этому howto - как-то уж совсем сухо и без пояснений, хотя местами это очень критично. |
|
Сообщ.
#8
,
|
|
|
|
Цитата Dark Side @ а можешь критику сделать подробнееПробежался по этому howto - как-то уж совсем сухо и без пояснений, хотя местами это очень критично. Это проект знакомого я как раз его изучаю детально. Я уже нашел пару неточностей мелких. и вот с этим не могу разобраться почему в примере есть конфликт, а у меня не выходит  |
|
Сообщ.
#9
,
|
|
|
|
orb, в том примере изменённые строки достаточно далеко друг от друга и алгоритму вполне может хватить этого чтобы понять, что это изменения в разных блоках кода. Если надо 100% конфликт, то лучше всё-таки менять одни и теже строки, либо соседние.
По критике: лучше подробнее остановиться на описании параметрах reset: --hard, --soft, --mixed. Стандартная справка бывает не всем понятна. Не нашел ни слова о fast-forward и вообще описании вывода команд. Всё-таки читателю стоит понимать, что значит behind, ahead и diverged, а также, почему push отказывается работать. Смущает, что описание bare-репозиториев находится довольно далеко от начала работы с удалёнными вообще. Отсутствие авторизации git-server иногда приводит к тому, что сервер по дефолту закрыт для записи. ИМХО, стоит бегло упомянуть об альтернативных транспортах работы с удалёнными репами. Здесь кратко о ssh: Если у человека есть опыт работы с ssh-сервером, то ему достаточно обеспечить доступ к катологу с репозиториями через протокол (т.е. примерно как с sftp) и (желательно, но необязательно) проходить авторизацию через пользователя у которого в качестве оболочки установлена git-shell. Последний пукнт (51) вообще не понял. |
|
Сообщ.
#10
,
|
|
|
|
спасибо
|
|
Сообщ.
#11
,
|
|
|
|
Теперь проблема тут http://githowto.com/pulling_shared_changes
Цитата C:\Program Files\Git/libexec/git-core/git-pull cannot be used without a working tree |
|
Сообщ.
#12
,
|
|
|
|
Не все операции выполняются из bare-репозитория. pull в их числе.
|
|
Сообщ.
#13
,
|
|
|
|
комбинация git fetch и git merge — работает
git pull — не работает?!?!! в консоле все работает (в линуксе) |
|
Сообщ.
#14
,
|
|
|
|
Цитата orb @ Репозиторий - "чистый", без working tree ? в консоле все работает (в линуксе) Добавлено yuri@jureth /home/git/reps/achromate.git $ git fetch . From . * branch HEAD -> FETCH_HEAD yuri@jureth /home/git/reps/achromate.git $ git merge fatal: This operation must be run in a work tree yuri@jureth /home/git/reps/achromate.git $ git pull fatal: /usr/libexec/git-core/git-pull cannot be used without a working tree. yuri@jureth /home/git/reps/achromate.git $ |
|
Сообщ.
#15
,
|
|
|
|
Цитата Dark Side @ не знаюбез working tree ? делал по инструкции |
0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
0 пользователей:
[ Script execution time: 0,0349 ] [ 15 queries used ] [ Generated: 28.04.24, 10:13 GMT ]