Здравствуйте, IT, Вы писали:
A>>С базовой версией. То есть дифф текущего состояния (причём лучше даже чтоб не требовало сохранять файл) и последнего закомиченного состояния. IT>Жмёшь Commit и там всё это смотришь.
Не, ну там все файлы. Иди ищи нужный...
IT>>>Кстати, есть ещё одна кнопка — открыть Git Extensions. Ну а дальше решение сводится к описанному в статье. A>>Ну ты — джедай. Тут уж ничего не поделаешь, привыкай IT>Ты не поверишь, но даже те кнопки, которые есть в студии мной практически не используются. Нет необходимости. Одтельный тул гораздо удобнее, чем всякие интеграционные штучки. Единственное исключение — история, ей и в гите не сложно пользоваться, но навигация по проекту в студии всё же поудобнее.
Верю, я сам люблю отдельные тулы. Но контекстное меню я тоже люблю.
Здравствуйте, IT, Вы писали:
IT>Ты не поверишь, но даже те кнопки, которые есть в студии мной практически не используются. Нет необходимости. Одтельный тул гораздо удобнее, чем всякие интеграционные штучки. Единственное исключение — история, ей и в гите не сложно пользоваться, но навигация по проекту в студии всё же поудобнее.
Внимание, опасность!
Следующий шаг — это переход к работе в командной строке. А дальше и до Линукса недалеко.
Здравствуйте, adontz, Вы писали:
IT>>В коммите не все файлы, а только те, которые ты изменил.
A>Ну какая разница, их может быть несколько десятков. Переименовал класс и куча файлов поменялась. Нет, как раз diff удобнее в контекстном меню.
А если файл не менялся, то что ты должен увидеть в контекстном меню? Нет, как раз diff удобнее в сабмите, видно не только один единственный файл, а сразу полный набор изменений.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Пока, кроме истории, больше ничего полезного для контекстного меню не приходит в голову.
Еще blame/annotate. Они могут понадобиться и для неизмененого файла. Я частенько пользуюсь этими инструментами, когда пытаюсь выяснить причины предыдущих изменений, сделанных предшественниками.
Здравствуйте, IT, Вы писали:
IT>>>В коммите не все файлы, а только те, которые ты изменил. A>>Ну какая разница, их может быть несколько десятков. Переименовал класс и куча файлов поменялась. Нет, как раз diff удобнее в контекстном меню. IT>А если файл не менялся, то что ты должен увидеть в контекстном меню?
Diff. А вот когда я на него нажму, он мне в обеих панельках покажет одинаковые файлы и диалоговое окно: files are binary identical.
IT>Нет, как раз diff удобнее в сабмите, видно не только один единственный файл, а сразу полный набор изменений.
Это другой use case. А мне не надо просто вспомнить что я поменял.
Здравствуйте, adontz, Вы писали:
A>Это другой use case. А мне не надо просто вспомнить что я поменял.
А если ты что-то удалил или переименовал, то как ты это вспомнишь?
В общем, всё это вкусовщина. А если есть непреодолимое желание такое получить, то всё это можно и самому воплотить. Благо с этим теперь на гитхабе вообще никаких проблем.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, IT, Вы писали:
IT>>Там три кнопки: Commit, Pull и Push. А какая другая функциональность нужна от интеграции?
A>diff для выбранного файла или папки, история (аналогично), revert (аналогично). Если там только Commit, Push и Pull, то считай что интеграции никакой нет.
История там тоже есть, через контекстное меню. Там же реверт. Другое дело, что и диф и блейм из контекстного меню работают только для закоммиченных файлов.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, AlexNek, Вы писали:
AN>>Оказывается как установить эту штуку нужно 13 минут объяснять
IT>Да ладно. Это требует времени меньше, чем написание твоего сообщения.
После просмотра, я почти уверен, что установка займет минимум вечер.
Я бы с удовольствием перешел бы с SVN на что то другое, но при этом не хочется вместо одних проблем иметь другие.
Ну например, изменение и переименование файла происходит почти автоматом при переименовании имени класса. Как я понял, Гит этого не любит.
С историей по файлам похоже также есть проблемы.
Похоже нет и отметок состояния файла в визуал студио в GitExtension.
Также не совсем понятно как Гиту удается минимизировать конфликты.
Вот например работа, с SVN небольшой команды в пятницу перед сдачей этапа в понедельник.
С утра все забрали актуальную копию репозитория, до обеда неспешная работа по исправлению ошибок, кто то успел закммитить исправления, кто то еще правит. После обеда тестеры вдруг находят еще пару багов кторые нужно непременно исправить сегодня.
Кто не успел доделать нужно бросить и править срочно найденные баги (можно либо текущее состояние куда скопировать, либо поверх править) Ну вот вроде все сделал, через час домой, пора коммитить. А фиг вам низзя, надо вначале забрать актуальную версию.
При взятии выясняется что в паре файлов конфликты, причем довольно много. Разбираться некогда оставляем свою версию. Идем в историю каждого конфликтного файла имена которых записали на бумажке и переносим изменения сделанные другим разработчиком. Сделали, но прога не стартует. Провидение рекомендует глянуть журнал изменений за сегодня и похоже кто то изменил сопуствующий проект, но забыл закомиттить ДЛЛ-ку. Вроде все. Пробуем опять сохранить все, и опять непонятно почему облом. Брать изменения сейчас нельзя иначе не удастся просто потестить свои исправления, я знаю, что изменения сделал сосед и теперь мне будут приходит только "правильные" данные. Ищем изменный файл "вручную", по счастью мержится на автомате. Ок все работает, теперь берем все и проверяем еще раз. Все ок, но вечер пятницы безвозвратно утерян. (Может и немного присочинил, но для сравнения пойдет)
Подозреваю что с Гитом будет по другому, но интересно как?
Здравствуйте, AlexNek, Вы писали:
AN> После просмотра, я почти уверен, что установка займет минимум вечер. AN> Я бы с удовольствием перешел бы с SVN на что то другое, но при этом не хочется вместо одних проблем иметь другие.
Ты можешь воспользоваться git svn для начала, поиграться самому, есть несколько подводных камней (надо бы это мне как-то рассказать на досуге), но почувствовать вкус вполне можно.
AN> Ну например, изменение и переименование файла происходит почти автоматом при переименовании имени класса. Как я понял, Гит этого не любит.
Почему не любит? Ему пофиг — переименовывай как хочешь, чем хочешь. Он сам всё что надо подхватит.
AN> С историей по файлам похоже также есть проблемы. AN> Похоже нет и отметок состояния файла в визуал студио в GitExtension.
В Идее есть суперская интеграция, есть tortoisegit, есть gitk, git gui, gitextensions... но я почему-то использую коммандную строку в большинстве случаев.
AN> Также не совсем понятно как Гиту удается минимизировать конфликты.
Тем, что коммиты маленькие.
AN> Вот например работа, с SVN небольшой команды в пятницу перед сдачей этапа в понедельник. AN> С утра все забрали актуальную копию репозитория, до обеда неспешная работа по исправлению ошибок, кто то успел закммитить исправления, кто то еще правит. После обеда тестеры вдруг находят еще пару багов кторые нужно непременно исправить сегодня. AN> Кто не успел доделать нужно бросить и править срочно найденные баги (можно либо текущее состояние куда скопировать, либо поверх править)
git stash
[делаем хотфикс обнаруженных багов]
git commit
git push
[пусть тестеры тестят]
git stash pop
[вернулись к своим изменениям, продолжаем добавлять новые баги]
AN> Ну вот вроде все сделал, через час домой, пора коммитить. А фиг вам низзя, надо вначале забрать актуальную версию. AN> При взятии выясняется что в паре файлов конфликты, причем довольно много. Разбираться некогда оставляем свою версию. Идем в историю каждого конфликтного файла имена которых записали на бумажке и переносим изменения сделанные другим разработчиком. Сделали, но прога не стартует. Провидение рекомендует глянуть журнал изменений за сегодня и похоже кто то изменил сопуствующий проект, но забыл закомиттить ДЛЛ-ку. Вроде все. Пробуем опять сохранить все, и опять непонятно почему облом. Брать изменения сейчас нельзя иначе не удастся просто потестить свои исправления, я знаю, что изменения сделал сосед и теперь мне будут приходит только "правильные" данные. Ищем изменный файл "вручную", по счастью мержится на автомате. Ок все работает, теперь берем все и проверяем еще раз. Все ок, но вечер пятницы безвозвратно утерян. (Может и немного присочинил, но для сравнения пойдет)
AN> Подозреваю что с Гитом будет по другому, но интересно как?
Да, там можно делать бранчи. Притом легко. Можно тупо внести исправление в утренний trunk, создав бранч с этим хотфиксом. Или тупо всё коммитить, создать бранч от последней стабильной версии и в неё сделать cherry-pick хотфикса.
Изменения брать можно в любой момент времени — с твоими исправлениями оно пересечётся только при мерже, который не обязателен. В svn же ты обязан замержить текущие модифицированные файлы при update. Притом, если что-то пошло не так... вешайся. В гите же обычный мерж веток — не понравилось — отменил, оставил на потом.
А ещё есть магический rebase...
Слияние в Git выполняется не сильно сложнее создания новых веток. Единственная вещь, которую нужно понимать – это то, что любые манипуляции делаются над текущей веткой. То есть, если вы ходить слить две ветки...
Здравствуйте, ., Вы писали:
.>Здравствуйте, AlexNek, Вы писали:
AN>> После просмотра, я почти уверен, что установка займет минимум вечер. AN>> Я бы с удовольствием перешел бы с SVN на что то другое, но при этом не хочется вместо одних проблем иметь другие. .>Ты можешь воспользоваться git svn для начала, поиграться самому, есть несколько подводных камней (надо бы это мне как-то рассказать на досуге), но почувствовать вкус вполне можно.
Но как я понял из описания — это просто синхронизатор двух репозиториев, да и еще с командной строкой
Вот нашел еще один огромный минус
Основными достоинствами git (в сравнении с другими распределёнными системами контроля версий) в настоящее время принято считать:
* Unix-ориентированность и глубокий unixway во всём;
и еще
Ревизии обозначаются с помощью SHA1-хэшей, с одной стороны они уникальны, с другой — возникает необходимость оперировать большими строками хэшей вместо маленьких номеров.
AN>> Ну например, изменение и переименование файла происходит почти автоматом при переименовании имени класса. Как я понял, Гит этого не любит. .>Почему не любит? Ему пофиг — переименовывай как хочешь, чем хочешь. Он сам всё что надо подхватит.
Не знаю, здесь где то было написано.
AN>> С историей по файлам похоже также есть проблемы. AN>> Похоже нет и отметок состояния файла в визуал студио в GitExtension. .>В Идее есть суперская интеграция, есть tortoisegit, есть gitk, git gui, gitextensions... но я почему-то использую коммандную строку в большинстве случаев.
А что такое "Идея"? И что же лучше для студии исходя из того, что я ненавижу командные строки.
AN>> Также не совсем понятно как Гиту удается минимизировать конфликты. .>Тем, что коммиты маленькие.
Так размер коммита зависит от программиста. Если для правки ошибки нужно исправить Х строк, так эти Х будут всегда.
AN>> Вот например работа, с SVN небольшой команды в пятницу перед сдачей этапа в понедельник. AN>> С утра все забрали актуальную копию репозитория, до обеда неспешная работа по исправлению ошибок, кто то успел закммитить исправления, кто то еще правит. После обеда тестеры вдруг находят еще пару багов кторые нужно непременно исправить сегодня. AN>> Кто не успел доделать нужно бросить и править срочно найденные баги (можно либо текущее состояние куда скопировать, либо поверх править)
.>git stash
добавить текущие незакоммиченные изменения в стек изменений и сбросить текущую рабочую копию до HEAD'а репозитория;
непонятно почему это начало работы. Что все мои изменения затрутся? Хочу просто взять текущее состояние и смержить с моим. .>[делаем хотфикс обнаруженных багов] .>git commit .>git push
вносим изменения в удаленный репозитарий (удаленную ветку)
А тут обломов не бывает? .>[пусть тестеры тестят] .>git stash pop
применить последнее изменение из стека к текущей рабочей копии и удалить его из стека;
То есть имеется еще какой то локальный стек изменений? .>[вернулись к своим изменениям, продолжаем добавлять новые баги]
AN>> Ну вот вроде все сделал, через час домой, пора коммитить. А фиг вам низзя, надо вначале забрать актуальную версию. AN>> При взятии выясняется что в паре файлов конфликты, причем довольно много. Разбираться некогда оставляем свою версию. Идем в историю каждого конфликтного файла имена которых записали на бумажке и переносим изменения сделанные другим разработчиком. Сделали, но прога не стартует. Провидение рекомендует глянуть журнал изменений за сегодня и похоже кто то изменил сопуствующий проект, но забыл закомиттить ДЛЛ-ку. Вроде все. Пробуем опять сохранить все, и опять непонятно почему облом. Брать изменения сейчас нельзя иначе не удастся просто потестить свои исправления, я знаю, что изменения сделал сосед и теперь мне будут приходит только "правильные" данные. Ищем изменный файл "вручную", по счастью мержится на автомате. Ок все работает, теперь берем все и проверяем еще раз. Все ок, но вечер пятницы безвозвратно утерян. (Может и немного присочинил, но для сравнения пойдет)
AN>> Подозреваю что с Гитом будет по другому, но интересно как? .>Да, там можно делать бранчи. Притом легко. Можно тупо внести исправление в утренний trunk, создав бранч с этим хотфиксом. Или тупо всё коммитить, создать бранч от последней стабильной версии и в неё сделать cherry-pick хотфикса. .>Изменения брать можно в любой момент времени — с твоими исправлениями оно пересечётся только при мерже, который не обязателен.
Это совсем не понятно куда денутся мои изменения? .>В svn же ты обязан замержить текущие модифицированные файлы при update. Притом, если что-то пошло не так... вешайся. В гите же обычный мерж веток — не понравилось — отменил, оставил на потом. .>А ещё есть магический rebase...
Пока искал описание комманд попалось несколько интересных ссылок http://githowto.com/ http://www.proft.com.ua/2010/10/17/spravochnik-po-git-i-mercurial/ http://www.freesource.info/wiki/RuslanHihin/gitusermanual http://www.altlinux.org/Справочник_по_git.alt http://evasive.ru/articles/git_kung-fu.html http://habrahabr.ru/blogs/Git/60347/ http://git.or.cz/course/svn.html http://habrahabr.ru/blogs/Git/118924/
Здравствуйте, AlexNek, Вы писали:
AN> .>Ты можешь воспользоваться git svn для начала, поиграться самому, есть несколько подводных камней (надо бы это мне как-то рассказать на досуге), но почувствовать вкус вполне можно. AN> Но как я понял из описания — это просто синхронизатор двух репозиториев, да и еще с командной строкой
Да. В общем-то в любой совместной работе в гите ты синхронизируешь два репозитория. Если используешь git svn, то просто второй репозиторий — svn. Правда так как он довольно примитивный, приходится шаманить слегка.
Насчёт командной строки... там в общем-то всего 2 команды надо. По-мему в tortoisegit есть, но я ни разу не использовал.
AN> Вот нашел еще один огромный минус AN>
AN> Основными достоинствами git (в сравнении с другими распределёнными системами контроля версий) в настоящее время принято считать:
AN> * Unix-ориентированность и глубокий unixway во всём;
Эээ... оно не сильно отлчиается от svn.
AN> и еще AN>
AN> Ревизии обозначаются с помощью SHA1-хэшей, с одной стороны они уникальны, с другой — возникает необходимость оперировать большими строками хэшей вместо маленьких номеров.
Оперировать с идентификаторами ревизий практически не приходится. Трудностей не вызывает. Тем более достаточно обычно первых 5-6 символов хеша. А запоминать ревизию 23723 и bd94f особой разницы нет.
AN> .>В Идее есть суперская интеграция, есть tortoisegit, есть gitk, git gui, gitextensions... но я почему-то использую коммандную строку в большинстве случаев. AN> А что такое "Идея"? И что же лучше для студии исходя из того, что я ненавижу командные строки.
Jetbrains IDEA. Хз... дело вкуса. Надо пробовать самому.
AN> AN>> Также не совсем понятно как Гиту удается минимизировать конфликты. AN> .>Тем, что коммиты маленькие. AN> Так размер коммита зависит от программиста. Если для правки ошибки нужно исправить Х строк, так эти Х будут всегда.
Нет. Если используешь svn, то перед тем как коммитить — надо точно знать, что коммитишь и не поломается ли чего у других.
При использовании git коммитишь когда завершаешь какую-то мысль. Т.е. например делаешь какую-то фичу. Чтобы её сделать — надо: что-то порефакторить, написать новый код, написать тест, добавить кнопки для новой фичи, поправить баги, дописать заглушки и т.п. Так вот коммитить можешь после каждого этапа.
AN>
AN> добавить текущие незакоммиченные изменения в стек изменений и сбросить текущую рабочую копию до HEAD'а репозитория;
AN> непонятно почему это начало работы. Что все мои изменения затрутся? Хочу просто взять текущее состояние и смержить с моим.
Я имел в виду, сиутацию, когда ты делаешь что-то новое, поломал кучу кода, ничего пока не работает и ВНЕЗАПНО надо сделать какой-то хотфикс.
AN> .>[делаем хотфикс обнаруженных багов] AN> .>git commit AN> .>git push
AN>
AN> вносим изменения в удаленный репозитарий (удаленную ветку)
AN> А тут обломов не бывает?
Если кто-то что-то до тебя закоммитил, то при наличии конфликтов ругнётся, конечно. Будешь должен смержить или оставить мерж на потом.
Или что ты имеешь в виду под обломом?
AN>
AN> применить последнее изменение из стека к текущей рабочей копии и удалить его из стека;
AN> То есть имеется еще какой то локальный стек изменений?
Тупо для удобства сделано — ветки автоматом создаются и в стек складываются, потом достаются. Автоматизация частого юзкейса.
AN> .>Да, там можно делать бранчи. Притом легко. Можно тупо внести исправление в утренний trunk, создав бранч с этим хотфиксом. Или тупо всё коммитить, создать бранч от последней стабильной версии и в неё сделать cherry-pick хотфикса. AN> .>Изменения брать можно в любой момент времени — с твоими исправлениями оно пересечётся только при мерже, который не обязателен. AN> Это совсем не понятно куда денутся мои изменения?
В локальной ветке останутся, продолжишь работу в понедельник.
Хотя полезно ветку куда-нибудь на другой сервер запушить, чисто ради бекапа, если за выходные твой комп сломается или потеряется.
Отличная статья, спасибо! Наконец-то осилил переход на Git. Кстати, совсем немного времени заняло...
У меня остался вопрос по кодировке. В проекте оказался файлик, названный по-русски (из документации). По-умолчанию в Git установилась кодировка UTF-8. С этой кодировкой он отказывается работать с файлом в Windows 7 (видит файл так: ��������.txt), при установке Unicode отказывается работать со всеми файлами, Windows 1251 — работает нормально. Переименовать проблемный файл — не проблема, однако, хотелось бы разобраться с кодировками. По идее, если проект не кросс-платформенный, то можно оставить Win1251, однако интересно почему UTF-8 и UNICODE не работают?
Здравствуйте, М.Р., Вы писали:
МР>Отличная статья, спасибо! Наконец-то осилил переход на Git. Кстати, совсем немного времени заняло...
МР>У меня остался вопрос по кодировке. В проекте оказался файлик, названный по-русски (из документации). По-умолчанию в Git установилась кодировка UTF-8. С этой кодировкой он отказывается работать с файлом в Windows 7 (видит файл так: ��������.txt), при установке Unicode отказывается работать со всеми файлами, Windows 1251 — работает нормально. Переименовать проблемный файл — не проблема, однако, хотелось бы разобраться с кодировками. По идее, если проект не кросс-платформенный, то можно оставить Win1251, однако интересно почему UTF-8 и UNICODE не работают?
С кодировками имён файлов в git’е Всё Плохо. То есть всё хорошо под *nix’ами, а под Windows плохо. Это потому, что по юниксовой идеологии имена файлов священны и транскодировать их никак нельзя — пришла по протоколу байтовая строка, изволь передать её в функции работы с файлами как есть. А в Windows эти функции как раз работают в 866 или 1251.
Какие-то работы по этой проблеме ведутся, но не факт, что скоро будет готово. А пока стоит принять правило, что имена файлов должны вписываться в us-ascii. И путь к локальному репозиторию, кстати, тоже.
Здравствуйте, Centaur, Вы писали:
МР>>У меня остался вопрос по кодировке. В проекте оказался файлик, названный по-русски (из документации). По-умолчанию в Git установилась кодировка UTF-8. С этой кодировкой он отказывается работать с файлом в Windows 7 (видит файл так: ��������.txt)
C>С кодировками имён файлов в git’е Всё Плохо. То есть всё хорошо под *nix’ами, а под Windows плохо.
не знаю как под win7, а под win2003 я специально создавал msysgit-ом с нуля репозиторий с русскими именами файлов, менял их и т.д. — никаких проблем ни с файлами на диске, ни с историей. Проблема с нелатинскими именами есть при импорте хранилища из svn, это как оказалось уж сто лет как зарегистрированная бага msysgit
За курс молодого бойца — спасибо. Но почему вы считаете, что создание веток в Subversion — гемор? Очень даже удобная фича. Никто в твои изменения не лезет, а ты можешь постепенно ваять новую функцию хоть два дня, хоть неделю, хоть месяц. И как раз не нужно на локальном компе держать. К примеру, я сейчас в SVN каждый день прыгаю, как минимум, по 2 веткам в своем репозитарии еще иногда еще по одной в чужом. И еще по 1-2 своим собственным, отведенным на вялотекущие задачи сроком от нескольких дней до неопределенного.
Я и сам периодически страдаю от того, что в моей прежней команде — с которой до сих пор сотрудничаем — 10 человек всё по мере работы выкладывают — в работающем или неработающем виде — в транк, превращая этот самый транк в помойку и затрудняя слитие (когда переданные им же изменения приходят тебе обратно, да еще и в искаженном виде вперемежку с их собственными изменениями). Да, и можно неделю держать код на своем компе и не коммитить, а потом говорить, как это круто — stash в git. А можно опять же ветки использовать. Но вы ведь не будете спорить, что возможности git можно точно так же НЕ использовать, как возможности subversion, ссылаясь на сложность и гемморойность этого Ваше ощущение свободы при использовании git, как мне кажется, связано с тем, что вас вынудили сменить парадигму работы с репозитарием, и новая оказалась удобнее прежней, хотя следовать ей вы могли и раньше — по доброй воле
Из реальных недостатков ветвлений в SVN я по опыту интенсивной работы назвал бы такие: 1) в SVN нельзя завести временную ветку, похимичить в ней пару дней, а потом бесследно прибить, не выпуская из "локального репозитария", 2) выгрузка дампа репозитария с ветками несколько избыточная, 3) просматривая историю ветки, мы не видим историю коммитов внутри слитых в нее веток (а видимо только единственный коммит, которым коммитили саму операцию слития). То есть ветки там функциональны, но попросту менее удобны, чем в git. И во многом, кстати, это вина утилит, а не самой системы управления версиями: скажем, показать дерево веток вполне можно было бы и в TortoiseSVN, пусть даже за счет дополнительных запросов к серверу. Но вот не сделали же.
Спору нет, у git есть преимущества. Но и конкурентам предыдущего поколения не стоит придумывать новые недостатки сверх тех, которыми они и так страдают...
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Если нам не помогут, то мы тоже никого не пощадим.
