Постигаем Git

Original author: Benjamin Sandofsky
  • Translation
От переводчика: в этой статье нет описания команд git, она подразумевает, что вы уже знакомы с ним. Здесь описывается вполне здравый, на мой взгляд, подход к содержанию публичной истории в чистоте и порядке.

Если вы не понимаете, что побудило сделать git именно таким, то вас ждут страдания. Используя множество флагов (--flag), вы сможете заставить git работать так, как по вашему мнению он должен работать, вместо того, чтобы работать так, как git того хочет. Это как забивать гвозди отверткой. Работа делается, но хуже, медленнее, да и отвертка портится.


Рассмотрим, как разваливается обычный подход к разработке с git.

Отпочковываем ветку от master, работаем, сливаем обратно, когда закончили.

Большую часть времени это работает, как и ожидается, потому как master меняется после того, как вы сделали ответвление (Имеется в виду, что в master коммитят ваши коллеги — прим. переводчика.). Однажды вы сливаете ветку feature в master, но master не менялась. Вместо коммита слияния (merge commit) git просто передвигает указатель master на последний коммит, происходит fast forward.

Для пояснения механизма fast forward я позаимствовал картинку из одной известной статьи. Прим. переводчика.



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

Итак, вы добавляется новое правило: «Использовать --no-ff при слиянии веток feature». Это решает проблему и вы двигаетесь дальше.

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

Вы локализуете баг вплоть до файла. Запускаете blame, чтобы увидеть, изменения за последние 48 часов. Вы знаете, что это невозможно, но blame сообщает, что файл не изменялся несколько недель. Выясняется, что blame выдает время исходного коммита вместо времени слияния ветки (логично, ведь merge commit пуст — прим. переводчика). Ваш первый промежуточный коммит изменил этот файл несколько недель назад, но изменение было влито только сегодня.

Костыль no-ff, поломанный bisect и невнятность blame — симптомы того, что вы забиваете гвозди отверткой.

Переосмысление контроля версий


Контроль версий нужен для двух вещей.

Первая — для помощи в написании кода. Есть необходимость синхронизировать правки со своей командой и регулярно бекапить свою работу.

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

Традиционно эти две причины вступают в конфликт.

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

В совершенном мире каждое изменение истории версий лаконично и стабильно. Здесь нет промежуточных коммитов, что создают помехи. Здесь нет гигантских коммитов на 10 000 строк. Опрятная история позволяет откатывать правки или перекидывать их между ветками с помощью cherry-pick. Опрятную историю проще изучать и анализировать. Однако, поддержание чистоты истории подразумевает доведение всех правок до идеального состояния.

Так какой подход выбираете вы? Частые коммиты или опрятную историю?

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

Как только значимость изменений увеличится, будь то рост команды разработки или размера пользовательской базы, вам понадобятся инструменты для поддержания порядка. Сюда входят автоматическое тестирование, code review и опрятная история.

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

Когда ваш проект достаточно разрастется, простой подход branch / commit / merge развалится. Время применения клейкой ленты закончилось. Вам нужна опрятная история изменений.

Git революционен, потому что он дает вам лучшее от двух миров. Можно делать частые коммиты в процессе разработки и чистить историю по окончании. Если это ваш подход, то умолчания git представляются более осмысленными (имеется в виду fast-forward по умолчанию при слиянии веток — прим. переводчика).

Последовательность действий


Думайте о ветках в разрезе двух категорий: публичные ветки и приватные.

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

Приватная ветка для себя. Это ваш черновик на время решения задачи.

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

Не стоит вливать приватную ветку в публичную простейшим merge. Сперва подчистите вашу ветку инструментами вроде reset, rebase, merge --squash и commit --amend.

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

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

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

Если рассматривать историю как нечто незапятнанное, то fast-forward слияние не только безопасно но и предпочтительно. Оно поддерживает линейность истории, ее проще отслеживать.

Единственный оставшийся аргумент за --no-ff — это документирование. Можно использовать коммиты слияния для ассоциации с последней версией продакшн кода. Это антипаттерн. Используйте теги.

Рекомендации и примеры


Я использую 3 простых подхода в зависимости от размера изменения, времени работы над ним и того, как далеко ветка ушла в сторону.

