Почему я не испытываю неприязни к Git: скрытая целостность

Original author: Armin Ronacher
  • Translation


Предлагаю вашему вниманию перевод небольшой статьи из блога Armin Ronacher — автора Flask, Jinja2 и много чего еще. На этот раз он поделится своими мыслями о Git — распределенной системе управления версиями файлов.

Git для меня интересная тема. Впервые я попробовал использовать Git, когда там не было вообще никакой системы команд, а Cogito считался многообещающим проектом. Не могу сказать, что мне это понравилось, в то время я в основном пользовался SVN, и он полностью решал все мои задачи. Вскоре я познакомился с Mercurial, и это была любовь с первого взгляда, положившая начало долгому и позитивному опыту использования этой VCS (version control system), которая получила в моем лице преданного сторонника. Только в 2008 году я перешел на Git, и мне потребовалось несколько попыток, прежде чем я понял, что пора переносить на него мои репозитории.

Чудовищная система команд Git


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

Тем не менее, каждый раз, когда эта тема снова обсуждается, я чувствую легкую растерянность, потому что не могу вспомнить никаких проблем с командами Git в моей ежедневной работе. Безусловно, синтаксис «git remove» отличается от «git branch» и «git tag» — но я и использую их для разных задач, даже не задумываясь о неконсистентности. Единственная странная команда, которую я помню, это «git show»: ее синтаксис для показа содержимого объекта каждый раз вызывает недоумение.

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

Изучение команд vs. изучения Идеи


Раздумывая над этим вопросом, я пришел к выводу, что причина такого легкого принятия синтаксиса Git состоит в принципах его изучения программистами. В случае с Mercurial и Perforce разработчик осваивает набор заклинаний командной строки для решения конкретных задач, и все, что находится «под капотом», при этом опускается.

А для Git все наоборот: с первых страниц введения читателя отсылают к описанию внутренностей этой VCS, где подробно изложено, что и как работает.

Такой метод обучения пошел еще с тех времен, когда у Git вообще не было системы команд. Ожидалось, что разработчик будет вручную редактировать файлы в директории «.git»! Я помню свои первые эксперименты с этой системой, когда даже не существовало команды commit: .git/HEAD, а только симлинком на текущую ветку, и документированным способом коммита было:

echo "Commit message" | git-commit-tree $(git-write-tree) > .git/HEAD

Лишь через некоторое время операция «commit» была выделена в команду, но даже тогда инструкция по ее использования была… вот такой.

Git изначально не разрабатывался как VCS: он создавался как некая идея, которую могут использовать другие программы для создания VCS. И это фундаментально отличает процесс разработки Git от того, как разрабатывались все остальные системы управления версиями.

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

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

Хорошее поведение по умолчанию


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

Хорошая архитектура


Я считаю, что Линус, когда создавал Git, придумал для него чертовски хорошую архитектуру, которая потребовала в дальнейшем минимального количества изменений. Как показало время, работа с коммитами и объектами была реализована верно, так же как и механизм работы с ветками. Даже Mercurial сдался и теперь предупреждает пользователя о том, что создание именованной ветки — не лучшая идея.

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

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

Git на моей стороне


Одна из причин, почему я прощаю Git его систему команд и местами неудобное поведение: он всегда играет на моей стороне. Много раз я ломал репозиторий чудовищным образом, делая неверные мерджи и стирая не те данные, но ни разу не было случая, чтобы данные были потеряны или VCS оставила бы меня один на один с руинами.

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

На моей памяти не было ни одного случая сломанного репозитория по причине неверного использования Git или же из-за его внутренней работы, тогда как с другими VCS у меня есть печальный опыт сломанных рабочих копий Subversion, разрушенных серверов, разломанных воркспейсов Perforce и репозиториев Mercurial, поврежденных моими руками.

Самое худшее, что случилось на моей памяти с Git, — некорректные разрешения для ряда файлов в репозитории Flask, возникшие из-за бага GitHub.

