6 мифов, мешающих разработчикам использовать Git

http://sixrevisions.com/web-development/git-myths/
  • Перевод


Сейчас вы с трудом найдете профессионального разработчика, который не пользуется системой контроля версий (VCS) такой, как Git.
Но есть и не мало тех среди нас, кто не использует VCS по причине предвзятого мнения о системах контроля версий.
Ниже несколько мифов и отговорок, которые препятствуют внедрению в рабочий процесс разработчика Git (или любой другой VCS).

Миф 1: Мне не нужен Git, потому что я делаю резервные копии своих файлов


Регулярное резервное копирование вашей работы, бесспорно, хорошая привычка. Рекомендую оставить эту привычку даже когда вы будете пользоваться Git.

Но Git предоставляет вам намного больше преимуществ по сравнению с лишь только одним резервным копированием ваших файлов.

Без VCS вы столкнетесь с некоторыми проблемами.

Как вам называть ваши резервные копии? Если вы очень организованный человек, то вы могли бы пользоваться какой-нибудь понятной системой имен типа acme-inc-redesign_2013-11-12_v23.html. Однако любое отклонение от этой концепции именования быстро приведет к путанице и, вполне возможно, к проблемам с вашим кодом.
Пусть система типа Git беспокоится об этих мелочах, чтобы вы могли сфокусироваться на том, что вы делаете лучше всего — писать код.

Какую часть работы сохранять? Только измененные файлы или весь проект? В первом случае, было бы сложно видеть полную картину версии/варианта вашего проекта в любой момент времени. Во втором случае, где вы регулярно делаете резервные копии всего кода, у вас будет огромное число резервных копий по всему жесткому диску и чем больше файлов, тем будет больше сложностей.

Самая важная проблема, которую решает Git, вероятно следующая:

Как узнать в чем разница между резервными копиями? Очень немногие тратят время чтобы тщательно задокументировать каждое изменение, которое они вносят. Зато Git «подразумевает», что есть только один проект. Все остальное (старые версии и варианты) аккуратно скрыты в серверной части системы контроля версий и доступны в любой момент, когда они необходмы. И когда они будут вам нужны, вы можете запросить любую версию в любое время и у вас под рукой всегда будет копия полного проекта.

Кроме того, вы можете с большой точностью узнать какие изменения были в каждом файле. Вы можете сказать какие строки были добавлены, какие удалены, какие изменены — а это значит, что процессы баг-трейсинга, аварийных откатов к стабильной или промежуточной версии проекта становятся проще.

Миф 2: Git слишком сложный чтобы заморачиваться


Люди часто переоценивают то, насколько нужно знать Git чтобы получить от него все преимущества. Это так, если вам нужно потратить уйму времени чтобы погрузиться в нюансы Git и команды для крайне редких случаев — в действительности, Git предельно гибкая и мощная система. Но правда и то, что вы можете продуктивно работать с Git и использовать большую часть его функционала всего горсткой команд.

Да, учиться чему-то новому требует немного труда — от этого никуда не денешься — но преимущества, которые вы получите начав пользоваться Git, существенно превышают время и силы затраченные на то, чтобы в нем разобраться.

Изучение Git улучшит качество ваших проектов, а также эффективность и производительность, как разработчика. Кроме того, вы сможете совместно работать с другими разработчиками более систематичным и надежным способом, обеспечивающим еще большую производительность разработки для вас и вашей команды.

Миф 3: Git только для команд разработчиков


Распределенные системы контроля версий типа Git или Mercurial позволяют вам работать прямо на локальном компьютере. Если у вас проект в котором вы не работаете с кем-то совместно, вполне возможно выполнять все задачи прямо на вашем компьютере. Git предоставляет те же преимущества для одного разработчика, что и для команды.

Вам не нужен удаленный сервер или хостинг, чтобы использовать Git и все его полезные возможности.

Но стоит отметить, что использование удаленных хостингов кода типа GitHub имеет смысл даже если вы разработчик-одиночка, в этом случае у вас всегда будут внешние копии вашего кода в случае поломки или потери компьютера, или для безопасной синхронизации вашего проекта между несколькими компьютерами (возможно, у вас есть рабочий нотбук и личный компьютер дома, которыми вы пользуетесь для разработки). Тем не менее, это вовсе не обязательно, это просто один из плюсов.

Преимущества, которые дает Git остаются теми же и не важно, работаете вы в команде или один.

Миф 4: Командная строка это слишком сложно


Вам не нужно быть экспертом по интерфейсу командной строки (CLI) для использования Git. Фактически, большинству разработчиков понадобится совсем немного команд.

Вы можете выучить самые важные команды Git меньше чем за вечер: мы создали руководство под названием Command Line 101, которое вы можете прочитать чтобы узнать о CLI и как это связано с Git, — это часть нашей бесплатной онлайн книги "Изучи контроль версий с помощью Git: Пошаговое руководство для абсолютных новичков".

Но скажем так, горстка основных команд все еще перебор для вас, да и любые контакты с CLI. Или может быть вы скрепили кровью с товарищем соглашение никогда больше не использовать командную строку или по некоторым причинам вы просто не можете пользоваться CLI. Вы все еще можете пользоваться Git через приложения с графическим интерфейсом (GUI). Если вы на Windows, я бы порекомендовал вам взглянуть на Tortoise Git. На Mac OS вы можете глянуть на Tower — приложение, которое разработала моя компания Fournova.

Даже тех пользователей, у которых нет проблем с командной строкой, GUI мог бы еще больше повысить производительность тем, что некоторые задачи Git можно делать проще.

Миф 5: Я боюсь, что я что-нибудь сломаю


Все должно быть совсем наоборот: вы должны бояться что-то сломать, если вы не используете систему контроля версий, потому что без нее сложно отследить все ваши шаги и изменения кода.

Контроль версий — это ваша подстраховка. Когда все выходит целиком из строя, мы можем легко откатиться на предыдущую стабильную версию.

Используя Git вы сможете:

  • отменить локальные изменения (частично или полностью)
  • восстановить любую версию, если что-то пойдет не так
  • отменить эффект любых изменений, сделанных в прошлом


И я бы хотел отметить что на мой взгляд наиболее важная особенность Git: ветки.

Ветвление предоставляет нам безопасную экосистему, полностью отделенную от других частей нашего разрабатываемого проекта, для того чтобы опробовать новые функции. Это дает нам возможность экспериментировать с новым кодом, видеть и тестировать эффекты любых изменений кода, давая нам уверенность, что мы ни на что не повлияем за пределами текущей ветки.

Миф 6: Git чрезмерно разрекламирован, это просто очередной модный тренд, который потом исчезнет


Конечно, Git, действительно, не единственная существующая система контроля версий. Есть много других VCS, которые тоже можно рассматривать и у каждой есть свои достоинства.

Но ведь не случайно такие крупные проекты как например jQuery, Rail и Linux Kernel полагаются на Git для контроля версий и совместной работы над кодом.

Для проектов связанных с кодом Git, на данный момент, лучшая из того, что есть. И вот несколько причин почему Git хороший выбор.

Функционал
Конечно, функционал Git и его философия наиболее ценны из того, что предлагается пользователям: великолепная модель ветвлений, возможность автономной работы и концепция области подготовленных файлов — всего лишь часть из тех основных возможностей, помогающих разработчиками быть производительными, творческими и эффективными.

Популярность и жизнеспособность
Быть популярной и широкодоступной важно для любой системы. Популярность означает, что существуют сообщества, готвые помочь тебе начать работу с системой.

И когда вам придется работать над кодом в команде, велика вероятность, что члены вашей команды уже знают как пользоваться Git.

Кроме того, являясь популярной VCS, Git становится привлекательной для сторонних разработчиков и предоставляет средства поддержки и сервисы (например GitHub), которые могли был в дальнейшем расширить возможности работы с Git.

Популярность также гарантирует, что Git, как проект с открытым исходным кодом, в ближайшее время не исчезнет — что является важным факторм для разработчиков думающих о том доверять или нет открытому проекту в долгосрочной перспективе.