Быстрая правка

Большую часть времени чистка это всего лишь squash коммит.
Допустим, я создал ветвь feature и сделал несколько промежуточных коммитов в течении часа.

git checkout -b private_feature_branch
touch file1.txt
git add file1.txt
git commit -am "WIP"

Как только я закончил, вместо простого merge, делаю следущее:

git checkout master
git merge --squash private_feature_branch
git commit -v

Затем трачу минуту на написание более подробного комментария к коммиту.

Правка побольше

Временами реализация фичи разрастается в многодневный проект с множеством мелких коммитов.

Я решаю, что моя правка должна быть разделена на более мелкие части, так что squash слишком грубый инструмент. (В качестве повседневного правила я спрашиваю себя: «Легко ли будет сделать code review?»)

Если мои промежуточные коммиты были логичным движением вперед, то можно использовать rebase в интерактивном режиме.

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

В ветке feature:

git rebase --interactive master

Откроется редактор со списком коммитов. Каждая строка это: команда, которая будет выполнена, SHA1 хэш и комментарий к коммиту. Внизу есть список возможных команд.

По умолчанию у каждого коммита стоит «pick», что означает «коммит не изменять».

pick ccd6e62 Work on back button
pick 1c83feb Bug fixes
pick f9d0c33 Start work on toolbar

Меняю команду на «squash», которая объединяет текущий коммит с предыдущим.

pick ccd6e62 Work on back button
squash 1c83feb Bug fixes
pick f9d0c33 Start work on toolbar

Сохраняю, теперь другой редактор запрашивает комментарий к объединенному коммиту. Все, готово.

Несостоявшиеся ветки

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

git checkout master
git checkout -b cleaned_up_branch
git merge --squash private_feature_branch
git reset

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

Резюмируем


Если вы боретесь с умолчаниями в git, спросите себя почему.

Считайте публичную историю неизменной, атомарной и легко прослеживаемой.
Считайте приватную историю изменяемой и гибкой.

Порядок действий таков:
  • Создаем приватное ответвление от публичной ветки.
  • Методично коммитим работу в эту приватную ветку.
  • Как только код достиг совершенства, приводим историю в порядок.
  • Сливаем упорядоченную ветку обратно в публичную.
