Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 134
1) А я обычно работаю с hg через консоль, даже если редактирую исходники через IDE с поддержкой hg.
2) Про последние замечания: если в IDE будут свои термины и свои методы работы с репами, то людям, уже знакомым с нужной DVCS, будет только больше головняка. Помню как я подвисал в netbeans, пытаясь понять, что значат те пункты меню, которые не совпадают с терминами hg.
2) Про последние замечания: если в IDE будут свои термины и свои методы работы с репами, то людям, уже знакомым с нужной DVCS, будет только больше головняка. Помню как я подвисал в netbeans, пытаясь понять, что значат те пункты меню, которые не совпадают с терминами hg.
а я в емакс воткнул всеже…
alexott.net/en/writings/emacs-vcs/EmacsMercurial.html
(уберите контрл+энтер!!!)
(уберите контрл+энтер!!!)
Тоже через консоль работаю, но иногда использую diff merge в качестве внешнего diff.
Я тоже очень часто работаю с git в консоли, хотя когда подключил к Emacs-у magit — начал потихоньку забивать. Основная причина — из magit значительно удобнее стейжить отдельные файлы.
Автору:
К git в больших проектах следует относится скорее не как к системе контроля версий, а как к конструктору любой системы контроля версий. В зависимости от предпочтений и стиля разработки, к нему можно один раз написать набор скриптов, покрывающих весь development routine, и больше не вбивать одни и те же комманды по несколько раз.
Автору:
К git в больших проектах следует относится скорее не как к системе контроля версий, а как к конструктору любой системы контроля версий. В зависимости от предпочтений и стиля разработки, к нему можно один раз написать набор скриптов, покрывающих весь development routine, и больше не вбивать одни и те же комманды по несколько раз.
Svn+eclipse — для меня слишком удобно, чтобы пытаться изучать и привыкать к чему-то еще. Заморачиваться с выбором инструмента контроля версий — выше моих сил.
Статья похожа на перевод :) А так да, почти все по дело, хотя по-моему у Меркуриала все не так плохо. По-крайней мере все каманды вполне логичны.
Опять же Backout и Strip ревизии у меня никогда не вызывали проблем(commit amend == Backout так ведь?)
Но, таки да, вот такие вещи в истории убивают:
habrastorage.org/storage/3449db33/2f7fc601/3d3dca21/03eedec2.png
Но можно упростить, включив Compact Graph
habrastorage.org/storage/ff20f07c/44683672/498bfc41/84de1220.png
Блин, картинки не вставляются.
Опять же Backout и Strip ревизии у меня никогда не вызывали проблем(commit amend == Backout так ведь?)
Но, таки да, вот такие вещи в истории убивают:
habrastorage.org/storage/3449db33/2f7fc601/3d3dca21/03eedec2.png
Но можно упростить, включив Compact Graph
habrastorage.org/storage/ff20f07c/44683672/498bfc41/84de1220.png
Блин, картинки не вставляются.
Зачетные картинки! А что за программа?
У меркуриала все прекрасно в Эклипсе
habreffect.ru/files/f8d/c61d11e7b/mercurial-eclipse.png
habreffect.ru/files/f8d/c61d11e7b/mercurial-eclipse.png
так на самом деле и не понял, почему git — «нелогичный набор утилит командной строки».
это похоже на то, если бы я жаловался на vi — «как это можно столько команд запомнить? как-то все непросто… и GUI нет? кто ж будет в консоли код редактировать?»
по-моему, git — очень удобный инструмент, всегда работаю с ним только из консоли, ничего лишнего, как и все профессиональные инструменты — мощь и простота в одном.
это похоже на то, если бы я жаловался на vi — «как это можно столько команд запомнить? как-то все непросто… и GUI нет? кто ж будет в консоли код редактировать?»
по-моему, git — очень удобный инструмент, всегда работаю с ним только из консоли, ничего лишнего, как и все профессиональные инструменты — мощь и простота в одном.
Потому что перемещения между четырьмя хранилищами (к примеру):
а) каждое называется своим словом, причем в него не входит имя хранилища,
б) некоторые разные перемещения выполняются одной командой + аргументы, в которых опять-таки не учавствует имя хранилища.
То есть, чтобы этим рулить, надо запомнить эн несвязанных слов и их соответствие реальности. Это я называю нелогичностью. Интерфейс поверх — чтобы не запоминать, чтобы не лазить в ман.
В vi все нормально — его текстовость ему не мешает. А в такой сложной визуальной штуке, как репозиторий, было бы более к месту непосредственное оперирование деревом, драг-унд-дроп какой-нибудь.
а) каждое называется своим словом, причем в него не входит имя хранилища,
б) некоторые разные перемещения выполняются одной командой + аргументы, в которых опять-таки не учавствует имя хранилища.
То есть, чтобы этим рулить, надо запомнить эн несвязанных слов и их соответствие реальности. Это я называю нелогичностью. Интерфейс поверх — чтобы не запоминать, чтобы не лазить в ман.
В vi все нормально — его текстовость ему не мешает. А в такой сложной визуальной штуке, как репозиторий, было бы более к месту непосредственное оперирование деревом, драг-унд-дроп какой-нибудь.
честно, ничего не понял…
примеры для а) и б) можно озвучить?
репозиторий необязательно должен быть визуальным, есть best practices в программировании, есть подобное и в организации работы с репозитариями. если следовать хотя бы некоторым из них — совсем необязательно «видеть» все дерево и оперировать на нодах.
примеры для а) и б) можно озвучить?
репозиторий необязательно должен быть визуальным, есть best practices в программировании, есть подобное и в организации работы с репозитариями. если следовать хотя бы некоторым из них — совсем необязательно «видеть» все дерево и оперировать на нодах.
Полностью согласен с вами, также работаю с git — очень удобно, особенно когда нужно переносить проекты с компа на комп через флешку. Также работаю и c hg, но после git чуствую себя не в своей тарелке.
вот такой оффтопичный вопрос
почему добавление в staging называется git add filename, а удаление оттуда git rm --cached filename.
Или есть другой вариант?
Как заанстеджить все файлы? А все файлы соответствующие маске?
почему добавление в staging называется git add filename, а удаление оттуда git rm --cached filename.
Или есть другой вариант?
Как заанстеджить все файлы? А все файлы соответствующие маске?
for i in `git status --porcelain | grep '^D.*\.foo$' | sed 's/^D \+//'`; do
git reset HEAD "$i"
git checkout "$i"
done
для файлов по маске *.foo
найдено в stackoverflow если что, мне пока что не приходилось с подобным сталкиваться. если не секрет — в svn это делается проще?
да я вот тоже находил это на stackoverflow, но сомнительное решение
особенно если учесть что git add dir/subdir может загрести пару временных файлов случайно и их хочется так же легко и непринужденно убрать из staging.
в svn — если мне не изменяет память svn checkout?
особенно если учесть что git add dir/subdir может загрести пару временных файлов случайно и их хочется так же легко и непринужденно убрать из staging.
в svn — если мне не изменяет память svn checkout?
не поймите неправильно, мне нравится гит, но хочется его использовать как-то эффективнее что ли, уловить стройность команд и аргументов, как к примеру приходит понимание Perl-а
я с svn загнул потому что в svn вообще нет staging :)
Воспользоваться GUI? :)
было бы интересно увидеть предложения по возможному интерфейсу для git или hg.
Сам далеко не на всю использую гит — больше для синхронизации локал репозитория с продакшеном — ни о каких слияниях не ведаю.
Сам далеко не на всю использую гит — больше для синхронизации локал репозитория с продакшеном — ни о каких слияниях не ведаю.
Пробовал использовать gui-ные клиенты, в частности для git / hg. Всё такое непонятное, по-моему в консоли в данном случае проще и быстрее работать. Скажем,
hg sum --remote опишет весь статус дерева в простой и лаконичной форме, чтобы получить столько же информации из окна программы, в него нужно две минуты смотреть.
Ха-ха, 5 баллов! Первая часть с описанием систем — именно так, как все и есть. Пока сижу на SVN, как-то привык, во всяком случае с логами не так запутанно как в git'е. Да и tortoisesvn помогает. Наверное, надо тоже выписать git команды на листочек. :)
Qgit — такой же кошмар, как и всё остальное, описанное тут. Проще в GitHub'е посмотреть, что где.
Да что ж все так с этим Git носятся… SVN нормальная система, пользуемся ей при разработке (клиент интегрирован в Zend Studio) — вопросов никаких — всё нормально… зачем париться и переводить всех на Git, если есть SVN?
каждому свое, как говорится. почему же люди переходят со старых систем на новые? сам Торвальдс отвечает на многие вопросы о гит. хотя бы вот это видео посмотрите (на русском) www.youtube.com/watch?v=BtAlN4MaBr8
а) локальные коммиты + редактирование коммитов перед пушем.
б) локальные ветки.
в) нет проблем с мержем (в svn при отделении ветки обратно ее можно смержить только один раз, что ли. А практика показала, что там еще какие-то странности вылезают).
г) ну и скорость.
д) работа в оффлайн еще, иногда.
б) локальные ветки.
в) нет проблем с мержем (в svn при отделении ветки обратно ее можно смержить только один раз, что ли. А практика показала, что там еще какие-то странности вылезают).
г) ну и скорость.
д) работа в оффлайн еще, иногда.
Вот еще замечательный ответ от deeGraYve. Я, честно говоря, уже и забыл, что в svn всего этого нет :)
habrahabr.ru/blogs/development_tools/112648/#comment_3609048
habrahabr.ru/blogs/development_tools/112648/#comment_3609048
Порог вхождения в РСУВ (DVCS) высок. Многие не пользуются ими не потому что думают, что это им не нужно, а потому что это на самом деле сложно. В том числе программисты, которые в большинстве своем тоже люди.
Пару консольных команд программистам выучить сложно да понять структуру репозитория, основанную на обычных деревьях? Я считаю, что таких людей вообще можно не относить к программистам.
для меня ваши слова звучат как «программистов в виндусе не бывает»
ну просто в виндусе консоль настолько убогая, что ею стараешься не пользоваться никогда
ну просто в виндусе консоль настолько убогая, что ею стараешься не пользоваться никогда
Окей, давайте поставим вопрос так: почему git/hg сделаны так, что ими могут пользоваться только программисты?
Хорошо, почему тулзы, которые нужны не только программистам, рассчитаны только на программистов?
Нет, я из тех, кому „Пару консольных команд… выучить сложно“. Ну и дизайнеры — они не люди? Технические писатели?
Необязательно технические писатели, любые: чем пользоваться им? Особенно, если творчество коллективное. Движками вики, другого ничего не остаётся подходящего обычным пользователям — не программистам?
Но вики не годятся для предпечатной подготовки. Чем пользоваться редактору/редакции при подготовке книги к печати, а именно для отслеживания процессов вёрстки и корректуры-вычитки?
Скрибус, как я понимаю, имеет бинарный формат и потому не прикручивается к системам контроля версий, TeX/LaTeX и сам по себе по юзабилити убойный, а если ещё надо объединить с системой контроля версий, то вообще ппц, неспецы не осилят.
Но вики не годятся для предпечатной подготовки. Чем пользоваться редактору/редакции при подготовке книги к печати, а именно для отслеживания процессов вёрстки и корректуры-вычитки?
Скрибус, как я понимаю, имеет бинарный формат и потому не прикручивается к системам контроля версий, TeX/LaTeX и сам по себе по юзабилити убойный, а если ещё надо объединить с системой контроля версий, то вообще ппц, неспецы не осилят.
> Для коллективного использования есть издательские системы
Какие? Adobe и QuarkXPress? Группа, к примеру, учёных должна ставить себе этих монстров, чтобы совместно написать статью или учебник? Я уж не говорю — покупать за деньги. Я, кстати, не уверен, что с управлением версиями там и коллективной работой там всё есть, что нужно.
Средства, как бы имеющиеся в MS Office или Open Office, для коллективной работы не годятся, ибо крайне убоги. А для предпечатной подготовки эти программы тем более не предназначены.
> Для остальных вот
И что — вот? Там нет ничего подходящего. Видно, что Вы сами не копали. К сведению: поиском по интернету я пользоваться умею.
> Бинарный формат сам по себе не помеха использования VCS просто текст-ориентированные системы с ними теряют смысл. Но историю хранить можно.
Вот именно, что теряется смысл.
Какие? Adobe и QuarkXPress? Группа, к примеру, учёных должна ставить себе этих монстров, чтобы совместно написать статью или учебник? Я уж не говорю — покупать за деньги. Я, кстати, не уверен, что с управлением версиями там и коллективной работой там всё есть, что нужно.
Средства, как бы имеющиеся в MS Office или Open Office, для коллективной работы не годятся, ибо крайне убоги. А для предпечатной подготовки эти программы тем более не предназначены.
> Для остальных вот
И что — вот? Там нет ничего подходящего. Видно, что Вы сами не копали. К сведению: поиском по интернету я пользоваться умею.
> Бинарный формат сам по себе не помеха использования VCS просто текст-ориентированные системы с ними теряют смысл. Но историю хранить можно.
Вот именно, что теряется смысл.
Вы еще спросите, почему все IDE, а также emacs и vim сделаны так, что ими могут пользоваться только программисты.
Исренне не понимаю, что сложного. Сам пользовался SVN и Hg (под Windows, из клмандной строки и с Tortoise* клиентами), за несколько дней осваиваешь, коммит — апдейт — пуш/пулл — просмотр истории, все элементарно и понятно. Все изменения в файле подсвечиваются разными цветами, очень просто.
Или вы ветки/теги создаете, форки и мержи делаете? Ну так либо освойте магию командной строки и силу воображения, либо мучайтесь дальше, Буратино вы наш. Это кунфу отнюдь не для людей, неспособных на что-то более сложное, чем «плагин к эклипсу» (хотя я сам не очень понимаю, зачем все эти сложности вообще нужны).
Или вы ветки/теги создаете, форки и мержи делаете? Ну так либо освойте магию командной строки и силу воображения, либо мучайтесь дальше, Буратино вы наш. Это кунфу отнюдь не для людей, неспособных на что-то более сложное, чем «плагин к эклипсу» (хотя я сам не очень понимаю, зачем все эти сложности вообще нужны).
Чёрт, среди множества людей, большинство из которых почему-то стремятся к усложнению, очень редко встречаю человека, который стремится к ясности и простоте.
Виват!
Виват!
git — ясно и просто
минусующих прошу объяснить чем checkout, merge, pull (--rebase), branch сложны и почему ими нельзя пользоваться?
Я склонен согласиться скорее с собственными наблюдениями и аргументацией в статье выше, чем с вашим, не слишком аргументированным, заявлением.
Фразы вроде «гит — это просто» или «а что не так в линуксе с отрисовкой шрифтов?» вызывают во мне такой взрыв негодования и справедливой аргументации, что я, пожалуй, лучше промолчу.
Фразы вроде «гит — это просто» или «а что не так в линуксе с отрисовкой шрифтов?» вызывают во мне такой взрыв негодования и справедливой аргументации, что я, пожалуй, лучше промолчу.
простите, ниже напишу более аргументированно.
в вашем, тоже далеко не самом аргументированном, ответе вы говорите об аргументации в статье. я увидел только два «аргумента» — GUI клиенты не умеют делать ничего, кроме отрисовки структуры и коммита, и то, что они делать не умеют.
не соглашусь с обоими — 1) есть proprietary клиенты для гит, которые могут больше, чем простой коммит (этой системой моя компания пользуется внутри, но я все-таки предпочитаю консоль) 2) «правильной» отрисовки не существует, потому как разным людям нравятся разные стили.
другого в статье не увидал, увольте, давно в России не был, быть может что-то пропустил. я уже писал выше, что так и не понял примеры про перемещения и хранилища автора статьи, он пока что мне не ответил.
уфф, передохнуть надо, давно я по-русски столько не писал, ниже отвечу, почему мне кажется, что гит — ясно и просто.
в вашем, тоже далеко не самом аргументированном, ответе вы говорите об аргументации в статье. я увидел только два «аргумента» — GUI клиенты не умеют делать ничего, кроме отрисовки структуры и коммита, и то, что они делать не умеют.
не соглашусь с обоими — 1) есть proprietary клиенты для гит, которые могут больше, чем простой коммит (этой системой моя компания пользуется внутри, но я все-таки предпочитаю консоль) 2) «правильной» отрисовки не существует, потому как разным людям нравятся разные стили.
другого в статье не увидал, увольте, давно в России не был, быть может что-то пропустил. я уже писал выше, что так и не понял примеры про перемещения и хранилища автора статьи, он пока что мне не ответил.
уфф, передохнуть надо, давно я по-русски столько не писал, ниже отвечу, почему мне кажется, что гит — ясно и просто.
все нижесказанное — мое личное мнение
1) гит ясен прежде всего своей структурой — разветвленная дерево-подобная цепочка коммитов. вся история создания продукта — как на ладони, никто не боится создавать дополнительные ветки, разработчики не наступают друг другу на ноги — у каждого своя ветвь. в svn все время боялся создавать новые ветки, потому что merge двух веток — жестокое упражнение, которое нужно было планировать заранее, чтобы никто во время мерджа случайно чего-нибудь там не обновил.
2) использование хэшей и тагов — любому программисту придутся по душе имена нодов, все уникальны, можно «перенестись в прошлое» без каких либо проблем
3) использование stash — невероятно удобно, если под рукой вертится кто-то, кто постоянно спрашивает, что да как происходит в master и какой-нибудь другой ветке (PM например) — не нужно суетиться и сохранять все то, над чем работаешь в данный момент (может оно и не компилируется вообще) — сохранить в stash и вернуться на исходную — одна комманда.
4) bisect просто незаменим, если работаешь в большой комманде и в день набегает по нескольку сотен коммитов — попробуй найди потом кто и когда закоммитил код, который что-то там сломал
5) git хранит полную историю — файлы, которые были когда-то давно добавлены и удалены, их можно вернуть когда угодно.
6) независимость от центрального репозитория — моя копия всегда хранит ВСЮ историю, из нее можно полностью восстановить репозиторий.
7) pull --rebase — очень удобен для слияния веток, если автоматически merge не происходит, rebase остановится, даст возможность вручную исправить код, rebase --continue продолжит merge, --abort вернет все на исходную
8) dry-run (для патчей --check) — предпросмотр, очень полезная штука, покажет где и почему произойдут ошибки merge
9) отсутствие бестолковых .svn папок — не люблю мусорить там, где работаю
10) cherry-pick — одна из моих любимых комманд, выборочно применяет коммит с определенным хэшем — легко проверить, что работает, а что нет.
я не агитирую никого за использование git, мне лишь непонятно то, почему люди им не пользуются. да, возможно, learning curve у него покруче остальных, но совсем необязательно пользоваться всеми коммандами гита, начинать можно с самых базовых, постепенно осваивая новые. это инструмент, прежде всего, как и у любого инструмента у него есть преимущества и недостатки, лично для себя его преимущества помогли мне стать намного эффективней, только и всего.
1) гит ясен прежде всего своей структурой — разветвленная дерево-подобная цепочка коммитов. вся история создания продукта — как на ладони, никто не боится создавать дополнительные ветки, разработчики не наступают друг другу на ноги — у каждого своя ветвь. в svn все время боялся создавать новые ветки, потому что merge двух веток — жестокое упражнение, которое нужно было планировать заранее, чтобы никто во время мерджа случайно чего-нибудь там не обновил.
2) использование хэшей и тагов — любому программисту придутся по душе имена нодов, все уникальны, можно «перенестись в прошлое» без каких либо проблем
3) использование stash — невероятно удобно, если под рукой вертится кто-то, кто постоянно спрашивает, что да как происходит в master и какой-нибудь другой ветке (PM например) — не нужно суетиться и сохранять все то, над чем работаешь в данный момент (может оно и не компилируется вообще) — сохранить в stash и вернуться на исходную — одна комманда.
4) bisect просто незаменим, если работаешь в большой комманде и в день набегает по нескольку сотен коммитов — попробуй найди потом кто и когда закоммитил код, который что-то там сломал
5) git хранит полную историю — файлы, которые были когда-то давно добавлены и удалены, их можно вернуть когда угодно.
6) независимость от центрального репозитория — моя копия всегда хранит ВСЮ историю, из нее можно полностью восстановить репозиторий.
7) pull --rebase — очень удобен для слияния веток, если автоматически merge не происходит, rebase остановится, даст возможность вручную исправить код, rebase --continue продолжит merge, --abort вернет все на исходную
8) dry-run (для патчей --check) — предпросмотр, очень полезная штука, покажет где и почему произойдут ошибки merge
9) отсутствие бестолковых .svn папок — не люблю мусорить там, где работаю
10) cherry-pick — одна из моих любимых комманд, выборочно применяет коммит с определенным хэшем — легко проверить, что работает, а что нет.
я не агитирую никого за использование git, мне лишь непонятно то, почему люди им не пользуются. да, возможно, learning curve у него покруче остальных, но совсем необязательно пользоваться всеми коммандами гита, начинать можно с самых базовых, постепенно осваивая новые. это инструмент, прежде всего, как и у любого инструмента у него есть преимущества и недостатки, лично для себя его преимущества помогли мне стать намного эффективней, только и всего.
5) git хранит полную историю — файлы, которые были когда-то давно добавлены и удалены, их можно вернуть когда угодно.
Справедливости ради надо сказать, что это не совсем правда. В git вполне можно, при неосторожном обращении, потерять что-то важное.
Создаете ветку -> добавляете файлы -> удаляете ветку.
Все — ваши файлы буду жить до первого git gc.
В меркуриале, как я понимаю, ничего никогда не исчезает в принципе.
и, на закуску, уже не МОЕ личное мнение — whygitisbetterthanx.com/
я вроде упомянул, что это не мое мнение, на сайте есть disclaimer — можете написать Scott Chacon письмо, если вы не согласны, код сайта в открытом доступе в гитхабе. я про hg не знаю ровным счетом ничего, я даже спорить не собирался про то, чем лучше git, потому что уверен, что сколько людей — столько и мнений. а сайт написан человеком, который дал сравнение git с другими системами.
Чуствую скоро будут священные между инструментами управления, как с языками программирования )
Уже есть, я уже пару раз холиварил на тему svn vs. git. Вот только никто так и не привел мне вменяемых аргументов чем гит лучше. Считаю, что и то и другое хорошая штука которой можно пользоваться, по крайней мере у меня за три года использования svn проблем не возникало.
У вас, наверное, просто относительно поступательная разработка.
Вряд ли у вас были задачи вроде: Support<A,B,C,trunk> = «работать над A на основе trunk, потом срочно разработать фикс B на основе trunk, подать B на тестирование, вернуться к A, дорабатывать, сделать исправления по результатам тестирования к B, подать B на тестирование, делать фикс C на основе trunk, зарелизить B, отдать на тестирование A, отдать на тестирвоание C, выполнять Support<D,E,F,B>, параллельно релизя A и C и мержа результаты вышеописанного процесса в trunk»
Сам пользуюсь git, при том, что основной репозитарий — svn и мержи приходится делать rebase`ами. Даже при этом удобство неописуемое — в описанном выше процессе не приходится постоянно заниматься конфликтами или молиться на svn`овский мерж, что бы он «не потерял» репозиторий.
Вряд ли у вас были задачи вроде: Support<A,B,C,trunk> = «работать над A на основе trunk, потом срочно разработать фикс B на основе trunk, подать B на тестирование, вернуться к A, дорабатывать, сделать исправления по результатам тестирования к B, подать B на тестирование, делать фикс C на основе trunk, зарелизить B, отдать на тестирование A, отдать на тестирвоание C, выполнять Support<D,E,F,B>, параллельно релизя A и C и мержа результаты вышеописанного процесса в trunk»
Сам пользуюсь git, при том, что основной репозитарий — svn и мержи приходится делать rebase`ами. Даже при этом удобство неописуемое — в описанном выше процессе не приходится постоянно заниматься конфликтами или молиться на svn`овский мерж, что бы он «не потерял» репозиторий.
В gitk я смотрю разноцветное дерево только для ощущения масштабности работы, никакого практического применения я ему не нашёл. В этом случае как раз большой плюс, что история запутанная и дерево получается развесистым, так оно сильнее внушает.
Согласен с тем, что изучить Git непросто. Но все становится гораздо очевиднее, если потратить немного времени на изучение внутреннего устройства репозитория. Могу посоветовать книгу Git Internals от Peepcode. Признаться, долго сокрушался и приводил в порядок свой первый репозиторий после ее прочтения ;)
P.S. Кстати, слышал мнение о том что некоторые другие DVCS, например Mercurial и Bazaar проще для понимания, но сам ничем кроме Git никогда пользовался (даже SVN), поэтому сравнивать не могу.
P.S. Кстати, слышал мнение о том что некоторые другие DVCS, например Mercurial и Bazaar проще для понимания, но сам ничем кроме Git никогда пользовался (даже SVN), поэтому сравнивать не могу.
Пытялся смотреть в сторону других VCS, но в результате до сих пор на SVN. Он, конечно, медленный и печальный, зато простой и удобный. А медленность и печальность отлично лечатся SSD.
Это git и mercurial для вас сложные? Ничего IBM Rational ClearCase доберётся и к вам, вот тогда и поговорим о сложности.
А вообще Tortoise HG/Git достаточно упрощают интерфейс. Я за час обучил инженеров электронщиков, которые до этого ничем кроме проэкт21.01.2003.12.34.rar не пользовались и ничего освоили успешно и довольны и почему то не жалуются на сложность.
А вообще Tortoise HG/Git достаточно упрощают интерфейс. Я за час обучил инженеров электронщиков, которые до этого ничем кроме проэкт21.01.2003.12.34.rar не пользовались и ничего освоили успешно и довольны и почему то не жалуются на сложность.
консоль лучше всего ;)
у меня вот так — snapplr.com/gpr1
у меня вот так — snapplr.com/gpr1
Странно, что среди нескольких gui-клиентов для git под mac не был упомянут SmartGit. Ведь весьма популярный и удобный на мой взгляд клиент.
Я так и не понял, о чём статья? О том, что все GUI фигово деревья рисуют? Или о том, что командная строка отстой? Напишите тогда ваше видение того, как надо работать с DVCS, у Mercurial есть API. Вы ведь не кричите, что вам стиральной машинкой пользоваться непонятно, а читаете инструкцию. Почему тут не хотите? Вы же программист, а не дитё малое.
P.S. TortoiseHG.
P.S. TortoiseHG.
Короче смысл статьи в том, что DVCS — это немного сложнее, чем VCS. Плюс у DVCS еще достаточно плохо проработаны гуевые тулзы.
Что касается TortoiseHG, мне не нравится в нем одно: у него все окошки сильно отличаются от TortoiseSVN, которым я пользовался несколько лет и к которому привык. Когда приходится иметь дело и с hg, и с svn (в некоторых проектах до сих пор сидят на нем), то бесит переключаться между одним GUI и другим.
Что касается TortoiseHG, мне не нравится в нем одно: у него все окошки сильно отличаются от TortoiseSVN, которым я пользовался несколько лет и к которому привык. Когда приходится иметь дело и с hg, и с svn (в некоторых проектах до сих пор сидят на нем), то бесит переключаться между одним GUI и другим.
Я думаю, что человек, придумавший стиральную машинку, тоже сначала долго возмущался необходимостью стирать на доске.
Попробуйте Darcs. У него есть свои минусы, да, но зато очень дружественный консольный интерфейс.
Под дружественным понимается «спрашивает вопросы». Например, набираете darcs whatsnew и darcs сам запускает less, показывая вам изменения в репозитарии относительно некоторого baseline. darcs record показывает изменения в репозитарии, спрашивает, «нужно ли вот это изменение записать?» — а вы отвечаете «да», «нет», «запиши сразу все» и т.д. Даже простой запуск darcs без аргументов выдает справку, которую можно просматривать (а не дамп в stdout, как обычно). В общем, более общительный инструмент. :)
Под дружественным понимается «спрашивает вопросы». Например, набираете darcs whatsnew и darcs сам запускает less, показывая вам изменения в репозитарии относительно некоторого baseline. darcs record показывает изменения в репозитарии, спрашивает, «нужно ли вот это изменение записать?» — а вы отвечаете «да», «нет», «запиши сразу все» и т.д. Даже простой запуск darcs без аргументов выдает справку, которую можно просматривать (а не дамп в stdout, как обычно). В общем, более общительный инструмент. :)
Ну с этим-то никто не спорит (кроме того, что git, в отличие от меркуриала, вроде именно ревизии хранит, а не ченжсеты)
кроме того, что git, в отличие от меркуриала, вроде именно ревизии хранит, а не ченжсеты
Феерический бред.
Устроит вас такая ссылка?
www.kernel.org/pub/software/scm/git/docs/user-manual.html#def_changeset
changeset: BitKeeper/cvsps speak for «commit». Since git does not store changes, but states, it really does not make sense to use the term «changesets» with git.
www.kernel.org/pub/software/scm/git/docs/user-manual.html#def_changeset
changeset: BitKeeper/cvsps speak for «commit». Since git does not store changes, but states, it really does not make sense to use the term «changesets» with git.
Вы меня извините, если я не совсем в тему, но заголовок топика следовало бы расширить до «Взгляд пользователя Eclipse». Пока не дочитал до момента с пояснением того — как вы используете VCS — сильно недоумевал.
Почему на Винде нужны, а в Линуксе не нужны?
В маке тоже есть консоль, которой можно пользоваться, однако мне НУЖЕН гуишный клиент. Более того, сядь я работать за линукс, он мне точно так же был бы нужен. Его, может быть, не было бы, но он был бы мне нужен.
Видимо, вы неправильно понимаете значение слова „нужны“. Вы его, видимо, путаете с „можно обойтись без“.
Еще раз, ну последний уже наверное. Если удобного инструмента нет, это не значит, что он никому не нужен.
Я против гуёв для программистов, по следующим причинам:
0. Гуй может увеличить эффективность только в некоторых редких операция, в большей части случаев он не приносит пользы, а часто бывает и вреден, операции с мышью они обычно тормозные.
1. На сервера ходишь по ssh — если вдруг нужно срочно что-то сделать, нужно не мануалы по командам читать и не любимы гуи ставить, а вводит давно выученные команды.
3. Всякие ide и графические клиенты скрывают от программиста как это устроено, подсевшие с юности на ide часто ничего не знают про то что компилятор, отладчик и текстовый редактор это разные компоненты, и про систему сборки могут не знать. Для кодеров может это и хорошо, а для разработчиков плохо.
Это касательно программистов, для остальных скажут так, если хочется фичей, то придётся немного подучиться, а кому фичей не надо, для тех есть соответствующие гуи. Я был бы только за, если бы был крутой гуй для все VCS, но потребности у меня в нём нет, и судя по комментам я не один.
Надеюсь вы найдёте/напишите/поспособствуете написанию удобного гуя, и весьма вероятно, если он реально будет прост, он поможет многим непрограммистам влиться в мир пользователей VCS.
0. Гуй может увеличить эффективность только в некоторых редких операция, в большей части случаев он не приносит пользы, а часто бывает и вреден, операции с мышью они обычно тормозные.
1. На сервера ходишь по ssh — если вдруг нужно срочно что-то сделать, нужно не мануалы по командам читать и не любимы гуи ставить, а вводит давно выученные команды.
3. Всякие ide и графические клиенты скрывают от программиста как это устроено, подсевшие с юности на ide часто ничего не знают про то что компилятор, отладчик и текстовый редактор это разные компоненты, и про систему сборки могут не знать. Для кодеров может это и хорошо, а для разработчиков плохо.
Это касательно программистов, для остальных скажут так, если хочется фичей, то придётся немного подучиться, а кому фичей не надо, для тех есть соответствующие гуи. Я был бы только за, если бы был крутой гуй для все VCS, но потребности у меня в нём нет, и судя по комментам я не один.
Надеюсь вы найдёте/напишите/поспособствуете написанию удобного гуя, и весьма вероятно, если он реально будет прост, он поможет многим непрограммистам влиться в мир пользователей VCS.
Всегда придерживался такой методики обучения новому языку, технологии и т. п. — сначала разбираюсь с консольными команды, ключами, структурами, форматами и т. п., а потом, разобравшись хотя бы с основами, ищу гуевины под них. Фейл был только один (вернее много, но однотипные — продукты для разработки от MS, от Borland разобрался всё же). Мне так удобнее и эффективнее получается работать (засекал по таймеру не раз, прочитав очередной пост или тред на хабре об эффективности работы в консоли с vim или emacs в качестве ide). В гуевинах, кстати, интенсивно использую хоткеи. Главный плюс гуевин для меня возможность визуально выбирать элементы в списках, деревьях и т. п., а не долбать tab и нажимать y в ответ на «Display all 3770 possibilities? (y or n)».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Текущее состояние инструментов. Взгляд пользователя