Комментарии 105
Огромное спасибо за труд. Спасибо, что в примечании указали ссылку на хабра-ссылку на оригинал. Интересно, что помешало оформить хабра-переводом?
Стоит отметить, что предлагаемая модель ветвления подходит не исключительно для Git, но и Mercurial, а скорее всего и большинству распределенных систем контроля версий
Стоит отметить, что предлагаемая модель ветвления подходит не исключительно для Git, но и Mercurial, а скорее всего и большинству распределенных систем контроля версий
Да, модель явно не заточена конкретно под Git, с другими DVCS, скорее всего, проблем не должно возникнуть.
Не совсем понял насчёт хабра-перевода. При создании топика я указал, что это перевод, и иконка перевода (Z->Я) рядом с названием отображается. Или Вы имели в виду что-то другое? Ткните носом в ссылку, если не трудно.
Не совсем понял насчёт хабра-перевода. При создании топика я указал, что это перевод, и иконка перевода (Z->Я) рядом с названием отображается. Или Вы имели в виду что-то другое? Ткните носом в ссылку, если не трудно.
я например иконку опять не заметил и опять досмотрев до конца увидел что это перевод…
Мои извинения. Картинка из кэша пропала. Ссылку Vincent Driessen не разглядел. Включил картинки, каюсь, горе мне, горе.
Извинения принимаются :) А я ещё было подумал, что хабра-перевод — это какая-то программа или веб-сервис специальный для перевода. Что-то типа translated.by Вот и попросил ссылку на этот случай.
Стоит отметить, что предлагаемая модель ветвления подходит не исключительно для Git, но и Mercurial, а скорее всего и большинству распределенных систем контроля версий
Если смотреть со стороны управления конфигурациями проекта, то ветвление это средство, а vcs — инструмент. От vcs нужна возможность работы с бранчами, а распределенность не играет большой роли. Просто так получается, что в распределенных управление бранчами реализовано лучше. scm-notes.blogspot.com/2010/09/branch-per-task-workflow-explained.html.
Мне одному кажется, что давно пора перейти от описания удобности технологии к описанию связки технология-инструмент?
Потому как сама по себе технология ни чего не значит, а удобный инструмент для конкретной технологии уже большой плюс к нему (например, C# — хороший и удобный язык программирования. Но без удобнейшей Visual Studio он бы ни когда не достиг такой популярности, т.к. хороших языков много).
Это я к чему веду: при описании GIT все работают с командной строкой. Нет, я согласен, что это удобно в определенных случаях, но далеко не всем.
Опишите наконец инструмент для работы с GIT, скажем TortoiseGit (да, да, под винду), разбавляя это теорией как в данной статье.
Лично для меня ключевым выбором той или иной технологии стало не ее возможности/продвинутость, а удобство работы.
Потому как сама по себе технология ни чего не значит, а удобный инструмент для конкретной технологии уже большой плюс к нему (например, C# — хороший и удобный язык программирования. Но без удобнейшей Visual Studio он бы ни когда не достиг такой популярности, т.к. хороших языков много).
Это я к чему веду: при описании GIT все работают с командной строкой. Нет, я согласен, что это удобно в определенных случаях, но далеко не всем.
Опишите наконец инструмент для работы с GIT, скажем TortoiseGit (да, да, под винду), разбавляя это теорией как в данной статье.
Лично для меня ключевым выбором той или иной технологии стало не ее возможности/продвинутость, а удобство работы.
P.S. спасибо за интересную статью.
P.S.S. да, я понимаю что это перевод и попрошу автора не принимать высказывание на свой счет ;)
P.S.S. да, я понимаю что это перевод и попрошу автора не принимать высказывание на свой счет ;)
с гитом все работают в командной строке, т.к. для линукса это нативный способ User Interaction, а для винды гит до сих пор собирается через зад^W Cygwin
Да, я понимаю что для продвинутых линукс-пользователей командная строка проблем не составляет.
Но у многих не столь продвинтых или переходящих возникают проблемы. Да и давно уже прошли времена, когда знание консоли было необходимым условием использования linux.
Но у многих не столь продвинтых или переходящих возникают проблемы. Да и давно уже прошли времена, когда знание консоли было необходимым условием использования linux.
да я не агитирую за консоль. я сам по большей части виндузятник (дома), но на работе вся работа только в линуксе и 99% в консоли. хочешь не хочешь, а привыкнешь. Но так же можно привыкнуть и к графическим интерфейсам и хорошо себя с ними ощущать. Так что консоль онли — это не мои слова
Git сам по себе просто очень удобно использовать именно через командную строку из-за кучи опций. Под виндой можно использовать cygwin + bash_completion для автодополнения.
В своей практике я применяю zsh (автодополнение, менюшки, и имя бранча в PS1), через GUI – делаю интерактивный стейджинг (когда надо закоммитить часть файла, а не весь, все забываю соответствующий флаг консольной версии), смотрю визуально дерево бранчей (на вещах типа linux-hnd весьма удобно). Изредка читаю диффы во внешнем редакторе (если много файлов и скроллинга). И очень редко открываю внешний EDITOR для написания коммит-сообщения. Это все под OSX: GitX, Araxis Merge/Kaleidoscope, TextMate.
В своей практике я применяю zsh (автодополнение, менюшки, и имя бранча в PS1), через GUI – делаю интерактивный стейджинг (когда надо закоммитить часть файла, а не весь, все забываю соответствующий флаг консольной версии), смотрю визуально дерево бранчей (на вещах типа linux-hnd весьма удобно). Изредка читаю диффы во внешнем редакторе (если много файлов и скроллинга). И очень редко открываю внешний EDITOR для написания коммит-сообщения. Это все под OSX: GitX, Araxis Merge/Kaleidoscope, TextMate.
wuake (консоль, вызывается, как в quake — по win+~) и cygwin — и никаких gui не надо. Обычно людей, перешедших с SVN, в командной строке страшит относительно сложное добавление отдельных файлов и коммит части изменений. В отличии от SVN (и других централизованных систем), где это — достаточно частая операция, в git и mercurial мне это не приходилось делать вообще (в основном, благодаря легкому созданию бранчей), почти всегда делаешь коммит всех изменений с автоматическим добавлением не добавленных файлов (git commit -a -m «message») — и все. Потому очень важно правильно понять саму идею распределенных систем — а это статья объясняет очень хорошо.
Я не против консоли.
Я против вырабатывания новых привычек в работе, под каждую технологию отдельно.
При переходе на новый продукт я хочу чтобы было «как в старом, только лучше».
А в случае с git мне надо фактически заново переучиваться для работы с ним через консоль.
Поэтому я и говорю: напишите тоже самое, но с примерами как это делать не через консоль, а через TortoiseGit. И тогда множество пользователей TortoiseSVN без проблем воспользуются статьей и поймут в чем удобство git.
Я против вырабатывания новых привычек в работе, под каждую технологию отдельно.
При переходе на новый продукт я хочу чтобы было «как в старом, только лучше».
А в случае с git мне надо фактически заново переучиваться для работы с ним через консоль.
Поэтому я и говорю: напишите тоже самое, но с примерами как это делать не через консоль, а через TortoiseGit. И тогда множество пользователей TortoiseSVN без проблем воспользуются статьей и поймут в чем удобство git.
Ну, заново переучиваться — это естественно при использовании принципиально отличающейся технологии. Или вы на C# в процедурном стиле пишете?
«Принципиально отличающаяся»?
90% взаимодействия разработчика с системой контроля версий не различаются ни в Git, ни в SVN — коммит, апдейт, создание веток, слияние веток — у Git и Hg получше с ветками и производительностью, у SVN — с чекаутом репозитория с долгой историей. Они не настолько отличаются по возможностям, чтобы использовать различные программы.
Воспользуюсь вашей аналогией — для любого программирования в любом стиле на любом языке прекрасно подходят одинаковые текстовые редакторы и даже IDE (Eclipse, например).
90% взаимодействия разработчика с системой контроля версий не различаются ни в Git, ни в SVN — коммит, апдейт, создание веток, слияние веток — у Git и Hg получше с ветками и производительностью, у SVN — с чекаутом репозитория с долгой историей. Они не настолько отличаются по возможностям, чтобы использовать различные программы.
Воспользуюсь вашей аналогией — для любого программирования в любом стиле на любом языке прекрасно подходят одинаковые текстовые редакторы и даже IDE (Eclipse, например).
Внешне — разницы почти нет. Идеологически — очень даже есть.
Если в SVN редко, кто использует ветки для выделения изменений, касающихся отдельной фичи или багфикса (поскольку механизм слияния там не сильно удобен), то в гите/меркуриале это стандартная процедура — это приводит к достаточно сильно отличающемуся процессу использования.
Если не учесть этого изменения — нет смысла вообще куда либо переходить с SVN.
Процесс лучше (и наиболее универсально) пояснить на примере командной строки, т.к. в случае необходимости любой GUI-клиент будет очень быстро изучен.
Как было сказано выше, одному удобно в Tortoise работать, другому — из Far'а, третьему — вообще из IDE (которых из широкоизвестных минимум три с разными вариантами интеграции) — в сумме минимум пять клиентов, их каждый описывать?
Если в SVN редко, кто использует ветки для выделения изменений, касающихся отдельной фичи или багфикса (поскольку механизм слияния там не сильно удобен), то в гите/меркуриале это стандартная процедура — это приводит к достаточно сильно отличающемуся процессу использования.
Если не учесть этого изменения — нет смысла вообще куда либо переходить с SVN.
Процесс лучше (и наиболее универсально) пояснить на примере командной строки, т.к. в случае необходимости любой GUI-клиент будет очень быстро изучен.
Как было сказано выше, одному удобно в Tortoise работать, другому — из Far'а, третьему — вообще из IDE (которых из широкоизвестных минимум три с разными вариантами интеграции) — в сумме минимум пять клиентов, их каждый описывать?
Unix-way. Отделение механизма от политики.
В данном случае механизм — это консоль и Тортилла, они есть и в СВН и в DVCS, а политика — это «идеология». Так вот, политика не должна затрагивать механизм — пользоваться инструментом должно быть одинаково полноценно и удобно как через консоль, так и через Гуи.
Так вот, в СВН оба механизма сбалансированы, а в Гит — еще нет.
В данном случае механизм — это консоль и Тортилла, они есть и в СВН и в DVCS, а политика — это «идеология». Так вот, политика не должна затрагивать механизм — пользоваться инструментом должно быть одинаково полноценно и удобно как через консоль, так и через Гуи.
Так вот, в СВН оба механизма сбалансированы, а в Гит — еще нет.
Еще раз: без знания технологии вопрос «какой инструмент выбрать» вторичен.
Т.е. если не знать, как работает SVN — неудобно будет пользоваться как тортиллой, так и командной строкой.
В случае же с SVN есть сильная зависимость от используемого клиента: в одном достаточно удобно, в другом — не очень, в командной строке в большинстве случаев почти невозможно — это, повторюсь, при реальной работе.
Т.е. если не знать, как работает SVN — неудобно будет пользоваться как тортиллой, так и командной строкой.
В случае же с SVN есть сильная зависимость от используемого клиента: в одном достаточно удобно, в другом — не очень, в командной строке в большинстве случаев почти невозможно — это, повторюсь, при реальной работе.
* «как работает SVN» — имелось в виду, что такое бранч/тэг/когда это использовать/как происходит процесс слияния/зачем он нужен и т.п., а не детальное знание внутренних механизмов.
Работа с GIT через консоль и TortoiseGit — это 2 принципиально разных подхода.
Да, при этом по сути TortoiseGit передает все управление консоли.
Но работать с TortoiseGit у многих проблем не вызывает — это «привычный» подход.
Кстати, стоит вспомнить, что 1е компиляторы C++ (тогда еще «C with Classes») транслировали сначала в C, а потом компилировали его.
P.S. на мой взгляд, процедурный и объектный подход представляют по сути одно и тоже. Значительно различаются идеологии подходов, но не их суть. Но это тема отдельного разговора ;)
Да, при этом по сути TortoiseGit передает все управление консоли.
Но работать с TortoiseGit у многих проблем не вызывает — это «привычный» подход.
Кстати, стоит вспомнить, что 1е компиляторы C++ (тогда еще «C with Classes») транслировали сначала в C, а потом компилировали его.
P.S. на мой взгляд, процедурный и объектный подход представляют по сути одно и тоже. Значительно различаются идеологии подходов, но не их суть. Но это тема отдельного разговора ;)
Создавать ветку при начале работы над каждой задачей или не создавать — вот два принципиально разных подхода. Набрать «git commit» или ткнуть правой кнопкой мыши в Explorer и выбрать «Commit» — не принципиально.
Про С++ — не смотря на трансляцию в C, никто, почему то, не пытался выполнять работу первых компиляторов С++ самостоятельно. В любом случае, детали реализации при описании идеологии не важны.
И да, статья про идеологию, если что.
Про С++ — не смотря на трансляцию в C, никто, почему то, не пытался выполнять работу первых компиляторов С++ самостоятельно. В любом случае, детали реализации при описании идеологии не важны.
И да, статья про идеологию, если что.
>Обычно людей, перешедших с SVN, в командной строке страшит относительно сложное добавление отдельных файлов и коммит части изменений. В отличии от SVN (и других централизованных систем), где это — достаточно частая операция, в git и mercurial мне это не приходилось делать вообще (в основном, благодаря легкому созданию бранчей)
а можно мысль развить — почему их это пугает? и при чем тут бранчи?
в git как раз специально разделили процесс коммита файлов на 2 этапа — сначала формируется список изменений для следующего коммита, а потому уже они коммитятся. ключ -a сделан лишь для тех случаев, когда все изменения идут в один коммит (удобство)
откройте для себя git add -i — из всех изменений даже одного файла можно сформировать несколько отдельных коммитов
а можно мысль развить — почему их это пугает? и при чем тут бранчи?
в git как раз специально разделили процесс коммита файлов на 2 этапа — сначала формируется список изменений для следующего коммита, а потому уже они коммитятся. ключ -a сделан лишь для тех случаев, когда все изменения идут в один коммит (удобство)
откройте для себя git add -i — из всех изменений даже одного файла можно сформировать несколько отдельных коммитов
поясните мысль… я например пишу код в FAR, коммичу набирая git add <ctrl-enter> <ctrl-enter> <ctrl-enter>
git commit -s
открывается редактор фара и там пишу текст комментария к коммиту. для меня это удобно
git commit -s
открывается редактор фара и там пишу текст комментария к коммиту. для меня это удобно
ок, а в чем неувязка с моими словами? правда у меня гит почему-то не запускается из виндовой консоли, хотя в PATH прописан. надо открыть гитовский шелл и уже оттуда коммитить. может это я что-то не так делаю?
я не вам ответил, извиняюсь :)
гляньте тут habrahabr.ru/blogs/Git/74839/ я описывал основные нюансы работы с git под windows
и да, у меня в путях есть C:\Program Files\Git\bin\
и да, у меня в путях есть C:\Program Files\Git\bin\
Как понимаю, комментарий для меня...
Я не призываю отказаться от консоли вообще.
Кто-то к ней привык, кому-то она удобней. Такие люди есть и будут. Но тем не менее их мало.
Для меня лично удобней в IDE правой кнопкой по проекту -> commit.
Для других — в консоли привычней и удобней.
Для третьих — в консоли скрипт по автоматической сборке проекта набросали, а сами через GUI работают.
Для выработки схемы работы с технологией существуют обзорные статьи по этим инструментам.
Но для популяризации надо все-таки ориентироваться на наиболее широкий круг пользователей.
Я не призываю отказаться от консоли вообще.
Кто-то к ней привык, кому-то она удобней. Такие люди есть и будут. Но тем не менее их мало.
Для меня лично удобней в IDE правой кнопкой по проекту -> commit.
Для других — в консоли привычней и удобней.
Для третьих — в консоли скрипт по автоматической сборке проекта набросали, а сами через GUI работают.
Для выработки схемы работы с технологией существуют обзорные статьи по этим инструментам.
Но для популяризации надо все-таки ориентироваться на наиболее широкий круг пользователей.
>Для меня лично удобней в IDE правой кнопкой по проекту -> commit.
тут же возникает вопрос коммит чего, нескольких новых файлов, текущего файла, или нех которые были исправлены с последнего коммита.
тут же возникает вопрос коммит чего, нескольких новых файлов, текущего файла, или нех которые были исправлены с последнего коммита.
Работая в IDE (или через GUI) я и не задумывался, что это разные вещи. ;)
Коммит на папке означает «измененные + новые», а по файлу — внесение изменений в конкретном файле или внесение нового фала в репозиторий.
Коммит на папке означает «измененные + новые», а по файлу — внесение изменений в конкретном файле или внесение нового фала в репозиторий.
в том то и дело что git вам позволит сделать и так и так, укажете git add. — добавит для коммита все новые изменения, укажете git add — добавит для коммита указанные файлы, мне последний вариант гораздо удобнее, т.к. часто нужно закоммитить не один файл, а все имеющие отношение, к текущему изменению состояния системы.
Вопрос не в том, чтобы найти аналог в git.
Я говорю о том, что видя необходимость работать с консолью, встречая при это кучу разных параметров, многие из которых могут значительно повлиять на процесс выполнения, я вероятнее всего не полезу в справочник по командам и не буду выносить пометки по работе с git на листочки вокруг себя.
Вероятнее всего что я просто закрою статью и останусь при инструментах, может не таких продвинутых, но удобных и привычных.
Даже если я захочу попробовать нового, непривычность к работе с консолью сводит на нет все желание.
Именно поэтому я и делаю акцент не на технологии так таковой, а на средствах работы с ней.
Я говорю о том, что видя необходимость работать с консолью, встречая при это кучу разных параметров, многие из которых могут значительно повлиять на процесс выполнения, я вероятнее всего не полезу в справочник по командам и не буду выносить пометки по работе с git на листочки вокруг себя.
Вероятнее всего что я просто закрою статью и останусь при инструментах, может не таких продвинутых, но удобных и привычных.
Даже если я захочу попробовать нового, непривычность к работе с консолью сводит на нет все желание.
Именно поэтому я и делаю акцент не на технологии так таковой, а на средствах работы с ней.
Эта статья была так написана её автором, поэтому переводчик вряд ли может помочь.
Тем более, что посвящена статья не самому гиту, а ветвлению в гите, следовательно ориентирована на пользователей этой системы, а не новичков, выбирающих инструмент. Описание какого-то GUI привело бы к тому, что большинству пришлось бы мысленно переводить команды меню и прочие действия, специфичные для данного конкретного GUI в параметры командной строки «канонического» git.
GUI — вещь часто удобная, даже для меня, и статья по различным «фронтэндам» для git была бы очень полезна IMO.
Тем более, что посвящена статья не самому гиту, а ветвлению в гите, следовательно ориентирована на пользователей этой системы, а не новичков, выбирающих инструмент. Описание какого-то GUI привело бы к тому, что большинству пришлось бы мысленно переводить команды меню и прочие действия, специфичные для данного конкретного GUI в параметры командной строки «канонического» git.
GUI — вещь часто удобная, даже для меня, и статья по различным «фронтэндам» для git была бы очень полезна IMO.
хм… только сейчас заметил что парсер отъел часть моего поста…
«git add .» добавит все изменённые файлы
«git add file1 file2 fileN» добавит для коммита указанные файлы…
«git add .» добавит все изменённые файлы
«git add file1 file2 fileN» добавит для коммита указанные файлы…
Я сижу под линуксом, но пользуюсь git-cola. В консоли с git мне лично неудобно работать.
PHPStorm\ItellyJ IDEA вполне себе хорошо работают из коробки с гитом.
не согласен совершенно. :) если я пью кофе каждое утро, не значит что все пьют кофе каждое утро. так что не надо обобщать.
Работаю под MacOS X. Я использую git в разработке уже несколько лет. Отлично с повседневными задачами справляется SourceTree, иногда я захожу в консоль что-то сделать, но только иногда.
Раньше я использовал GitX и пару его форков, тоже не жаловался.
Работаю под MacOS X. Я использую git в разработке уже несколько лет. Отлично с повседневными задачами справляется SourceTree, иногда я захожу в консоль что-то сделать, но только иногда.
Раньше я использовал GitX и пару его форков, тоже не жаловался.
все просто — у гита миллион фронтендов и каждый из них описывать неразумно. достаточно один раз понять какие консольные команды для чего нужны, а потом у фронтенда посмотреть через какую менюшку они вызываются. и всё.
я использую gitextensions и в ежедневной работе комстроку не трогаю практически — только если нужно что-то нетривиальное или при деплое на сервер.
я использую gitextensions и в ежедневной работе комстроку не трогаю практически — только если нужно что-то нетривиальное или при деплое на сервер.
Я не предлагаю описывать все.
Тот же C# имеет туеву кучу IDE, инструментов и т.д.
Я предлагаю описать 1, причем для переходящих с SVN (где на винде популярен TortoiseSVN) удобен будет именно TortoiseGit.
Тот же C# имеет туеву кучу IDE, инструментов и т.д.
Я предлагаю описать 1, причем для переходящих с SVN (где на винде популярен TortoiseSVN) удобен будет именно TortoiseGit.
кмк просто описанием кнопок не решить проблему перехода. переходящие должны сначала понять концепцию dvcs, а после этого кнопки выучить будет тривиально.
Согласен, вопрос перехода не решается нажатием кнопок.
Но и обзорные статьи «повторяй в консоли за мной» тоже не способствуют ни переходу, ни понимании концепции.
Если поискать «TortoiseGit» здесь, на хабре, то мы ни одной статьи не найдем с ним. А вот комментариев достаточно. Причем половина ответ на «а если не в консоли?», а 2я половниа — «спасибо за совет».
Но и обзорные статьи «повторяй в консоли за мной» тоже не способствуют ни переходу, ни понимании концепции.
Если поискать «TortoiseGit» здесь, на хабре, то мы ни одной статьи не найдем с ним. А вот комментариев достаточно. Причем половина ответ на «а если не в консоли?», а 2я половниа — «спасибо за совет».
В примечании есть ссылка на gitflow, реализующий данный способ управления проектом. Хотя, согласен, сам gitflow тоже работает через командную строку.
Для данной модели идеальным вариантом, наверно, был бы плагин для того же TortoiseGit, который поддерживал бы gitflow. Но его пока не существует в природе.
Кстати, удобство работы — это вопрос индивидуальный. Мне удобно работать с Git через командную строку даже в Windows (открыто окно с git shell). Очень ускоряют процесс автодополнение по табу и возможность делать очередь команд.
Но получается так, что одни люди стараются не отрывать руки от клавиатуры, а другие от мышки. И в разработке Git явно доминируют первые. :)
Для данной модели идеальным вариантом, наверно, был бы плагин для того же TortoiseGit, который поддерживал бы gitflow. Но его пока не существует в природе.
Кстати, удобство работы — это вопрос индивидуальный. Мне удобно работать с Git через командную строку даже в Windows (открыто окно с git shell). Очень ускоряют процесс автодополнение по табу и возможность делать очередь команд.
Но получается так, что одни люди стараются не отрывать руки от клавиатуры, а другие от мышки. И в разработке Git явно доминируют первые. :)
Лично для меня достаточно того, чтобы IDE подсвечивала измененные файлы, показывала diff'ы. Ну, иногда коммитить удобнее, чем из консоли. Но все возможные действия перекладывать на плечи IDE бессмысленно.
Не понимаю почему вы считаете, что интерфейс командной строки чем-то плох или не удобен. Ведь именно это и есть основной интерфейс работы с git. Зачем разбирать какой-то графический клиент, если им никто не пользуется? Зачем вообще пользоваться графическим git клиентом. По-моему выгода от того, что вы будете тыкать мышкой, а не набирать команды нулевая.
потому что привычки менять очень тяжко, да и переучиться работать из gui в консоль не всегда хочется.
Лично мне он не удобен и непривычен. Я не говорю за всех. Но многие со мной согласятся.
Новую привычку вырабатывать для замены технологии, которая в целом меня устраивает я не вижу ни какого смысла. Завтра выйдет еще одна, после завтра — следующая. И каждая будет лучше предыдущей. И каждая своей новой привычки потребует.
А если новая будет «как старая, только лучше» — вот на это я согласен.
Новую привычку вырабатывать для замены технологии, которая в целом меня устраивает я не вижу ни какого смысла. Завтра выйдет еще одна, после завтра — следующая. И каждая будет лучше предыдущей. И каждая своей новой привычки потребует.
А если новая будет «как старая, только лучше» — вот на это я согласен.
Здесь ситуация как с ядром. Есть консольный git и его подразумевают по-умолчанию. Если хочется приключений, то используйте графическиую обёртку, но будьте готовы что вас могут не понять, потому что большинству удобен git из консоли. Не думаю что вы чем-то принципиально чем-то отличаетесь от этого большинства.
Может git — просто не то что вам нужно?
Может git — просто не то что вам нужно?
> большинству удобен git из консоли.
А большинству, которому не удобна консоль просто не перешли на git.
Вот и получаем что большинство на консоли, потому как кроме консоли ни чего нет или не было в момент когда они переходили (ну или о GUI просто не афишируют).
Честно, я не считаю что это в пользу git говорит. Потому как популярные инструменты имеют GUI, какими бы они продвинутыми в консоли не были. Лично для меня появился сейчас TortoiseGit, что дает мне возможность «пощупать» и сравнить с SVN.
Появись статья, подобная этой, но с TortoiseGit вместо консоли — желающих «пощупать» (а затем и перейти на работу с ним) прибавилось бы значительно.
А большинству, которому не удобна консоль просто не перешли на git.
Вот и получаем что большинство на консоли, потому как кроме консоли ни чего нет или не было в момент когда они переходили (ну или о GUI просто не афишируют).
Честно, я не считаю что это в пользу git говорит. Потому как популярные инструменты имеют GUI, какими бы они продвинутыми в консоли не были. Лично для меня появился сейчас TortoiseGit, что дает мне возможность «пощупать» и сравнить с SVN.
Появись статья, подобная этой, но с TortoiseGit вместо консоли — желающих «пощупать» (а затем и перейти на работу с ним) прибавилось бы значительно.
Это прекрасно, когда люди используют инструменты которые удобны им. Кому-то не удобен консольный git и он использует TortoiseSVN. И это хорошо. Каждый может выбрать инструмент себе по душе, благо выбор есть.
Вы же расцениваете пользователя git не как человека сделавшего свой осознанный выбор, а как человека которых пытается переползти на TortoiseGIT с TortoiseSVN.
Можно писать статьи для людей не способных запомнить пару команд, но если их никто не пишет, видимо, они никому не нужны.
Вы же расцениваете пользователя git не как человека сделавшего свой осознанный выбор, а как человека которых пытается переползти на TortoiseGIT с TortoiseSVN.
Можно писать статьи для людей не способных запомнить пару команд, но если их никто не пишет, видимо, они никому не нужны.
Скажите, что я ошибаюсь и статья по переходу на TortoiseGIT с TortoiseSVN не нужна.
habrahabr.ru/blogs/development_tools/106916/
Как показал опрос, очень даже нужна.
При этом я рассматриваю пользователя git как сделавшего сознательный выбор (по другому выбор обычно не делается, только если навязали, но о выборе здесь говорить не приходится).
Я говорю о том, что много желающих работать с GIT просто даже и не будут пробовать — потому как вместо привычных меню и диалогов увидят консоль.
А на TortoiseSVN я остановился потому, что он популярный для SVN. При наличии аналога в лице TortoiseGIT переход на GIT может оказаться намного проще, чем многим думается.
habrahabr.ru/blogs/development_tools/106916/
Как показал опрос, очень даже нужна.
При этом я рассматриваю пользователя git как сделавшего сознательный выбор (по другому выбор обычно не делается, только если навязали, но о выборе здесь говорить не приходится).
Я говорю о том, что много желающих работать с GIT просто даже и не будут пробовать — потому как вместо привычных меню и диалогов увидят консоль.
А на TortoiseSVN я остановился потому, что он популярный для SVN. При наличии аналога в лице TortoiseGIT переход на GIT может оказаться намного проще, чем многим думается.
По-моему TortoiseHg достаточно развитый продукт, более интересный, нежели TortoiseGit
Почему-то никто не упоминает TortoiseGit — просто волшебнуй гуй для гита, работающий из контекстного меню проводника. Очень, очень мощный и удобный.
А под маком CtrlCtrl, и команду, благо что большинтво команд очень краткие, ключи вообще очень редко нужны.
А под маком CtrlCtrl, и команду, благо что большинтво команд очень краткие, ключи вообще очень редко нужны.
уупс, не то ._.
progit.org/book/ru/ — тут хорошее описание, только опять же с консолью.
progit.org/book/ru/ — тут хорошее описание, только опять же с консолью.
Я не считаю git технологией, я считаю git готовым инструментом.
А вы привыкайте, насколько я знаю даже под виндой есть консоль для git
Cпасибо за перевод. Оригинал давно появился в закладках — когда-то, именно он помог догнать как эффективно работать в команде.
Схема не учитывает модель, когда необходимо поддерживать более одной продакшн ветки (разные версии продукта). А остальное все действительно великолепно. Более общий вариант: www.infoq.com/articles/agile-version-control
Просто делается больше одной продакшн-ветки =)
На самом деле, я бы даже при одной версии продукта вел разработку в master, а под продакшн завел бы соответствующую ветку. Но тут кому как больше удобно уже.
На самом деле, я бы даже при одной версии продукта вел разработку в master, а под продакшн завел бы соответствующую ветку. Но тут кому как больше удобно уже.
Согласен. Сам использую 3 основные ветки, production, master и testing. Потому что так повелось что в master были разные дев плюшки. Вобще пост весьма хорош, т.к. описывает простую логику ведения проекта в нескольких ветках и если разобраться зачем это делается, то работать становится проще и мержить руками надо меньше.
В таких статьях всё красиво и понятно, но как обстоят дела на практике?
>>Ветви исправлений (hotfix branches)
Допустим, обнаружили серьёзный баг в ветке master, делаем hotfix, исправление бага затрагивает один файл/класс, пару методов в нём.
Но в то же время над этим файлом/классом идёт работа в ветке develop — например, его рефакторят, или частично меняют логику работы.
>>Когда баг исправлен, изменения надо влить обратно в главную ветвь (master), а также в ветвь разработки (develop), чтобы гарантировать, что это исправление окажется и в следующем релизе. Это очень похоже на то, как закрывается ветвь релиза (release branch).
Что будет конкретно с этим файлом? Он перепишется и тем самым похерится пару недель работы в ветке develop?
Или Git предложит вручную слить develop- и hotfix-версии файлов?
Понятно, что в случае пары методов проще переписать их с учётом исправления бага, но что если в реале баг может потребовать изменения десятков файлов, сотен строк кода из ветки master, которые уже частично и значительно изменены в ветке develop относительно master? Что сделает Git, если сказать ему
>>Ветви исправлений (hotfix branches)
Допустим, обнаружили серьёзный баг в ветке master, делаем hotfix, исправление бага затрагивает один файл/класс, пару методов в нём.
Но в то же время над этим файлом/классом идёт работа в ветке develop — например, его рефакторят, или частично меняют логику работы.
>>Когда баг исправлен, изменения надо влить обратно в главную ветвь (master), а также в ветвь разработки (develop), чтобы гарантировать, что это исправление окажется и в следующем релизе. Это очень похоже на то, как закрывается ветвь релиза (release branch).
Что будет конкретно с этим файлом? Он перепишется и тем самым похерится пару недель работы в ветке develop?
Или Git предложит вручную слить develop- и hotfix-версии файлов?
Понятно, что в случае пары методов проще переписать их с учётом исправления бага, но что если в реале баг может потребовать изменения десятков файлов, сотен строк кода из ветки master, которые уже частично и значительно изменены в ветке develop относительно master? Что сделает Git, если сказать ему
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff hotfix-1.2.1
попробует смержить автоматически, не получится — надо будет мержить вручную
не знаю как git, но mercurial будет вам показывать три файлика: базовый (который был одинаковым в обоих версиях), то, что вы наисправляли в фиксе и то, что наменялось в текущем девелопменте. Вы везде выбираете (в случае конфликта) то, что в девелопмент-ветке, но в то же время мимо вас не проходит ни одно изменение хотфикса. Если код куда-то переехал вы видите что конкретно надо зафиксить, идете туда, куда оно переехало и руками добавляете фикс. И так с каждым конфликтом. СВН, конечно, в пролете в таких ситуациях.
Или я чего-то не допонял?)
Или я чего-то не допонял?)
А кто может мне внятно объяснить, зачем удалять бранчи? Имхо, пусть себе лежат. В одной из компаний, где я работал, создавался бранч под каждый баг или реквест в багтреккере. Соответственным образом подбиралось имя ветки. Потом легко было найти, как тот или иной баг фиксился.
не надо плодить лишних сущностей. а чтобы найти как фиксился баг — коммит месседжи надо внятные писать, с номером таска/бага из трекера
Чтобы найти как фиксился баг — нужно писать к багу комментарии вида «Исправлено в [21] ревизии» (в данном случае используется синтаксис Trac)
Согласно статье ветки удаляются из локального репозитория, в центральном этих веток нет. Поэтому и удалять оттуда нечего :)
1. выше уже правильно указали — в коммитмессадже явно указывайте номер тикета, который этот коммит закрывает. Редмайн, увидев такое, статус тикета поменять может к примеру на Need feedback и в тикете укажет, что к нему имеет отношение такой-то коммит.
2. ставьте тэг, раз так надо запомнить, а то в ветках запутаетесь.
2. ставьте тэг, раз так надо запомнить, а то в ветках запутаетесь.
а .NET-проекты можно туда пихать?
Можно даже .bat-файлы и конфиги =)
можно даже бложек
gitwrite.com/
gitwrite.com/
А я использую git для синхронизации многочисленных конфигов на нескольких компьютерах: ~/sync/ (который под гитом) содержит сами конфиги, а, к примеру, ~/.vimrc — симлинк на ~/sync/vim/vimrc, ~/.muttrc -> ~/sync/mail/muttrc.
Плюсы — если меняются файлы на двух или более машинах, то при мерже с ручной правкой сразу видно что и как было изменено.
Дополнительный плюс — если даже конфиг был удалён, он останется в истории :)
Если куплю новый компьютер/установлю новую систему, то надо будет просто выполнить git clone ssh//segoon@XXX:sync && cd sync && ./scripts/update-links.
Если задолбает история, то можно будет сделать rm .git && git init && git add. && git commit -m 'After armageddon'
Плюсы — если меняются файлы на двух или более машинах, то при мерже с ручной правкой сразу видно что и как было изменено.
Дополнительный плюс — если даже конфиг был удалён, он останется в истории :)
Если куплю новый компьютер/установлю новую систему, то надо будет просто выполнить git clone ssh//segoon@XXX:sync && cd sync && ./scripts/update-links.
Если задолбает история, то можно будет сделать rm .git && git init && git add. && git commit -m 'After armageddon'
>Технически это реализуется несложно: Алиса создаёт удалённую ветку Git под названием bob, которая указывает на репозиторий Боба, а Боб делает то же самое с её репозиторием.
Не очень понятно, как именно это несложно делается. Допустим, Алиса в Самаре, а Боб в Европе. В svn все понятно — делается ветка в центральном репозитории, и в ней работают и Алиса и Боб, позже производится слияние с trunk. Собственно, именно так мы и делаем. Какой легкий способ для этого есть в git?
Не очень понятно, как именно это несложно делается. Допустим, Алиса в Самаре, а Боб в Европе. В svn все понятно — делается ветка в центральном репозитории, и в ней работают и Алиса и Боб, позже производится слияние с trunk. Собственно, именно так мы и делаем. Какой легкий способ для этого есть в git?
самый простой способ такой:
git checkout master #переключаемся на то от чего хотим отбранчеваться (в данном случае от мастера) git pull #получаем последние изменения git checkout -b 1234_editor_redo_feature #создаем локальную ветвь git-punlish-branch #публикуем её
Получается, что разработчики создают ветки для задач в центральном репозитории. Понятно, но почему эта технология не описывается в git-литературе, в том числе и в этой статье? Тут же какой-то другой способ подразумевается.
да, только не обязательно в центральном, это могут быть любые (не локальные) репозитарии т.е можно на гитхаб создать свой реп и рассказать о нем Алисе (дать ей прав на него) и она туда будет коммитить, или подключиться к её репу и забрать из него нужную ветвь и смерджить со своим репом.
«это могут быть любые (не локальные) репозитарии». А что мешает расшарить локальные репозитории?
Недоступность из вне локального репозитория, например.
Упс, видимо, не так понял вопрос. К локальному репозиторию любого разработчика можно обращаться, при условии наличия ssh-доступа к целевой машине и к папке с репозиторием — это из коробки. Плюс, можно настроить у себя какой-нибудь gitosis, и дать доступ другим разработчикам к нему (тогда ssh-доступ не нужен).
нет-нет, это не было вопрос, просто человек так явно указал что репозитории должны быть не локальными, как будто есть какая-то проблема с расшариванием локальных.
конечно есть проблема :) если bob сидит за 3-мя файрволами и наружу для него открыт только 80/443 порт. Легко и непринужденно как с github не получится пробиться к локальному репозиторию Боба…
что вы имеете ввиду под расшариванием? публикация локального репа на общедоступном ресурсе или пробивку туннеля?
Скажите а возможен ли такой сценарий: у меня есть ветка фичи feature1, я над ней работал, реализовал что нужно и потом слил ее в девелоп ветку, прошло немного времени и появилась необходимость еще кое-что доработать в этой фиче. Могу ли я опять перейти на ветку feature1, доработать что нужно и снова влить ее в ветку девелоп? Т.е. получается вот так:
Так можно делать?
$ git checkout develop
$ git merge --no-ff feature1
$ git push origin develop
(прошло время...)
$ git checkout feature1
(какие-то изменения...)
$ git checkout develop
$ git merge --no-ff feature1
$ git push origin develop
Так можно делать?
По поводу gitflow, про который вскользь сказано. Привожу перевод примера использования.
Видеоролик по теме
vimeo.com/16018419
# Создание веток master/developer/release/hotfix
$ git flow init
# Начинаем работать над функционалом feature1 (ответвление от develop)
$ git flow feature start feature1
# делаем изменения
$ git add ...изменения...
$ git commit -m "изменения для feature1"
# Эта команда сделает слияние feature1 с develop и удалит ветку
$ git flow feature finish feature1
# Давайте начнём работу над релизом
$ git flow release start release1
# делаем изменения
$ git add ...изменения...
$ git commit -m "release1"
# Эта команда сделает слияние release1 с master
$ git flow release finish release1
Видеоролик по теме
vimeo.com/16018419
Для автоматического
(Не знаю, с каких версий гита эта фишка работает, но точно есть в
--no-ff пользуюсь такими строчками в кофиге:[merge]
ff = false
(Не знаю, с каких версий гита эта фишка работает, но точно есть в
git version 1.7.2.5)
Я ветки функциональности и фиксов называю по номеру таски, например issue_123.
Дайте, пожалуйста, консультацию, потому что я не понимаю, что происходит с файлом проэкта, если его редактируют одновременно два девелопера, и потом push'ат изменения в master?
Если изменения произведены в разных местах, то git автоматически применит оба изменения. Если же изменения пересекаются, то возникнет конфликт, который уже потребуется исправлять руками одному из авторов.
расскажите, как разрешается следующая ситуация:
появляются новые feature-branches (fb) из dev-branch (dev). Но изменения в одной из них влияют на работу и реализацию в другой (т.е. функционально они слабо связаны, но тем не менее взаимное влияние у них имеется, например, использованием новой версии протокола, которое в одной fb обкатано, но функциональность из другой ветки может поломаться при вливании их обеих в dev). Что в таком случае делать? По описанию feature-branches друг в друга не вливаются, только лишь из/в dev. Допустим, влили мы обе fb в dev, что-то сломалось, порождается новая fb из dev типа «латание косяков после слияния fb1 и fb2» или же каждая из fb (или какая-то одна) забирает изменения из dev и латает косяки у себя с последующим возвратом изменений в dev?
появляются новые feature-branches (fb) из dev-branch (dev). Но изменения в одной из них влияют на работу и реализацию в другой (т.е. функционально они слабо связаны, но тем не менее взаимное влияние у них имеется, например, использованием новой версии протокола, которое в одной fb обкатано, но функциональность из другой ветки может поломаться при вливании их обеих в dev). Что в таком случае делать? По описанию feature-branches друг в друга не вливаются, только лишь из/в dev. Допустим, влили мы обе fb в dev, что-то сломалось, порождается новая fb из dev типа «латание косяков после слияния fb1 и fb2» или же каждая из fb (или какая-то одна) забирает изменения из dev и латает косяки у себя с последующим возвратом изменений в dev?
Не нужно смотреть на предлагаемый workflow как на жёсткий шаблон, от которого невозможно отступить. Это всего лишь общая рекомендация, как вести себя в «обычном случае», а с различными нестандартными ситуациями часто проще всего разбираться, используя весь доступный арсенал команд git. Если есть ощущение, что в этом случае будет удобно слить две feature-ветки — договоритесь об этом с командой и сливайте. Если есть ощущение, что лучше перекинуть один-два коммита из одной ветки в другую с помощью
git cherry-pick — договоритесь об этом с командой и перекидывайте. Если есть ощущение, что лучше слить ветки независимо, а потом править возможные дефекты в новой fix-ветке — делайте так. Всё зависит только от Вас.
Некрокомментарий.
Данная схема работает (и в Git, и в SVN) при условии только одной версии в эксплуатации. Это типично, например, для заказной разработки под клиента.
Если поддерживаем одновременно несколько релизов (типично для вендоров), то схему придется основательно ломать.
Данная схема работает (и в Git, и в SVN) при условии только одной версии в эксплуатации. Это типично, например, для заказной разработки под клиента.
Если поддерживаем одновременно несколько релизов (типично для вендоров), то схему придется основательно ломать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Удачная модель ветвления для Git