image
Официальная страница Git (2014)

Наличие качественных образовательных материалов
Еще ничего не было проще, чем начать изучение Git. На сегодняшний день существуют тонны документации, учебников, видео и руководств по этой VCS.

Вот несколько ресурсов которые помогут вам начать работу с Git.

Почему вы еще не пользуетесь Git?
Да, да, это я к вам: что же вас сдерживает от использования контроля версий на базе Git? Дайте знать об этом в комментариях!
Метки:
Поделиться публикацией
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама
Комментарии 228
  • +6
    Вот еще замечательный ресурс, на котором я сам учил GIT: githowto.com
    Есть на русском.
  • +39
    Но есть и не мало тех среди нас, кто не использует VCS по причине предвзятого мнения о системах контроля версий.

    Ребята, покажитесь!
    • +1
      Конечно, не показательно (по контексту опроса), но немного пугающе.
      85% опрошенных компаний используют систему контроля версий. Непонятно, как работают остальные 15%… Наверное, делают простые проекты, которые создаются одним разработчиком за одну неделю.

      habrahabr.ru/company/ruward/blog/215629/
      • 0
        Когда-то, давным-давно, работал по принципу: одна площадка, каждый пилит свой кусок.
        Я думаю, с тех пор у многих ничего не изменилось.
        А еще, помню, делали софт, и в конце задачи rsync'ались на машины всех остальных разрабов. Но это уже вообще за царя гороха, что называется.
        • 0
          К тому, как работают остальные. В одной из компаний, с которыми я сталкивался, в качестве хранилища кода (не скажешь же, что VCS) использовали реляционную БД.
          • 0
            Это вы, случайно, не про Midgard говорите? :)
            midgard-project.org/
            • 0
              нет, не про них. Где-то ниже, как я уже потом заметил, тоже вспоминали такой способ хранения кода. Выходит, он даже популярен.
        • +7
          Я видел, как люди сохраняют бэкапы кода, копируя каталоги и делают branch-и, копируя виртуальную машину (с установленной IDE и библиотеками).
          • 0
            Для домашнего пользования я знаю таких. На работе почти (не Git) всё (только общие проекты, персональные только я свои контролирую) хорошо.
            • +23
              VCS — для неуверенных в себе. Профессионалы не используют VCS. Они не используют версии. Они сразу пишут финальный вариант. Без ошибок. Без тестов и опросов пользователей.
              • 0
                Ага, а потом силой мысли упаковывают его в инсталлятор и устанавливают на компьютеры пользователей. :D
              • –6
                Не считаю своё мнение предвзятым. Всю жизнь писа́л код без VCS в простейшем редакторе и пока не испытываю необходимости в более сложных системах. Я не люблю следовать за модой.
                • +7
                  А какой средний размер проекта?
                  • +9
                    При чём тут мода?
                    Я тоже когда-то писал — даже не в редакторе — в тетрадке, ручкой, на коленях, в электричках. Когда учебник по ассемблеру доставался раз в неделю.
                    У вас такое же тяжёлое детство продолжается до сих пор, серьёзных проектов не доверяют?
                • +6
                  Вам не нужно быть экспертом по интерфейсу командной строки (CLI) для использования Git. Фактически, большинству разработчиков понадобится совсем немного команд.

                  Я вообще не могу вспомнить, когда и зачем юзал гит или свн из командной строки… И было ли это в принципе — не для каких-то административных задач :)
                  • +3
                    А чего народ минусует? Ну понятно, что в каком-то батнике автосборки обновление исходников из репозитория можно вызвать командой. Но в остальном, вы что, будете логи изменений в текстовом виде смотреть? Или версии в консоли сравнивать?? Или может вы результат выполнения blame каким-нибудь grep-ом анализируете??? Конечно сейчас набежит куча юникс-гиков с воплями «КС — это лучший интерфейс общения компьютера и человека» но ВЫ УЖ МЕНЯ ИЗВИНИТЕ, избаловался я — подавайте мне нормальный функциональный удобный GUI с рюшечками, хотя бы на уровне TortoiseSVN. На меньшее ни ради какого «супер навороченного» функционала Git'а не согласен.
                    • +8
                      В процессе миграции рабочего окружения с windows/tortoisesvn на гит и unix я первое время была того же мнения и искала удобный GUI. Нашла, благо под мак есть отличный SourceTree + разработчики из IntelliJ запилили достаточно удобную интеграцию в IDE. Но вот с течением времени все свелось к тому, что в rubymine/idea из всего функционала их VCS оболочки я использую только диффы и делаю коммиты ( удобно просмотреть локальные правки ), а SourceTree — это тяжелая артиллерия при сложных мержах или когда нужно разобраться в каше веток чужого проекта. Все остальное ( log, push/pull, rebase, атомарные коммиты, бранчевание ) теперь в терминале, так как быстрее и затачивается под себя.
                      • +5
                        SourceTree есть и под windows
                      • +11
                        А вот и толпа подоспела…
                        Ну почитать комиты конечно очень удобно в gitk, но всё остальное уж извините но в shell'е поудобнее будет. Хотя тут кому что приятнее и дело не в том какой ОС вы пользуетесь, просто либо вам уютно сидеть в терминале, либо нет.
                        • +1
                          Читать коммиты и в tig'е комфортно (он, правда, не всегда ветки показывает правильно после сложных rebase'ов, тогда заглядываю ещё в qgit/gitg).

                          Интересно, а в графических тулзах есть git add --patch? Удобен ли он, если есть?
                        • +1
                          Не знаю, как насчет git-а, но в целом в мире очень немного хороших GUI. Командная строка зачастую позволяет сделать все быстрее и удобнее, хотя бы потому что не требует двигать мышкой. Это даже несмотря на то, что я даже близко не гуру командной строки и баша.
                          Да, логи и диффы изменений я, конечно, буду смотреть в текстовом виде (поскольку это текст и есть).
                        • 0
                          Базовый гайд на bitbucket подразумевает минимальное использование командной строки. Если еще не пробовали, можете попробовать)
                          • +1
                            Во-первых, инициализация репозиториев — это всё-таки больше административная задача. Во-вторых, у меня там есть несколько проектов, и, если правильно помню, инициализировал я их из IDE (во всяком случае Eclipse давно и глубоко подружен со всевозможными altassian-примочками). В любом случае мне в жизни работы с консолью достаточно, и если её можно избежать — буду избегать :-)
                            • +3
                              Это «git init»-то в терминале набрать? Или вы про (о боги) «git push -u origin master»? (:
                              • +1
                                Это вообще о чём? Нет, «git init» набрать не лень. Но если то же самое можно сделать из текущего гуёвого окна, не вижу никакого резона специально искать консоль, в ней — нужный каталог, etc. Хочется кому-то всё это делать в консоли — да на здоровье, я предпочту выбирать тот метод, который лично моей левой пятке удобен в данный момент.
                                • +2
                                  Да хоть из гуя, хоть из консоли. Это об «административной задаче».
                          • +1
                            >> Я вообще не могу вспомнить, когда и зачем юзал гит или свн из командной строки…

                            Могу сказать, что PHPStorm нередко не может сделать commit при исправлении конфликтов. Только через консоль получается.

                            Ну и ещё git status, git -rm --cached
                            • 0
                              git add -p? Прекрасная штука для избирательного добавления в staging.
                              • 0
                                Был такой косяк, не коммитил. Поставил 8 версию, ту что EAP, вроде пофиксили, почти за месяц ни разу не повторилось.
                              • 0
                                init и config делаю. Ещё помню что-то хитрое с коммитами делал в текущей ветке.
                                • НЛО прилетело и опубликовало эту надпись здесь
                                  • 0
                                    Вот тут напоминают, что больше 10 лет назад, когда кроме CVS ничего не было, а исходников было так мало, что логи [l|s]trace можно было разглядывать глазами… :-)
                                  • +1
                                    Я вообще не могу вспомнить, когда и зачем юзал гит или свн из командной строки…

                                    Когда-то я начал свое знакомство с RCS с SVN. Я просто посчитал важным попробовать его, понять как оно в целом работает, концепции, достоинства и недостатки, дабы в будущем было с чем сравнивать. История, как никак.
                                    В качестве «клиента» выбрал tortoise svn. Ох, каким же это кошмаром! Казалось бы, вот создаем репозиторий, вот делаем коммиты, вот история перед глазами. Но проблема в том, что как только я сталкивался с трудностями или чем-то не понятным — приходилось отправляться перечитывать главы руководства. Особенно много хлопот доставили начальные директории. Т.е. где конкретно у начинается репозиторий, где проект и т.д.

                                    После того как я попробовал поработать с svn в терминале — все начало вставать на свои места, пришло какое-то понимание и предсказуемость. С гитом знакомиться начал уже сразу с шелла, потом как-то глянул на гуи и… ужаснулся. Как вообще его можно использовать?)

                                    p.s. гит профессионально не использую, программистом не являюсь
                                    • 0
                                      >гит профессионально не использую, программистом не являюсь

                                      Системы контроля версий использую со времён когда ни SVN, ни, тем более Git в природе не было. Профессиональным программистом являюсь. Git не очень-то употребляю в принципе, в работе больше Subversion. Не в терминале — ещё не хватало, отрывать левую руку от головы, а правую от мышки :) Более того, считаю, что признак консольного юзания VCS — просто отсутствие опыта работы с действительно большими проектами. Подчёркиваю: не навыков работы в консоли с гитом etc вообще, а именно повседневного юзания.
                                      • +1
                                        отрывать левую руку от головы, а правую от мышки
                                        работы с действительно большими проектами
                                        То есть левая рука в перманентном фейспалме из-за отчаяния от масштабов проекта и отвратительной локализации функциональности, поэтому можно пользоваться только GUI с помощью свободной правой руки с мышкой? :)

                                        Я думаю, GUI действительно полезен для всяких мерджилок. Там side-by-side сравнение очень кстати. Но что такого помимо просмотра диффов и мерджей, где GUI значительно может помочь?..
                                  • +20
                                    Любые DCVS (будь то гит или меркуриал) — это уже не просто какой-то плюс в резюме для разработчика, а уже своего рода часть культуры разработки, без которой уже просто нельзя. Не важно, один ты или в команде — если не умеешь согласовывать свою работу с чужой — то ты очень жирный минус как в команде, так и в опенсорс-проекте, начинаемым тобою. Если вы не используете какую-либо DCVS — можете считать себя в прошлом веке. Если ваша команда до сих пор не смогла перейти на что-либо, контролирующее историю разработки — то вы, как владелец бизнеса — уже теряете деньги и очень серьезно пора подумать как эту ситуацию изменить. Особенно если команда начинает упираться (это в особо запущенных случаях).

                                    Если вы наемный разработчик и вам руководство сильно мешает использовать DCVS — увольняйтесь, это тупик.
                                    Если вы работодатель и ваша команда сильно не хочет использовать DCVS — увольняйте, это тоже тупик.

                                    www.codeschool.com/courses/try-git
                                    • +5
                                      В hola.org вообще cvs используют и слушать не хотят про эти ваши гиты)
                                      • +3
                                        При всей моей любви к DVCS, всё же существуют валидные случаи, когда git хуже, например, svn. Если разрабатывается огромный проект и объём истории весит порядка нескольких терабайт, то тупо непрактично заставлять каждого разработчика держать копию всей истории локально. Насколько мне известно, git пока ещё не умеет полноценно работать с частичной историей.
                                        • +1
                                          Что в вашем понимании «огромный проект»? Мне приходилось работать с репозиториями 50 000 коммитов при ежедневном обновлении около 100 бранчей (и несколько сотен новых коммитов). С точки зрения клиента это заметно только в том, что иногда приходится делать git gc, ибо большое количество объектов замедляет операции с репозиторием. Но это замедление практически незаметно. На локальных операциях с ветками сказывается чуть менее чем никак.

                                          Если же в репозитории хранить блобы по 100 мегабайт, то это уже проблема организации данных а не DVCS как таковой.
                                          • +3
                                            История ~500K коммитов. Бинарных блобов минимум. Полная история в git'е, как я сказал выше, занимает несколько терабайт.
                                            • 0
                                              Ну это уже серьезные размеры, да. Но тут уже можно выкачивать конкретные ветки, а не делать git fetch.

                                              В конце концов, никому не нужно «все». Коллективы могут иметь непересекающиеся наборы бранчей и только «центр» хранит все актуальные ветки.
                                              • 0
                                                Скажите, а для чего вообще нужен репозиторий с 500к коммитов. Для каких целей реально может пригодиться история в пятьсот тысяч версий?
                                                • 0
                                                  Видимо вот для таких вот случаев. Еще и бинарей туда напихают для терабайтности :)
                                              • +1
                                                Не соглашусь с вами.
                                                Есть два момента, где git реально проигрывает svn: большие репозитории и права доступа.
                                                Так как svn работает с отдельными директориями, вы можете иметь репозиторий в несколько гигов (например, вы храните там xml-ки, или графические файлы), и не испытывать никакого дискомфорта. Разработчики используют одну директорию, дизайнеры — другую, и при этом вы имеете всегда единую версию. Git с такими размерами начнет вас жутко бесить (а потом просто сломается).
                                                Проблема с правами не такая существенная, и решается разделением на несколько репозиториев с индивидуальными правами. Но так вы теряете единую версию, что довольно неудобно.

                                                И вот тут вы начинаете использовать git локально, а svn централизованно. И прекрасно себя чувствуете :)
                                                • 0
                                                  По-моему первая проблема как и вторая решается разделением на отдельные репозитории, тем более что с этими частями работают разные люди в основном.
                                                  • +1
                                                    Во-первых, вы теряете тем самым единую версию репозитория, и поддержка версионирования становится затрудненной.
                                                    Кроме того, первая проблема не решается таким образом. Делать под каждый элемент дизайна отдельный репозиторий, конечно, можно, но очень неудобно.
                                                    • 0
                                                      Я согласен, что есть случпи когда это удобнее. Но все-таки у SVN и GIT разная парадигма работы с проектами, в SVN зачастую удобнее держать все в одном большом репозитории, а в GIT принято разделять на более мелкие. Вы сами написали, что разработчики используют одну часть, а дизайнеры другую, так вот в GIT приянято такие репозитории просто разделять, чтобы можно было удобно с ними работать.
                                                      • 0
                                                        Да, я это прекрасно представляю. Но гит устроен таким образом, что плохо поддерживает большие репозитории, с рабочей копией в несколько гигов. А согласитесь, дизайнерам удобнее работать с одним репозиторием designers.git, чем с десятком (иначе один большой не разобъешь на маленькие).
                                                        Собственно, это спор ни о чем. Гит — прекрасное средство, очень мощное. Да, это всё-таки не потребительский продукт, но он и не для домохозяек предназначен. И естественно, у него есть границы применимости. И в некоторых случаях svn — тоже весьма мощное средство — бывает удобнее. Если знаешь где что использовать, то и претензий к инструментам не будет.
                                              • 0
                                                Вы немного путаете понятия: git отлично умеет работать с частичной историей. Он не умеет работать с удалённой историей (то есть с той историей, которая не у вас локально хранится, а где-то на сервере).
                                              • +5
                                                Возможно вам будет удобно реорганизовать столь обьемную историю в набор субмодулей, тогда разработчики могли бы работать именно с частями проекта (частями истории проекта). Если есть какие-то бинарные данные в репе и их действительно необходимо по тем или иным причинам держать в связке с кодом (например, запакованные чем-то вроде themida билды ехешников, которые нужно проверять на множестве машин/сборок/виртуалок, чтобы все было всегда пучком и софт третьей стороны не ломал наши сборки + сюда же по каждой такой сборке свой отчет по тестированию) — то это можно и нужно реорганизовывать. Есть авторские эскизы, по которым ведется работа/обсуждение — также, в отдельную папку/субмодуль. Есть сомнение что на каждую задачу каждый разработчик обязан таскать полностью весь проект.

                                                git-scm.com/book/ru/Инструменты-Git-Подмодули

                                                Если это недопустимо и проект полностью неразборный — то так или иначе придется подумать над упрощением работы с ним, рано или поздно это выльется в замедление процесса разработки = потерю денег и конкурентного преимущества в скорости роста.
                                                • 0
                                                  Использование git submodules — это уже компромисс по удобству и подводным граблям. Плюс, доброй половине разработчиков таки нужен весь набор.
                                                  Размер и неразборность проекта, безусловно, не ускоряют разработку, да. Но это специфика нашего направления.
                                              • –1
                                                Ой, ну ладно уж. У меня прошлый проект был на GIT, а на текущем — SVN. Перейти на GIT могу в любой момент. Но смысла не вижу — SVN удобнее на простых операциях: тупо на коммит требуется меньше действий, проект небольшой, бранч актуальный всегда только один — что на проде стоит. Короче не везде фичи GIT нужны, а сложности они добавляют. Про всякие приколы с настройкой гита под винду — я вообще молчу.

                                                Я и в дропбоксе иногда код держу — какие-нибудь там задачки на пару страниц кода. Что мне теперь — голову пеплом посыпать и уйти на пенсию?
                                              • 0
                                                Меня останавливает только то, что есть еще структура БД и части кода хранятся в полях БД.
                                                • +21
                                                  По хорошему, «Я не использую git, так как код в БД» — нехорошая фраза.
                                                  «Я не держу код в БД, так как не смогу использовать git» — хорошая фраза.
                                                  • +8
                                                    + на тот случай, если где-то надо зафиксировать используемый в БД код и без него почему-то никак (процедуры, триггеры) — есть код с миграциями БД, который хранится в GIT
                                                    • 0
                                                      Насколько я знаю такой подход значительно усложняет сам процесс разработки. Впрочем, если есть хорошие ссылки — киньте почитать.
                                                      • 0
                                                        В чем вы видите усложнение? В миграциях или в коде в БД? Код в БД мне тоже не нравится, но бывают разные ситуации, по которым это нужно (либо требование заказчика, либо legacy система, либо по причинам производительности). Миграции — это просто набор инструкций в скрипте, который говорит, что и как нужно сделать с базой (структурой и данными в ней), чтобы ее «проагрейдить» или откатить назад до нужной версии. Типа как git для бд. Никакого значительного усложнения нет. Просто нужно описать вносимые в БД изменения или то, что уже там есть.
                                                        • 0
                                                          Ну так а потом мне можно будет менять структуру БД только в этих файлах? Могу я зайти в какой-нибудь MySQLAdmin (или в другую удобную мне систему) и поправить что-нибудь?

                                                          Или взять пример такой: в базе данных хранятся пункты меню (сайта, программы — не важно). Разработчик добавил пункт меню в панели управления и работает с новым ID (автоинкремент) в программе. Если INSERT еще можно в миграцию вставить (вручную?), то откатить такие изменения при наличии других подобных будет невозможно (вы не знаете до какого значения откатывать автоинкремент).

                                                          Я уже не говорю о том, что все эти выкрутасы с контролем версий не идут в стандартных пакетах систем контроля версий. Скорее всего придется самим писать/дописывать/додюдюривать… это соразмерно целому отдельному проекту.
                                                          • +2
                                                            Править потом структуру вы можете, но идеологически правильно будет это исправление внести потом в миграцию и ее протестировать, конечно. А то мало ли что и как вы направите… надо же это изменение как-то задокументировать в идеале и где-то хранить. Вы же наверное понимаете, что сегодня ручками вы что-то удачно подправили, а завтра — неудачно… или не вы… и как это все восстанавливать? Миграция помогает. Бэкапы БД тоже, но в меньшей степени — не та степень контроля.

                                                            С примером про меню все просто. В миграциях вы можете делать с БД все что угодно, в т.ч. и данными манипулировать. Т.е. это по сути обычные команды работы с БД. С той только разницей, что есть соглашение и вспомогательные функции по описанию операций апгрейда/даунгрейда до разных миграций («состояний» БД). Это конечно все в сильно упрощенном виде, тем не менее суть такая. Если что-то у вас откатить нельзя, то можете пометить миграция как безоткатную… С другой стороны, почему это insert не откатить? Смотря какой…

                                                            > Я уже не говорю о том, что все эти выкрутасы с контролем версий не идут в стандартных пакетах систем контроля версий. Скорее всего придется самим писать/дописывать/додюдюривать… это соразмерно целому отдельному проекту.

                                                            Что значит не идут? Любой текстовый файл прекрасно хранится в VCS с полной историей изменений. Будь то документация о коде, который содержится в БД, справка, или же исходный код миграций. Вообще, хранить можно что угодно, хоть raw dump'ы. Но тогда нормальной истории и сравнения версий не будет, конечно. Хотя тоже лучше, чем никак.
                                                            • +5
                                                              Ну так а потом мне можно будет менять структуру БД только в этих файлах? Могу я зайти в какой-нибудь MySQLAdmin (или в другую удобную мне систему) и поправить что-нибудь?

                                                              Т.е. вы на работающую production БД заходите гуевой тулзой и правите схему прямо налету?
                                                              • +8
                                                                Т.е. вы на работающую production БД заходите гуевой тулзой и правите схему прямо налету?

                                                                Welcome to the real world!
                                                                Два последних дня оперировали систему биллинга без наркоза. Спасибо начальству за принятие решений за час до срока их реализаций.
                                                                • +6
                                                                  Это не real world, а какой-то underworld. Даже не слышал, чтобы кто-то из знакомых так делал.
                                                                  • +1
                                                                    На самом деле такое повсеместно, если работаете не в IT-конторе. То есть IT — вспомогательная функция основного вида деятельности. Как правило квалификация сотрудников там ниже, начальство не понимает рисков неправильных подходов в разработке, зато видит результат в максимально короткие сроки.
                                                                    — Но ведь вы можете сейчас вон-там поменять, а мы посмотрим?
                                                                    — Могу, но…
                                                                    — Никаких «НО», надо сделать!
                                                                    • 0
                                                                      А вместо пробок в таких конторах тоже жучки вкручиваются? Просто интересно.
                                                                      • 0
                                                                        Бывает, что да. Но эти риски начальство видит, так как можно получить по шапке от пожарной инспекции (или кто там ими заведует).
                                                                • 0
                                                                  Я имел ввиду правку БД любого ответвления проекта. Править БД с помощью текстовых команд — то еще занятие.
                                                                • 0
                                                                  Могу я зайти в какой-нибудь MySQLAdmin (или в другую удобную мне систему) и поправить что-нибудь?

                                                                  Mysql Workbench позволяет синхронизировать структуру БД в обе стороны (кроссплатформенная, но только для mysql, впрочем аналогичное и для других баз должно быть). В git-е же будет храниться sql дамп (обновлять придется вручную через экспорт) и/или sql миграций.
                                                          • +3
                                                            Хорошие фразы действуют на девушек или на работодателей.
                                                            «Я не изобретаю искусственный интеллект, так как нейронная сеть не умещается в идеологию git» — плохая фраза.
                                                          • 0
                                                            1. Почему не применять к остальной части кода?
                                                            2. Структура бд хранится только в одной единственной базе?
                                                            • 0
                                                              1. В принципе, можно, но сомневаюсь, что будут какие-то плюсы. Код статической части примерно 5% от всего проекта.
                                                              2. Баз около 40 штук, структуры все разные. В зависимости от пользователей и прав доступа выполняются разные части кода из разных баз.

                                                              Вообщем, это мрак для любой системы контроля версий :)
                                                              • +10
                                                                это вы отлично придумали
                                                                • +8
                                                                  Это, наверное, и для программиста мрак.
                                                                  • +5
                                                                    Да ладно вам. Система на триггерах даёт неявный control и data flow, что значит, что поддерживать это сможет только один человек (команда), который становится незаменимым. Это же прекрасно для любого бизнеса.
                                                              • –1
                                                                Возможно, вам будет интересным вариант размещения в репозиторий (в основной, отдельным субмодулем) описания той части SQL, которая содержит такой код. Как минимум это даст ссылку на дату и автора задачи, которая что-то поломала, что в свою очередь поможет устранить проблему быстрее, чем без подобной информации.
                                                                Также, при проведении рефакторинга вами или же уже другими разработчиками эта информация тоже может помочь для ускорения старта над работами или же уточнениями что и для чего (если код не имеет ключевых комментариев).
                                                                • +1
                                                                  Поработали над структурой проекта — запустили дамп в файл, закоммитили. Какие проблемы?
                                                                  • 0
                                                                    Какие это дает преимущества перед простым бэкапом?
                                                                    • +6
                                                                      Диффы. Чужие правки и командная работа. Привязывание конкретной схемы БД к конкретному состоянию всего остального кода приложения в коммите.
                                                                      • +1
                                                                        1. У одной и той же БД на разных клиентах в разных системах и при разных настройках текст дампа может быть принципиально разным.
                                                                        2. Как можно забрать изменения в базе от других, если есть только полный дамп — не совсем понятно. Добавить строчку в программе — это не одно и тоже, что добавить строчку в БД (нужен отдельный INSERT)

                                                                        Правки должны выглядеть в виде скрипта-апдейта к какому-то эталонному состоянию БД, а не просто каждый раз дамп БД. Нужно делать что-то типа вот такого, как минимум: habrahabr.ru/post/121265/
                                                                        • +1
                                                                          Мы может про разные штуки говорим, когда дамп упоминаем? pg_dump в общем ло этих самых insert базу и бекапит, диффай не хочу.

                                                                          А так да, осталось ещё один малюсенький шажок сделать, и мы изобретем ActiveRecord Migrations и seed.rb пророк его.
                                                                          • +4
                                                                            1. Я думаю можно взять любые скриптовые миграции из RoR, Django, или Doctrine и писать миграции через него, если база достаточно простая. Под монстров типо Oracle наверняка существуют аналогичные инструменты для однообразного дампа в обычные файлы.
                                                                            2. Данные нужно бекапить, тут не нужна система контроля версий. В тех же скриптовых языках есть инструменты для фикстур — данные, для дальнейшего тестирования. Это уже flow конкретно взятого проекта.
                                                                    • 0
                                                                      Мы при выпуске релизов используем скриптование схемы базы (пользуемся для этого программой Aqua Data Studio, платная, зато там отличный Schema Script Generator для всех СУБД). На основе сравнения скриптов схемы можно прослеживать изменения в БД (как в структуре, так и в данных, если данные тоже скриптуются).
                                                                    • +1
                                                                      Если кто-то еще сомневается стоит использовать VCS или нет — стоит попробовать, уверяю вас, после того как я узнал об их существовании моя жизнь изменилась раз и навсегда =)
                                                                      Методы вроде резервного копирования файлов в качестве системы контроля версий не выдерживают никакой критики.
                                                                      Git — очень мощная и гибкая система, также рекомендую Mercurial — он, имхо, попроще.

                                                                      P.S. Выше в комментах не видел ссылки на этот ресурс — для всех начинающих и продолжающих обучение Git рекомендую великолепный интерактивный тренажер.
                                                                      • +12
                                                                        Под мак отличный клиент — SourceTree от Atlassian. Уже даже не помню, когда последний раз делал из консоли что-то сложнее git pull
                                                                        уже есть и весьма сносная версия под винду
                                                                        • +1
                                                                          Tower круче, имхо.
                                                                          • 0
                                                                            уже не помню чем, то чем-то он мне понравился меньше, чем sourcetree. Но это было давно
                                                                            • 0
                                                                              сейчас в sourcetree мне не хватает только драг-н-дроп.
                                                                            • +3
                                                                              Рискну спросить — а для чего гиту гуи клиент?
                                                                              • +13
                                                                                Ну вот сидишь ты в задумчивости. Перед глазами — IDE с каким-то жалким пятком открытых файлов. Левая рука крепко подпирает голову, а правая задумчиво елозит мышкой: клик на таб, Team -> History -> View commit message / Compare with revision… Diff? Нет уж, увольте — графический tkdiff, или meld, или diffuse, или diffmerge… Да и вообще, стоковые компараторы эклипса или комоды тоже сгодятся. И они прекрасны тем, что вполне вписываются в концепцию «голова в облаках, подпираемая одной рукой». Которая без гуёвого клиента невозможна в принципе, хоть с гитом, хоть с свн :-)
                                                                                • +4
                                                                                  Спасибо. Аж проникся…
                                                                                • +4
                                                                                  Порой под гуем удобней отбирать файлы для коммита/отмены. Ну удобней же.
                                                                                  По истории изменений бегать, смотреть кто, что, когда и как, анализировать, подпирая голову одной рукой, да…
                                                                                  • 0
                                                                                    Какие gui поддерживают git add --patch?
                                                                                    • 0
                                                                                      Например, эклипсовские плагины, и для гита, и для свн.
                                                                                • +2
                                                                                  Чтобы пальцы отдыхали.
                                                                                • +1
                                                                                  Tower ещё весьма хорош. Я из-за него чуть на Mac не перешел.
                                                                                  • 0
                                                                                    Наверное SourceTree в общем случае хорош. Умный, автоматически разнюхивающий изменения в ветке…
                                                                                    Однако, если применять расширения (такие как например git-fat — штука держащая массовый бинарный контент вне базы git) и консоль, то с ним могут случиться глюки — перестанет правильно оценивать изменения.
                                                                                    Словом, перешел в такой ситуации на SmartGit.
                                                                                    • +2
                                                                                      Под Windows есть Git Extensions, весьма удобный и простой в использовании инструмент.
                                                                                      • 0
                                                                                        Уж очень он гламурный. Пользуюсь GitExtensions.
                                                                                      • +43
                                                                                        Я активно пользуюсь git в своей профессиональной деятельности и тем не менее считаю, что он слишком сложный. Это, выражаясь по-английски, худший experience среди всех средств вэб-разработки, которыми я когда либо пользовался.

                                                                                        И да, я постоянно боюсь, что я что-нибудь сломаю. Потому что с git я постоянно что-нибудь ломаю. Шаг вправо/шаг влево от типового workflow «add-commit-push», и все, капец. Сиди гугли, консультируйся на git@freenode и бей в бубен. Авось починишь.

                                                                                        Чаще, чем хотелось бы, оказывался в ситуации, когда переделать работу заново было проще, чем восстанавливать покалеченное состояние репозитория.

                                                                                        Все локальные копии проектов держу в Dropbox с проплаченной функцией истории правок, чтобы можно было откатить проект (ну и, в первую очередь, состояние локального репозитория), не заморачиваясь с созданием резервных копий вручную.

                                                                                        А все потому, что git сделан кишками наружу. Если провести аналогию со стиральной машиной, то у git на переднюю панель выведены не кнопки «деликатная стирка», «отжим» и т. п., а «нагреть спираль», «подать воду», «раскрутить барабан» и далее в таком духе. И любое неверное действие заставляет вас горько жалеть, что вы — домохозяйка. Включил нагрев, забыв подать воду, — сжег одежду. Открыл крышку, забыв слить воду, — затопил соседей.

                                                                                        Или представьте, что git — это автомобиль. В случае с любым другим автомобилем, вы можете быть высокопрофессиональным водителем и при этом не иметь никакого представления, что у автомобиля под капотом. Но только не с git! C git вы должны быть матерым автослесарем, способным с завязанными глазами перебрать карбюратор, чтобы водить эту машину. В противном случае недостаточное знание git приведет к тому, что во время езды он вас катапультирует на ровном месте — но ведь любой уважающий себя автослесарь знает, что нельзя втыкать зарядку в прикуриватель в то мгновение, когда «стреляют» свечи зажигания.

                                                                                        Сейчас набегут гуру программироавния и объяснят, что я лох и не умею пользоваться инструментом (ну и карму сольют, куда без этого). Так вот, отвечу, что во всем мире вэб-разработки нет другой такой программы, как git. Все остальные утилиты нормальные (с другими VCS не сравниваю, опыта нет). Из неадекватных инструментов можно вспомнить разве что vi, который во времена, когда в мобильниках не было интернета, не оставил мне, оздаченному школьнику, вариантов, кроме как перезагрузить комп. Но vi по сравнению с git, как говорится, курит в сторонке.

                                                                                        Спасибо-пожалуйста.
                                                                                        • +1
                                                                                          Все локальные копии проектов держу в Dropbox с проплаченной функцией истории правок, чтобы можно было откатить проект (ну и, в первую очередь, состояние локального репозитория), не заморачиваясь с созданием резервных копий вручную.

                                                                                          Так для этого за рамки сценария «add-commit-push» и не придется выходить. Я полностью согласен с тем, что git — довольно-таки запутанная и местам (многими) не интуитивно-понятная система, но простые вещи она позволяет сделать просто, а сложные вещи позволяет хоть как-то сделать. И без гита я бы уже на несколько раз поседел.
                                                                                          • +3
                                                                                            Да я не агитирую против git. Наоборот, рекомендую всем начинающим разработчикам нырнуть в эту прорубь чем раньше, тем лучше. И никаких Svn и Mercurial: конкуретны git'а хоть и проще (и некоторые даже не уступают по функционалу), но в современном мире разработки git — полный монополист. Без него никуда. Если вы будете уметь пользоваться Mercurial и не будете уметь git, вы будете маргиналом.

                                                                                            Но, млять… Линус, за что?!
                                                                                            • +14
                                                                                              Пользуюсь исключительно Mercurial, если есть нужда поработать с чужим git-репозиторием — hg-git приходит на помощь. Не чувствую себя маргиналом. Mercurial как раз и славится тем, что он не «кишками наружу».
                                                                                              • +4
                                                                                                Но, млять… Линус, за что?!
                                                                                                Его можно понять как основного майнтейнера репо кода ядра линукса на тот момент. Для упрощения сопровождения ему просто необходимо было придумать Git, а всем остальным пришлось с этим согласиться, смириться и принять. И надо признать, что для этих целей Git — самое то!
                                                                                                Но потом Git стали тулить и к месту и не очень (чаще не очень). На самом деле это просто инструмент, точнее один из набора похожих инструментов — главное уметь выбрать из них наиболее подходящий. Но с этим сейчас мало кто заморачивается — а зря, т.к. в конкретной ситуации скорее всего лучше подойдет другая СКВ. Но слава богу еще есть те, кто способен поразмыслить над выбором СКВ для конкретного проекта и благодаря им продолжают развиваться известные и не очень альтернативы Git.
                                                                                                • +10
                                                                                                  Откровенно говоря, git вышел не очень по сравнению с mercurial.
                                                                                                  К сожалению, толпы адептов с гитхаба никогда этого не признают.
                                                                                                  • +1
                                                                                                    Не «за что», а «почему». Изначально Git делался так, как он делался, потому что он должен был в первую очередь удовлетворять потребности Linus'а. Который даже не автослесарь, а скорее автоконструктор. А для других — были разные надстройки (первой был Cogito). Но потом выяснилось, что поскольку надстроек — много, а git — один, то в конечном итоге всё равно git знать надо, иначе невозможно общаться с другими. А если ты уже знаешь git, то и Cogito тебе не нужен.
                                                                                                • +1
                                                                                                  Существует немало способов не иметь дела с «кишками» и не заглядывать под капот для совершения рутинных (да и не очень рутинных) операций :) Более того, у меня в работе 2 системы: subversion и git. Так вот, я даже не задумываюсь какие проекты в какой из них, всю заботу об этом берут на себя клиенты, точнее — плагины к IDE.
                                                                                                  • +5
                                                                                                    Опять же, это все замечательно в рамках стандартного workflow.

                                                                                                    А когда мэйнтейнер проекта в ответ на твой пулл-реквест говорит тебе, все супер, только у меня две недели не доходили руки посмотреть твой PR, так что ты rebase'ни его относительно master'а, squash'ни свои коммиты и попинай меня снова. И ты час разбираешься, как делать squash, потом полдня разбираешься, как разрешать конфликты merge'а, и в итоге оказываешься у разбитого корыта в состоянии detached head, из которого можно выйти только созданием новой ветки, что делает невозможным продолжение отправленного тобой PR'а…

                                                                                                    … то тут какбе никакие GUI не помогут. А вот сделать еще хуже — запросто.

                                                                                                    • +7
                                                                                                      А чем тут «локальная копия проекта в Dropbox» поможет? Вы хотите странного, а потом жалуетесь, что это сложно.

                                                                                                      Rebase изменяет контекст коммитов, его вообще лучше использовать как можно реже. Я согласен с kloppspb, современные IDE предоставляют возможность пользоваться git'ом, не открывая консоль, в СТАНДАРТНЫХ случаях. А для всего остального есть MasterCard man и google.

                                                                                                      Если уж использовать Вашу аналогию, то «быть высокопрофессиональным водителем и при этом не иметь никакого представления, что у автомобиля под капотом» невозможно. Элементарно, чтобы знать, почему на переднеприводном автомобиле в случае заноса надо газовать, а на заднеприводном — тормозить (упрощенно говоря), надо иметь хотя бы минимальное представление о физике и об устройстве автомобиля.
                                                                                                      • +6
                                                                                                        Необходимость для пользователя автомобиля знать, тормозить или газовать в заносе, — это нормально.

                                                                                                        А вот когда отсутствие знания, например, чем минеральное масло отличается от синтетического, может привести к внезапной капитальной поломке — это уже перебор.

                                                                                                        Хотя ваша аналогия «rebase/merge == способы выхода из заноса» очень хороша. Принимается.

                                                                                                        Но опять же, в обычном автомобиле вы для выхода из заноса просто жмете на нужную педаль. А в автомобиле git вы одной рукой залезаете под приборную панель, чтобы контролировать зажигание, другой регулируете заслонку, а рулите зубами. Из заноса вы в итоге выходите успешно, но по прибытии в пункт Б вы обнаруживаете, что переключение передаче при открытой пепельнице вызвало катапультирование вашего багажа в придорожную канаву.
                                                                                                        • +9
                                                                                                          Прекратите истерику и прочитайте Pro Git, пожалуйста. Добра, любви и чистой истории коммитов вам и вашей команде.
                                                                                                          • +1
                                                                                                            Чистая история коммитов — истинный кошмар дева в вечер пятницы.
                                                                                                            Давайте пожелаем непротиворечивой истории коммитов. :)
                                                                                                            • 0
                                                                                                              Для меня понятие «чистая» автоматически подразумевает и включает в себя «непротиворечивая» (:
                                                                                                              Даже не могу представить примера, когда может быть одно без другого. Есть идеи?
                                                                                                      • +5
                                                                                                        Эм, а зачем так сложно-то?
                                                                                                        Берем свою ветку, сквошим (git rebase -i hash) всё в один коммит, и черри-пиком переносим его на их мастер.
                                                                                                        • +24
                                                                                                          Берем шлицевую отвертку, ключ на двенадцать, залезаем по локоть под капот и с подвывертом регулируем карбюратор. Ничего сложного!
                                                                                                          • +4
                                                                                                            Так вы ведь и хотели карбюратор регулировать вместо того чтобы просто ехать. Разве нет?
                                                                                                            • +22
                                                                                                              Нет, я просто хотел доехать из пункта А в пункт Б — сделать pull request. Но на автомобиле Git без плясок с масленкой и домкратом ездить можно только вокруг гаража.
                                                                                                              • +6
                                                                                                                Шикарные у вас аналогии! Я в восторге!
                                                                                                                • +9
                                                                                                                  У вас ответ как у менеджера или клиента. Какие нафиг рефакторинги, какой код, какая еще спецификация мне просто нужна работающая программа.

                                                                                                                  Автомобили. Это если вы спроектировали и сделали, скажем, дверь для машины, принесли, а уже все поменялось, и вас просят исправить все крепления да и вообще всю форму двери что бы она подходила к новой машине.

                                                                                                                  А если по делу, пример что вы привели вполне класический, если есть трудности с ним, может есть смысл почитать документацию, пройти туториалы, на курсы там сходить что ли? Как вы себе представляете что бы система контроля версий, за вас исправила логику в коде?
                                                                                                          • +2
                                                                                                            Что-то я вас не понимаю. Чего сложного в rebase по другой ветке, и если сложность в конфликтах — в каких vcs решение конфиликтов проще? По моему оно вообще проще быть не может, только GUI. Ну и сливать коммиты проще некуда.
                                                                                                            Да, первый раз трудно смержить/сребейзить ветку, а пару раз это сделаешь — и все становится ясно-понятно.
                                                                                                            • +6
                                                                                                              так что ты rebase'ни его относительно master'а, squash'ни свои коммиты

                                                                                                              Видите ли, решение таких задач просто не может быть «простым». Слишком много ньюансов, которые будут меняться от случая к случаю.

                                                                                                              Поэтому ваша жалоба непонятна. Вы хотите решить _сложную_ задачу, но жалуетесь, что это нельзя сделать одной командой :)
                                                                                                              • +2
                                                                                                                >>rebase'ни его относительно master'а, squash'ни свои коммиты и попинай меня снова
                                                                                                                Потому, что 'rebase' нужно делать через merge:
                                                                                                                Делаем merge c веткой мастер, при этом происходит правильное слияние с учетом истории, также всегда создается новый коммит, по этому для того, чтобы откатить результат, достаточно перенести указатель ветки на один шаг назад.
                                                                                                                После слияния ветка master будет являться началом Ваших изменений, rebase на master уже пройдет без конфликтов, можно делать squash, если того требует мэйнтейнер: rebase --interactive, либо вообще способ для ленивых reset --mixed и делаем новый коммит.
                                                                                                                Важно: Если Вы знаете, что Ваши действия приведут к удалению оригинального коммита (как при rebase или reset) или если в чем-то не уверенны, сделайте резервный указатель (новый branch), к которому потом всегда можно будет вернуться.
                                                                                                              • 0
                                                                                                                Ок, есть проблема, когда изменения делались на одну версию, а потом надо их сделать на другую. При этом, сквош на ребейзе может наплодить конфликтов. Теперь вопрос в том, кто виноват — git или мейнтернер?

                                                                                                                Идем далее, измерим роль git`а — он может показать какие изменения на проекте произошли, а в некоторых случаях поможет даже нормально смержить. Но если какие-то проблемы с мерджами, то ничего не мешает вручную переписать код.

                                                                                                                Потом, про порчу репозитория — центральный репозиторий сложно испортить, если туда не пушить что попало. Если проблемы с локальным — можно скачать центральный в соседнюю папку, создать в ней локальную ветку заново и наложить в нее изменения из своего проекта, поскольку он никуда не денется, если не колдовать над коммитами задним числом. Ежели захочется в этом поупражняться — ничто не мешает забэкапить локальный репозиторий в пару кликов, просто создав архив из его папки.
                                                                                                            • 0
                                                                                                              Странно. Для меня наоборот — Mercurial намного непонятней, сложнее, и заставляет приспосабливать свой рабочий процесс под себя, а не себя под рабочий процесс.
                                                                                                              Видимо, действительно дело вкуса.

                                                                                                              P.S: vim сам не люблю. Emacs наше все (:
                                                                                                              • +3
                                                                                                                Дело не вкуса, а, скорее, привычки. Я лет 6 назад сходу гит не осилил, а с меркуриалом разобрался за полчаса. Это, конечно, было давно, сейчас гитом пользуюсь ежедневно, но все равно на операциях чуть сложнее тривиальных напрягаю мозг и вспоминаю меркуриал хорошим словом. При этом мне меркуриал всегда казался на порядок более простым, удобным и очевидным, но коллеги, привыкшие к гиту, испытывали с меркуриалом примерно те же ощущения, что и я с гитом.

                                                                                                                P.S: в JetBrains-овских IDE всегда первым делом ставлю vim-плагин, а из емакса я, если вдруг он где-то оказался в $EDITOR, каждый раз вспоминаю, как выходить :)
                                                                                                                • +1
                                                                                                                  По-моему, на уровне пользователя (коммиты, создание и слияние веток, pull/push) при работе из GUI что git, что mercurial — всё просто и быстро освоить, за 15 минут. Вот для понимания процесса и более сложных действий да, время уже другое.
                                                                                                                  • 0
                                                                                                                    У меня есть глупая привычка — досконально разбираться с каждый инструментом, с которым я работаю. Понять весь git тогда сходу не получилось.

                                                                                                                    Для домохозяйки примерно одинаково, да :)
                                                                                                              • +1
                                                                                                                Как вам удается сломать git? Можно пару примеров из реальной жизни? Я просто себе и представить не могу, так как там всё просто как гвозди.
                                                                                                                  • +1
                                                                                                                    так как там всё просто как гвозди

                                                                                                                    Гит после коммита никак не проверяет состояние репозитория и если во время записи коммита записываемый файл будет поврежден (у меня на винде частенько открыты eclipse с jgit-ом и tortoisegit что, похоже, иногда и приводит к конфликтам), то ваш репозиторий будет поврежден, но заметите вы это далеко не сразу и, скорее всего, успеете много накоммитить в уже мертвый репозиторий. В какой то момент гит поймет что репозиторий умер и скажет «error: sha1 mismatch». А вот дальше… дальше начитается дикий трэш, угар и содомия* (чего только стоят попытки определить что перед нами по известному sha1 и к какому коммиту это всё относится)… Собственно, нормального способа починить репозиторий в git-е нет (от слова вообще)

                                                                                                                    * «официальный» способ, но работает далеко не всегда, иногда репозиторий вообще невозможно восстановить.
                                                                                                                    • +2
                                                                                                                      Git всегда проверяет целостность. commit id берётся из контрольных сумм объектов. К тому же, файлы в репозиторий добавляются не из рабочей копии, как можно сначала подумать, а из индекса. а эта область лежит целиком в папке .git. Эта папка в свою очередь является «собственностью» git-a. И если кто-то что-то там в ней будет менять вслед за git — ничего удивительного тут нет.
                                                                                                                      Git пишет «карта», программа перетирает «В*ЧНОСТЬ».
                                                                                                                      Естественно, git задаст резонный вопрос:
                                                                                                                      «Где карта, Билли!»

                                                                                                                      Кстати, вброшу ка я: jgit некорректно работает с git и там много багов. Это скорее всего основная проблема.
                                                                                                                      Сам лично словил тонну глюков, когда использова maven-jgitflow-plugin. Обновление jgit частично помогло. Было это 3 месяца назад. Как сейчас обстоят дела я не знаю.
                                                                                                                      • 0
                                                                                                                        TortoiseGit по умолчанию обновляет индекс перед коммитом, возможно, это тоже играет свою роль. Но в любом случае, хотелось бы чтобы восстановление проходило проще чем сейчас (ну а угадывать содержимое файла чтобы получился нужный sha1 вообще по-моему за гранью).
                                                                                                                      • 0
                                                                                                                        При чем тут сам Git к jgit и TortoiseGit?

                                                                                                                        Сам я всегда работаю через Git Bash. Файлы всегда добавляю через git add --patch, реже просто через git add. И еще ни разу, за года 2 где-то, не было никаких проблем.
                                                                                                                        • 0
                                                                                                                          При чем тут сам Git к jgit и TortoiseGit?

                                                                                                                          При том что внутри TortoiseGit обычный git.

                                                                                                                          не было никаких проблем

                                                                                                                          Повезло. У меня раза три было и при этом в первый раз восстановить вообще не получилось, в последний же пришлось долго вспоминать что было в файле пару дней назад (но в итоге удалось все восстановить и залить его обратно).
                                                                                                                      • 0
                                                                                                                        У нас случалось сломать (после того как перешли с CVS). Обычно это выглядит так: Вася не делал pull пару дней и отстал от мастера на сотню-другую коммитов, создавая свои коммиты параллельно. Потом Вася выкачался, закономерно получил несколько конфликтов. Дальше Вася, не зная, что с ними делать, нажимает какую-то мутную кнопку в GUI-клиенте типа SmartGit, и в merge-commit попадают только Васины изменения. Вася думает, что всё нормально, потому что свой код он видит в исправном виде, и со спокойной душой нажимает push. После этого случается ещё где-нибудь 25 коммитов от всей команды, а на следующий день кто-то замечает, что часть функционала бесследно исчезла (причём тесты могли не упасть, потому что они тоже откатились). В результате получается ситуация, когда 1) надо понять, что вообще произошло и что конкретно исчезло; 2) склеить в единое целое коммиты Васи, сотню потерянных коммитов и 25 коммитов после этого (вполне возможны новые конфликты); 3) надрать попу Васе. Это всё решаемо, но замедляло процесс разработки.
                                                                                                                        • 0
                                                                                                                          Я правильно понимаю, что вы все вместе работаете в одной ветке?
                                                                                                                          Потому что я бывал в подобной ситуации на поза-поза прошлом проекте. Как только всем было выдано в мозг и предписание выучить и использовать git flow (парадигму, а не тулзу; хотя тулза зачётная), проблемы исчезли.
                                                                                                                          • –2
                                                                                                                            На 90% в одной. Ветки создают единичные разработчики в основном для рискованных и экспериментальных изменений.
                                                                                                                            • +1
                                                                                                                              Почитал про git flow здесь. Отдельные ветки для production и релизов есть, конечно. Обычно ад разворачивается в девелоперской ветке, но от этого не легче.
                                                                                                                        • 0
                                                                                                                          Это не лох — это ленивец.

                                                                                                                          Понять, какие команды нужны и только их тыкать:

                                                                                                                          * status, add, commit, reset, push, pull
                                                                                                                          * всякие логи и диффы уже удобнее в gui смотреть для тех, кто не очень

                                                                                                                          Также «git flow» на помощь.
                                                                                                                          • +2
                                                                                                                            Ну а чего тут бояться? Вполне адекватное мнение! Трольвадс же писал git не для мэйнстрима, а ПЕРСОНАЛЬНО ДЛЯ СЕБЯ, чтобы было удобнее управлять громадиной под названием linux kernel. Соответственно, никакого особо вдумчивого проектирования он не предполагал, чисто наляпывал функции, каких нехватало.
                                                                                                                            Я ведь тоже непредвзято сел сначала за git, почитал руководства и ощутил, что вроде бы все сущности на поверхности, но я не понимаю зачем это всё! А когда пробежался по меркуриалу, просветление наступило сразу — да это же DVCS! :) С тех пор git'а даже не касаюсь.
                                                                                                                          • +12
                                                                                                                            У Git очень высокий порог входа.
                                                                                                                            Git создаёт проблемы если с сурсконтролом работают не только программисты, но и переводчики, техврайтеры или верстальщики, которые могут быть на аутсорсе. В этом случае репозиторий превращается в сплошные merge веток и на диаграму без боли не взглянешь.
                                                                                                                            Именно потому SVN живее всех живых — он простой, что бы Линус не говорил.
                                                                                                                            По моему опыту, Hg показывает себя намного лучше чем Git в командах где работают не только гики.
                                                                                                                            Но в любом случае, Smart GitHG и SourceTree это спасение от сложностей с командам git'а.
                                                                                                                            • +1
                                                                                                                              Какой же он высокий?
                                                                                                                              Написать git init на текущей директории. Прочитать хотя бы про команды add и commit. Всё, можно использовать git: после каждого логического этапа git add. && git commit.
                                                                                                                              • +3
                                                                                                                                Абзац и фейспалм:
                                                                                                                                — Мержить и резолвить конфликты
                                                                                                                                — Смотреть изменения в файле
                                                                                                                                — Смотреть список измененных файлов
                                                                                                                                — Смотреть краткую или развернутую историю коммитов
                                                                                                                                — Передислоцировать локальный репозиторий на другой сервак
                                                                                                                                — Просмотреть кем создана та или ина строчка
                                                                                                                                — Отворачивать измения локально
                                                                                                                                — Отворачивать закомиченные изменения
                                                                                                                                — Развернуть рабочую копию/Файл той или иной ревизи.
                                                                                                                                Для нормального и самодостаточного обслуживания своей рабочей копии все это нужно знать.
                                                                                                                                P.S. Subversion-user мнение — кроме гита существуют другие системы контроля версий. Не нужно уподобляться мамочкам под подгузниками подразумевающими «памперс».
                                                                                                                                • +1
                                                                                                                                  Каждое из этого делается одной командой (в большинстве случаев даже без ключей) и изучается по мере надобности.
                                                                                                                                • +1
                                                                                                                                  Сгенерить ssh-ключик еще, и понять куда его на винде положить чтобы оно его увидело.
                                                                                                                              • +2
                                                                                                                                Для всех кто считает что git это очень сложно, или даже для тех кто так не считает рекомендую посмотреть это видео: www.youtube.com/watch?v=1ffBJ4sVUb4 оно прояснит множество непонятных вещей, останется только запомнить команды.
                                                                                                                                • 0
                                                                                                                                  Да, отличное выступление! Недавно его смотрел, очень доходчиво.
                                                                                                                                  Вот ещё сайт, где довольно просто объясняется работа git: think-like-a-git.net/. В том числе упоминается, почему для кого-то git прост, а кто-то не никак может «въехать».
                                                                                                                                  • 0
                                                                                                                                    В интернетах уже не продохнуть от статей и видео а-ля «Getting Started with Git», «Git For Dummies», «The Definitive Guide to Understanding Git» и т.п., а тут еще детские игрушки, махание руками… Целый перформанс.

                                                                                                                                    Дальше падать некуда. Если инструмент настолько нелогичен и настолько непрост в понимании, а его настойчиво проталкивают, внедряют и насаждают, то это уже Cargo Cult Engineering в самом ярком его проявлении.
                                                                                                                                  • +2
                                                                                                                                    svn достаточно хорош.
                                                                                                                                    • +2
                                                                                                                                      Задача:
                                                                                                                                      Имеется продукт, основная ветка.
                                                                                                                                      Команда делает 5-6 вещей (баг фиксы, изменения поведения, новые фичи и т.д.) одновременно, тестят их по готовности и вместе (проверить финальную интеграцию).
                                                                                                                                      На момент релиза (сроки которые могут, внезапно (с), меняться) нужно выпустить несколько фич:
                                                                                                                                      какие-то ещё не доделаны, 5 готовы, но выпустить надо только 4, от последней отказались. Ещё 2 перенесли на следующий релиз.
                                                                                                                                      Вопрос: как это сделать с SVN, чтобы разработчики не заплакали кровавыми слезами?
                                                                                                                                      • 0
                                                                                                                                        Ох блин, писать чтоли огромную статью про то как это делать? Крадко, в нашей команде 4 программиста и 6 художников, и 35 стабильных веток и около полутора десятков фичебранчей. И мы поддерживаем когда нужно ещё и разные версии продукта на разных инсталляциях и умеем катать фиксы и туда и туда. Короче ветки просто работают, и кровавыми слезами никто не плачет.
                                                                                                                                    • +12
                                                                                                                                      Но ведь не случайно такие крупные проекты как например jQuery, Rail и Linux Kernel полагаются на Git для контроля версий и совместной работы над кодом.


                                                                                                                                      Конкретно Linux Kernel его использует по той причине что git и был создан для его исходников. Как мне кажется есть немалая вероятность того что если бы git сделал не Торвальдс и его не форсили бы с помощью исходников линукса то он был бы далеко не так популярен.
                                                                                                                                      • 0
                                                                                                                                        --Сейчас вы с трудом найдете профессионального разработчика, который не пользуется системой контроля версий (VCS) такой, как Git

                                                                                                                                        думаю это миф. От силы 10% судя по С++/C# позициям.

                                                                                                                                        perforce, svn, teamviewr

                                                                                                                                        В гугле, в блакбери — perforce