Comments 228
Вот еще замечательный ресурс, на котором я сам учил GIT: githowto.com
Есть на русском.
Есть на русском.
Оф.доки тоже на русском есть
Но есть и не мало тех среди нас, кто не использует VCS по причине предвзятого мнения о системах контроля версий.
Ребята, покажитесь!
Конечно, не показательно (по контексту опроса), но немного пугающе.
habrahabr.ru/company/ruward/blog/215629/
85% опрошенных компаний используют систему контроля версий. Непонятно, как работают остальные 15%… Наверное, делают простые проекты, которые создаются одним разработчиком за одну неделю.
habrahabr.ru/company/ruward/blog/215629/
Когда-то, давным-давно, работал по принципу: одна площадка, каждый пилит свой кусок.
Я думаю, с тех пор у многих ничего не изменилось.
А еще, помню, делали софт, и в конце задачи rsync'ались на машины всех остальных разрабов. Но это уже вообще за царя гороха, что называется.
Я думаю, с тех пор у многих ничего не изменилось.
А еще, помню, делали софт, и в конце задачи rsync'ались на машины всех остальных разрабов. Но это уже вообще за царя гороха, что называется.
К тому, как работают остальные. В одной из компаний, с которыми я сталкивался, в качестве хранилища кода (не скажешь же, что VCS) использовали реляционную БД.
Это вы, случайно, не про Midgard говорите? :)
midgard-project.org/
midgard-project.org/
UFO just landed and posted this here
Для домашнего пользования я знаю таких. На работе почти (не Git) всё (только общие проекты, персональные только я свои контролирую) хорошо.
VCS — для неуверенных в себе. Профессионалы не используют VCS. Они не используют версии. Они сразу пишут финальный вариант. Без ошибок. Без тестов и опросов пользователей.
UFO just landed and posted this here
UFO just landed and posted this here
А чего народ минусует? Ну понятно, что в каком-то батнике автосборки обновление исходников из репозитория можно вызвать командой. Но в остальном, вы что, будете логи изменений в текстовом виде смотреть? Или версии в консоли сравнивать?? Или может вы результат выполнения blame каким-нибудь grep-ом анализируете??? Конечно сейчас набежит куча юникс-гиков с воплями «КС — это лучший интерфейс общения компьютера и человека» но ВЫ УЖ МЕНЯ ИЗВИНИТЕ, избаловался я — подавайте мне нормальный функциональный удобный GUI с рюшечками, хотя бы на уровне TortoiseSVN. На меньшее ни ради какого «супер навороченного» функционала Git'а не согласен.
В процессе миграции рабочего окружения с windows/tortoisesvn на гит и unix я первое время была того же мнения и искала удобный GUI. Нашла, благо под мак есть отличный SourceTree + разработчики из IntelliJ запилили достаточно удобную интеграцию в IDE. Но вот с течением времени все свелось к тому, что в rubymine/idea из всего функционала их VCS оболочки я использую только диффы и делаю коммиты ( удобно просмотреть локальные правки ), а SourceTree — это тяжелая артиллерия при сложных мержах или когда нужно разобраться в каше веток чужого проекта. Все остальное ( log, push/pull, rebase, атомарные коммиты, бранчевание ) теперь в терминале, так как быстрее и затачивается под себя.
А вот и толпа подоспела…
Ну почитать комиты конечно очень удобно в gitk, но всё остальное уж извините но в shell'е поудобнее будет. Хотя тут кому что приятнее и дело не в том какой ОС вы пользуетесь, просто либо вам уютно сидеть в терминале, либо нет.
Ну почитать комиты конечно очень удобно в gitk, но всё остальное уж извините но в shell'е поудобнее будет. Хотя тут кому что приятнее и дело не в том какой ОС вы пользуетесь, просто либо вам уютно сидеть в терминале, либо нет.
Не знаю, как насчет git-а, но в целом в мире очень немного хороших GUI. Командная строка зачастую позволяет сделать все быстрее и удобнее, хотя бы потому что не требует двигать мышкой. Это даже несмотря на то, что я даже близко не гуру командной строки и баша.
Да, логи и диффы изменений я, конечно, буду смотреть в текстовом виде (поскольку это текст и есть).
Да, логи и диффы изменений я, конечно, буду смотреть в текстовом виде (поскольку это текст и есть).
Базовый гайд на bitbucket подразумевает минимальное использование командной строки. Если еще не пробовали, можете попробовать)
>> Я вообще не могу вспомнить, когда и зачем юзал гит или свн из командной строки…
Могу сказать, что PHPStorm нередко не может сделать commit при исправлении конфликтов. Только через консоль получается.
Ну и ещё git status, git -rm --cached
Могу сказать, что PHPStorm нередко не может сделать commit при исправлении конфликтов. Только через консоль получается.
Ну и ещё git status, git -rm --cached
init и config делаю. Ещё помню что-то хитрое с коммитами делал в текущей ветке.
UFO just landed and posted this here
Я вообще не могу вспомнить, когда и зачем юзал гит или свн из командной строки…
Когда-то я начал свое знакомство с RCS с SVN. Я просто посчитал важным попробовать его, понять как оно в целом работает, концепции, достоинства и недостатки, дабы в будущем было с чем сравнивать. История, как никак.
В качестве «клиента» выбрал tortoise svn. Ох, каким же это кошмаром! Казалось бы, вот создаем репозиторий, вот делаем коммиты, вот история перед глазами. Но проблема в том, что как только я сталкивался с трудностями или чем-то не понятным — приходилось отправляться перечитывать главы руководства. Особенно много хлопот доставили начальные директории. Т.е. где конкретно у начинается репозиторий, где проект и т.д.
После того как я попробовал поработать с svn в терминале — все начало вставать на свои места, пришло какое-то понимание и предсказуемость. С гитом знакомиться начал уже сразу с шелла, потом как-то глянул на гуи и… ужаснулся. Как вообще его можно использовать?)
p.s. гит профессионально не использую, программистом не являюсь
UFO just landed and posted this here
отрывать левую руку от головы, а правую от мышки
работы с действительно большими проектамиТо есть левая рука в перманентном фейспалме из-за отчаяния от масштабов проекта и отвратительной локализации функциональности, поэтому можно пользоваться только GUI с помощью свободной правой руки с мышкой? :)
Я думаю, GUI действительно полезен для всяких мерджилок. Там side-by-side сравнение очень кстати. Но что такого помимо просмотра диффов и мерджей, где GUI значительно может помочь?..
Любые DCVS (будь то гит или меркуриал) — это уже не просто какой-то плюс в резюме для разработчика, а уже своего рода часть культуры разработки, без которой уже просто нельзя. Не важно, один ты или в команде — если не умеешь согласовывать свою работу с чужой — то ты очень жирный минус как в команде, так и в опенсорс-проекте, начинаемым тобою. Если вы не используете какую-либо DCVS — можете считать себя в прошлом веке. Если ваша команда до сих пор не смогла перейти на что-либо, контролирующее историю разработки — то вы, как владелец бизнеса — уже теряете деньги и очень серьезно пора подумать как эту ситуацию изменить. Особенно если команда начинает упираться (это в особо запущенных случаях).
Если вы наемный разработчик и вам руководство сильно мешает использовать DCVS — увольняйтесь, это тупик.
Если вы работодатель и ваша команда сильно не хочет использовать DCVS — увольняйте, это тоже тупик.
www.codeschool.com/courses/try-git
Если вы наемный разработчик и вам руководство сильно мешает использовать DCVS — увольняйтесь, это тупик.
Если вы работодатель и ваша команда сильно не хочет использовать DCVS — увольняйте, это тоже тупик.
www.codeschool.com/courses/try-git
В hola.org вообще cvs используют и слушать не хотят про эти ваши гиты)
При всей моей любви к DVCS, всё же существуют валидные случаи, когда git хуже, например, svn. Если разрабатывается огромный проект и объём истории весит порядка нескольких терабайт, то тупо непрактично заставлять каждого разработчика держать копию всей истории локально. Насколько мне известно, git пока ещё не умеет полноценно работать с частичной историей.
Что в вашем понимании «огромный проект»? Мне приходилось работать с репозиториями 50 000 коммитов при ежедневном обновлении около 100 бранчей (и несколько сотен новых коммитов). С точки зрения клиента это заметно только в том, что иногда приходится делать git gc, ибо большое количество объектов замедляет операции с репозиторием. Но это замедление практически незаметно. На локальных операциях с ветками сказывается чуть менее чем никак.
Если же в репозитории хранить блобы по 100 мегабайт, то это уже проблема организации данных а не DVCS как таковой.
Если же в репозитории хранить блобы по 100 мегабайт, то это уже проблема организации данных а не DVCS как таковой.
История ~500K коммитов. Бинарных блобов минимум. Полная история в git'е, как я сказал выше, занимает несколько терабайт.
Ну это уже серьезные размеры, да. Но тут уже можно выкачивать конкретные ветки, а не делать git fetch.
В конце концов, никому не нужно «все». Коллективы могут иметь непересекающиеся наборы бранчей и только «центр» хранит все актуальные ветки.
В конце концов, никому не нужно «все». Коллективы могут иметь непересекающиеся наборы бранчей и только «центр» хранит все актуальные ветки.
Скажите, а для чего вообще нужен репозиторий с 500к коммитов. Для каких целей реально может пригодиться история в пятьсот тысяч версий?
Не соглашусь с вами.
Есть два момента, где git реально проигрывает svn: большие репозитории и права доступа.
Так как svn работает с отдельными директориями, вы можете иметь репозиторий в несколько гигов (например, вы храните там xml-ки, или графические файлы), и не испытывать никакого дискомфорта. Разработчики используют одну директорию, дизайнеры — другую, и при этом вы имеете всегда единую версию. Git с такими размерами начнет вас жутко бесить (а потом просто сломается).
Проблема с правами не такая существенная, и решается разделением на несколько репозиториев с индивидуальными правами. Но так вы теряете единую версию, что довольно неудобно.
И вот тут вы начинаете использовать git локально, а svn централизованно. И прекрасно себя чувствуете :)
Есть два момента, где git реально проигрывает svn: большие репозитории и права доступа.
Так как svn работает с отдельными директориями, вы можете иметь репозиторий в несколько гигов (например, вы храните там xml-ки, или графические файлы), и не испытывать никакого дискомфорта. Разработчики используют одну директорию, дизайнеры — другую, и при этом вы имеете всегда единую версию. Git с такими размерами начнет вас жутко бесить (а потом просто сломается).
Проблема с правами не такая существенная, и решается разделением на несколько репозиториев с индивидуальными правами. Но так вы теряете единую версию, что довольно неудобно.
И вот тут вы начинаете использовать git локально, а svn централизованно. И прекрасно себя чувствуете :)
По-моему первая проблема как и вторая решается разделением на отдельные репозитории, тем более что с этими частями работают разные люди в основном.
Во-первых, вы теряете тем самым единую версию репозитория, и поддержка версионирования становится затрудненной.
Кроме того, первая проблема не решается таким образом. Делать под каждый элемент дизайна отдельный репозиторий, конечно, можно, но очень неудобно.
Кроме того, первая проблема не решается таким образом. Делать под каждый элемент дизайна отдельный репозиторий, конечно, можно, но очень неудобно.
Я согласен, что есть случпи когда это удобнее. Но все-таки у SVN и GIT разная парадигма работы с проектами, в SVN зачастую удобнее держать все в одном большом репозитории, а в GIT принято разделять на более мелкие. Вы сами написали, что разработчики используют одну часть, а дизайнеры другую, так вот в GIT приянято такие репозитории просто разделять, чтобы можно было удобно с ними работать.
Да, я это прекрасно представляю. Но гит устроен таким образом, что плохо поддерживает большие репозитории, с рабочей копией в несколько гигов. А согласитесь, дизайнерам удобнее работать с одним репозиторием designers.git, чем с десятком (иначе один большой не разобъешь на маленькие).
Собственно, это спор ни о чем. Гит — прекрасное средство, очень мощное. Да, это всё-таки не потребительский продукт, но он и не для домохозяек предназначен. И естественно, у него есть границы применимости. И в некоторых случаях svn — тоже весьма мощное средство — бывает удобнее. Если знаешь где что использовать, то и претензий к инструментам не будет.
Собственно, это спор ни о чем. Гит — прекрасное средство, очень мощное. Да, это всё-таки не потребительский продукт, но он и не для домохозяек предназначен. И естественно, у него есть границы применимости. И в некоторых случаях svn — тоже весьма мощное средство — бывает удобнее. Если знаешь где что использовать, то и претензий к инструментам не будет.
Вы немного путаете понятия: git отлично умеет работать с частичной историей. Он не умеет работать с удалённой историей (то есть с той историей, которая не у вас локально хранится, а где-то на сервере).
Нет, я не путаю понятия. Судя по всему, ограничения о которых я говорил, уже не актуальны: blog.oio.de/2014/02/06/better-support-for-shallow-clones-in-git-1-9/
Возможно вам будет удобно реорганизовать столь обьемную историю в набор субмодулей, тогда разработчики могли бы работать именно с частями проекта (частями истории проекта). Если есть какие-то бинарные данные в репе и их действительно необходимо по тем или иным причинам держать в связке с кодом (например, запакованные чем-то вроде themida билды ехешников, которые нужно проверять на множестве машин/сборок/виртуалок, чтобы все было всегда пучком и софт третьей стороны не ломал наши сборки + сюда же по каждой такой сборке свой отчет по тестированию) — то это можно и нужно реорганизовывать. Есть авторские эскизы, по которым ведется работа/обсуждение — также, в отдельную папку/субмодуль. Есть сомнение что на каждую задачу каждый разработчик обязан таскать полностью весь проект.
git-scm.com/book/ru/Инструменты-Git-Подмодули
Если это недопустимо и проект полностью неразборный — то так или иначе придется подумать над упрощением работы с ним, рано или поздно это выльется в замедление процесса разработки = потерю денег и конкурентного преимущества в скорости роста.
git-scm.com/book/ru/Инструменты-Git-Подмодули
Если это недопустимо и проект полностью неразборный — то так или иначе придется подумать над упрощением работы с ним, рано или поздно это выльется в замедление процесса разработки = потерю денег и конкурентного преимущества в скорости роста.
Ой, ну ладно уж. У меня прошлый проект был на GIT, а на текущем — SVN. Перейти на GIT могу в любой момент. Но смысла не вижу — SVN удобнее на простых операциях: тупо на коммит требуется меньше действий, проект небольшой, бранч актуальный всегда только один — что на проде стоит. Короче не везде фичи GIT нужны, а сложности они добавляют. Про всякие приколы с настройкой гита под винду — я вообще молчу.
Я и в дропбоксе иногда код держу — какие-нибудь там задачки на пару страниц кода. Что мне теперь — голову пеплом посыпать и уйти на пенсию?
Я и в дропбоксе иногда код держу — какие-нибудь там задачки на пару страниц кода. Что мне теперь — голову пеплом посыпать и уйти на пенсию?
Меня останавливает только то, что есть еще структура БД и части кода хранятся в полях БД.
По хорошему, «Я не использую git, так как код в БД» — нехорошая фраза.
«Я не держу код в БД, так как не смогу использовать git» — хорошая фраза.
«Я не держу код в БД, так как не смогу использовать git» — хорошая фраза.
UFO just landed and posted this here
Насколько я знаю такой подход значительно усложняет сам процесс разработки. Впрочем, если есть хорошие ссылки — киньте почитать.
UFO just landed and posted this here
Ну так а потом мне можно будет менять структуру БД только в этих файлах? Могу я зайти в какой-нибудь MySQLAdmin (или в другую удобную мне систему) и поправить что-нибудь?
Или взять пример такой: в базе данных хранятся пункты меню (сайта, программы — не важно). Разработчик добавил пункт меню в панели управления и работает с новым ID (автоинкремент) в программе. Если INSERT еще можно в миграцию вставить (вручную?), то откатить такие изменения при наличии других подобных будет невозможно (вы не знаете до какого значения откатывать автоинкремент).
Я уже не говорю о том, что все эти выкрутасы с контролем версий не идут в стандартных пакетах систем контроля версий. Скорее всего придется самим писать/дописывать/додюдюривать… это соразмерно целому отдельному проекту.
Или взять пример такой: в базе данных хранятся пункты меню (сайта, программы — не важно). Разработчик добавил пункт меню в панели управления и работает с новым ID (автоинкремент) в программе. Если INSERT еще можно в миграцию вставить (вручную?), то откатить такие изменения при наличии других подобных будет невозможно (вы не знаете до какого значения откатывать автоинкремент).
Я уже не говорю о том, что все эти выкрутасы с контролем версий не идут в стандартных пакетах систем контроля версий. Скорее всего придется самим писать/дописывать/додюдюривать… это соразмерно целому отдельному проекту.
UFO just landed and posted this here
Ну так а потом мне можно будет менять структуру БД только в этих файлах? Могу я зайти в какой-нибудь MySQLAdmin (или в другую удобную мне систему) и поправить что-нибудь?
Т.е. вы на работающую production БД заходите гуевой тулзой и правите схему прямо налету?
Т.е. вы на работающую production БД заходите гуевой тулзой и правите схему прямо налету?
Welcome to the real world!
Два последних дня оперировали систему биллинга без наркоза. Спасибо начальству за принятие решений за час до срока их реализаций.
Это не real world, а какой-то underworld. Даже не слышал, чтобы кто-то из знакомых так делал.
На самом деле такое повсеместно, если работаете не в IT-конторе. То есть IT — вспомогательная функция основного вида деятельности. Как правило квалификация сотрудников там ниже, начальство не понимает рисков неправильных подходов в разработке, зато видит результат в максимально короткие сроки.
— Но ведь вы можете сейчас вон-там поменять, а мы посмотрим?
— Могу, но…
— Никаких «НО», надо сделать!
— Но ведь вы можете сейчас вон-там поменять, а мы посмотрим?
— Могу, но…
— Никаких «НО», надо сделать!
Я имел ввиду правку БД любого ответвления проекта. Править БД с помощью текстовых команд — то еще занятие.
Могу я зайти в какой-нибудь MySQLAdmin (или в другую удобную мне систему) и поправить что-нибудь?
Mysql Workbench позволяет синхронизировать структуру БД в обе стороны (кроссплатформенная, но только для mysql, впрочем аналогичное и для других баз должно быть). В git-е же будет храниться sql дамп (обновлять придется вручную через экспорт) и/или sql миграций.
Хорошие фразы действуют на девушек или на работодателей.
«Я не изобретаю искусственный интеллект, так как нейронная сеть не умещается в идеологию git» — плохая фраза.
«Я не изобретаю искусственный интеллект, так как нейронная сеть не умещается в идеологию git» — плохая фраза.
1. Почему не применять к остальной части кода?
2. Структура бд хранится только в одной единственной базе?
2. Структура бд хранится только в одной единственной базе?
1. В принципе, можно, но сомневаюсь, что будут какие-то плюсы. Код статической части примерно 5% от всего проекта.
2. Баз около 40 штук, структуры все разные. В зависимости от пользователей и прав доступа выполняются разные части кода из разных баз.
Вообщем, это мрак для любой системы контроля версий :)
2. Баз около 40 штук, структуры все разные. В зависимости от пользователей и прав доступа выполняются разные части кода из разных баз.
Вообщем, это мрак для любой системы контроля версий :)
Возможно, вам будет интересным вариант размещения в репозиторий (в основной, отдельным субмодулем) описания той части SQL, которая содержит такой код. Как минимум это даст ссылку на дату и автора задачи, которая что-то поломала, что в свою очередь поможет устранить проблему быстрее, чем без подобной информации.
Также, при проведении рефакторинга вами или же уже другими разработчиками эта информация тоже может помочь для ускорения старта над работами или же уточнениями что и для чего (если код не имеет ключевых комментариев).
Также, при проведении рефакторинга вами или же уже другими разработчиками эта информация тоже может помочь для ускорения старта над работами или же уточнениями что и для чего (если код не имеет ключевых комментариев).
Поработали над структурой проекта — запустили дамп в файл, закоммитили. Какие проблемы?
Какие это дает преимущества перед простым бэкапом?
Диффы. Чужие правки и командная работа. Привязывание конкретной схемы БД к конкретному состоянию всего остального кода приложения в коммите.
1. У одной и той же БД на разных клиентах в разных системах и при разных настройках текст дампа может быть принципиально разным.
2. Как можно забрать изменения в базе от других, если есть только полный дамп — не совсем понятно. Добавить строчку в программе — это не одно и тоже, что добавить строчку в БД (нужен отдельный INSERT)
Правки должны выглядеть в виде скрипта-апдейта к какому-то эталонному состоянию БД, а не просто каждый раз дамп БД. Нужно делать что-то типа вот такого, как минимум: habrahabr.ru/post/121265/
2. Как можно забрать изменения в базе от других, если есть только полный дамп — не совсем понятно. Добавить строчку в программе — это не одно и тоже, что добавить строчку в БД (нужен отдельный INSERT)
Правки должны выглядеть в виде скрипта-апдейта к какому-то эталонному состоянию БД, а не просто каждый раз дамп БД. Нужно делать что-то типа вот такого, как минимум: habrahabr.ru/post/121265/
Мы может про разные штуки говорим, когда дамп упоминаем? pg_dump в общем ло этих самых insert базу и бекапит, диффай не хочу.
А так да, осталось ещё один малюсенький шажок сделать, и мы изобретем ActiveRecord Migrations и seed.rb пророк его.
А так да, осталось ещё один малюсенький шажок сделать, и мы изобретем ActiveRecord Migrations и seed.rb пророк его.
1. Я думаю можно взять любые скриптовые миграции из RoR, Django, или Doctrine и писать миграции через него, если база достаточно простая. Под монстров типо Oracle наверняка существуют аналогичные инструменты для однообразного дампа в обычные файлы.
2. Данные нужно бекапить, тут не нужна система контроля версий. В тех же скриптовых языках есть инструменты для фикстур — данные, для дальнейшего тестирования. Это уже flow конкретно взятого проекта.
2. Данные нужно бекапить, тут не нужна система контроля версий. В тех же скриптовых языках есть инструменты для фикстур — данные, для дальнейшего тестирования. Это уже flow конкретно взятого проекта.
Мы при выпуске релизов используем скриптование схемы базы (пользуемся для этого программой Aqua Data Studio, платная, зато там отличный Schema Script Generator для всех СУБД). На основе сравнения скриптов схемы можно прослеживать изменения в БД (как в структуре, так и в данных, если данные тоже скриптуются).
Если кто-то еще сомневается стоит использовать VCS или нет — стоит попробовать, уверяю вас, после того как я узнал об их существовании моя жизнь изменилась раз и навсегда =)
Методы вроде резервного копирования файлов в качестве системы контроля версий не выдерживают никакой критики.
Git — очень мощная и гибкая система, также рекомендую Mercurial — он, имхо, попроще.
P.S. Выше в комментах не видел ссылки на этот ресурс — для всех начинающих и продолжающих обучение Git рекомендую великолепный интерактивный тренажер.
Методы вроде резервного копирования файлов в качестве системы контроля версий не выдерживают никакой критики.
Git — очень мощная и гибкая система, также рекомендую Mercurial — он, имхо, попроще.
P.S. Выше в комментах не видел ссылки на этот ресурс — для всех начинающих и продолжающих обучение Git рекомендую великолепный интерактивный тренажер.
Под мак отличный клиент — SourceTree от Atlassian. Уже даже не помню, когда последний раз делал из консоли что-то сложнее git pull
уже есть и весьма сносная версия под винду
уже есть и весьма сносная версия под винду
Tower круче, имхо.
Рискну спросить — а для чего гиту гуи клиент?
Tower ещё весьма хорош. Я из-за него чуть на Mac не перешел.
Наверное SourceTree в общем случае хорош. Умный, автоматически разнюхивающий изменения в ветке…
Однако, если применять расширения (такие как например git-fat — штука держащая массовый бинарный контент вне базы git) и консоль, то с ним могут случиться глюки — перестанет правильно оценивать изменения.
Словом, перешел в такой ситуации на SmartGit.
Однако, если применять расширения (такие как например git-fat — штука держащая массовый бинарный контент вне базы git) и консоль, то с ним могут случиться глюки — перестанет правильно оценивать изменения.
Словом, перешел в такой ситуации на SmartGit.
Под Windows есть Git Extensions, весьма удобный и простой в использовании инструмент.
Уж очень он гламурный. Пользуюсь GitExtensions.
Я активно пользуюсь git в своей профессиональной деятельности и тем не менее считаю, что он слишком сложный. Это, выражаясь по-английски, худший experience среди всех средств вэб-разработки, которыми я когда либо пользовался.
И да, я постоянно боюсь, что я что-нибудь сломаю. Потому что с git я постоянно что-нибудь ломаю. Шаг вправо/шаг влево от типового workflow «add-commit-push», и все, капец. Сиди гугли, консультируйся на git@freenode и бей в бубен. Авось починишь.
Чаще, чем хотелось бы, оказывался в ситуации, когда переделать работу заново было проще, чем восстанавливать покалеченное состояние репозитория.
Все локальные копии проектов держу в Dropbox с проплаченной функцией истории правок, чтобы можно было откатить проект (ну и, в первую очередь, состояние локального репозитория), не заморачиваясь с созданием резервных копий вручную.
А все потому, что git сделан кишками наружу. Если провести аналогию со стиральной машиной, то у git на переднюю панель выведены не кнопки «деликатная стирка», «отжим» и т. п., а «нагреть спираль», «подать воду», «раскрутить барабан» и далее в таком духе. И любое неверное действие заставляет вас горько жалеть, что вы — домохозяйка. Включил нагрев, забыв подать воду, — сжег одежду. Открыл крышку, забыв слить воду, — затопил соседей.
Или представьте, что git — это автомобиль. В случае с любым другим автомобилем, вы можете быть высокопрофессиональным водителем и при этом не иметь никакого представления, что у автомобиля под капотом. Но только не с git! C git вы должны быть матерым автослесарем, способным с завязанными глазами перебрать карбюратор, чтобы водить эту машину. В противном случае недостаточное знание git приведет к тому, что во время езды он вас катапультирует на ровном месте — но ведь любой уважающий себя автослесарь знает, что нельзя втыкать зарядку в прикуриватель в то мгновение, когда «стреляют» свечи зажигания.
Сейчас набегут гуру программироавния и объяснят, что я лох и не умею пользоваться инструментом (ну и карму сольют, куда без этого). Так вот, отвечу, что во всем мире вэб-разработки нет другой такой программы, как git. Все остальные утилиты нормальные (с другими VCS не сравниваю, опыта нет). Из неадекватных инструментов можно вспомнить разве что vi, который во времена, когда в мобильниках не было интернета, не оставил мне, оздаченному школьнику, вариантов, кроме как перезагрузить комп. Но vi по сравнению с git, как говорится, курит в сторонке.
Спасибо-пожалуйста.
И да, я постоянно боюсь, что я что-нибудь сломаю. Потому что с git я постоянно что-нибудь ломаю. Шаг вправо/шаг влево от типового workflow «add-commit-push», и все, капец. Сиди гугли, консультируйся на git@freenode и бей в бубен. Авось починишь.
Чаще, чем хотелось бы, оказывался в ситуации, когда переделать работу заново было проще, чем восстанавливать покалеченное состояние репозитория.
Все локальные копии проектов держу в Dropbox с проплаченной функцией истории правок, чтобы можно было откатить проект (ну и, в первую очередь, состояние локального репозитория), не заморачиваясь с созданием резервных копий вручную.
А все потому, что git сделан кишками наружу. Если провести аналогию со стиральной машиной, то у git на переднюю панель выведены не кнопки «деликатная стирка», «отжим» и т. п., а «нагреть спираль», «подать воду», «раскрутить барабан» и далее в таком духе. И любое неверное действие заставляет вас горько жалеть, что вы — домохозяйка. Включил нагрев, забыв подать воду, — сжег одежду. Открыл крышку, забыв слить воду, — затопил соседей.
Или представьте, что git — это автомобиль. В случае с любым другим автомобилем, вы можете быть высокопрофессиональным водителем и при этом не иметь никакого представления, что у автомобиля под капотом. Но только не с git! C git вы должны быть матерым автослесарем, способным с завязанными глазами перебрать карбюратор, чтобы водить эту машину. В противном случае недостаточное знание git приведет к тому, что во время езды он вас катапультирует на ровном месте — но ведь любой уважающий себя автослесарь знает, что нельзя втыкать зарядку в прикуриватель в то мгновение, когда «стреляют» свечи зажигания.
Сейчас набегут гуру программироавния и объяснят, что я лох и не умею пользоваться инструментом (ну и карму сольют, куда без этого). Так вот, отвечу, что во всем мире вэб-разработки нет другой такой программы, как git. Все остальные утилиты нормальные (с другими VCS не сравниваю, опыта нет). Из неадекватных инструментов можно вспомнить разве что vi, который во времена, когда в мобильниках не было интернета, не оставил мне, оздаченному школьнику, вариантов, кроме как перезагрузить комп. Но vi по сравнению с git, как говорится, курит в сторонке.
Спасибо-пожалуйста.
Все локальные копии проектов держу в Dropbox с проплаченной функцией истории правок, чтобы можно было откатить проект (ну и, в первую очередь, состояние локального репозитория), не заморачиваясь с созданием резервных копий вручную.
Так для этого за рамки сценария «add-commit-push» и не придется выходить. Я полностью согласен с тем, что git — довольно-таки запутанная и местам (многими) не интуитивно-понятная система, но простые вещи она позволяет сделать просто, а сложные вещи позволяет хоть как-то сделать. И без гита я бы уже на несколько раз поседел.
Да я не агитирую против git. Наоборот, рекомендую всем начинающим разработчикам нырнуть в эту прорубь чем раньше, тем лучше. И никаких Svn и Mercurial: конкуретны git'а хоть и проще (и некоторые даже не уступают по функционалу), но в современном мире разработки git — полный монополист. Без него никуда. Если вы будете уметь пользоваться Mercurial и не будете уметь git, вы будете маргиналом.
Но, млять… Линус, за что?!
Но, млять… Линус, за что?!
Пользуюсь исключительно Mercurial, если есть нужда поработать с чужим git-репозиторием — hg-git приходит на помощь. Не чувствую себя маргиналом. Mercurial как раз и славится тем, что он не «кишками наружу».
Но, млять… Линус, за что?!Его можно понять как основного майнтейнера репо кода ядра линукса на тот момент. Для упрощения сопровождения ему просто необходимо было придумать Git, а всем остальным пришлось с этим согласиться, смириться и принять. И надо признать, что для этих целей Git — самое то!
Но потом Git стали тулить и к месту и не очень (чаще не очень). На самом деле это просто инструмент, точнее один из набора похожих инструментов — главное уметь выбрать из них наиболее подходящий. Но с этим сейчас мало кто заморачивается — а зря, т.к. в конкретной ситуации скорее всего лучше подойдет другая СКВ. Но слава богу еще есть те, кто способен поразмыслить над выбором СКВ для конкретного проекта и благодаря им продолжают развиваться известные и не очень альтернативы Git.
Откровенно говоря, git вышел не очень по сравнению с mercurial.
К сожалению, толпы адептов с гитхаба никогда этого не признают.
К сожалению, толпы адептов с гитхаба никогда этого не признают.
Не «за что», а «почему». Изначально Git делался так, как он делался, потому что он должен был в первую очередь удовлетворять потребности Linus'а. Который даже не автослесарь, а скорее автоконструктор. А для других — были разные надстройки (первой был Cogito). Но потом выяснилось, что поскольку надстроек — много, а git — один, то в конечном итоге всё равно git знать надо, иначе невозможно общаться с другими. А если ты уже знаешь git, то и Cogito тебе не нужен.
UFO just landed and posted this here
Опять же, это все замечательно в рамках стандартного workflow.
А когда мэйнтейнер проекта в ответ на твой пулл-реквест говорит тебе, все супер, только у меня две недели не доходили руки посмотреть твой PR, так что ты rebase'ни его относительно master'а, squash'ни свои коммиты и попинай меня снова. И ты час разбираешься, как делать squash, потом полдня разбираешься, как разрешать конфликты merge'а, и в итоге оказываешься у разбитого корыта в состоянии detached head, из которого можно выйти только созданием новой ветки, что делает невозможным продолжение отправленного тобой PR'а…
… то тут какбе никакие GUI не помогут. А вот сделать еще хуже — запросто.
А когда мэйнтейнер проекта в ответ на твой пулл-реквест говорит тебе, все супер, только у меня две недели не доходили руки посмотреть твой PR, так что ты rebase'ни его относительно master'а, squash'ни свои коммиты и попинай меня снова. И ты час разбираешься, как делать squash, потом полдня разбираешься, как разрешать конфликты merge'а, и в итоге оказываешься у разбитого корыта в состоянии detached head, из которого можно выйти только созданием новой ветки, что делает невозможным продолжение отправленного тобой PR'а…
… то тут какбе никакие GUI не помогут. А вот сделать еще хуже — запросто.
А чем тут «локальная копия проекта в Dropbox» поможет? Вы хотите странного, а потом жалуетесь, что это сложно.
Rebase изменяет контекст коммитов, его вообще лучше использовать как можно реже. Я согласен с kloppspb, современные IDE предоставляют возможность пользоваться git'ом, не открывая консоль, в СТАНДАРТНЫХ случаях. А для всего остального естьMasterCard man и google.
Если уж использовать Вашу аналогию, то «быть высокопрофессиональным водителем и при этом не иметь никакого представления, что у автомобиля под капотом» невозможно. Элементарно, чтобы знать, почему на переднеприводном автомобиле в случае заноса надо газовать, а на заднеприводном — тормозить (упрощенно говоря), надо иметь хотя бы минимальное представление о физике и об устройстве автомобиля.
Rebase изменяет контекст коммитов, его вообще лучше использовать как можно реже. Я согласен с kloppspb, современные IDE предоставляют возможность пользоваться git'ом, не открывая консоль, в СТАНДАРТНЫХ случаях. А для всего остального есть
Если уж использовать Вашу аналогию, то «быть высокопрофессиональным водителем и при этом не иметь никакого представления, что у автомобиля под капотом» невозможно. Элементарно, чтобы знать, почему на переднеприводном автомобиле в случае заноса надо газовать, а на заднеприводном — тормозить (упрощенно говоря), надо иметь хотя бы минимальное представление о физике и об устройстве автомобиля.
Необходимость для пользователя автомобиля знать, тормозить или газовать в заносе, — это нормально.
А вот когда отсутствие знания, например, чем минеральное масло отличается от синтетического, может привести к внезапной капитальной поломке — это уже перебор.
Хотя ваша аналогия «rebase/merge == способы выхода из заноса» очень хороша. Принимается.
Но опять же, в обычном автомобиле вы для выхода из заноса просто жмете на нужную педаль. А в автомобиле git вы одной рукой залезаете под приборную панель, чтобы контролировать зажигание, другой регулируете заслонку, а рулите зубами. Из заноса вы в итоге выходите успешно, но по прибытии в пункт Б вы обнаруживаете, что переключение передаче при открытой пепельнице вызвало катапультирование вашего багажа в придорожную канаву.
А вот когда отсутствие знания, например, чем минеральное масло отличается от синтетического, может привести к внезапной капитальной поломке — это уже перебор.
Хотя ваша аналогия «rebase/merge == способы выхода из заноса» очень хороша. Принимается.
Но опять же, в обычном автомобиле вы для выхода из заноса просто жмете на нужную педаль. А в автомобиле git вы одной рукой залезаете под приборную панель, чтобы контролировать зажигание, другой регулируете заслонку, а рулите зубами. Из заноса вы в итоге выходите успешно, но по прибытии в пункт Б вы обнаруживаете, что переключение передаче при открытой пепельнице вызвало катапультирование вашего багажа в придорожную канаву.
Прекратите истерику и прочитайте Pro Git, пожалуйста. Добра, любви и чистой истории коммитов вам и вашей команде.
Эм, а зачем так сложно-то?
Берем свою ветку, сквошим (git rebase -i hash) всё в один коммит, и черри-пиком переносим его на их мастер.
Берем свою ветку, сквошим (git rebase -i hash) всё в один коммит, и черри-пиком переносим его на их мастер.
Берем шлицевую отвертку, ключ на двенадцать, залезаем по локоть под капот и с подвывертом регулируем карбюратор. Ничего сложного!
Так вы ведь и хотели карбюратор регулировать вместо того чтобы просто ехать. Разве нет?
Нет, я просто хотел доехать из пункта А в пункт Б — сделать pull request. Но на автомобиле Git без плясок с масленкой и домкратом ездить можно только вокруг гаража.
Шикарные у вас аналогии! Я в восторге!
У вас ответ как у менеджера или клиента. Какие нафиг рефакторинги, какой код, какая еще спецификация мне просто нужна работающая программа.
Автомобили. Это если вы спроектировали и сделали, скажем, дверь для машины, принесли, а уже все поменялось, и вас просят исправить все крепления да и вообще всю форму двери что бы она подходила к новой машине.
А если по делу, пример что вы привели вполне класический, если есть трудности с ним, может есть смысл почитать документацию, пройти туториалы, на курсы там сходить что ли? Как вы себе представляете что бы система контроля версий, за вас исправила логику в коде?
Автомобили. Это если вы спроектировали и сделали, скажем, дверь для машины, принесли, а уже все поменялось, и вас просят исправить все крепления да и вообще всю форму двери что бы она подходила к новой машине.
А если по делу, пример что вы привели вполне класический, если есть трудности с ним, может есть смысл почитать документацию, пройти туториалы, на курсы там сходить что ли? Как вы себе представляете что бы система контроля версий, за вас исправила логику в коде?
Что-то я вас не понимаю. Чего сложного в rebase по другой ветке, и если сложность в конфликтах — в каких vcs решение конфиликтов проще? По моему оно вообще проще быть не может, только GUI. Ну и сливать коммиты проще некуда.
Да, первый раз трудно смержить/сребейзить ветку, а пару раз это сделаешь — и все становится ясно-понятно.
Да, первый раз трудно смержить/сребейзить ветку, а пару раз это сделаешь — и все становится ясно-понятно.
так что ты rebase'ни его относительно master'а, squash'ни свои коммиты
Видите ли, решение таких задач просто не может быть «простым». Слишком много ньюансов, которые будут меняться от случая к случаю.
Поэтому ваша жалоба непонятна. Вы хотите решить _сложную_ задачу, но жалуетесь, что это нельзя сделать одной командой :)
>>rebase'ни его относительно master'а, squash'ни свои коммиты и попинай меня снова
Потому, что 'rebase' нужно делать через merge:
Делаем merge c веткой мастер, при этом происходит правильное слияние с учетом истории, также всегда создается новый коммит, по этому для того, чтобы откатить результат, достаточно перенести указатель ветки на один шаг назад.
После слияния ветка master будет являться началом Ваших изменений, rebase на master уже пройдет без конфликтов, можно делать squash, если того требует мэйнтейнер: rebase --interactive, либо вообще способ для ленивых reset --mixed и делаем новый коммит.
Важно: Если Вы знаете, что Ваши действия приведут к удалению оригинального коммита (как при rebase или reset) или если в чем-то не уверенны, сделайте резервный указатель (новый branch), к которому потом всегда можно будет вернуться.
Потому, что 'rebase' нужно делать через merge:
Делаем merge c веткой мастер, при этом происходит правильное слияние с учетом истории, также всегда создается новый коммит, по этому для того, чтобы откатить результат, достаточно перенести указатель ветки на один шаг назад.
После слияния ветка master будет являться началом Ваших изменений, rebase на master уже пройдет без конфликтов, можно делать squash, если того требует мэйнтейнер: rebase --interactive, либо вообще способ для ленивых reset --mixed и делаем новый коммит.
Важно: Если Вы знаете, что Ваши действия приведут к удалению оригинального коммита (как при rebase или reset) или если в чем-то не уверенны, сделайте резервный указатель (новый branch), к которому потом всегда можно будет вернуться.
Ок, есть проблема, когда изменения делались на одну версию, а потом надо их сделать на другую. При этом, сквош на ребейзе может наплодить конфликтов. Теперь вопрос в том, кто виноват — git или мейнтернер?
Идем далее, измерим роль git`а — он может показать какие изменения на проекте произошли, а в некоторых случаях поможет даже нормально смержить. Но если какие-то проблемы с мерджами, то ничего не мешает вручную переписать код.
Потом, про порчу репозитория — центральный репозиторий сложно испортить, если туда не пушить что попало. Если проблемы с локальным — можно скачать центральный в соседнюю папку, создать в ней локальную ветку заново и наложить в нее изменения из своего проекта, поскольку он никуда не денется, если не колдовать над коммитами задним числом. Ежели захочется в этом поупражняться — ничто не мешает забэкапить локальный репозиторий в пару кликов, просто создав архив из его папки.
Идем далее, измерим роль git`а — он может показать какие изменения на проекте произошли, а в некоторых случаях поможет даже нормально смержить. Но если какие-то проблемы с мерджами, то ничего не мешает вручную переписать код.
Потом, про порчу репозитория — центральный репозиторий сложно испортить, если туда не пушить что попало. Если проблемы с локальным — можно скачать центральный в соседнюю папку, создать в ней локальную ветку заново и наложить в нее изменения из своего проекта, поскольку он никуда не денется, если не колдовать над коммитами задним числом. Ежели захочется в этом поупражняться — ничто не мешает забэкапить локальный репозиторий в пару кликов, просто создав архив из его папки.
Странно. Для меня наоборот — Mercurial намного непонятней, сложнее, и заставляет приспосабливать свой рабочий процесс под себя, а не себя под рабочий процесс.
Видимо, действительно дело вкуса.
P.S: vim сам не люблю. Emacs наше все (:
Видимо, действительно дело вкуса.
P.S: vim сам не люблю. Emacs наше все (:
Дело не вкуса, а, скорее, привычки. Я лет 6 назад сходу гит не осилил, а с меркуриалом разобрался за полчаса. Это, конечно, было давно, сейчас гитом пользуюсь ежедневно, но все равно на операциях чуть сложнее тривиальных напрягаю мозг и вспоминаю меркуриал хорошим словом. При этом мне меркуриал всегда казался на порядок более простым, удобным и очевидным, но коллеги, привыкшие к гиту, испытывали с меркуриалом примерно те же ощущения, что и я с гитом.
P.S: в JetBrains-овских IDE всегда первым делом ставлю vim-плагин, а из емакса я, если вдруг он где-то оказался в $EDITOR, каждый раз вспоминаю, как выходить :)
P.S: в JetBrains-овских IDE всегда первым делом ставлю vim-плагин, а из емакса я, если вдруг он где-то оказался в $EDITOR, каждый раз вспоминаю, как выходить :)
Как вам удается сломать git? Можно пару примеров из реальной жизни? Я просто себе и представить не могу, так как там всё просто как гвозди.
так как там всё просто как гвозди
Гит после коммита никак не проверяет состояние репозитория и если во время записи коммита записываемый файл будет поврежден (у меня на винде частенько открыты eclipse с jgit-ом и tortoisegit что, похоже, иногда и приводит к конфликтам), то ваш репозиторий будет поврежден, но заметите вы это далеко не сразу и, скорее всего, успеете много накоммитить в уже мертвый репозиторий. В какой то момент гит поймет что репозиторий умер и скажет «error: sha1 mismatch». А вот дальше… дальше начитается дикий трэш, угар и содомия* (чего только стоят попытки определить что перед нами по известному sha1 и к какому коммиту это всё относится)… Собственно, нормального способа починить репозиторий в git-е нет (от слова вообще)
* «официальный» способ, но работает далеко не всегда, иногда репозиторий вообще невозможно восстановить.
Git всегда проверяет целостность. commit id берётся из контрольных сумм объектов. К тому же, файлы в репозиторий добавляются не из рабочей копии, как можно сначала подумать, а из индекса. а эта область лежит целиком в папке .git. Эта папка в свою очередь является «собственностью» git-a. И если кто-то что-то там в ней будет менять вслед за git — ничего удивительного тут нет.
Git пишет «карта», программа перетирает «В*ЧНОСТЬ».
Естественно, git задаст резонный вопрос:
«Где карта, Билли!»
Кстати, вброшу ка я: jgit некорректно работает с git и там много багов. Это скорее всего основная проблема.
Сам лично словил тонну глюков, когда использова maven-jgitflow-plugin. Обновление jgit частично помогло. Было это 3 месяца назад. Как сейчас обстоят дела я не знаю.
Git пишет «карта», программа перетирает «В*ЧНОСТЬ».
Естественно, git задаст резонный вопрос:
«Где карта, Билли!»
Кстати, вброшу ка я: jgit некорректно работает с git и там много багов. Это скорее всего основная проблема.
Сам лично словил тонну глюков, когда использова maven-jgitflow-plugin. Обновление jgit частично помогло. Было это 3 месяца назад. Как сейчас обстоят дела я не знаю.
При чем тут сам Git к jgit и TortoiseGit?
Сам я всегда работаю через Git Bash. Файлы всегда добавляю через
Сам я всегда работаю через Git Bash. Файлы всегда добавляю через
git add --patch, реже просто через git add. И еще ни разу, за года 2 где-то, не было никаких проблем.При чем тут сам Git к jgit и TortoiseGit?
При том что внутри TortoiseGit обычный git.
не было никаких проблем
Повезло. У меня раза три было и при этом в первый раз восстановить вообще не получилось, в последний же пришлось долго вспоминать что было в файле пару дней назад (но в итоге удалось все восстановить и залить его обратно).
У нас случалось сломать (после того как перешли с CVS). Обычно это выглядит так: Вася не делал pull пару дней и отстал от мастера на сотню-другую коммитов, создавая свои коммиты параллельно. Потом Вася выкачался, закономерно получил несколько конфликтов. Дальше Вася, не зная, что с ними делать, нажимает какую-то мутную кнопку в GUI-клиенте типа SmartGit, и в merge-commit попадают только Васины изменения. Вася думает, что всё нормально, потому что свой код он видит в исправном виде, и со спокойной душой нажимает push. После этого случается ещё где-нибудь 25 коммитов от всей команды, а на следующий день кто-то замечает, что часть функционала бесследно исчезла (причём тесты могли не упасть, потому что они тоже откатились). В результате получается ситуация, когда 1) надо понять, что вообще произошло и что конкретно исчезло; 2) склеить в единое целое коммиты Васи, сотню потерянных коммитов и 25 коммитов после этого (вполне возможны новые конфликты); 3) надрать попу Васе. Это всё решаемо, но замедляло процесс разработки.
Я правильно понимаю, что вы все вместе работаете в одной ветке?
Потому что я бывал в подобной ситуации на поза-поза прошлом проекте. Как только всем было выдано в мозг и предписание выучить и использовать git flow (парадигму, а не тулзу; хотя тулза зачётная), проблемы исчезли.
Потому что я бывал в подобной ситуации на поза-поза прошлом проекте. Как только всем было выдано в мозг и предписание выучить и использовать git flow (парадигму, а не тулзу; хотя тулза зачётная), проблемы исчезли.
На 90% в одной. Ветки создают единичные разработчики в основном для рискованных и экспериментальных изменений.
Почитал про git flow здесь. Отдельные ветки для production и релизов есть, конечно. Обычно ад разворачивается в девелоперской ветке, но от этого не легче.
Это не лох — это ленивец.
Понять, какие команды нужны и только их тыкать:
* status, add, commit, reset, push, pull
* всякие логи и диффы уже удобнее в gui смотреть для тех, кто не очень
Также «git flow» на помощь.
Понять, какие команды нужны и только их тыкать:
* status, add, commit, reset, push, pull
* всякие логи и диффы уже удобнее в gui смотреть для тех, кто не очень
Также «git flow» на помощь.
Ну а чего тут бояться? Вполне адекватное мнение! Трольвадс же писал git не для мэйнстрима, а ПЕРСОНАЛЬНО ДЛЯ СЕБЯ, чтобы было удобнее управлять громадиной под названием linux kernel. Соответственно, никакого особо вдумчивого проектирования он не предполагал, чисто наляпывал функции, каких нехватало.
Я ведь тоже непредвзято сел сначала за git, почитал руководства и ощутил, что вроде бы все сущности на поверхности, но я не понимаю зачем это всё! А когда пробежался по меркуриалу, просветление наступило сразу — да это же DVCS! :) С тех пор git'а даже не касаюсь.
Я ведь тоже непредвзято сел сначала за git, почитал руководства и ощутил, что вроде бы все сущности на поверхности, но я не понимаю зачем это всё! А когда пробежался по меркуриалу, просветление наступило сразу — да это же DVCS! :) С тех пор git'а даже не касаюсь.
У Git очень высокий порог входа.
Git создаёт проблемы если с сурсконтролом работают не только программисты, но и переводчики, техврайтеры или верстальщики, которые могут быть на аутсорсе. В этом случае репозиторий превращается в сплошные merge веток и на диаграму без боли не взглянешь.
Именно потому SVN живее всех живых — он простой, что бы Линус не говорил.
По моему опыту, Hg показывает себя намного лучше чем Git в командах где работают не только гики.
Но в любом случае, Smart GitHG и SourceTree это спасение от сложностей с командам git'а.
Git создаёт проблемы если с сурсконтролом работают не только программисты, но и переводчики, техврайтеры или верстальщики, которые могут быть на аутсорсе. В этом случае репозиторий превращается в сплошные merge веток и на диаграму без боли не взглянешь.
Именно потому SVN живее всех живых — он простой, что бы Линус не говорил.
По моему опыту, Hg показывает себя намного лучше чем Git в командах где работают не только гики.
Но в любом случае, Smart GitHG и SourceTree это спасение от сложностей с командам git'а.
Какой же он высокий?
Написать git init на текущей директории. Прочитать хотя бы про команды add и commit. Всё, можно использовать git: после каждого логического этапа git add. && git commit.
Написать git init на текущей директории. Прочитать хотя бы про команды add и commit. Всё, можно использовать git: после каждого логического этапа git add. && git commit.
Абзац и фейспалм:
— Мержить и резолвить конфликты
— Смотреть изменения в файле
— Смотреть список измененных файлов
— Смотреть краткую или развернутую историю коммитов
— Передислоцировать локальный репозиторий на другой сервак
— Просмотреть кем создана та или ина строчка
— Отворачивать измения локально
— Отворачивать закомиченные изменения
— Развернуть рабочую копию/Файл той или иной ревизи.
Для нормального и самодостаточного обслуживания своей рабочей копии все это нужно знать.
P.S. Subversion-user мнение — кроме гита существуют другие системы контроля версий. Не нужно уподобляться мамочкам под подгузниками подразумевающими «памперс».
— Мержить и резолвить конфликты
— Смотреть изменения в файле
— Смотреть список измененных файлов
— Смотреть краткую или развернутую историю коммитов
— Передислоцировать локальный репозиторий на другой сервак
— Просмотреть кем создана та или ина строчка
— Отворачивать измения локально
— Отворачивать закомиченные изменения
— Развернуть рабочую копию/Файл той или иной ревизи.
Для нормального и самодостаточного обслуживания своей рабочей копии все это нужно знать.
P.S. Subversion-user мнение — кроме гита существуют другие системы контроля версий. Не нужно уподобляться мамочкам под подгузниками подразумевающими «памперс».
Сгенерить ssh-ключик еще, и понять куда его на винде положить чтобы оно его увидело.
Для всех кто считает что git это очень сложно, или даже для тех кто так не считает рекомендую посмотреть это видео: www.youtube.com/watch?v=1ffBJ4sVUb4 оно прояснит множество непонятных вещей, останется только запомнить команды.
Да, отличное выступление! Недавно его смотрел, очень доходчиво.
Вот ещё сайт, где довольно просто объясняется работа git: think-like-a-git.net/. В том числе упоминается, почему для кого-то git прост, а кто-то не никак может «въехать».
Вот ещё сайт, где довольно просто объясняется работа git: think-like-a-git.net/. В том числе упоминается, почему для кого-то git прост, а кто-то не никак может «въехать».
В интернетах уже не продохнуть от статей и видео а-ля «Getting Started with Git», «Git For Dummies», «The Definitive Guide to Understanding Git» и т.п., а тут еще детские игрушки, махание руками… Целый перформанс.
Дальше падать некуда. Если инструмент настолько нелогичен и настолько непрост в понимании, а его настойчиво проталкивают, внедряют и насаждают, то это уже Cargo Cult Engineering в самом ярком его проявлении.
Дальше падать некуда. Если инструмент настолько нелогичен и настолько непрост в понимании, а его настойчиво проталкивают, внедряют и насаждают, то это уже Cargo Cult Engineering в самом ярком его проявлении.
svn достаточно хорош.
Задача:
Имеется продукт, основная ветка.
Команда делает 5-6 вещей (баг фиксы, изменения поведения, новые фичи и т.д.) одновременно, тестят их по готовности и вместе (проверить финальную интеграцию).
На момент релиза (сроки которые могут, внезапно (с), меняться) нужно выпустить несколько фич:
какие-то ещё не доделаны, 5 готовы, но выпустить надо только 4, от последней отказались. Ещё 2 перенесли на следующий релиз.
Вопрос: как это сделать с SVN, чтобы разработчики не заплакали кровавыми слезами?
Имеется продукт, основная ветка.
Команда делает 5-6 вещей (баг фиксы, изменения поведения, новые фичи и т.д.) одновременно, тестят их по готовности и вместе (проверить финальную интеграцию).
На момент релиза (сроки которые могут, внезапно (с), меняться) нужно выпустить несколько фич:
какие-то ещё не доделаны, 5 готовы, но выпустить надо только 4, от последней отказались. Ещё 2 перенесли на следующий релиз.
Вопрос: как это сделать с SVN, чтобы разработчики не заплакали кровавыми слезами?
Ох блин, писать чтоли огромную статью про то как это делать? Крадко, в нашей команде 4 программиста и 6 художников, и 35 стабильных веток и около полутора десятков фичебранчей. И мы поддерживаем когда нужно ещё и разные версии продукта на разных инсталляциях и умеем катать фиксы и туда и туда. Короче ветки просто работают, и кровавыми слезами никто не плачет.
Но ведь не случайно такие крупные проекты как например jQuery, Rail и Linux Kernel полагаются на Git для контроля версий и совместной работы над кодом.
Конкретно Linux Kernel его использует по той причине что git и был создан для его исходников. Как мне кажется есть немалая вероятность того что если бы git сделал не Торвальдс и его не форсили бы с помощью исходников линукса то он был бы далеко не так популярен.
--Сейчас вы с трудом найдете профессионального разработчика, который не пользуется системой контроля версий (VCS) такой, как Git
думаю это миф. От силы 10% судя по С++/C# позициям.
perforce, svn, teamviewr
В гугле, в блакбери — perforce
думаю это миф. От силы 10% судя по С++/C# позициям.
perforce, svn, teamviewr
В гугле, в блакбери — perforce
Суть не в использовании конкретно гита, а вообще любой VSC.
Уж прям-таки и perforce? Не знаю про BlackBerry, но в Google все новые проекты — это Git. Android — это чистый git, Chromium — это тоже git, где кое-где ещё не до конца убит SVN. Perforce тоже есть, куда без него — но он используется скорее по историческим причинам.
Как раз сегодня столкнулся с проблемой, из-за которой коллеги на полном серьзе советовали поставить линукс на виртуалку… специально чтобы пользоваться git-ом. Один из девелоперов со стороны заказчика запулил папку с двоеточием в репозиторий. Я на виндовс, конечно же, словил fatal error при попытке обновиться — нельзя создать папку с двоеточием. В svn я мог бы забрать только свою часть проекта и работать, горя бы не зная. Но в гит ты обязан забрать все целиком. И костыли типа git-submodule-tools только под линукс. В конце-концов тот девелопер нехорошую папку удалил, но осадочек остался: при всей своей гибкости гит не может решить такую, казалось бы, элементарную проблему.
Хозяйке на заметку: в git можно забрать только определенные файлы/каталоги из remote ветки; более того, в git можно даже закомитить не файл целиком, а его часть.
А почему вы проблему системы валите на git? Если бы двоеточие оказалось в каталоге который вам нужен, даже svn никак бы вам не помогла. А вообще, git умеет по меньшей мере два способа обойти эту проблему (которую не надо считать элементарной при том что полнота и целостность репозитория как-бы лежит в основе DVCS): git clone --no-checkout и sparse checkout (git help read-tree).
Да, согласен, это не проблема VCS. Но для меня этот случай стал показателем, как в разных системах подходят к решению проблем. С svn это не проблема вообще — достаточно забрать только тот каталог, который нужен для работы. А с git нужно копаться в мануалах. Вроде решение есть, но нужно потратить кучу времени, чтобы его найти и воспользоваться.
Вы даже указали конкретные команды, я прочитал описание этих команд, но до сих пор не до конца понимаю, как мне это может помочь. --no-checkout закачивает только историю без самих файлов. Нафига мне нужна история, если я хочу работать с файлам? sparse checkout ругнулся, что это недопустимая команда (возможно нужно что-то доустановить). Судя по описанию, такая команда есть и она позволяет забрать отдельный каталог. К сожалению, установка глобальная, по-видимому я тогда не смогу работать с другими репозиториями.
Вы даже указали конкретные команды, я прочитал описание этих команд, но до сих пор не до конца понимаю, как мне это может помочь. --no-checkout закачивает только историю без самих файлов. Нафига мне нужна история, если я хочу работать с файлам? sparse checkout ругнулся, что это недопустимая команда (возможно нужно что-то доустановить). Судя по описанию, такая команда есть и она позволяет забрать отдельный каталог. К сожалению, установка глобальная, по-видимому я тогда не смогу работать с другими репозиториями.
> А с git нужно копаться в мануалах.
Вы составляете мнение о git на основании одного случая, почему-то решив что именно он показательный. Для любого нехарактерного паттерна использования сложного инструмента нужно читать документацию. Для git нехарактерен sparse checkout, для svn нехарактерны, например, локальные коммиты — когда понадобится работать с репозиторием оффлайн, велкам читать про всяческие svnsync и svn switch, а потом про слияние этого дела.
> Нафига мне нужна история, если я хочу работать с файлам?
Так зачекаутите после clone только то что нужно и работайте. git clone --no-checkout && git reset && git co <нужные файлы/директории>
> sparse checkout ругнулся
Это не команда, я написал какой help надо прочитать. Подробнее написано тут: briancoyner.github.io/blog/2013/06/05/git-sparse-checkout/. На другие репозитории это никак не влияет.
Вы составляете мнение о git на основании одного случая, почему-то решив что именно он показательный. Для любого нехарактерного паттерна использования сложного инструмента нужно читать документацию. Для git нехарактерен sparse checkout, для svn нехарактерны, например, локальные коммиты — когда понадобится работать с репозиторием оффлайн, велкам читать про всяческие svnsync и svn switch, а потом про слияние этого дела.
> Нафига мне нужна история, если я хочу работать с файлам?
Так зачекаутите после clone только то что нужно и работайте. git clone --no-checkout && git reset && git co <нужные файлы/директории>
> sparse checkout ругнулся
Это не команда, я написал какой help надо прочитать. Подробнее написано тут: briancoyner.github.io/blog/2013/06/05/git-sparse-checkout/. На другие репозитории это никак не влияет.
А почему вы проблему системы валите на git? Если бы двоеточие оказалось в каталоге который вам нужен, даже svn никак бы вам не помогла.Если не знаете — не пишите чушь! svn грубо говоря, хранит папки и файлы, git хранит изменениня.
Поэтому в svn это решается легко и просто — переименовываете папку прямо в репо простой командой:
svn move -m «текст комита» репо/путь/к/старой/папке репо/путь/к/новой/папке
и все!
Только речь-то про то как проблему решить не изменяя репозиторий. Например, у вас банально нет прав за запись, или полиси проекта такое что нужны директории с двоеточиями (например, какие-нибудь имена классов/модулей). Повторяю, svn ничем не поможет.
> svn грубо говоря, хранит папки и файлы, git хранит изменениня
Это неправда, git хранит именно целиковые файлы и директории (в объектах blob и tree соответственно), а pack'и их этих объектов дополнительно сжимаются эффективной delta компрессией. Но, честно говоря, не знаю как к обсуждаемому вопросу вообще относится внутреннее представление данных в VCS.
> svn грубо говоря, хранит папки и файлы, git хранит изменениня
Это неправда, git хранит именно целиковые файлы и директории (в объектах blob и tree соответственно), а pack'и их этих объектов дополнительно сжимаются эффективной delta компрессией. Но, честно говоря, не знаю как к обсуждаемому вопросу вообще относится внутреннее представление данных в VCS.
Только речь-то про то как проблему решить не изменяя репозиторий. Например, у вас банально нет прав за запись, или полиси проекта такое что нужны директории с двоеточиями (например, какие-нибудь имена классов/модулей). Повторяю, svn ничем не поможет.Вы можете придумывать все что вам угодно, но сам автор поста написал, что проблема решилась после того как папку удалили комитом с системы где допустимы двоеточия в именах, а это именно изменение репозитория. Но вы конечно можете продолжать думать что это не так :-)
Я написал как эта проблема могла быть легко решена изменением репо с помощью svn команды, аналогичной которой в git нет.
И кстати в svn есть очень много такого, чего git не умеет именно из-за различия внутреннего представления данных, архитектуры и т.д. Конечно справедливо и обратное утверждение, поэтому и есть над чем подумать при выборе СКВ для конкретного проекта т.к. кроме git и svn есть еще и другие СКВ.
Спасибо за статью, а точнее за ссылку на Tower 2. Субъективно лучший git-клиент для OS X.
Субъективно, бесплатный SourceTree ну ничем не хуже.
UFO just landed and posted this here
А я вообще не программист (ну быдло-кодер в лучшем случае) и все-равно обожаю гит, гитхаб и октокэта. Знаю всего, грубо говоря, пару консольных команд, для остального использую GUI. И мне все очень нравится, удивляюсь, что кто-то может считать это сложным. Конечно, бывали сложности, но в них я был сам дурак и больше дураком не буду.
Пожалуй разбавлю всеобщее восхваление небольшим зерном недовольства. Я сам пользуюсь Системами Контроля Версий (правда больше не git'ом, а mercurial'ом, но не суть), но не испытываю от этого особого удовольствия и прибегаю к их помощи только в крайнем случае.
Причина проста: эти системы обязывают постоянно принимать неотменяемые решения. Другими словами они чуть более чем полностью не поддерживают столь милый моему сердцу (и глазу) рефакторинг.
Писать качественные сообщения к коммитам, придумать вменяемые названия веток, которые должны быть и достаточно самоописываемыми и при этом не сильно многословными — всё это ты должен делать здесь и сейчас, иначе продолжать работу (не нарушая другие правила СКВ) невозможно.
А стоит лишь на секунду отвлечься, совершить небольшую ошибку — и всё. Это навсегда. Она навеки останется в репозитории как след на бетонной дорожке и миллион вечностей будет мозолить глаза тебе и твоим коллегам, постоянно вынуждая бороться со жгучим желанием удалить всё и создать новый репозиторий.
Кроме того эта «незыблемость старого» влечёт и ещё одну проблему, происходящую из самой сути СКВ — хранению ВСЕГО: постоянно перед добавлением чего-то нового в репу мучительно размышляешь, а стоит ли делать коммит сейчас? А может ещё немного поработать? А сколько осталось времени, пока репозиторий не раздуется и не начнёт тормозить? А что если он начнёт прямо в разгаре рабочего дня, как я это буду чинить?
Плюс СКВ по умолчанию не решает проблему бекапов кода между коммитами (например в течение дня). Вряд ли ты будешь создавать отдельную ветку «бекапы» и делать в неё коммиты скриптом каждые 10 сек (см выше про засорение репы).
Итого: болезный перфекционизм? Возможно. Но так или иначе при всех преимуществах СКВ зачастую я склоняюсь использовать обычную файловую систему и пачку самописных скриптов поверх неё. Ценой утраты некоторых вкусных искоробочных возможностей СКВ я получаю полнейшую гибкость в виде постоянной возможности оптимизировать структуру папок (заниматься рефакторингом в любое время и без ограничения). Производить любые оптимизации файловой системы и не быть ограниченным ничем кроме своей осторожности.
Причина проста: эти системы обязывают постоянно принимать неотменяемые решения. Другими словами они чуть более чем полностью не поддерживают столь милый моему сердцу (и глазу) рефакторинг.
Писать качественные сообщения к коммитам, придумать вменяемые названия веток, которые должны быть и достаточно самоописываемыми и при этом не сильно многословными — всё это ты должен делать здесь и сейчас, иначе продолжать работу (не нарушая другие правила СКВ) невозможно.
А стоит лишь на секунду отвлечься, совершить небольшую ошибку — и всё. Это навсегда. Она навеки останется в репозитории как след на бетонной дорожке и миллион вечностей будет мозолить глаза тебе и твоим коллегам, постоянно вынуждая бороться со жгучим желанием удалить всё и создать новый репозиторий.
Кроме того эта «незыблемость старого» влечёт и ещё одну проблему, происходящую из самой сути СКВ — хранению ВСЕГО: постоянно перед добавлением чего-то нового в репу мучительно размышляешь, а стоит ли делать коммит сейчас? А может ещё немного поработать? А сколько осталось времени, пока репозиторий не раздуется и не начнёт тормозить? А что если он начнёт прямо в разгаре рабочего дня, как я это буду чинить?
Плюс СКВ по умолчанию не решает проблему бекапов кода между коммитами (например в течение дня). Вряд ли ты будешь создавать отдельную ветку «бекапы» и делать в неё коммиты скриптом каждые 10 сек (см выше про засорение репы).
Итого: болезный перфекционизм? Возможно. Но так или иначе при всех преимуществах СКВ зачастую я склоняюсь использовать обычную файловую систему и пачку самописных скриптов поверх неё. Ценой утраты некоторых вкусных искоробочных возможностей СКВ я получаю полнейшую гибкость в виде постоянной возможности оптимизировать структуру папок (заниматься рефакторингом в любое время и без ограничения). Производить любые оптимизации файловой системы и не быть ограниченным ничем кроме своей осторожности.
Вы не путаете комиты с пушем в удаленный репозиторий? Думать над именем комита можно и позже и комитить сколько влезит пока все не сделаешь. А уже в конце перед пушем все почистить, написать сообщения для комитов или вообще все комиты заново нарезать.
Ну вот моя логика
Если стоит большая задача, то создаю отдельную ветку, если нет — моя ветка это мастер.
Если чувствую, что сегодня буду эксперементировать, то создаю отдельную локальную ветку на этот день. Если это рутина — то ничего не делаю.
Далее в течении дня делаю быстрые коммиты. Под его конец, если есть необходимость правлю историю. Если создавал дневную локальную ветку — rebase в ветку родителя.
Далее по ситуации в удаленном репозитории, если я вижу, что за день там нету коммитов, которые пересекались бы с тем, что я сделал, то делаю rebase того. что сделал. Если есть проблемы или коммитов слишком много, то merge.
Если стоит большая задача, то создаю отдельную ветку, если нет — моя ветка это мастер.
Если чувствую, что сегодня буду эксперементировать, то создаю отдельную локальную ветку на этот день. Если это рутина — то ничего не делаю.
Далее в течении дня делаю быстрые коммиты. Под его конец, если есть необходимость правлю историю. Если создавал дневную локальную ветку — rebase в ветку родителя.
Далее по ситуации в удаленном репозитории, если я вижу, что за день там нету коммитов, которые пересекались бы с тем, что я сделал, то делаю rebase того. что сделал. Если есть проблемы или коммитов слишком много, то merge.
Не надо ничего делать в мастере. Даже если вы две буквы хотите поправить. Зачем? Ветка в git'е — это одно число в файле с названием метки (старые метки могут паковаться вместе, что делает их ещё «легче»). Вы их можете буквально миллионами заводить — единственным следствием будет длинный вывод команды "
Таким образом можно параллельно разрабатывать хоть 10 фич одновременно. Когда они готовы — вливаете в
P.S. Это всё, конечно, работает если у вас надёжная инкрементальная система сборки и при переключении от ветки к ветке вам не приходится ждать полчаса пока всё пересоберётся. Если зависимости неправильно отрабатываются, то этот подход превращается в муку. Но это просто обозначает, что нужно разобраться с вашей системой сборки, вот и всё.
git branch"), но с этим легко бороться фильтрами.Таким образом можно параллельно разрабатывать хоть 10 фич одновременно. Когда они готовы — вливаете в
master, сносите временные метки и всё. Чисто, аккуратно, красиво. Грязи нет нигде — ни в репозитории, ни в истории.P.S. Это всё, конечно, работает если у вас надёжная инкрементальная система сборки и при переключении от ветки к ветке вам не приходится ждать полчаса пока всё пересоберётся. Если зависимости неправильно отрабатываются, то этот подход превращается в муку. Но это просто обозначает, что нужно разобраться с вашей системой сборки, вот и всё.
Не вижу необходимости создавать ветку или ставить метку для того чтобы поменять две буквы
Все зависит от вашей схемы ветвления.
Если вы по сути один, то по этому и лепите все в мастере. Если будете не один тогда прийдут все эти ветки.
Вот тут хорошее описание про один из способов использования гит веток: nvie.com/posts/a-successful-git-branching-model/
Если вы по сути один, то по этому и лепите все в мастере. Если будете не один тогда прийдут все эти ветки.
Вот тут хорошее описание про один из способов использования гит веток: nvie.com/posts/a-successful-git-branching-model/
Даже если ты один — это не повод всё валить в мастер. Затеял ты какой-нибудь красивый рефакторинг, разобрал всё на запчасти и тут к тебе прибегает заказчик и требуют срочно что-нибудь починить. Если у тебя каждая фича — в отдельной ветке (или серии веток, как у меня), то нет никаких проблем — переключились на мастер, создали ветку для багфикса, сидим починяем. Если же всё уже залито в master, то нужно перекинуть мастер в другую ветку, «сдвинуть» мастер «назад» и только после этого начать чинить. В запарке легко откатить не все правки (или откатить слишком много) и потом угробить день (а то и больше) в попытках понять почему оно «вдруг» перестало работать…
Ееех, цитирую себя же:
>>Если стоит большая задача, то создаю отдельную ветку.
Большая задача это та, которая займет больше дня. Если посреди дня прибегает заказчик и требует к концу запилить фичу, а ты в разработке — тупо наплевать и сделать на следующий день.
Если он прибегает и требует исправить баг. Коммитим текущее изменеия у себя локально. Переключаемся на стабильную ветку, исправляем и делаем патч.
>>Если стоит большая задача, то создаю отдельную ветку.
Большая задача это та, которая займет больше дня. Если посреди дня прибегает заказчик и требует к концу запилить фичу, а ты в разработке — тупо наплевать и сделать на следующий день.
Если он прибегает и требует исправить баг. Коммитим текущее изменеия у себя локально. Переключаемся на стабильную ветку, исправляем и делаем патч.
Завидую вашей уверенности в себе. Я вот не раз обнаруживал, что исправление двух букв влекло за собой необходимость чинить какие-нибудь тесты и/или приводило к весьма немалым изменениям в коде.
Ну разве что вы меняете две буквы в комментарии — тогда ещё есть шанс заранее предсказать чем это всё кончится.
Ну разве что вы меняете две буквы в комментарии — тогда ещё есть шанс заранее предсказать чем это всё кончится.
Просто соблюдайте правила гигиены и запускайте все тесты, если правите чужой код или только нужные, если правите свой.
После этого сразу становится понятно какой масштаб бедствия, чаще он близок к нулю, а раз в сто лет можно и совершить маневр: от текущего мастера делаем новые ветку, а потом откатывается до коммита удаленного мастера git reset
После этого сразу становится понятно какой масштаб бедствия, чаще он близок к нулю, а раз в сто лет можно и совершить маневр: от текущего мастера делаем новые ветку, а потом откатывается до коммита удаленного мастера git reset
Вы это всерьёз? Нет, реально?
Я могу сказать как эту проблему решаю я. Как только я начинаю работать над чем-то я создаю новый branch ("git checkout -b feature+0" и пустой commit ("git commit --allow-empty") с описанием. Дальше я периодически делаю "git checkout -b feature+1" и "git commit --amend" (можно и автоматом делать каждые 10 секунд — кому от этого хуже?). Всё. У меня есть как «тупая» история работы над фичей, так и всегда более-менее готовый к заливке changelist. Никакого «засорения репы» нет, так как после окончания работы над фичей все эти временные branch'и можно легко снести.
Что же касается «a сколько осталось времени, пока репозиторий не раздуется и не начнёт тормозить?», то этого я как бы совсем не понимаю. Чего вы такое складываете в Git, что он у вас тормозит? UHD video? А ваша пачка самописных скриптом не тормозит туда-сюда гонять терабайты?
В том-то и дело, что Git — это не совсем даже система контроля версий. Это просто система, которая позволяет вам удобно хранить много копий вашего дерева в одном репозитории и быстро между ними переключаться. Ну и там ещё пара вещей. Все ваши скрипты можно с лёгкостью навесить поверх git'а при желании — только работать всё будет раз в несколько быстрее.
Я могу сказать как эту проблему решаю я. Как только я начинаю работать над чем-то я создаю новый branch ("git checkout -b feature+0" и пустой commit ("git commit --allow-empty") с описанием. Дальше я периодически делаю "git checkout -b feature+1" и "git commit --amend" (можно и автоматом делать каждые 10 секунд — кому от этого хуже?). Всё. У меня есть как «тупая» история работы над фичей, так и всегда более-менее готовый к заливке changelist. Никакого «засорения репы» нет, так как после окончания работы над фичей все эти временные branch'и можно легко снести.
Что же касается «a сколько осталось времени, пока репозиторий не раздуется и не начнёт тормозить?», то этого я как бы совсем не понимаю. Чего вы такое складываете в Git, что он у вас тормозит? UHD video? А ваша пачка самописных скриптом не тормозит туда-сюда гонять терабайты?
В том-то и дело, что Git — это не совсем даже система контроля версий. Это просто система, которая позволяет вам удобно хранить много копий вашего дерева в одном репозитории и быстро между ними переключаться. Ну и там ещё пара вещей. Все ваши скрипты можно с лёгкостью навесить поверх git'а при желании — только работать всё будет раз в несколько быстрее.
Интересное решение. Если правильно понял, то вы что бы зафиксировать новое изменение, вы создаете новую ветку? Если это так, то можете пояснить, в чем отличие от нового комита в одной ветке и слиянием их всех после? Или же вы создаюете ветку для фичи с пустым комитом и потом все время добавляете в него?
Я создаю ветку с пустым commit'ом и всё время его меняю.
Важных отличий два:
1. У вас в истории не возникают 100500 commit'ов с бессмысленными названиями.
2. Вы можете ваши фичи с лёгкостью необычайной комбинировать в разных порядках.
Тут все почему-то обсуждают случай, когда они что-то такое наколбасили — и залили в master. И всё.
А если вам этого сделать не дадут? Когда я отправляю мой CL на review в gerrit — это только начало процесса. Он может после этого ещё неделю дорабатываться. А то и месяц. Всё это время ветки (ну какая-то их часть, конечно) остаются и позволяют мне смотреть что и как там происходит. И это ГОРАЗДО проще делать с одним CL'ем, чем с цепочкой из 100 измений типа «добавили строчку, удалили строчку». Конфликтов меньше.
Важных отличий два:
1. У вас в истории не возникают 100500 commit'ов с бессмысленными названиями.
2. Вы можете ваши фичи с лёгкостью необычайной комбинировать в разных порядках.
Тут все почему-то обсуждают случай, когда они что-то такое наколбасили — и залили в master. И всё.
А если вам этого сделать не дадут? Когда я отправляю мой CL на review в gerrit — это только начало процесса. Он может после этого ещё неделю дорабатываться. А то и месяц. Всё это время ветки (ну какая-то их часть, конечно) остаются и позволяют мне смотреть что и как там происходит. И это ГОРАЗДО проще делать с одним CL'ем, чем с цепочкой из 100 измений типа «добавили строчку, удалили строчку». Конфликтов меньше.
Есть ещё git rebase, чтобы собрать кучу коммитов в один.
Можно. Но… зачем? Если это — отдельные осмысленные изменения, то зачем мне их сливать в одну кучу? А если это — одно большое изменение, то зачем мне знать как я к нему шёл?
Да, это требует некоторого планирования, но в целом, не так сложно.
P.S. Вообще для «зарубок» нужно использовать теги (
Да, это требует некоторого планирования, но в целом, не так сложно.
P.S. Вообще для «зарубок» нужно использовать теги (
git tag), но я как-то привык использовать branch'и. Большой разницы нет: lightweight tag и branch — это почти одно и то же в git'е…git squash*
rebase переносит коммиты из ветки на другую ветку.
rebase переносит коммиты из ветки на другую ветку.
И да, и нет :-)
habrahabr.ru/post/161009/#comment_5546481
habrahabr.ru/post/161009/#comment_5546481
Тут обсуждают даже не то что, что то залили в мастер, а вообще в нужности системы контроля версии, и это пишут программисты, лол :)
Сразу определимся что, наживую в мастер ни кто ничего не льет, он только для релизов, все фичи по отдельным веткам, и потом мержатся с --no-ff в дев. И далее по git flow.
По поводу одного комита, тут сложно согласиться что он легче, чем пачка, особенно при мерже. Только если это не микрофича.
Когда есть комиты и нормально расписаны что они делают, и делают что то одно кокретное, их очень легко мержить или ребэйзить, так как не нужно вникать в логику всей фичи, а только конкретного комита. А когда у вас огромный комит, с 100+ изменений, конфликтов может, как будто меньше, но они на самом деле заметно больше, нужно дольше вникать что и как должно работать. Так же с большим комитом, нет возможности что то отменить позже. Так что я бы не стал экономить на комитах и описании ;)
Сразу определимся что, наживую в мастер ни кто ничего не льет, он только для релизов, все фичи по отдельным веткам, и потом мержатся с --no-ff в дев. И далее по git flow.
По поводу одного комита, тут сложно согласиться что он легче, чем пачка, особенно при мерже. Только если это не микрофича.
Когда есть комиты и нормально расписаны что они делают, и делают что то одно кокретное, их очень легко мержить или ребэйзить, так как не нужно вникать в логику всей фичи, а только конкретного комита. А когда у вас огромный комит, с 100+ изменений, конфликтов может, как будто меньше, но они на самом деле заметно больше, нужно дольше вникать что и как должно работать. Так же с большим комитом, нет возможности что то отменить позже. Так что я бы не стал экономить на комитах и описании ;)
Ну разумеется речь не идёт про создание commit'а на 1000 строк. Если вы свалили в кучу вещи, которые хотите потом залить по частям, то это, конечно, проблема, да, но не слишком большая: выдёргиваете из большого commit'а куски и вливаете их по отдельности. После rebase (или merge) ваш commit станет меньше :-) Одинаковые правки, сделанные в разных commit'ах не конфликтуют ведь.
Эти куски нужно потом еще найти что бы выдергнуть и слепить комит из них, в общем проблемы на пустом месте.
Имхо проще и лучше всегда использовать комиты с нормальным описанием.
1. Если это рабочая репа, то всегда будет видна история, легко найти комит который что то ломает, так же легко перенести отдельные комиты в другие ветки, мержить намного легче, в общем все лучше :)
2. Если от вас требуется, как при отправке в герит, «патч файл», дублируем ветку, сливаем все комиты в один и отправляем. Что то надо доработать? У вас всегда есть исходная ветка, легко мержимся/ребэйзимся, и далее все заново.
Имхо проще и лучше всегда использовать комиты с нормальным описанием.
1. Если это рабочая репа, то всегда будет видна история, легко найти комит который что то ломает, так же легко перенести отдельные комиты в другие ветки, мержить намного легче, в общем все лучше :)
2. Если от вас требуется, как при отправке в герит, «патч файл», дублируем ветку, сливаем все комиты в один и отправляем. Что то надо доработать? У вас всегда есть исходная ветка, легко мержимся/ребэйзимся, и далее все заново.
В Mercurial есть очень удобное расширение MQ, с которым вы сможете легко и удобно заниматься полировкой ваших коммитов, если для вас это так важно. Я обычно держу в MQ фичи, которые я начал делать, но временно бросил незаконченными. Я раньше тоже загонялся по поводу «делать только очень важные коммиты», но к счастью это прошло, сейчас иногда даже делаю коммиты с исправлениями опечаток в старых комментариях. На самом деле бояться большого количества коммитов не нужно, оно даже интересно — просматривать очень детальный лог. Чтобы отмечать нужные вам ревизии и иметь быстрый доступ к ним — используйте теги.
То, что вы описываете — это скорее про svn. Покуда коммит = пуш, и сразу виден всем остальным коллегам.
А в распределённой системе ну вот совершенно никто от Вас ничего такого не требует!
Там коммит это просто как кнопочка save в ворде. Пишите что угодно, или не пишите ничего. Это никого, кроме вас не волнует! Собираться проект на каждом локальном коммите тоже не обязан. Вот когда уже придёт время пушить — тогда можно просто засквашить всё в один коммит и дать человеческое описание.
А в распределённой системе ну вот совершенно никто от Вас ничего такого не требует!
Там коммит это просто как кнопочка save в ворде. Пишите что угодно, или не пишите ничего. Это никого, кроме вас не волнует! Собираться проект на каждом локальном коммите тоже не обязан. Вот когда уже придёт время пушить — тогда можно просто засквашить всё в один коммит и дать человеческое описание.
Для контроля структуры БД есть хорошие инструменты RedGATE Source Controll (умеет понимать работать с репозиториями различных VCS, в том числе git и svn), схожее есть в Toad
Я боюсь, что я что-нибудь сломаю.
Если без git, то починю и ни кто не заметит.
А с git потом все команда будет читать git log и ржать ;-).
Если без git, то починю и ни кто не заметит.
А с git потом все команда будет читать git log и ржать ;-).
Видите, за то теперь есть причина для самосовершенствования :)
Не обязательно сразу пушить изменения в центральный репозиторий — если Вы их предварительно протестируете, ничего плохого не случится. Если же найдете ошибку, которую не хотите показывать — можно создать еще одну ветку, на ней закоммитить исправленный код и уже ее запушить в центральный репозиторий, а ветку с некрасивым логом можно никому не показывать. То есть, всегда можно иметь две локальные ветки — черновую и чистовую.
не нужно лишних веток, для этого всего есть git rebase
Ветки — вещь полезная, не надо их бояться. Особенно если разрабатываешь код не один, а на изменения, которые вносишь, требуется много времени.
Может мы не поняли друг друга. Но, то что новая фича — новая ветка, это даже не стоит упоминать, это само собой разумеющееся.
Выше, если я правильно понял, советуют иметь 2 ветки дополнительных ветки на каждую фичу, и что то куда то переносить. Вот я и пишу, что ничего переносить не нужно, фича ветка чинится с помощью ребэйза.
Выше, если я правильно понял, советуют иметь 2 ветки дополнительных ветки на каждую фичу, и что то куда то переносить. Вот я и пишу, что ничего переносить не нужно, фича ветка чинится с помощью ребэйза.
Если быстро не пушить, то потом долго мержить. ;-)
Вам rebase забанили?
Зря вас заминусовали, ибо тот комплекс, который вы продемонстрировали (боязнь быть хуже остальных), касается практически всех людей.
Осознайте тот простой факт, что вы — человек, а значит имеете право на ошибку. И у всех находятся такие факапы, от которых веет самым маразматичным фэйспалмом.
Инструмент надо тыркать — чем дольше практика, тем меньше боязнь сделать что-то не то. Кроме того, VCS для того и предназначена, чтобы «накатывать-откатывать». Более того — в «правильном» процессе исподники не только VCSятся, но и бэкапятся (полное дерево файлов), так что риск завалить работу — минимален.
Осознайте тот простой факт, что вы — человек, а значит имеете право на ошибку. И у всех находятся такие факапы, от которых веет самым маразматичным фэйспалмом.
Инструмент надо тыркать — чем дольше практика, тем меньше боязнь сделать что-то не то. Кроме того, VCS для того и предназначена, чтобы «накатывать-откатывать». Более того — в «правильном» процессе исподники не только VCSятся, но и бэкапятся (полное дерево файлов), так что риск завалить работу — минимален.
Изучайте mercurial, он юзабельнее.
… и используйте HgLab
bitbucket вполне отвечает требованиям + возможность интеграции с jira и другими продуктами atlassian
… как только он станет бесплатным для некоммерческого применения. :)
Даже если это вопрос пяти долларов, сам гемор со всей этой оплатой, пересылкой лицензий и т.п. отталкивает — проще заюзать BitBucket. Так что подумайте, имеет ли смысл сидеть «без ничего», вымарщивая копейки или выталкивать бизнес на широкое использование и иметь бабло с «корпоратива».
Даже если это вопрос пяти долларов, сам гемор со всей этой оплатой, пересылкой лицензий и т.п. отталкивает — проще заюзать BitBucket. Так что подумайте, имеет ли смысл сидеть «без ничего», вымарщивая копейки или выталкивать бизнес на широкое использование и иметь бабло с «корпоратива».
А лучше — Kallithea.
Статья какая-то тухловатая… Автору не кажется, что переводить подобные статьи уже не модно лет как 10? Практически все команды разрабов и даже индивидуалы используют VCS, какой смысл тут увещевать «давайте перейдём с дискет на флэшки»? Да ещё с такой непотребной системой как Git.
Mercurial — вот за что надо агитировать.
Mercurial — вот за что надо агитировать.
А я уже сдался. Git стал де-факто, и им уже все более-менее умеют пользоваться. Ну, cli неконсистентен, ну, кишки наружу — да и фиг с ним, зато работает и все привыкли.
UFO just landed and posted this here
Если бы все им более-менее умели пользоваться, никто не писал бы статей типа «еще 10 способов сломать git репозиторий».
Де-факто он только для тех, кто фапает на Торвальдса. :) Раздуть шумиху вокруг продукта — много ума не надо (SharePoint, Java, Android), а понять, что за ними стоит просто пшик — тут циничный, непредвзятый ум нужен. :) Не слушайте толпу — она тоже может ошибаться, слушайте голос разума. Мне он говорит, что Mercurial лучше — профессиональная интуиция редко ошибается.
Кстати, если хотите, небольшая шпора по бранчеводству: thornik.livejournal.com слэш 436232.html
Кстати, если хотите, небольшая шпора по бранчеводству: thornik.livejournal.com слэш 436232.html
Я меркуриал и его преимущества прекрасно знаю, и сам им пользуюсь для личных проектов. А в команде все же эффективнее использовать то, что все знают и к чему все привыкли, чем разводить холивар :)
Уже давно была вдумчивая статья от гугла — сравнение гита и меркуриала, с подробным разбором ключевых особенностей, плюсов, минусов, в разных условиях. Найти не состави труда, но краткий вывод там — если вам не требуются какие-то индивидуальные особенности конкретной VCS, то используйте любую из них, существенной разницы вы не заметите. При этом mercurial был признан чуть более дружественным к пользователю.
UFO just landed and posted this here
Вы изрядно подбросили на вентилятор.
Mercurial пользовался не так много (на работе и для себя использую Git). Вот на днях нужно было найти кое-что в большом репозитории Mercurial (исходник Mozilla Firefox). Запустил hg grep 'word' и был огорчён тем, насколько медленно эта операция работает. При том, что винт SSD. Удручает.
Нет идеального инструмента, не нужно убеждать. Да, у Git есть недостатки, но есть и свои плюсы. Точно так же и с CVS, и с Mercurial.
Mercurial пользовался не так много (на работе и для себя использую Git). Вот на днях нужно было найти кое-что в большом репозитории Mercurial (исходник Mozilla Firefox). Запустил hg grep 'word' и был огорчён тем, насколько медленно эта операция работает. При том, что винт SSD. Удручает.
Нет идеального инструмента, не нужно убеждать. Да, у Git есть недостатки, но есть и свои плюсы. Точно так же и с CVS, и с Mercurial.
Основной плюс CVS в том, что он подох благополучно.
Но есть минус — до сих пор блуждают их зомби. =)
Если серьезно. Может показаться странным, но существуют ситуации, когда просто cvs'a хватает. Его можно заменить git'ом, конечно, но это потребует вложений ресурсов. А отдачи не будет никакой. В идеальном случае НЕ будет фейлов, а профита 0.
Простите за жаргонизмы.
Если серьезно. Может показаться странным, но существуют ситуации, когда просто cvs'a хватает. Его можно заменить git'ом, конечно, но это потребует вложений ресурсов. А отдачи не будет никакой. В идеальном случае НЕ будет фейлов, а профита 0.
Простите за жаргонизмы.
Закон хабра: в любую статью о гите всегда придут меркуриаловцы и расскажут, как всё делать правильно. Даже если их никто не приглашал.
У Меркуриал для меня неоспоримое преимущество — глубокая интеграция с Башем в Убунту
А что не так с git-completion в баше в стандартной поставке Убунты?
Сам пользуюсь фишем, где всё вообще волшебно, но только что проверил — в баше тоже в команде
Может есть какие-то вообще магические вещи, а я и не в курсе?
Сам пользуюсь фишем, где всё вообще волшебно, но только что проверил — в баше тоже в команде
git pull origin bug-647 автодополнились все 4 слова, к месту и разумным образом.Может есть какие-то вообще магические вещи, а я и не в курсе?
Ну, тогда и у Git для кого-то есть «неоспоримое преимущество» — zsh + плагин для Git тоже никто не отменял. Плюшек и у Git, и у Mercurial хватает.
Sign up to leave a comment.
6 мифов, мешающих разработчикам использовать Git