Здравствуйте, ., Вы писали:
.>Здравствуйте, AlexNek, Вы писали:
AN>> Менее удобно еще куда то переключаться. AN>> — я всегда вижу визульно какой файл модифицирован AN>> — нажав commit на solution сразу видно все изменения только в файлах включенных в проект. Могу тут же глянуть отличия. .>Т.е. "включённых в проект"? Те, которые не в проекте вообще в игноре должны быть.
Для чего нужно делать лишнюю работу? Сделал допустим новую диаграмму, закинул в проект и она уже будет закоммичена, старую просто убрал с проекта и она больше не будет обновлятся, зато смогу эксперименты наней делать. Мне лично удобнее следить за одним чем то.
AN>> Если делать в проводнике нужно минимум еще туда перейти, при этом нужно переходить в корень всех проектов. .>В git не надо вроде. Он коммитит рабочую копию целиком (как минимум из командной строки).
Ну тогда к коммандную строку нужно хотя бы перейти, а как там отличия смотреть, вначале записать список изменений а после по нему идти?
AN>> А делал вот что
AN>> Копирую через проводник файл в локальную папку под гитом. AN>> Через git extension делаю ему коммит. AN>> Через гит черепаху даю команду ребасе. AN>> Появляется диалог, вверху виден мой файл. AN>> Не помню уже точно как, может через контектное меню, может слева где кликнул, ставлю ему признак ignore. AN>> Нажимаю кнопочку ОК AN>> Файл бесследно исчезает. .>В общем понял теперь. Короче, рассказываю. Ты делал rebase, т.е. перебазирование. Что это значит. У тебя есть история svn, c коммитами s1, s2, s3.
Я брал просто Head .>Ты делаешь изменение в гите и коммитишь, получается коммит g1. История теперь такая: s1->s2->s3->g1. Допустим за это время кто-то другой что-то в svn закоммитил s4, получается теперь есть 2 истории: s1->s2->s3->s4 в svn и s1->s2->s3->g1. Тебе их надо слить. В случае git всё просто, а с svn надо сделать линейную историю. Т.е. должно получиться s1->s2->s3->s4->g1. Т.е. твой коммит g1 должен быть применён не к s3 а к s4. Когда ты делаешь git svn rebase он скачивает историю из svn и переносит твой коммит в её конец. При этом tgit предлагает эту историю тут же подредактировать (например, возможно s4 уже фиксит проблему которую ты пофиксил в g1 или там что-то пересекается). Ты же поставил признак "skip" .>(а не ignore как ты написал).
Возможно, для меня, в данном случае это были синонимы. .>Т.е. ты отказался применять твоё изменение g1. Логично, что файла в итоге не стало.
А что нужно было тогда делать, если я хочу сохранить файл в гите но не хочу его тправлять в svn .>Да, кстати это не важно что не было никакого s4, перебазирование позволяет редактировать историю в любом случае, чтобы при отправке в удалённый репозиторий было всё красиво в истории.
.>Если тебе интересно, поразбирайся с git reflog, если хочешь понять как тебе вернуть твой файл.
спасибо гляну
Здравствуйте, Bear Hunter, Вы писали:
BH> Я пробовал перевести, ради интереса, наш проект в Гит. Размер проекта около 300 мб. BH> Теперь когда я создал ветку с изменениями, то переключение между главной и созданной веткой занимает около 5-7 секунд. BH> Хотя реально изменен был только один файл.
А сейчас под какой системой проект? Такого размера проект в том же svn по-моему будет на порядок дольше работать.
Здравствуйте, AlexNek, Вы писали:
AN> Для чего нужно делать лишнюю работу? Сделал допустим новую диаграмму, закинул в проект и она уже будет закоммичена, старую просто убрал с проекта и она больше не будет обновлятся, зато смогу эксперименты наней делать. Мне лично удобнее следить за одним чем то.
Хз, не очень представляю что ты там такое делаешь и за чем следишь.
AN> Ну тогда к коммандную строку нужно хотя бы перейти, а как там отличия смотреть, вначале записать список изменений а после по нему идти?
В статье с картинками вроде всё просто и без командной строки. Что куда записывать ты собираешься?
AN> .>В общем понял теперь. Короче, рассказываю. Ты делал rebase, т.е. перебазирование. Что это значит. У тебя есть история svn, c коммитами s1, s2, s3. AN> Я брал просто Head
Ты не понял что-ли? git выкачивает весь svn репозиторий, целиком.
AN> А что нужно было тогда делать, если я хочу сохранить файл в гите но не хочу его тправлять в svn
Попробуй сохранить файл в гите и не отправлять его в svn.
hint: rebase в svn ничего не отправляет.
Здравствуйте, ., Вы писали:
.>Здравствуйте, AlexNek, Вы писали:
AN>> Для чего нужно делать лишнюю работу? Сделал допустим новую диаграмму, закинул в проект и она уже будет закоммичена, старую просто убрал с проекта и она больше не будет обновлятся, зато смогу эксперименты наней делать. Мне лично удобнее следить за одним чем то. .>Хз, не очень представляю что ты там такое делаешь и за чем следишь.
Я могу менять файлы как в проекте так и вне его, но в корневом каталоге, например документацию. Да и со студии гораздо удобнее, без проблем могу файл, проект или солюшин закоммитить. (Конечно можно тожесамое и на уровен файловой системы сделать, но это все лишнии движения)
AN>> Ну тогда к коммандную строку нужно хотя бы перейти, а как там отличия смотреть, вначале записать список изменений а после по нему идти? .>В статье с картинками вроде всё просто и без командной строки. Что куда записывать ты собираешься?
Там не в студии.
AN>> .>В общем понял теперь. Короче, рассказываю. Ты делал rebase, т.е. перебазирование. Что это значит. У тебя есть история svn, c коммитами s1, s2, s3. AN>> Я брал просто Head .>Ты не понял что-ли? git выкачивает весь svn репозиторий, целиком.
Точно уверен? http://www.haypocalc.com/blog/index.php/2008/11/05/172-git-svn
Потверждено практикой, можно выкачать исключительно последнюю ревизию
AN>> А что нужно было тогда делать, если я хочу сохранить файл в гите но не хочу его тправлять в svn .>Попробуй сохранить файл в гите и не отправлять его в svn. .>hint: rebase в svn ничего не отправляет.
Может мы говорим о разных командах?
Здравствуйте, AlexNek, Вы писали:
AN> Я могу менять файлы как в проекте так и вне его, но в корневом каталоге, например документацию. Да и со студии гораздо удобнее, без проблем могу файл, проект или солюшин закоммитить. (Конечно можно тожесамое и на уровен файловой системы сделать, но это все лишнии движения)
Вот и не понятно. Как коммитить что-то из студии, если ты можешь менять что-то не в проекте/солюшне?
В общем непонятно что именно такого в Студии. Но наверное дело привычки/вкуса.
AN> .>В статье с картинками вроде всё просто и без командной строки. Что куда записывать ты собираешься? AN> Там не в студии.
И слава богу!
AN> .>Ты не понял что-ли? git выкачивает весь svn репозиторий, целиком.
AN> Точно уверен?
Если не делать лишних телодвижений, то да. git svn clone выкачивает всё. Естественно можно частями, но редко когда нужно.
AN> .>Попробуй сохранить файл в гите и не отправлять его в svn. AN> .>hint: rebase в svn ничего не отправляет.
AN> Может мы говорим о разных командах?
rtfm хоть что-ли. Отправить что-то в svn можно командой git svn dcommit, на картинке предыдущий пункт меню.
Здравствуйте, ., Вы писали:
.>Здравствуйте, AlexNek, Вы писали:
AN>> Я могу менять файлы как в проекте так и вне его, но в корневом каталоге, например документацию. Да и со студии гораздо удобнее, без проблем могу файл, проект или солюшин закоммитить. (Конечно можно тожесамое и на уровен файловой системы сделать, но это все лишнии движения) .>Вот и не понятно. Как коммитить что-то из студии, если ты можешь менять что-то не в проекте/солюшне?
В студии у меня все исходники и прочее что нужно для компиляции проекта. Вне проекта, но в каталоге есть еще различные документы которые не хочется коммитить вместе с исходниками.
.>В общем непонятно что именно такого в Студии. Но наверное дело привычки/вкуса.
нам намного удобнее делать все со студии.
AN>> Точно уверен? .>Если не делать лишних телодвижений, то да. git svn clone выкачивает всё. Естественно можно частями, но редко когда нужно.
А про клоне я не видел (git-svn fetch -rREVISION) А нафига мне весь репозиторий?
AN>> .>Попробуй сохранить файл в гите и не отправлять его в svn. AN>> .>hint: rebase в svn ничего не отправляет.
AN>> Может мы говорим о разных командах? .>rtfm хоть что-ли. Отправить что-то в svn можно командой git svn dcommit, на картинке предыдущий пункт меню.
Отчего то мне казалось, что это синхронизация
Я теперь просто ветку сделал с изменениями, а перед svn переключаюсь на мастер.
Здравствуйте, ., Вы писали:
.>А сейчас под какой системой проект? Такого размера проект в том же svn по-моему будет на порядок дольше работать.
Сейчас проект под Perforce. Но у нас немного подход не такой. Мы делаем отдельные ветки только для релизов.
Но после прочтения статьи Игоря и еще этой то очень понравилась идея ветвления проекта для каждого фикса/фичи отдельно. Очень удобно!
Вот и решил попробовать как оно будет выглядеть на большом проекте.
Здравствуйте, Bear Hunter, Вы писали:
BH> Сейчас проект под Perforce. Но у нас немного подход не такой. Мы делаем отдельные ветки только для релизов. BH> Но после прочтения статьи Игоря и еще этой то очень понравилась идея ветвления проекта для каждого фикса/фичи отдельно. Очень удобно! BH> Вот и решил попробовать как оно будет выглядеть на большом проекте.
Если я не ошибаюсь, то это преимущество p4 над git — оно умеет ворочить огромные репозитории, в том числе с бинарниками, ценой удобства работы.
Уже не первый раз встречаю мнение, что ветки в свн — это что-то очень сложное и неудобное.
Постоянно ими пользуюсь, активно создаю, сливаю, удаляю. Часто работаю параллельно над разными ветками.
Единственный минус — инфа о слияниях хранится не совсем удобно (точнее ее неудобно смотреть в тортиле). Однако я использовал ветки еще до появления в свн этой инфы и завел привычку при мердже писать что именно было слито.
В последнее время часто использую меркуриал. Каких-то мегапреимуществ именно для веток я в нем не увидел. Более того, свн — это что-то типа версионной файловой системы, там можно создать иерархическую организацию веток и тагов, чем активно пользуюсь на работе.
Здравствуйте, enji, Вы писали:
E>Уже не первый раз встречаю мнение, что ветки в свн — это что-то очень сложное и неудобное.
E>Постоянно ими пользуюсь, активно создаю, сливаю, удаляю. Часто работаю параллельно над разными ветками.
E>Единственный минус — инфа о слияниях хранится не совсем удобно (точнее ее неудобно смотреть в тортиле). Однако я использовал ветки еще до появления в свн этой инфы и завел привычку при мердже писать что именно было слито.
E>В последнее время часто использую меркуриал. Каких-то мегапреимуществ именно для веток я в нем не увидел. Более того, свн — это что-то типа версионной файловой системы, там можно создать иерархическую организацию веток и тагов, чем активно пользуюсь на работе.
Может личный процесс опишите более подробно?
Вот как у нас делают:
— создание ветки. Говорю админу он делает ветку. (Копия всего проекта)
— взятие ветки. Делаю checkout и "иду на прогулку"
— играемся с кодом.
— Часто после "игрушек" нужно не более 50% исправлений, которые нужно абсолютно все контроллировать. Поэтому нужные части кода просто переносятся вручную при необходимости в основную ветку.
Ветки делаются только тогда когда нужна какая то особая версия продукта или есть большой шанс все "поломать"
Здравствуйте, AlexNek, Вы писали:
AN>Может личный процесс опишите более подробно? AN>Вот как у нас делают: AN>- создание ветки. Говорю админу он делает ветку. (Копия всего проекта)
у нас админ не занимается свн. Настраивал его в свое время лично я. Потратил наверное часа 2. Особых проблем не припомню. С тех пор просто добавляю новых пользователей по мере надобности.
У программеров есть права на запись в brunches. Программеров человека 4, все люди вменяемые и саботажем никто не занимается — поэтому права особо не ограничиваются.
Когда мне нужна ветка — просто ее создаю. В свн копирование "легкое", создание ветки в репозитории — практически мгновенно. Мои личные ветки живут в brunches/fio. С личными ветками других не пересекаются. AN>- взятие ветки. Делаю checkout и "иду на прогулку"
У меня чекаут- минут 10. Часто можно сделать не чекаут, а переключение имеющей раб копии. У меня их в работе штук 5. Обычно просто переключаю, это пара минут. Работаю на С++, разные раб копии используют общий кэш объектников. Сборка довольно быстрая. Билд-скрипт сделан так, чтобы не зависеть от местоположения раб копии. AN>- играемся с кодом.
При "играх" делаю частые коммиты в ветку, стараюсь чтобы 1 коммит = 1 логическое изменение. Если возникает необходимость попробовать неск альтернатив — создаю новые ветки. При необходимости мержу их друг с другом. Но необходимость в ветках от ветки бывает не сильно часто. AN>- Часто после "игрушек" нужно не более 50% исправлений, которые нужно абсолютно все контроллировать. Поэтому нужные части кода просто переносятся вручную при необходимости в основную ветку.
Так как 1 коммит = 1 изменение, можно выбрать нужные коммиты. Мерж автоматический. После мержа просматриваю изменения в файлах. Если мерж значительный — компилирую, прогоняю тесты, иногда проверяю работу. AN>Ветки делаются только тогда когда нужна какая то особая версия продукта или есть большой шанс все "поломать"
Ветки делаются практически на каждый чих — на каждую версию продукта, на каждое нововведение. Иногда если нововведение заведомо маленькое, ветку не делаем, коммитим в транк.
После мерже в сообщении коммита пишу, какая ветка и какие ревизии были влиты. Содержимое комментария формализовано и может быть разобрано программно — собственно так и строится плоский журнал изменений.
Пользуясь фильтром по комментарию в тортилле можно легко понять что с чем было слито. Иногда смотрю граф ревизий, но редко
Я только начал работать с git и хотел бы получить подробную пошаговую инструкцию (в картинках), как настраивать сервер. Сервер, где предполагается хранить репозиторий, находится в защищенной сети за маршрутизатором и файрволом. Клиентские компьютеры частично находятся в этой же сети, частично за ее пределами. Администратор сети может открыть доступ компьютерам с определенными IP-адресами, но он требует название протокола и номер порта, по которому будет выполняться взаимодействие с сервером. Сервер работает на машине под управлением Windows 7, клиенты используют GitExtension с PuTTY (интеграция с Visual Studio). Что нужно сделать для настройки маршрутизатора (и файрвола) сети и настройки сервера. Очень хотелось бы получить максимально подробную инструкцию или ссылку на нее, если таковая уже имеется.
Здравствуйте, rsdn_gurin, Вы писали:
_>Администратор сети может открыть доступ компьютерам с определенными IP-адресами, но он требует название протокола и номер порта, по которому будет выполняться взаимодействие с сервером.
$ grep ^git /etc/services
git 9418/tcp # git pack transfer service
git 9418/udp # git pack transfer service
Либо ssh, тогда стандартный порт 22. Либо любой, специально назначенный для. Например, 2222.
Здравствуйте, enji, Вы писали:
AN>>- взятие ветки. Делаю checkout и "иду на прогулку" E>У меня чекаут- минут 10. Часто можно сделать не чекаут, а переключение имеющей раб копии. У меня их в работе штук 5. Обычно просто переключаю, это пара минут. Работаю на С++, разные раб копии используют общий кэш объектников.
Вот тут проблема. В git создание (или переключение) ветки это секунд 5-10 независимо от размера репозитория. Если бы это занимало пару минут, то ветки были бы малополезны. А так на любой чих (баг, фичу, эксперимент) создаётся короткоживущая ветка, которая видна только мне, и не мешает остальным.
Re: про лицензию
От:
Аноним
Дата:
28.07.11 13:02
Оценка:
Здравствуйте, Игорь Ткачев, Вы писали:
ИТ>Статья: ИТ>Git в картинках
ИТ>Авторы: ИТ> Игорь Ткачев
ИТ>Аннотация: ИТ>Краткое введение в Git и Git Extensions.
а про лицензию вопрос есть.
GIT идет под GNU лицензией.
Что это обязывает?
Т.е. разработанный мною продукт, для которого я использовал в качестве GIT должен быть под GNU лицензией => open source?
Здравствуйте, <Аноним>, Вы писали:
А>а про лицензию вопрос есть. А>GIT идет под GNU лицензией. А>Что это обязывает? А>Т.е. разработанный мною продукт, для которого я использовал в качестве GIT должен быть под GNU лицензией => open source?
Если ваш продукт является производным от Git (ну например линкуется с ним каким-то образом) — то продукт должен быть выпущен под GPL. Но врядли это ваш случай.
Спасибо большое за статью.
Жаль что только сейчас увидел.
Хотелось бы в нее добавить 2 вещи.
1) ссылку на http://hginit.com/ (Ну ведь много сравнений с Hg)
2) описание недостатков Git
для нас основным был — невозможно ограничить доступ к части репозитория (например к коду защиты)
P_Y>1) ссылку на http://hginit.com/ (Ну ведь много сравнений с Hg)
Это действительно стоит почитать! Написано кратко, доходчиво, и с юмором. Рассказано не только что система делает, но и зачем это все надо. К сожалению такое очень редко сейчас можно увидеть. Обычно или толмуд на тему "Введение в CM", где на 90% вода вокруг да около или тупое подробное описание всех команд.
Re[3]: про лицензию
От:
Аноним
Дата:
28.07.11 17:34
Оценка:
Здравствуйте, Peregrin, Вы писали:
P>Здравствуйте, <Аноним>, Вы писали:
А>>а про лицензию вопрос есть. А>>GIT идет под GNU лицензией. А>>Что это обязывает? А>>Т.е. разработанный мною продукт, для которого я использовал в качестве GIT должен быть под GNU лицензией => open source?
P>Если ваш продукт является производным от Git (ну например линкуется с ним каким-то образом) — то продукт должен быть выпущен под GPL. Но врядли это ваш случай.
можно точно разъяснить:
если я его использую только для контроля версий при разработке проекта, то мой проект должен быть под GNU?
также не совсем понял, что значит линкуется? т.е. взял за основу GIT т.к. исходники открыты — допилил?