Share post

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 91

    0
    Очень предвзятый взгляд на --no-ff, не помню случая чтобы он мешал бисектить и находить коммит который поломал бы релиз… вобщем очень спорная статья…
      +3
      Местами аргументация автора мне тоже не очень ясна, но что можно иметь против лаконичной и прямолинейной публичной истории?
        +5
        А что именно в ней должно привлекать? Если мержи сделаны с помощью --no-ff вы в любой момент можете открыть gitk и увидеть что вот — эта фича началась вот тут, закончилась вот тут, не читая описание к каждому коммиту.

        Что касается лаконичности, то если лаконичность это синоним «давайте уместим фичу в три гигантских коммита», то я определенно против. Когда я делаю ревью кода, я люблю смотреть маленькие, аккуратные диффы, а не на простыню на десятки экранов.

          0
          вот и я за --no-ff история выглядит красиво и наглядно и нет кучи непонятных ветвлений непонятно где начинающихся и непонятно куда уходящих.
            +1
            Так, насколько я понимаю, люди вообще против ветвлений. Они хотят историю прямую как стрела.
            +1
            Что касается лаконичности, то если лаконичность это синоним «давайте уместим фичу в три гигантских коммита», то я определенно против.

            Для меня лаконичность это синоним скорее «давайте не будем хранить в истории основных веток коммиты с исправлением „helo“ на „hello“.
              0
              я наоборот когда замечаю опечатку в процессе правки бага или ее отдельным коммитом пправлю или в рамках бранча dev_cleanup так же отдельным коммитом.
                0
                Может мы про разные опечатки? Я про ситуацию типа:
                — что-то написал, закоммитил и запушил (по хуку на пуш ушло на дев-сервер)
                — посмотрел на дев-сервере, заметил опечатку (не суть, синтаксическая ошибка или опечатка в строке)
                — исправил, закоммитил и запушил (по хуку на пуш ушло на дев-сервер)
                — посмотрел — всё ок
                — смержил в продакшен ветку, закоммитил, запушил (по хуку ушло на продакшен сервер)

                И вот в продакшен ветке будет два коммита с разницей в пару минут, причём второй коммит — исправление одного символа. Нелаконично.
                  +2
                  а… ну да если косяк в рамках бранча я его сквошу
                  если найдена случайно опечатка из чего то тревнего то я не правлю «заодно» а выношу отдельным коммитом. чтобы мух от котлет отделять.
                +4
                Я вот как раз мотивирую всех делать вот такие мелкие фиксы в отдельных коммитах.
                Потому что иногда бывает, что в коммит содержит какое-то важное и нетривиальное изменение на пять строк. Ну и плюс человек, чтобы не плодить коммиты в нем же сделал какое-то «мелкое и неважное изменение» — типа убрал пробелы перед концами строк в половине строк файла.

                В результате в этом важном и нетривиальном диффе сам черт ногу сломит. И, если это важное изменение не заработает, то при откате коммита получим еще и откат кучи мелочей.

                Коммит должен быть маленьким, по возможности атомарным и в нем должно быть то, и только то, о чем написано в комментарии этого коммита. Это очень упрощает жизнь.
                  0
                  абсолютно согласен.
                    0
                    Это-то да. Но вот если написал эти пять строк, закоммитил и обнаружил в ней ошибку, просто опечатку. Пускай из-за неё на билд-сервере проект не собирается. То есть коммит составляет логическое целое с предыдущим.
                  0
                  Представим опенсорсный проект. Реализовано 10 фич, все они слиты в master. В каждой фиче было по 10 промежуточных коммитов. Открываем gitk или github и лицезреем паутину из 100 коммитов.
                  Не лучше ли было бы увидеть линейную историю из 10-20 коммитов?
                  И нет, я не предлагаю фичи в 10 килострок умещать в один коммит, все должно быть разумно.
                    0
                    хотите пример приведу
                    github.com/MidnightCommander/mc/network
                    если полистать влево, то видно как бранчи были влиты с --no-ff в мастер.
                    где то от 20 марта и далее посмотрите на коммиты…
                      0
                      Если делать ребейз перед слиянием фич в мастер, а потом merge с --no-ff, то никакой паутины не будет.

                      На самом деле я двумя руками за правку истории перед сливанием и публикацией. Правда я считаю что маленькие коммиты и --no-ff это добро. Часто, я в процессе rebase -i, наоборот разбиваю коммиты на несколько мелких.
                +1
                спасибо, давно хотелось почитать поподробнее на русском!
                  +1
                  Как-то нелогично, лучше ведь узнать в каком микрокоммите произошёл фейл, чем узнать что он просто произошёл. Да и если уж так заморачиваться с тем, чтоб иметь возможность собрать любую ревизию, то есть два пути: коммитить всё в транк, потом сливать с master, либо ставить теги на стабильные версии кода.
                    +2
                    Промежуточные рабочие микрокоммиты не обязаны даже компилироваться, не говоря уже о какой-то функциональности.
                    +5
                    Затем в один прекрасный день вы обнаруживаете критичный баг в продакшене и вам требуется отследить момент, когда он появился. Вы запускаете bisect, но постоянно попадаете на промежуточные коммиты. Вы сдаетесь и ищете руками.

                    Может, просто, перейти на Mercurial?
                    Вы точно знаете какой коммит относится к какой ветке.
                    Если разработка идет фича-ветка, то таких проблем — просто не будет.

                    Я серьёзно, не холивара ради. Если ошибаюсь в этом мнении, то буду рад услышать — почему?
                      0
                      Вопрос ведь не в том из какой подветки коммит, а в том как быстро найти сам коммит.
                        +1
                        Я так понимаю, вопрос в том, как вообще найти feature, которая все сломала.
                        Т.к. промежуточный commit не дает представления о том, что в данном месте происходит.
                        Ну и статья посвящена тому, что в git это сделать не совсем уж тривиально.
                          0
                          Зачем искать фичу, которая всё сломала? Имхо, нужно искать как раз коммит. Там есть commit message, поясняющий изменение; там есть автор, которого можно спросить.
                            0
                            Кстати, да. Когда микрокоммиты потóм начинают подчищать, то теряется изложенное (в комментарии к коммиту) представление о том, чего хотел автор.

                            Пример из жизни: если четыре коммита из изложенного по адресу https://github.com/CloudMade/Leaflet/pull/586 запроса на слияние будут слиты в один, то может быть не понятен ряд его нюансов, тем более что каждый из двух последних коммитов является ответом на конкретную реплику в обсуждении, по адресу https://github.com/CloudMade/Leaflet/issues/582 расположенном.
                              0
                              Используем на основном проекте GIT.
                              Автор сделал merge в master ветку.
                              Через 4 часа обнаружилось, что один из модулей вернулся к доисторическому состоянию.
                              Даже он не смог объяснить, что за факап произошел.
                              Сидели и восстанавливали целый день реп и выполненную большую задачу(несколько задач).

                              Так что, вот жизненный use-case, когда зная автора проблеме не поможет.

                              p.s.
                              commitы мы конечно же нашли. Но вычленить их из различных фич мы не смогли, ибо авторы периодически делали pull из masterа и дерево было похоже на лабиринт.
                                +1
                                Что мешало откатить этот merge commit? Или вообще всю ветку срезетить на предыдущее состояние?

                                А вообще, кривые руки (несанкционированный merge ветки в мастер, «дерево было похоже на лабиринт») на любом проекте с любыми инструментами могут привести к печальным последствиям. ;)
                                  0
                                  Ничего не мешало.
                                  Просто не получилось. Откатили и все пошло наперекосяк.

                                  А что значит срезетить всю ветку на предыдущее состояние?

                                  Дерево в любой момент у нас похоже на лабиринт. У вас разве нет, вы все время делаете rebase?

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

                                  В свое время, была похожая ситуация с другим проектом, который велся на Mercurial. Там потратили на порядок меньше времени что бы найти и исключить ветку-фичу которая привела к серьёзной регрессии.
                                  Что очень важно, необходимо вырезать именно фичу, т.к. багованная, она никому, не нужна в релизе.
                                    0
                                    «срезетить всю ветку на предыдущее состояние»:
                                    1. Найти злостчастный merge commit.
                                    2. Сделать git reset --hard <hash^> — резет ветки на последнее «хорошее» состояние.
                                    3. Переприменить все полезные коммиты, сделанные после вредного. За 4 часа вряд ли что-то плохое могло случиться.
                                    4. git push --force
                                    У нас в проекте была такая ситуация. Вот таким образом и решили проблему, довольно быстро.

                                    У нас дерево тоже далеко от идеала, но не подмёрдживая из мастера в feature branches, удаётся сохранять довольно понятную структуру. Честности ради, у нас просто мало кто пользуется feature branches, так бы обязательно бардак устроили ;)
                                    0
                                    Кстати, у нас ничего не получилось откатить, т.к. ситуация была похожа на описанную в веточке: habrahabr.ru/post/141160/#comment_4725394

                                    Т.к. после автора были merge в master.
                            +3
                            И пост habrahabr.ru/post/123700/ в подтверждение.
                              0
                              В том посте точно такой же холивар разгорелся насчёт разного подхода к бранчам.
                            +6
                            Пусть ссылочка www.git-legit.org тут побудет, вдруг пригодится кому-то.
                              0
                              Вообще команды полезные. Позволяют многое автоматизировать. Но мне кажется, что для новичка они могут быть даже вредны, т.к., абстрагируясь некоторым образом от гитовской терминологии, не позволяют понять функционирование гита. И тогда, когда случается непредвиденная ситуация, люди впадают в панику.

                              Говорю это не понаслышке. У нас в компании большинство людей пользуются гит интеграцией с IDE, которая тоже многое позволяет делать, не думая. При это большинство этих людей с гитом на «вы». Поэтому когда случается что-то из ряда вон, то они зовут на помощь ;)
                                0
                                Я с вами совершенно согласен. Новичкам может навредить а вот ветеранам экономит время. Этот вопрос уже поднимался на Hacker News и даже в описании репозитория этого git-legit приведена цитата:

                                They haven't re-created the git CLI tool in a GUI, they've created something different. They've created a tool that makes Git more accessible. Little things like auto-stashing when you switch branches will confuse git veterans, but it will make Git much easier to grok for newcomers because of the assumptions it makes about your Git workflow.
                                  0
                                  Как видно цитата говорит об обратном. Мол новичкам так проще, и а ветеранов может запутать.
                                  Но я думаю то что написал выше над цитатой — тоесть считаю что лучше учить гит как есть а те кто шарит могут и упростить себе всё.
                                    0
                                    Да. Я согласен с вами, но не с цитатой. Ветеранов ничем не запутаешь ;)
                              0
                              ИМХО, git создавался с вполне конкретными целями — для разработки ядра Linux. На мой взгляд, это достаточно специфическая задача, и заточка git под нее отразилась на удобство работы с ним в более широком круге задач. Когда распределенная по земному шару команда разработчиков клепает патчи к ядру — это одно. Когда разрабатывается новая версия Photoshop — это немного другое. На мой взгляд, отсутствие хорошей поддержки feature branches как в mercurial — это скорее минус.
                                +3
                                Отсутствие хорошей поддержки feature branches? В Гите? Поясните мысль, пожалуйста. Бранчи считаются одной из самых сильных сторон Гита, поэтому боюсь, не вполне понял вашу мысль.
                                  0
                                  Feature branching — это такая техника, при которой мы делаем бранч для разработки сложной функциональности, которую больше дня пилить, и время от времени мерджим в нее транк чтобы работать с актуальным кодом и потом было обратно мерджиться проще. В гите коммиты не привязаны к веткам (тоесть ветка — это метка ее «последнего» коммита). Соответственно после того как мы нашу feature branch смерджим обратно в транк, при просмотре истории не будет информации о том, был ли какой-то changeset этой ветки разработан в рамках этой ветки или же был получени из транка в рамках актуализации этой ветки.
                                    0
                                    Если вы не сделаете rebase, то ветка (именно физическая ветка графа истории) никуда не денется и будет отлична видна в графе. Да и указатель на последний коммит этой ветки можно оставить, в виде бранча или в виде тега.

                                    Подход Mercurial в этом смысле мне нравится куда меньше. Его heavyweight branches, записывающие информацию о ветке в каждый коммит, убивают идею быстрых и лёгких feature branches. Именно поэтому для feature branches в Mercurial часто используют букмарки или просто неименованные ветки. А это и есть аналог гитовых бранчей.

                                    Преимущество у «тяжёлых» веток тоже есть, не спорю. Например, поиск бранча, в котором был сделан коммит, о чём вы говорили. Лично мне, впрочем, такая функциональность редко нужна.
                                    Так что я бы не говорил об «отсутствии хорошей поддержки feature branches». Это просто другой подход. И тот факт, что в меркуриале изобретают велосипеды, чтобы достичь той же функциональности, говорит о преимуществах этого подхода.
                                      0
                                      Я не говорил, что информация о ветке теряется. Я говорил, что в случае актуализации feature branch путем мерджа в нее транка впоследствии теряется инормация о том, откуда взялся конкретный коммит — из транка или из ветки.
                                        0
                                        Для feature бранчей удобней merge --rebase. Тогда все остается простым и понятным (новые коммиты сверху).
                                          0
                                          Во-первых, rebase возможен только в тривиальных случаях. Если бранч делался две недели и идет последовательное изменение общего кода в транке и в бранче, то фиг там rebase получится. Во-вторых, хорошо, разделили мы последовательность коммитов на «до» и «после». Как это потом в истории смотреть? Вручную метки ставить? :)
                                            0
                                            Почему? Делается тот же merge, просто без сохранения истории. Все там получится, с любой сложностью.
                                              0
                                              Потому что если мы поменяли общий код, затем смерджили из транка изменения этого же общего кода, закоммитили результат мерджа, опять поменяли общий код, опять смерджили из транка изменения этого же кода — то тут важна последовательность когда мы этот код меняли а когда его меняли в транк. И последовательность изменений ветка-транк-ветка-транк нифига не тождественно равна последовательности изменений транк-транк-ветка-ветка, которая захочет получиться после rebase
                                                0
                                                Я несколько запутался в Вашем объяснении :( Если мы делаем full rebase, то мы имеем один коммит в нашей ветке, который выглядит как наши изменения примененные в мастере и так после после каждого reabase. Таким образом мы всегда создаём иллюзию всего лишь одного коммита. Т.е. как будто мы просто взяли патч и применили его к master. Какие тут могут быть проблемы? Если будут конфликты, тогда решаем их обычным механизмом. Т… е. этот процесс полностью идентичен merge
                                                  0
                                                  Сложно объяснить на пальцах :(. Тут нужно писать последовательность коммитов, а это долго. Вообщем если в бранче и транке много раз меняют одно и то же — то rebase даст нам «резульирующее» изменение, которое не будет иметь ничего общего с тем, как на самом деле происходила разработка. А это как бы потеря истории, что негативно скажется на возможность ее изучть через несколько лет.
                                                    +1
                                                    Потеря истории вторичной ветки, не master
                                                      0
                                                      Да. И, как показывает практика, это плохо. История нужна не когда все хорошо, а когда приходит пушной зверек. И нет никакого желания воевать на два фронта — с пушным зверьком и с тем, что часть истории потеряна.
                                              0
                                              Не знаю зачем обязательно знать откуда коммит. На мой взгляд, вполне достаточно того что логически связанные коммиты идут последовательно. Если сильно надо, можно найти голову и хвост посмотрев на описание/автора коммитов.

                                              В общем, идея git в том что в правильно написанной истории знать откуда коммит не надо. Я согласен, что если же все перемешано промежуточными merge то в этой каше без знания «что-куда» не разобраться, но кашу можно легко избежать.

                                              Как уже выше заметили, разница между merge и merge --rebase только в получающейся истории, конфликты разрешать приходится те же самые.
                                        +1
                                        Кстати, подмёрдживать изменения из транка в feature branch не рекомендуется. Именно потому, что это путает историю. Вот тут Junio Hamano говорит об этом: kentnguyen.com/development/visualized-git-practices-for-team/#comment-423841808
                                        У него, кажется, был ещё пост на эту тему, но я не смог сходу найти его.
                                          +2
                                          Это именно то, о чем я говорю — слабая поддержка feature branch :)
                                            0
                                            К слову, на чем вы сейчас остановились из подобных систем? И почему?
                                              +1
                                              Увы, все еще выбираю :(. Git популярнее, в mercurial ветки лучше. А в продакше используется subversion. И я пока не знаю на что ее менять.
                                                +3
                                                hg-git.github.com/ и mercurial.selenic.com/wiki/HgSubversion спасут отца русской демократии
                                                  +1
                                                  Под windows собирали?
                                                    +1
                                                    AFAIR тупо setuptoolsами ставилось; в pypi есть оба.
                                                      0
                                                      Не совсем ©. Тоесть «тупо», конечно, ставится. Но при попытке поставить на чистой Windows 7 64-бит с ActivePython 2.7.чтототам получим:

                                                      > pip install hg-git
                                                      ...
                                                      building 'dulwich._objects' extension
                                                      error: Unable to find vcvarsall.bat
                                                      


                                                      Я честно пытался в течении часа это побороть. И из Visual Studio 2008 shell запускал, и пути к этому батнику в разные места подкладывал, и гуглил… Гугл выдает примерно следующее:
                                                      "- WTF, у меня под Windows ничего не собирается.
                                                      — Ваши проблемы, у меня под Linux все собирается."
                                                        0
                                                        Unable to find vcvarsall.bat
                                                        видимо, пытается MSVC найти, чтобы бинарник скомпилить. оно у вас есть установленное?
                                                        А вообще, конечно, виндопроблемы ;)
                                                          0
                                                          Ну вы меня совсем обижаете :). Написал же — все установлено и пытался «подсунуть» разными способами. Не видит. Тоесть конечно можно убить много времени, разобрать их код, понять как и что они ищут и соорудить им ситуацию когда все будет работать — но как-то пока не хочется :).

                                                          Да, виндопроблемы. А также макпроблемы, убунтупроблемы, <вставьтеназваниеоси>проблемы. Я, в целом, рад что у автора под его дистрибутивом все собирается и работает. Но у меня тут и винда, и макось, и линуксы разные — и subversion подо всем этим работает.
                                                            0
                                                            не хотел обидеть, извините
                                                            тут в интернетах пишут, что
                                                            Just download and install Microsoft Visual Studio Express 2008 which is free. Please note the 2008 part. This must match the compiler that Python itself was built with, and that’s the 2008 (NOT 2010) version. (See mail.python.org/pipermail/python-list/2010-April/1242706.html for more details why 2008 is important.)
                                                            То есть у вас VS2008 (или чем там ваш питон собирался) установлена?
                                                              0
                                                              Питон у всех разработчиков установлен с помощью дистрибутива ActiveState. Вряд ли они все будут его пересобирать :).

                                                              VS2008 пробовал устанавливать в разных вариантах, начиная от Express и заканчивая Enterprise. Не работает ©.

                                                              BTW, то что написано в статье по ссылке — бред несколько расходится с реальностью — установленная Visual Studio 2008 ничего не прописывает в систему, поэтому вряд ли просто инсталляция поможет делу. Чтобы сборочный скрипт знал где лежит vcvars.bat нужно либо запускать Visual Studio CMD Shell, либо что-то где-о прописывать.
                                                                0
                                                                забавно
                                                                тут я не копенгаген, извините. Разве что
                                                                * найти каталоги, в к-рых ищется vcvars.bat чем-нить вроде filemon ну и подсунуть
                                                                * пнуть ActiveState (скорее всего, под виндами у вас вообще ничего с бинарниками не соберётся)
                                                                но вы это уже, полагаю, сделали
                                                                  0
                                                                  Тру стори, все сделано. Минимальное время я потратил — не заработало. Если приму решение пробовать мигрировать на mercurial — я, конечно, все это разберу и все починю. Но пока не готов :). Так что наличие hg-svn и hg-git рассматриваю скорее как умозрительное — это где-то собирается, где-то не собирается :).
                                                                  0
                                                                  PATH ?)
                                                            +1
                                                            «Windows 7 64-бит»? Возможно, он хочет компилятор, способный генерировать 64-битные бинарники? В Express Edition такой просто отсутствует, а в других редакциях, возможно, по умолчанию не поставился. Тут — wiki.cython.org/64BitCythonExtensionsOnWindows — рекомендуют ставить SDK и указывать специальной переменной окружения, чтобы distutils использовал прописанные в PATH бинарники, а не лез в реестр за папками студии.
                                                              +1
                                                              mercurial.selenic.com/wiki/WindowsInstall
                                                              Caution: Don't use Active Python in www.activestate.com/activepython/ or you will probably fail to build Mercurial from source.
                                                        –1
                                                        А bzr не рассматриваете?
                                                          0
                                                          Вернее Bazaar, который царит на Launchpad'е.
                                                            +1
                                                            Нет. Он как-то совсем не популярен O_O. Да и плюсов по сравнению с git / hg я у него не вижу. По факту — все то же самое, но менее популярное.
                                                              0
                                                              Не популярен в какой сфере? В плане репозиториев для Ubuntu он очень даже популярен)
                                                                +2
                                                                В целом — количество разработчиков и компаний которые его используют, интеграция с Issue Tracker'ами, интеграция с IDE, с системами автобилда и прочее.
                                                        0
                                                        «
                                                        — Доктор, мне больно когда я так делаю!
                                                        — Ну не делайте так!
                                                        »
                                                        :-)
                                                        Специально разделил комментарии, чтобы не смешивать темы, т.к. не подумал, что именно проблемы при синхронизации ветки с транком могут считаться наибольшим неудобством в Гите.
                                                        Просто не надо так делать, и всё. Предлагаю не просто так, а потому что не очень понимаю, зачем так делать (по крайней мере, на постоянной основе).
                                                          +3
                                                          Это стандартная практика при разработке фичей с большим объемом кода. Если не мерджить время от времени в себя транк, то может случится рассинхронизация, и мердж бранча обратно в транк станет невозможным. Это практика, от этого никуда не деться.
                                                            0
                                                            Для этого необходимо делать периодический rebase feature-ветки на upstream. Это позволяет поддерживать кодовую базу feature-ветки в актуальном состоянии.
                                                              0
                                                              Обсуждалось уже. rebase хорошо работает если нет последовательных изменений одного и того же в ветке и в транке. Если есть — то rebase сделает «коммулятивные» изменения, которые при изучении истории через полгода будут абсолютно нечитаемы — после rebase десяток мелких изменений в транке и в бранче одного и того же (а такое на практике, увы, бывает довольно часто) превратится в оно огромное изменение в транке и в одно огромное изменение в бранче. Что как бы не есть гут.
                                                  0
                                                  Не холивара ради, а токмо разобраться что я делал не так. Начинал с hg (пару лет назад, не помню версию, переходил с svn если что), и натыкался на наприятные моменты, как то: девелоплю себе в /mycalc и веб-сервер смотрит туда же, нужна новая ветка — приходится или делать именованную (значит публичной) либо же клонировать папку в /mycalc-feature, что предполагает изменения настроек веб-сервера. Я не шибко разбирался в DVCS, но всё это показалось чересчур странным либо же чуждым веб-разработке. В git всё стало ок (кроме синтаксиса, конечно, но это другое).

                                                  Второе, уже холиварное конечно: git имеет все комманды сразу (мультитул), hg доставляется экстеншнами (из коробки — молоток с гвоздями). Разницы по скорости эти подходы не показывают, а вот проблему несовместимости доставляют. Я не уверен есть ли у товарища нужный экстеншн, чтобы доставить его нужно копаться в системных папках, то же на любом сервере, постоянный головняк. И если смысл заключается в «альтернативных» экстеншнах, то это еще более повышает порог вхождения — какой там экстеншн лучше Attic или Shelve, тут или разбираться дольше придется, или махнуть рукой и использовать «работает как-то ну и ладно».
                                                    0
                                                    Это вы вообще о чем? O_O
                                                      +3
                                                      Любой экстеншн включается в hgrc прямо в .hg репозитория.
                                                        +1
                                                        Либо в hgrc системы, что может быть ещё удобней для серверов.
                                                          0
                                                          Естественно. Просто речь шла о том, чтобы не редактировать system-wide конфигурацию.
                                                  • UFO just landed and posted this here
                                                      +6
                                                      не могу избавиться от впечатления, что истории кода уделяется едва ли не больше внимания, чем собссно коду.
                                                        0
                                                        Если Вас эта тема не волнует, видимо Вы не видели действительно херовой истории. Я ее видел и в CVS, и в git, и копаться в ней тоже приходилось, как-то оно не очень…
                                                          0
                                                          Понимаете, в топике (да и, пожалуй, практически любой статье о Git объёмом более трёх абзацев) описаны какие-то совершенно непропорциональные результату приседания. Читая это и имея перед глазами пример Mercurial и veracity, я испытываю как минимум недоумение.
                                                          0
                                                          История — это важный элемент инфраструктуры разработки.
                                                          Так, например, станку на заводе уделяется внимание, сопоставимое с вниманием к изделию.
                                                            0
                                                            Важный, не отрицаю. Но, к счастью, код главнее, и оплачивается именно он, а не красивая история.
                                                              0
                                                              Не будет станка — не будет изделия требуемого качества и в требуемые сроки.
                                                              С соответствующим эффектом по оплате.
                                                                0
                                                                Мне не совсем понятно, что бы хотели сказать этой некорректной аналогией. Если «станок» == красивая_история_ревизий, то «Не будет станка» — это не будет истории вообще или красивой истории? Да и в любом случае код-то всё равно никуда не девается.
                                                                И нет, я ничего не имею против атомарных коммитов, внятных комментариев к ним, децентрализованных VCS в частности и VCS вообще.
                                                                  0
                                                                  История — это часть документации проекта. Некачественная документация — себестоимость проекта растёт, эффективность разработки и другие связанные показатели — падают.
                                                          +3
                                                          Я думал что хоть что-то понимаю в Git… до этого момента
                                                            0
                                                            SCM делает акценты на изменения. здесь удобнее работать не с хронологической историей коммитов, а со стеком патчей. например www.procode.org/stgit/

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