Заключение


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

Контрпримером такого ПО может служить когнитивное разделение, возникающее между мной и последними решениями Apple в софтостроении. Больше нет окна «сохранить как», а диалог «сохранить» теперь часто показывает кнопку удаления, даже если ничего еще не было сохранено в файловую систему. Слишком часто я перезаписывал презентации в Keynote по причине того, что логика работы файловой системы и логика работы пользовательского интерфейса кардинально отличаются друг от друга. Меня сильно огорчает, когда фундаментально разные операции (discard еще не сохраненных данных и стирание файла, уже сохраненного в файловой системе) названы и выглядят одинаково.

От переводчика


С автором статьи и другими знатными питонистами можно будет пообщаться в эту пятницу, 20 марта, в Санкт-Петербурге в рамках конференции PiterPy, на которую мы их пригласили :) На мероприятии, которое Positive Technologies поддерживает в качестве генерального спонсора, также выступят эксперты компании Александр Кошкин и Иван Цыганов, а её ведущий разработчик Сергей Матвеенко станет ведущим одного из потоков.

Перевод: Григорий Петров (@eyeofhell)
Positive Technologies
268.33
Company
Share post

Comments 83

    –2
    Что за редактор у на фото? Если Sublime, то что за сайдбар слева?
      +3
      Похоже на Intellij IDEA с темой Dracula
        +2
        У sublime text есть сайдбар слева! Он появляется, если открыть в редакторе папку, как-то так:
        subl ~/dev/project
        


        Возможно, как-то его можно и из интерфейса показать.
        Но на фото не sublime.
          0
          Возможно, как-то его можно и из интерфейса показать.

          View -> Side bar -> Show side bar
            0
            это будет не такой сайдбар как на фото. саблаймовский сайдбар показывает только открытые файлы, а судя по фото — на сайдбаре у него показано намного больше файлов, чем открыто. и цвет у сайдбара другой
              0
              Цвет задается темой, так что это тут ни при чем.
                +2
                Project -> Add folder to Project…
                  +3
                  >саблаймовский сайдбар показывает только открытые файлы

                  Чушь. Сайдбар показывает также и папки и другие файлы в директории.
                  Например если открывать не файлик а папку.
            0
            Atom? atom.io/
              0
              Скорее всего Atom с isotope-ui или чем-то подобным atom.io/themes/isotope-ui
                0
                похоже на саблайм разбитый на 2 окна
                  0
                  envelopsolutions.com/ — оригинал картинки похоже что отсюда. Можно попробовать им написать, узнать.
                    0
                    Вот картинка покрупнее
                    web-designer-working

                    может кто-то распознает что там за редактор.
                      0
                      очень похоже на jetbrains %product_name% + darcula theme. примерно так:
                      image
                      0
                      На Atom с Seti UI похоже atom.io/themes/seti-ui
                        +3
                        Это точно Atom. Характерная иконка корня проекта, характерная подсветка дерева файлов, характерная оранжевая иконка незакомиченных изменений внизу справа.

                        У Саблайма статус бар на все окно, а Atom сайдбар на всю высоту, и под ним нет статус бара. Тема стандартная темная.
                          +1
                          Atom 100%
                            0
                            Почему вы думаете, что это может быть не Sublime!? Для примера мой интерфейс Sublime:
                              0
                              Извините, карма не пропустила картинку по видимому :(
                            +1
                            > Много раз я ломал репозиторий чудовищным образом, делая неверные мерджи и стирая не те данные, но ни разу не было случая, чтобы данные были потеряны или VCS оставила бы меня один на один с руинами.

                            Видимо автор не сталкивался с «error: sha1 mismatch», посмотрел бы я как он это чинить будет :(
                              0
                              Да даже detached head не так просто починить бывает.
                              У нас в команде наступило счастье, когда мы стали использовать SourceTree. Репозиторий стал ломаться реже, чем при использовании консоли.
                                +4
                                Ээээ, с каких пор detached head нужно «чинить»? И да, SourceTree хорош, но проще и понятнее GitHub ничего нет. Самое то для новичков. Я его использую как монитор диффов и ознакомления с историей, а командую всё равно в консоли — очень быстро и функционально, хоть и сам признаю что команды иногда совсем не соответствуют тому чего от них ожидаешь.
                                  +3
                                  Для консоли зело рекомендую tig.
                                  Крайне редко пользуюсь графическими инструментами, но без него работу практически не мыслю.
                                    0
                                    Со своей стороны порекомендую git-forest из набора github.com/jwiegley/git-scripts
                                    Тоже не мыслю без него работы, настолько привык :)
                                    +4
                                    Сталкивался несколько раз с людьми, которые принципиально с гитом работали из консоли.
                                    Так вот от них постоянно косяки шли.
                                    То файлик не добавят, то ошибку пропустят, то закомитят лишнее и т.д.
                                    Не знаю почему так.
                                    Все остальные юзали различные GUI и никаких проблем.
                                    Да и самому, перед коммитом, так сказать «окинуть взглядом то что комитишь» гораздо проще из GUI.
                                    Того же SourceTree или прямо из IDEA.
                                    Много таких ошибок вылезает именно в этот момент.
                                      +1
                                      Готов поспорить на деньги, что этих людей было у вас от двух до трех, и теперь вы по ним судите всех «консольщиков».
                                        +6
                                        Готов поспорить, что вы не читали мой камент.
                                        Иначе как можно «сталкивался несколько раз» понять как «все консольщики»? ;)
                                        +3
                                        Так вот от них постоянно косяки шли.

                                        Звучит, как неплохое начало холивара. Уверен, что забыть добавить файл можно и в GUI, это скорее вопрос внимательности.
                                          0
                                          а вот предположим такую ситуацию — разворачиваем проект на сервере где нет gui?
                                          можно придумать более сложную задачу чем просто git clone и еще ограничить ситуацию по времени — надо сделать это позавчера.
                                          и что делать человеку который привык к кнопочкам?!
                                          после пары таких ситуаций плюнул на все gui клиенты и научился работать в консоли
                                          gui бывает пользуюсь чтобы окуинуть взглядом дерево коммитов, но не более.
                                            +2
                                            Принципиально работаю из консоли. Никогда ничего не ломаю, а проблемы всегда идут от тех, кто использует GUI. :)
                                              0
                                              И неправильные настройки autocrlf/safecrlf…
                                              +1
                                              По-моему тут скорее вопрос о наглядности представления состояния репозитория.

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

                                              С GUI упор делается на визуализацию, поэтому в принципе состояние репозитария более понятно пользователю. Но при этом GUI зачастую прячет многие полезные команды либо под слой абстракции, либо вообще. И это существенный минус, потому что в любом случае приходится лезть в консоль, чтобы сделать что-либо менее тривиальное, чем add-commit-push-pull.
                                                0
                                                Я сталкивался много раз с обратной ситуацией (сам работаю с git через консоль), те кто работают через GUI (SourceTree) не раз ломали дерево коммитов и не могли самостоятельно починить во многих случаях.

                                                Те кто используют консольный вариант, как правило, глубже понимают как работает git (в данном случае я правда скорей всего сужу по себе в большей степени, ибо большинство знакомых программистов сидят на винде и не любят консоль в принципе), т.к. официальная документация хорошо раскрывает все внутренности (с примерами в консоли), по которой и стоит изучать git.
                                                  0
                                                  Мне кажется дело в том, что и они, и вы не умеете работать с git. Гуй страхует, а используя консоль легче выстрелить себе в ногу.
                                                  Поэтому вопрос только в опыте.
                                                  Со своей стороны могу противопоставить ситуацию, когда я периодически исправляю (в консоли, поскольку gui не дает полноценного контроля) косяки разработчиков, которые «что-то не то нажали» в tortoisegit.
                                              0
                                              Один раз словили этот sha1 mismatch на сервере репозитория. Ни кто не мог сделать fetch. Запросил поломанные файлы у разработчика, скопировал поверх повреждённых, после чего всё заработало. Но времени, конечно, на это я потратил не мало.
                                                +1
                                                А уж как легко потерять данные при использовании «push -f» :-/ (привычка hg-шника, который твёрдо уверен, что DCVS — это штука, которая ни при каких условиях не должна терять данные неявно).
                                                  0
                                                  Данные/коммиты некоторое время остаются в reflog-е откуда их можно достать обратно.
                                                    +1
                                                    Особенно это актуально, если вы с помощью git push -f удалили изменения, которые никогда не загружали (git pull) на свою машину.
                                                      0
                                                      я извиняюсь, но для целей восстановления потерянных веток в git-reflog слишком много мусора, и выковыривать оттуда хэш коммита, скажем, недельной давности, приходится много дольше чем хотелось бы
                                                      +3
                                                      >неявно
                                                      -f == --force
                                                      не знаю, как ещё более явно дать понять.
                                                        +1
                                                        «push -f» не всегда можно сделать. Например, мы не даём такое делать в интеграционный репозиторий.

                                                        Как уже заметили, "-f" это явный способ сказать — я знаю, что делаю что-то очень необычное, и хорошо понимаю к чему это может привести.
                                                          0
                                                          Лучше его вообще не использовать без крайней необходимости. Обычно достаточно + в refspec.
                                                          0
                                                          Можно по привычке топором по ноге себе стукнуть, но это не значит, что топор так плох. Скорее, если при этом что-то оттяпалось, значит, как раз хорош.

                                                          Но и это не проблема для git.
                                                          Если что-то перезатерлось, значит оно там было, а значит его можно там достать из reflog.
                                                          Но, конечно, это должен быть исключительный случай.
                                                            +1
                                                            Откуда опять reflog? git push -f легко затрёт данные, которых в вашем reflog’е никогда не были, а чужой (к примеру, reflog GitHub’а) может быть не доступен.

                                                            Хорошесть топора определяется не тем, как легко он что‐то оттяпывает. А тем, как легко им оттяпать только то, что нужно. И это всегда баланс между «его даже взять нельзя без подробного пересказа техники безопасности с последующим подписанием бумаги о том, что я с нею ознакомлен» и «я его уронил, так он половину Земли оттяпал». То, где находится баланс в git меня не устраивает. И не только меня.
                                                          0
                                                          И я за много лет использования не ломал репозитория ни разу и ни разу не делал хедшот, даже когда серьезно ошибался и удалял все изменения и в локальном и в удаленном репозитории, все равно была возможность восстановить мои коммиты из кэша удаленных коммитов.

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

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

                                                          Порой удивляюсь, когда общаюсь со своими разработчиками и оказывается, что одно и то же действие мы делаем совершенно по разному, приходя к одному и тому же результату.
                                                          +3
                                                          Note: «некорректные разрешения» лучше перевести как «некорректные права на файлы». Слово «разрешение» имеет другой смысл в русско-айтишном, не связанное с permission.
                                                            +7
                                                            > Даже Mercurial сдался и теперь предупреждает пользователя о том, что создание именованной ветки — не лучшая идея.
                                                            А что не так с именованными ветками?
                                                              +1
                                                              В обсуждении оригинальной статьи на reddit задали точно такой же вопрос. срач обсуждение можно почитать по ссылке :).
                                                                +4
                                                                А это просто wishful thinking у автора. Вот что Mercurial говорит на самом деле:
                                                                $  hg branch foo
                                                                marked working directory as branch foo
                                                                (branches are permanent and global, did you want a bookmark?)
                                                                  +2
                                                                  Например, на Bitbucket для Mercurial-репозиториев реализовали pull requests через именованные ветки, и это всех бесит, так как такой подход захламляет репозиторий никому ненужными ветками, потому что их нельзя удалить. Именованные ветки были сделаны вообще не для этого, они не являются временными. Как можно было сделать на них систему PR?!

                                                                  Вот тут bitbucket.org/site/master/issue/6705/cant-create-pull-request-from-hg-bookmark 121 votes за то, чтобы сделать поддержку PR из bookmarks. Но Atlassian по факту давно забил на поддержку Mercurial.

                                                                  Вот хороший комментарий из обсуждения issue:
                                                                  i'm curious about one thing: as far as i understand it, the workflow endorsed by bitbucket (named branch per pull request) goes straight against the mercurial documentation: «don't treat branch names as disposable», so let's say the mercurial authors know their code, and creating a branch name for every pull request is «using it wrong». where will i get support if mercurial hits some performance or correctness limits thanks to a few thousand closed branches?

                                                                  Возможно, автор имел в виду что-то подобное.
                                                                    0
                                                                    Вот тут bitbucket.org/site/master/issue/6705/cant-create-pull-request-from-hg-bookmark 121 votes за то, чтобы сделать поддержку PR из bookmarks
                                                                    в качестве workaround есть PR не только из bookmarks, а вообще из любого коммита
                                                                • UFO just landed and posted this here
                                                                    +1
                                                                    Гитлаб тоже запрещает? Он так же позволяет создавать бесплатно приватные репозитории.
                                                                      +1
                                                                      Гитлаб для работы можно совершенно бесплатно развернуть в собственной инфраструктуре.
                                                                        0
                                                                        Можно и так, а можно и в облаке покрутить для начала.
                                                                      0
                                                                      Попробуйте gogs.io, если вам нужен веб-гуй и gitolite.com если не нужен.
                                                                        +1
                                                                        Попробуйте scm-manager. Достойная внимания реализация. Обновляется, гит/свн/меркуриал, плагинов гора.
                                                                        Разворачивается за 15 минут.
                                                                        0
                                                                        Мне вот что в гите не нравится:
                                                                        Удалить ветку: git branch -d
                                                                        Удалить remote ветку: git push origin :branch_name

                                                                        Для меня эти команды выглядят как одно и тоже.
                                                                        Хотя конечно, я уже привык и все ему прощаю
                                                                          +1
                                                                          Честно говоря, эти команды совсем не одно и тоже, если посмотреть на них под другим углом. Первая команда работает с локальным состоянием, вторая пушит изменения в удаленный (remote) репозиторий. Команда push в общем виде условно имеет формат git push origin src:dst. Отсутствие «источника» (src) воспринимается обрабатывающим сервером как замена ветки (указателя на коммит) на пустоту (null), то есть удаление.
                                                                            0
                                                                            и тем не менее, не так давно у push появился ключ --delete
                                                                              0
                                                                              А вот тут даже я не могу найти оправданий: почему добавили --delete но не добавили -d?
                                                                                +1
                                                                                насколько я могу судить, улучшения интерфейса в git принимаются крайне неохотно, поэтому скажите спасибо, что --delete вообще появился
                                                                            0
                                                                            Тоже как первый раз смотрел, как удалить (физически) ветку в удаленном (дистанционно) репозитории, был в недоумении от синтаксиса.
                                                                            Но, как раз тут и проявляется прозрачность команд по отношению к логике работы.
                                                                            Как только вы поймете, что делается этими командами на самом деле, вопросы отпадут сами собой.
                                                                              +2
                                                                              Как только вы поймете, что делается этими командами на самом деле, вопросы отпадут сами собой.
                                                                              это верно. как верно и то, что интерфейс гита не про предметную область пользователя git, а про кишки git.
                                                                            +1
                                                                            даже не задумываясь о неконсистентности


                                                                            Извините, пожалуйста:

                                                                            inconsistence
                                                                            Существительное

                                                                            непоследовательность
                                                                            несовместимость
                                                                            несоответствие
                                                                            необоснованность
                                                                            несогласованность
                                                                              –1
                                                                              И что?
                                                                                +3
                                                                                Этот, как его — произвол переводчика, вот :).
                                                                                  0
                                                                                  В русском языке используется это слово, посмотрим, например, на вики сюда или сюда.
                                                                                    0
                                                                                    Википедию тоже пишут люди. Видимо, любящие кальку. Кто-то и «дигитальный» использует вместо «цифровой».

                                                                                    Современный толковый словарь русского языка Ефремовой
                                                                                    Консистентный
                                                                                    ТолкованиеПеревод

                                                                                    Консистентный

                                                                                    консисте́нтный
                                                                                    прил.
                                                                                    соотн. с сущ. консистенция, связанный с ним

                                                                                    Толковый словарь Ефремовой. Т. Ф. Ефремова. 2000.

                                                                                    .

                                                                                    Синонимы:
                                                                                    пластичный

                                                                                +1
                                                                                В тред врывается git submodule! В широких кругах более известен как «pain in the ass». 9 шагов(!) чтобы переместить, 7 шагов чтобы удалить.

                                                                                Да, в последних версиях попроще.
                                                                                  +1
                                                                                  Поэтому всегда советую субмодулями не пользоваться, если нет хороших причин, по которым он становится нужен.
                                                                                    +1
                                                                                    В документации mercurial тоже советуют использовать свои subrepos, только если без них нельзя. (http://mercurial.selenic.com/wiki/Subrepository: «This is considered a feature of last resort.»)
                                                                                  +8
                                                                                  Настоящие гуру делают git init внутри папки .git и хранят состояние репозитория в репозитории. Если сделать коммиты состояния репозитория перед сложными изменениями, то чтобы вы не сломали, в каком бы промежуточном состоянии не находились, всегда можно выполнить git reset --hard HEAD внутри папки .git и откатить весь репозиторий до рабочего состояния.
                                                                                    +9
                                                                                    Xzibit-style какой-то.
                                                                                    +6
                                                                                    У гита есть проблема с дизайном, не надо пытаться искать в этом тайный смысл.
                                                                                      0
                                                                                      Ух, красота какая )
                                                                                      Не додумался. Тупо копировал, правда уже не помню, когда в последний раз, ибо оно само по себе не ломается.
                                                                                        0
                                                                                        напомнило фильм "Начало"...
                                                                                        –16
                                                                                        Вообще не разу в жизни не открывал консоль Git, всё делаю через PhpStorm. Поэтому поводов испытывать непреязнь у меня тоже нет.
                                                                                        Каким же надо быть задротом чтобы учить эти тупые, нелогичные команды и хвалиться этим. У меня есть в жизни дела поважнее.
                                                                                          +1
                                                                                          «но ни разу не было случая, чтобы данные были потеряны» — странно это читать, когда GIT позволяет историю редактировать. Как мне кажется, в GIT легко сделать необратимые изменения, особенно если не до конца понимать, что именно ты делаешь.
                                                                                            –10
                                                                                            При принятии решения использования гита для проекта я бы еще учитывал, на каких языках пишется проект. ИМХО гит неплох для скриптовых языков, но для низкоуровневых, типа си, с++, с# и т.п. он просто неудобен. К тому же стоит учитывать, что гит плохо работает с большими файлами (например, когда нужно корректировать модель в десятки мегабайт, то гиту может поплохеть).
                                                                                              +3
                                                                                              А в чем разница между языками для гита и для его пользователя?
                                                                                                +12
                                                                                                Ну да, поэтому он совершенно не подходит, например, для ядра linux в 16 млн строк кода. Подождите…
                                                                                                  +7
                                                                                                  >модель в десятки мегабайт
                                                                                                  мне кажется, у вас на проекте есть проблемы посерьёзнее, чем git.
                                                                                                    0
                                                                                                    Даже PSD хранил одно время — удобно в офисе скинуть, а дома работать, потом правда подсел на дропбокс и давно уже так не делал.

                                                                                                  Only users with full accounts can post comments. Log in, please.