0,0
рейтинг
31 июля 2014 в 23:14

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



Сейчас вы с трудом найдете профессионального разработчика, который не пользуется системой контроля версий (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? Дайте знать об этом в комментариях!
Перевод: Tobias Günther
Александр Малинов @almalini
карма
24,0
рейтинг 0,0
Full Stack Web Dev
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (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
            Например, эклипсовские плагины, и для гита, и для свн.
            • 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
            Для ленивых или удачливых (в смысле временных веток) есть ещё reflog.
          • 0
            Я все это прочитал и благословил богов за TFS на работе. Насколько в нем все проще!
        • 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? Можно пару примеров из реальной жизни? Я просто себе и представить не могу, так как там всё просто как гвозди.
      • 0
      • +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
    • +1
      Суть не в использовании конкретно гита, а вообще любой VSC.
    • +2
      Уж прям-таки и perforce? Не знаю про BlackBerry, но в Google все новые проекты — это Git. Android — это чистый git, Chromium — это тоже git, где кое-где ещё не до конца убит SVN. Perforce тоже есть, куда без него — но он используется скорее по историческим причинам.
  • +1
    Как раз сегодня столкнулся с проблемой, из-за которой коллеги на полном серьзе советовали поставить линукс на виртуалку… специально чтобы пользоваться git-ом. Один из девелоперов со стороны заказчика запулил папку с двоеточием в репозиторий. Я на виндовс, конечно же, словил fatal error при попытке обновиться — нельзя создать папку с двоеточием. В svn я мог бы забрать только свою часть проекта и работать, горя бы не зная. Но в гит ты обязан забрать все целиком. И костыли типа git-submodule-tools только под линукс. В конце-концов тот девелопер нехорошую папку удалил, но осадочек остался: при всей своей гибкости гит не может решить такую, казалось бы, элементарную проблему.
    • +9
      Хозяйке на заметку: в git можно забрать только определенные файлы/каталоги из remote ветки; более того, в git можно даже закомитить не файл целиком, а его часть.
    • +2
      А почему вы проблему системы валите на git? Если бы двоеточие оказалось в каталоге который вам нужен, даже svn никак бы вам не помогла. А вообще, git умеет по меньшей мере два способа обойти эту проблему (которую не надо считать элементарной при том что полнота и целостность репозитория как-бы лежит в основе DVCS): git clone --no-checkout и sparse checkout (git help read-tree).
      • 0
        Да, согласен, это не проблема VCS. Но для меня этот случай стал показателем, как в разных системах подходят к решению проблем. С svn это не проблема вообще — достаточно забрать только тот каталог, который нужен для работы. А с git нужно копаться в мануалах. Вроде решение есть, но нужно потратить кучу времени, чтобы его найти и воспользоваться.
        Вы даже указали конкретные команды, я прочитал описание этих команд, но до сих пор не до конца понимаю, как мне это может помочь. --no-checkout закачивает только историю без самих файлов. Нафига мне нужна история, если я хочу работать с файлам? sparse checkout ругнулся, что это недопустимая команда (возможно нужно что-то доустановить). Судя по описанию, такая команда есть и она позволяет забрать отдельный каталог. К сожалению, установка глобальная, по-видимому я тогда не смогу работать с другими репозиториями.
        • +2
          > А с 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/. На другие репозитории это никак не влияет.
      • –1
        А почему вы проблему системы валите на git? Если бы двоеточие оказалось в каталоге который вам нужен, даже svn никак бы вам не помогла.
        Если не знаете — не пишите чушь! svn грубо говоря, хранит папки и файлы, git хранит изменениня.
        Поэтому в svn это решается легко и просто — переименовываете папку прямо в репо простой командой:
        svn move -m «текст комита» репо/путь/к/старой/папке репо/путь/к/новой/папке
        и все!
        • +2
          Только речь-то про то как проблему решить не изменяя репозиторий. Например, у вас банально нет прав за запись, или полиси проекта такое что нужны директории с двоеточиями (например, какие-нибудь имена классов/модулей). Повторяю, svn ничем не поможет.

          > svn грубо говоря, хранит папки и файлы, git хранит изменениня

          Это неправда, git хранит именно целиковые файлы и директории (в объектах blob и tree соответственно), а pack'и их этих объектов дополнительно сжимаются эффективной delta компрессией. Но, честно говоря, не знаю как к обсуждаемому вопросу вообще относится внутреннее представление данных в VCS.
          • –1
            Только речь-то про то как проблему решить не изменяя репозиторий. Например, у вас банально нет прав за запись, или полиси проекта такое что нужны директории с двоеточиями (например, какие-нибудь имена классов/модулей). Повторяю, svn ничем не поможет.
            Вы можете придумывать все что вам угодно, но сам автор поста написал, что проблема решилась после того как папку удалили комитом с системы где допустимы двоеточия в именах, а это именно изменение репозитория. Но вы конечно можете продолжать думать что это не так :-)
            Я написал как эта проблема могла быть легко решена изменением репо с помощью svn команды, аналогичной которой в git нет.
            И кстати в svn есть очень много такого, чего git не умеет именно из-за различия внутреннего представления данных, архитектуры и т.д. Конечно справедливо и обратное утверждение, поэтому и есть над чем подумать при выборе СКВ для конкретного проекта т.к. кроме git и svn есть еще и другие СКВ.
  • 0
    Спасибо за статью, а точнее за ссылку на Tower 2. Субъективно лучший git-клиент для OS X.
    • +4
      Субъективно, бесплатный SourceTree ну ничем не хуже.
      • 0
        Спасибо. Посмотрел, соглашусь с вами. Функционал идентичен почти полностью.
  • НЛО прилетело и опубликовало эту надпись здесь
  • +3
    А я вообще не программист (ну быдло-кодер в лучшем случае) и все-равно обожаю гит, гитхаб и октокэта. Знаю всего, грубо говоря, пару консольных команд, для остального использую GUI. И мне все очень нравится, удивляюсь, что кто-то может считать это сложным. Конечно, бывали сложности, но в них я был сам дурак и больше дураком не буду.
  • –10
    Пожалуй разбавлю всеобщее восхваление небольшим зерном недовольства. Я сам пользуюсь Системами Контроля Версий (правда больше не git'ом, а mercurial'ом, но не суть), но не испытываю от этого особого удовольствия и прибегаю к их помощи только в крайнем случае.

    Причина проста: эти системы обязывают постоянно принимать неотменяемые решения. Другими словами они чуть более чем полностью не поддерживают столь милый моему сердцу (и глазу) рефакторинг.

    Писать качественные сообщения к коммитам, придумать вменяемые названия веток, которые должны быть и достаточно самоописываемыми и при этом не сильно многословными — всё это ты должен делать здесь и сейчас, иначе продолжать работу (не нарушая другие правила СКВ) невозможно.

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

    Кроме того эта «незыблемость старого» влечёт и ещё одну проблему, происходящую из самой сути СКВ — хранению ВСЕГО: постоянно перед добавлением чего-то нового в репу мучительно размышляешь, а стоит ли делать коммит сейчас? А может ещё немного поработать? А сколько осталось времени, пока репозиторий не раздуется и не начнёт тормозить? А что если он начнёт прямо в разгаре рабочего дня, как я это буду чинить?

    Плюс СКВ по умолчанию не решает проблему бекапов кода между коммитами (например в течение дня). Вряд ли ты будешь создавать отдельную ветку «бекапы» и делать в неё коммиты скриптом каждые 10 сек (см выше про засорение репы).

    Итого: болезный перфекционизм? Возможно. Но так или иначе при всех преимуществах СКВ зачастую я склоняюсь использовать обычную файловую систему и пачку самописных скриптов поверх неё. Ценой утраты некоторых вкусных искоробочных возможностей СКВ я получаю полнейшую гибкость в виде постоянной возможности оптимизировать структуру папок (заниматься рефакторингом в любое время и без ограничения). Производить любые оптимизации файловой системы и не быть ограниченным ничем кроме своей осторожности.
    • +6
      Вы не путаете комиты с пушем в удаленный репозиторий? Думать над именем комита можно и позже и комитить сколько влезит пока все не сделаешь. А уже в конце перед пушем все почистить, написать сообщения для комитов или вообще все комиты заново нарезать.
      • +1
        Именно. Я внизу описал мой workflow. Git вот ни разу не требует для внесения изменений придумывания каких-то там описаний или ещё чего-нибудь в этом роде.
    • +1
      Ну вот моя логика
      Если стоит большая задача, то создаю отдельную ветку, если нет — моя ветка это мастер.
      Если чувствую, что сегодня буду эксперементировать, то создаю отдельную локальную ветку на этот день. Если это рутина — то ничего не делаю.

      Далее в течении дня делаю быстрые коммиты. Под его конец, если есть необходимость правлю историю. Если создавал дневную локальную ветку — rebase в ветку родителя.

      Далее по ситуации в удаленном репозитории, если я вижу, что за день там нету коммитов, которые пересекались бы с тем, что я сделал, то делаю rebase того. что сделал. Если есть проблемы или коммитов слишком много, то merge.
      • +2
        Не надо ничего делать в мастере. Даже если вы две буквы хотите поправить. Зачем? Ветка в git'е — это одно число в файле с названием метки (старые метки могут паковаться вместе, что делает их ещё «легче»). Вы их можете буквально миллионами заводить — единственным следствием будет длинный вывод команды "git branch"), но с этим легко бороться фильтрами.

        Таким образом можно параллельно разрабатывать хоть 10 фич одновременно. Когда они готовы — вливаете в master, сносите временные метки и всё. Чисто, аккуратно, красиво. Грязи нет нигде — ни в репозитории, ни в истории.

        P.S. Это всё, конечно, работает если у вас надёжная инкрементальная система сборки и при переключении от ветки к ветке вам не приходится ждать полчаса пока всё пересоберётся. Если зависимости неправильно отрабатываются, то этот подход превращается в муку. Но это просто обозначает, что нужно разобраться с вашей системой сборки, вот и всё.
        • 0
          Не вижу необходимости создавать ветку или ставить метку для того чтобы поменять две буквы
          • +1
            Все зависит от вашей схемы ветвления.
            Если вы по сути один, то по этому и лепите все в мастере. Если будете не один тогда прийдут все эти ветки.
            Вот тут хорошее описание про один из способов использования гит веток: nvie.com/posts/a-successful-git-branching-model/
            • 0
              Даже если ты один — это не повод всё валить в мастер. Затеял ты какой-нибудь красивый рефакторинг, разобрал всё на запчасти и тут к тебе прибегает заказчик и требуют срочно что-нибудь починить. Если у тебя каждая фича — в отдельной ветке (или серии веток, как у меня), то нет никаких проблем — переключились на мастер, создали ветку для багфикса, сидим починяем. Если же всё уже залито в master, то нужно перекинуть мастер в другую ветку, «сдвинуть» мастер «назад» и только после этого начать чинить. В запарке легко откатить не все правки (или откатить слишком много) и потом угробить день (а то и больше) в попытках понять почему оно «вдруг» перестало работать…
              • 0
                Ееех, цитирую себя же:
                >>Если стоит большая задача, то создаю отдельную ветку.
                Большая задача это та, которая займет больше дня. Если посреди дня прибегает заказчик и требует к концу запилить фичу, а ты в разработке — тупо наплевать и сделать на следующий день.

                Если он прибегает и требует исправить баг. Коммитим текущее изменеия у себя локально. Переключаемся на стабильную ветку, исправляем и делаем патч.
          • +2
            Завидую вашей уверенности в себе. Я вот не раз обнаруживал, что исправление двух букв влекло за собой необходимость чинить какие-нибудь тесты и/или приводило к весьма немалым изменениям в коде.

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

              После этого сразу становится понятно какой масштаб бедствия, чаще он близок к нулю, а раз в сто лет можно и совершить маневр: от текущего мастера делаем новые ветку, а потом откатывается до коммита удаленного мастера git reset
    • +5
      Вы это всерьёз? Нет, реально?

      Я могу сказать как эту проблему решаю я. Как только я начинаю работать над чем-то я создаю новый 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'а при желании — только работать всё будет раз в несколько быстрее.
      • 0
        Интересное решение. Если правильно понял, то вы что бы зафиксировать новое изменение, вы создаете новую ветку? Если это так, то можете пояснить, в чем отличие от нового комита в одной ветке и слиянием их всех после? Или же вы создаюете ветку для фичи с пустым комитом и потом все время добавляете в него?
        • +1
          Я создаю ветку с пустым commit'ом и всё время его меняю.

          Важных отличий два:
          1. У вас в истории не возникают 100500 commit'ов с бессмысленными названиями.
          2. Вы можете ваши фичи с лёгкостью необычайной комбинировать в разных порядках.

          Тут все почему-то обсуждают случай, когда они что-то такое наколбасили — и залили в master. И всё.

          А если вам этого сделать не дадут? Когда я отправляю мой CL на review в gerrit — это только начало процесса. Он может после этого ещё неделю дорабатываться. А то и месяц. Всё это время ветки (ну какая-то их часть, конечно) остаются и позволяют мне смотреть что и как там происходит. И это ГОРАЗДО проще делать с одним CL'ем, чем с цепочкой из 100 измений типа «добавили строчку, удалили строчку». Конфликтов меньше.
          • 0
            Есть ещё git rebase, чтобы собрать кучу коммитов в один.
            • +1
              Можно. Но… зачем? Если это — отдельные осмысленные изменения, то зачем мне их сливать в одну кучу? А если это — одно большое изменение, то зачем мне знать как я к нему шёл?

              Да, это требует некоторого планирования, но в целом, не так сложно.

              P.S. Вообще для «зарубок» нужно использовать теги (git tag), но я как-то привык использовать branch'и. Большой разницы нет: lightweight tag и branch — это почти одно и то же в git'е…
              • +1
                Потому что если процесс разработки фичи длится долго, в какой-то момент вы можете оказатся у одного толстого коммита, которые перестал работать, а откатиться на последнее стабильное изменение в пределах этой фичи вы уже не сможете (если не лазать по reflog'у с факелом и слезами на глазах).
            • 0
              git squash*
              rebase переносит коммиты из ветки на другую ветку.
          • +1
            Тут обсуждают даже не то что, что то залили в мастер, а вообще в нужности системы контроля версии, и это пишут программисты, лол :)

            Сразу определимся что, наживую в мастер ни кто ничего не льет, он только для релизов, все фичи по отдельным веткам, и потом мержатся с --no-ff в дев. И далее по git flow.

            По поводу одного комита, тут сложно согласиться что он легче, чем пачка, особенно при мерже. Только если это не микрофича.
            Когда есть комиты и нормально расписаны что они делают, и делают что то одно кокретное, их очень легко мержить или ребэйзить, так как не нужно вникать в логику всей фичи, а только конкретного комита. А когда у вас огромный комит, с 100+ изменений, конфликтов может, как будто меньше, но они на самом деле заметно больше, нужно дольше вникать что и как должно работать. Так же с большим комитом, нет возможности что то отменить позже. Так что я бы не стал экономить на комитах и описании ;)
            • 0
              Ну разумеется речь не идёт про создание commit'а на 1000 строк. Если вы свалили в кучу вещи, которые хотите потом залить по частям, то это, конечно, проблема, да, но не слишком большая: выдёргиваете из большого commit'а куски и вливаете их по отдельности. После rebase (или merge) ваш commit станет меньше :-) Одинаковые правки, сделанные в разных commit'ах не конфликтуют ведь.
              • 0
                Эти куски нужно потом еще найти что бы выдергнуть и слепить комит из них, в общем проблемы на пустом месте.
                Имхо проще и лучше всегда использовать комиты с нормальным описанием.

                1. Если это рабочая репа, то всегда будет видна история, легко найти комит который что то ломает, так же легко перенести отдельные комиты в другие ветки, мержить намного легче, в общем все лучше :)
                2. Если от вас требуется, как при отправке в герит, «патч файл», дублируем ветку, сливаем все комиты в один и отправляем. Что то надо доработать? У вас всегда есть исходная ветка, легко мержимся/ребэйзимся, и далее все заново.
    • +1
      В Mercurial есть очень удобное расширение MQ, с которым вы сможете легко и удобно заниматься полировкой ваших коммитов, если для вас это так важно. Я обычно держу в MQ фичи, которые я начал делать, но временно бросил незаконченными. Я раньше тоже загонялся по поводу «делать только очень важные коммиты», но к счастью это прошло, сейчас иногда даже делаю коммиты с исправлениями опечаток в старых комментариях. На самом деле бояться большого количества коммитов не нужно, оно даже интересно — просматривать очень детальный лог. Чтобы отмечать нужные вам ревизии и иметь быстрый доступ к ним — используйте теги.
    • +3
      То, что вы описываете — это скорее про svn. Покуда коммит = пуш, и сразу виден всем остальным коллегам.
      А в распределённой системе ну вот совершенно никто от Вас ничего такого не требует!
      Там коммит это просто как кнопочка save в ворде. Пишите что угодно, или не пишите ничего. Это никого, кроме вас не волнует! Собираться проект на каждом локальном коммите тоже не обязан. Вот когда уже придёт время пушить — тогда можно просто засквашить всё в один коммит и дать человеческое описание.
  • 0
    Для контроля структуры БД есть хорошие инструменты RedGATE Source Controll (умеет понимать работать с репозиториями различных VCS, в том числе git и svn), схожее есть в Toad
  • –7
    Я боюсь, что я что-нибудь сломаю.
    Если без git, то починю и ни кто не заметит.
    А с git потом все команда будет читать git log и ржать ;-).
    • +3
      Видите, за то теперь есть причина для самосовершенствования :)
    • 0
      Не обязательно сразу пушить изменения в центральный репозиторий — если Вы их предварительно протестируете, ничего плохого не случится. Если же найдете ошибку, которую не хотите показывать — можно создать еще одну ветку, на ней закоммитить исправленный код и уже ее запушить в центральный репозиторий, а ветку с некрасивым логом можно никому не показывать. То есть, всегда можно иметь две локальные ветки — черновую и чистовую.
      • 0
        не нужно лишних веток, для этого всего есть git rebase
        • 0
          Ветки — вещь полезная, не надо их бояться. Особенно если разрабатываешь код не один, а на изменения, которые вносишь, требуется много времени.
          • 0
            Может мы не поняли друг друга. Но, то что новая фича — новая ветка, это даже не стоит упоминать, это само собой разумеющееся.
            Выше, если я правильно понял, советуют иметь 2 ветки дополнительных ветки на каждую фичу, и что то куда то переносить. Вот я и пишу, что ничего переносить не нужно, фича ветка чинится с помощью ребэйза.
      • 0
        Если быстро не пушить, то потом долго мержить. ;-)
    • +1
      Вам rebase забанили?
      • –2
        rebase при групповой разработке создает заметные неудобства. На практике больше подойдет revert.

        Юмор даже по смайликам распознавать перестали…
    • 0
      Зря вас заминусовали, ибо тот комплекс, который вы продемонстрировали (боязнь быть хуже остальных), касается практически всех людей.
      Осознайте тот простой факт, что вы — человек, а значит имеете право на ошибку. И у всех находятся такие факапы, от которых веет самым маразматичным фэйспалмом.
      Инструмент надо тыркать — чем дольше практика, тем меньше боязнь сделать что-то не то. Кроме того, VCS для того и предназначена, чтобы «накатывать-откатывать». Более того — в «правильном» процессе исподники не только VCSятся, но и бэкапятся (полное дерево файлов), так что риск завалить работу — минимален.
  • +2
    Изучайте mercurial, он юзабельнее.
    • –2
      … и используйте HgLab
      • 0
        bitbucket вполне отвечает требованиям + возможность интеграции с jira и другими продуктами atlassian
      • 0
        … как только он станет бесплатным для некоммерческого применения. :)

        Даже если это вопрос пяти долларов, сам гемор со всей этой оплатой, пересылкой лицензий и т.п. отталкивает — проще заюзать BitBucket. Так что подумайте, имеет ли смысл сидеть «без ничего», вымарщивая копейки или выталкивать бизнес на широкое использование и иметь бабло с «корпоратива».
      • +1
        А лучше — Kallithea.
  • +8
    Статья какая-то тухловатая… Автору не кажется, что переводить подобные статьи уже не модно лет как 10? Практически все команды разрабов и даже индивидуалы используют VCS, какой смысл тут увещевать «давайте перейдём с дискет на флэшки»? Да ещё с такой непотребной системой как Git.
    Mercurial — вот за что надо агитировать.
    • +1
      А я уже сдался. Git стал де-факто, и им уже все более-менее умеют пользоваться. Ну, cli неконсистентен, ну, кишки наружу — да и фиг с ним, зато работает и все привыкли.
      • 0
        Git стал де-факто, и им уже все более-менее умеют пользоваться

        Со вторым согласен, с первым — категорически нет. Немало проектов живут на svn, немало даже на cvs. Просто они работают, а не з***дят «о трендах» :-)
      • 0
        Если бы все им более-менее умели пользоваться, никто не писал бы статей типа «еще 10 способов сломать git репозиторий».
      • –5
        Де-факто он только для тех, кто фапает на Торвальдса. :) Раздуть шумиху вокруг продукта — много ума не надо (SharePoint, Java, Android), а понять, что за ними стоит просто пшик — тут циничный, непредвзятый ум нужен. :) Не слушайте толпу — она тоже может ошибаться, слушайте голос разума. Мне он говорит, что Mercurial лучше — профессиональная интуиция редко ошибается.
        Кстати, если хотите, небольшая шпора по бранчеводству: thornik.livejournal.com слэш 436232.html
        • +2
          Я меркуриал и его преимущества прекрасно знаю, и сам им пользуюсь для личных проектов. А в команде все же эффективнее использовать то, что все знают и к чему все привыкли, чем разводить холивар :)
        • 0
          Уже давно была вдумчивая статья от гугла — сравнение гита и меркуриала, с подробным разбором ключевых особенностей, плюсов, минусов, в разных условиях. Найти не состави труда, но краткий вывод там — если вам не требуются какие-то индивидуальные особенности конкретной VCS, то используйте любую из них, существенной разницы вы не заметите. При этом mercurial был признан чуть более дружественным к пользователю.
  • +9
    А я считаю, что это не мифы.
    Миф 1: Мне не нужен Git, потому что я делаю резервные копии своих файлов
    — Так и есть, гит не нужен, нужен меркуриал.
    Миф 2: Git слишком сложный чтобы заморачиваться
    — Так и есть, гит сложен и нелогичен. Меркуриал, опять же, в этом плане намного более привлекателен. Четкая математическая модель, лежащая в его основе, помогает понимать, что происходит и как добиться нужного эффекта.
    Миф 3: Git только для команд разработчиков
    — Гит только для тех команд, которые уже используют гит.
    Миф 4: Командная строка это слишком сложно
    — Командная строка гита действительно сложна. Командная строка меркуриала намного дружелюбнее.
    Миф 5: Я боюсь, что я что-нибудь сломаю
    — Я тоже боюсь. Множество гайдов есть про то, как использовать гит, чтобы ничего не сломать. Это как языки, где можно срелять себе в ноги, против языков с большим количеством статических проверок.
    Миф 6: Git чрезмерно разрекламирован, это просто очередной модный тренд, который потом исчезнет
    — Надеюсь мой коментарий укажет людям на существование лучших альтернатив.
    • +4
      Вы изрядно подбросили на вентилятор.
      Mercurial пользовался не так много (на работе и для себя использую Git). Вот на днях нужно было найти кое-что в большом репозитории Mercurial (исходник Mozilla Firefox). Запустил hg grep 'word' и был огорчён тем, насколько медленно эта операция работает. При том, что винт SSD. Удручает.
      Нет идеального инструмента, не нужно убеждать. Да, у Git есть недостатки, но есть и свои плюсы. Точно так же и с CVS, и с Mercurial.
      • +2
        Основной плюс CVS в том, что он подох благополучно.
        • +1
          Но есть минус — до сих пор блуждают их зомби. =)
          Если серьезно. Может показаться странным, но существуют ситуации, когда просто cvs'a хватает. Его можно заменить git'ом, конечно, но это потребует вложений ресурсов. А отдачи не будет никакой. В идеальном случае НЕ будет фейлов, а профита 0.
          Простите за жаргонизмы.
    • –1
      Закон хабра: в любую статью о гите всегда придут меркуриаловцы и расскажут, как всё делать правильно. Даже если их никто не приглашал.
  • +1
    У Меркуриал для меня неоспоримое преимущество — глубокая интеграция с Башем в Убунту
    • +1
      А что не так с git-completion в баше в стандартной поставке Убунты?
      Сам пользуюсь фишем, где всё вообще волшебно, но только что проверил — в баше тоже в команде git pull origin bug-647 автодополнились все 4 слова, к месту и разумным образом.

      Может есть какие-то вообще магические вещи, а я и не в курсе?
    • 0
      Ну, тогда и у Git для кого-то есть «неоспоримое преимущество» — zsh + плагин для Git тоже никто не отменял. Плюшек и у Git, и у Mercurial хватает.

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