Как научить людей использовать Git

Original author: Rachel M. Carmena
  • Translation
  • Tutorial
По работе приходится участвовать в разных проектах, поэтому я хорошо знаю, как работают все мои коллеги. Помню, что компания начала использовать Git буквально за пару недель до моего прихода. На мониторах разработчиков кругом висели наклейки с напоминанием: сначала add, потом коммит, затем пуш.


Они не знали, зачем. Программистам просто сказали строго следовать инструкции, иначе беда. Но проблемы возникали так часто, что я решила провести семинар по Git.

Идея


Мне нравится составлять карту в голове. Я не говорю «ментальные карты», потому что это хорошо известный тип диаграмм. Речь о неких картинках, структурах или любом графическом представлении в уме. Например, в детстве я учила арифметику, представляя игральные кубики.

Поэтому я подготовила несколько рисунков. Не обязательно их смотреть, чтобы понять текст. Для каждого есть пояснение.

Кроме того, очень важно научить человека терминам. Иначе он не поймёт сообщения от Git. Рисунки — хороший способ.

Распределенная система контроля версий




На рисунке четыре области распределены следующим образом:

  • Среда разработки:
    • Рабочий каталог
    • Промежуточная область (staging) или индекс
    • Локальный репозиторий
  • Сервер:
    • Удалённый репозиторий

Здесь можно объяснить преимущества распределённой системы управления версиями.

Клонирование репозитория




При клонировании данные из удалённого репозитория перемещаются в две области:

  • Рабочий каталог
  • Локальный репозиторий

Внесение изменений в рабочий каталог




В рабочем каталоге два типа файлов:

  • Отслеживаемые: файлы, о которых знает Git.
  • Неотслеживаемые: которые ещё не были добавлены, поэтому Git не знает о них.

Обновление удаленного репозитория




После подготовки изменений в рабочем каталоге их необходимо добавить в промежуточную область (staging area).

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

Если в локальном репозитории есть один или несколько коммитов, готовых к совместному использованию всем остальным миром, они отправляются в удалённый репозиторий.

В этот момент можно говорить о различных состояниях файла в среде разработки: изменённом, промежуточном (staged) и зафиксированном (commited).



Далее вы можете объяснить:

  • как показать изменения файла в рабочем каталоге: git diff
  • как показать изменения файла в промежуточной области: git diff --staged
  • как изменить файл в рабочем каталоге после добавления в промежуточную область
  • и т. д.

Обновление среды разработки


Получение (fetching)




При выполнении git fetch данные из удалённого репозитория перемещаются только в локальный репозиторий.

Вытягивание (pulling)




При выполнении git pull данные из удалённого репозитория перемещаются в две области:

  • В локальный репозиторий: fetch
  • В рабочий каталог: merge

Если важна история коммитов, рассмотрите возможность использования git pull --rebase. Тогда вместо команд fetch + merge выполняются команды fetch + rebase. Ваши локальные коммиты будут воспроизведены, так что вы не увидите в истории коммитов известную форму бриллианта.



Дальнейшие действия


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

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

Дружеское напоминание


Я работала с другими системами управления версиями (Visual SourceSafe, TFS и Subversion): по моему скромному опыту, недостаток знаний вредит и со старым инструментом, и с новым. Сосредоточьтесь не только на выборе инструмента, но и на его освоении.

Дальнейшее чтение



Полученные отзывы


Мой друг Марк Виллаграса напомнил, что очень полезно решить задачки Git и делиться с коллегами решением.

Ресурсы из комментариев на Hacker News:


Прочитав комментарии на Reddit, я подумала, что более точным названием этой статьи было бы «Идея, как научить людей использовать Git», потому что это только идея, которая появилась в моей голове, когда я сама несколько лет назад изучала Git по книге Pro Git. Статья не является полным руководством, лишь отправная точка. Уверена, что все эти ресурсы будут очень полезны. Спасибо!

И спасибо Стюарту Максвеллу, который поделился ссылкой на Hacker News, и u/cryptoz, который запостил её на Reddit!
Support the author
Share post

Similar posts

Comments 384

    –44
    Если в 2019 году разрабочик не умеет в Git, то такой разработчик не нужен.
      +32
      Перестаньте. Управляю кодом с помощью git'а уже больше 6 лет, но поверьте, я не знаю этот инструмент. Что говорить уже о юных падаванах?
        –17
        Как вы им управляете и не знаете?
          +14
          Я думаю имелось в виду, что всех тонкостей не знает…
            +20
            Именно. Спасибо.
            Я ежедневно пользуюсь rebase/marge, show/log/diff, stash, reset/checkout, cherry-pick и мне этого хватает. Но признаюсь честно, я очень часто иду спрашивать в гугла или у своих коллег по цеху.
            Git имеет больше десятка полезных утилит, с своими параметрами и опциями. Я бы очень сильно хотел знать их все, а еще лучше правильно это все применять.

            А программист который пришел в команду без базовых знаний, получить их в первую неделю работы. И такого человека нужно брать. Ибо если не вы то другие
              +4
              Я ежедневно пользуюсь rebase/marge, show/log/diff, stash, reset/checkout, cherry-pick и мне этого хватает.

              Этого более чем достаточно, Git вы наверняка знаете. Не обязательно на 100% знать возможности инструмента чтобы эффективно его использовать.

                –2
                С такими тезисами на устах рождаются инженеры, не умеющие в документацию и серийные велосипедостроители.
                +10
                За ~6 лет ни разу не понадобился rebase. Обычно только clone / add / commit / push / pull / status. Около 2 лет назад начал юзать merge, checkout, log и stash (да-да, я не юзал ветки). Раза 3 за всё время использовал cherry-pick. Иногда юзаю reset по подсказке гита. сам её синтаксис не помню.
                  +2
                  А что вы используете если вашу фичу месяц не хотят принимать, если не rebase???
                    +3
                    Ээ… мердж и фикс конфликтов руками?
                      +4
                      Ну можно и так, наверное, но потом непонятно как это ревьюить.

                      Я как-то привык к тому, что мёрдж допустим только тогда, когда конфликтов нет…
                        –2
                        git merge X
                        # there are conflicts
                        git mergetool
                        # N часов разрешения конфликтов спустя
                        git commit
                          –2
                          Последующие пункты:
                          # оно посыпалось в проде (так как конфликты как-то разрешили, но тестировать не тестировали)
                          # научились пользоваться rebase
                            +1

                            А что, ребейз автоматически исправляет ошибки?


                            После мержа мастера в фичу, разрешения конфликтов, фича пушится, CI прогоняет тесты, и мержится мерж реквест.

                              –3
                              А что, ребейз автоматически исправляет ошибки?После ребейза следует ещё одна стадия: проверка всего, что случилось и исправление ошибок.

                              После мержа мастера в фичу, разрешения конфликтов, фича пушится, CI прогоняет тесты, и мержится мерж реквест.Однако при этом разработчик, почти никогда, не смотрит на то, что там произошло и почему возник конфликт. Потому что у вас на всё стадию разрешения конфликтов — один шаг:
                              # N часов разрешения конфликтов спустя
                              git commit
                              В случае же с rebase вы вполне можете решить сделать его в несколько шагов. Или вообще интерактивно — с проверкой после каждой стдии. Контроля над процессом — на два порядка больше.
                                0
                                После ребейза следует ещё одна стадия: проверка всего, что случилось и исправление ошибок.

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

                        +9

                        image

                          0

                          В гитлабе такие графы выглядят гораздо читаемее.

                            +1
                            Или в GitExtensions, например
                            +3
                            осторожно, двери закрываются следующая станция ff9af9b0fb70e75839761489c5b1880d77adf90d

                            Ох уж эти схемы линий git'овского метрополитена;)
                            +4
                            вы серьезно? за что вы так не любите ревьюверов? =)
                            а если в вашей feature бранче из множества коммитов нужно поправить 3-й с конца — как вы делаете?
                              +2

                              Правишь и коммитишь. Править коммит в глубине истории — очень странное использование гита.

                                0
                                Интесная точка зрения, если учесть что это «странное использование» — это то, ради чего, собственно, git и был создан изначально.
                                  0
                                  Гит намеренно делает очень сложным переписывание истории.

                                  Отличный пример — git revert: создает новый коммит, откатывающий более ранний, вместо внесения изменений в историю.
                                    +3
                                    Git намеренно делает сложным незаметное переписывание истории, да. История, которая уже опубликована — изменению не подлежит.

                                    А вот для изменения истории, которая ещё не опубликована — как раз rebase и предназначен. А до него пользовали Quilt, да.
                                      0

                                      При чём тут revert? svn revert тоже как бы создает новую ревизию. Revert никогда не предназначался для исправления истории.


                                      А для исправления коммитов в прошлом есть довольно удобный инструмент: комбинация git commit --fixup и git rebase --interactive --autosquash

                                    0
                                    а вы точно знакомы с git-flow? =)
                                      +2
                                      С каких пор это сильно сомнительное флоу стало непреклонной истиной?
                                      И почему это вы вспомнили про него в ответе на комментарий?
                                        0
                                        сильно сомнительное флоу? =) ок, а какое флоу вы считаете не сомнительным?
                                        почему вспомнил — ну, так кейс такой. вот сделали вы локальную feature бранчу. в ней куча атомарных коммитов. и нужно поправить третий коммит с конца.
                                        вопрос — как это сделать без rebase?
                                        основная идея в том, что rebase очень полезная команда =)
                                          0
                                          и нужно поправить третий коммит с конца.
                                          Кому нужно? Я бы новым коммитом менял код на тот, который нужен.
                                          А еще можно автоматически засквошить всю фичу в один коммит.

                                          сновная идея в том, что rebase очень полезная команда =)
                                          Но при чём тут гитфлоу?

                                          ок, а какое флоу вы считаете не сомнительным?
                                          Гитлабовское, например.
                                            +1
                                            вы тоже не любите ревьюверов? =)
                                            +1
                                            сильно сомнительное флоу? =) ок, а какое флоу вы считаете не сомнительным?
                                            Такое, которое позволяет эффективно делать git bisect.

                                            А для этого требуется следующее:
                                            1. Все коммиты обозримы и, как правило, имеют небольшие размеры (иначе смысл делать git bisect: найдёте вы коммит размером в миллион строк, меняющий несколько тысяч файлов… что дальше?).
                                            2. Каждый коммит имеет смысл в отдельности, сам по себе (иначе, найдя него, нельзя понять что в нём пыталось сделать и зачем).
                                            3. Каждый коммит содержит в себе образ, который можно собрать и не содержит ошибок (тут стоит, конечно, уточнить: «насколько нам известно можно собрать» и «известных ошибок, которые мы не решили сознательно не править „здесь и сейчас“»). Самое важное и, вместе с тем, самое спорное свойство — но если оно не соблюдается, то всё время будете через git bisect находить не что-то полезное, а тот мусор, который вы оставили во время разработки.

                                            Ключевая фича Git'а — это git bisect. Он позволяет искать ошибки в крупных проектах, над которыми работают тысячи разработчиков. Однако накладывает ограничение на то, что вы кладёте в ваш репозиторий.

                                            Но, разумеется, если ваш проект невелик, то это не особо нужно. А если вы один работаете — то и папочек с датами может быть достаточно.
                                              0
                                              Такое, которое позволяет эффективно делать git bisect.

                                              rebase многократно увеличивает трудозатраты, которые нужно сделать для git bisect.

                                                0
                                                аналог changeset obsolescence из Mercurial сильно помог бы, но в Git ничего подобного нет и в обозримом будущем не появится
                                                  0
                                                  Каким образом?
                                                    0
                                                    Каким образом [rebase многократно увеличивает трудозатраты, которые нужно сделать для git bisect]?

                                                    После того, как сделан rebase каждый коммит потенциально может быть сломан из-за того, что изменения в мастере оказались несовместимы с тем, что осталось в ветке. Например, в мастере был переименован какой-то метод. Конфликтов не возникнет, но код перестанет собираться.


                                                    Автоматический bisect в таком случае естественно скажет, что коммит сломан. Чтобы такого не было, после rebase нужно прогнать тесты на каждом коммите и потенциально поправить код в каждом коммите.

                                                      0
                                                      Чтобы такого не было, надо после каждого rebase проверить сво код так, как будто написал его на основе нового кода.
                                                        0
                                                        Мне казалось, что это само собой разумеется. Если вы делаете rebase — то вы делаете его для того, чтобы облегчить себе задачу в будущем, а не наоборот. Если у вас нет времени на то, чтобы прогнать тесты, то rebase делать не стоит, вот и всё.
                                                          0
                                                          Если вы делаете rebase — то вы делаете его для того, чтобы облегчить себе задачу в будущем, а не наоборот.

                                                          Ну вот если хочется использовать bisect, то rebase очень осложняет задачу.


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

                                                          Ну в общем да. Допустим в ветке работали около недели, там 100 коммитов. Тесты прогоняются, допустим, около двух минут. Для каждого коммита нужно прогнать эти тесты. Итого, примерно три с половиной часа нужно потратить на просто прогон тестов, плюс, думаю, не менее минуты на коммит для сопуствующих действий. Так что да, если жалко четырёх с половиной часов — не стоит делать rebase.

                                                            +1
                                                            Допустим в ветке работали около недели, там 100 коммитов.

                                                            В таком случае я бы вообще не стал делать rebase уже не задумываясь ни о чём другом.
                                                              0

                                                              Ну да, а ветки в с какой-нибудь фичей, они в основном такие и есть.

                                                                0
                                                                Смотря что в Вашем понимании «фича». У нас это уровень функционала на несколько месяцев работы — такое часто лучше делать частями на мастере. Ну или merge без вариантов. А задачи от дня до недели, баги на пару часов — там один или два коммита будут.
                                                                  –1
                                                                  У нас это уровень функционала на несколько месяцев работы — такое часто лучше делать частями на мастере
                                                                  Часто фичу нельзя выкатывать пока она окончательно не готова. Ну, к примеру, какой-то новый режим в онлайн-игре. Скажем, турниры. Они довольно довольно крупные (Epic Story) и пока не закончены — могут не выливаться на продакшн, получая несколько пул-реквестов в отдельную ветку для эпика.
                                                                    +2
                                                                    Такие вещи не всегда возможно, но часто очень удобно делать с помощью feature toggle. Но вообще мы уходим от основного вопроса. Такие фичи, конечно же, надо мержить через merge по целому ряду причин.
                                                                      0
                                                                      А почему неуозможны-то? Что может мешать? Просто Chrome всё свои фичи так делает — и как-то ни во что особо не упирается.

                                                                      Это если сомнений в том, что фича нужна нет.

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

                                                                      Хотя, конечно, тут приходится мириться с тем, что фича будет не поверх прямо последней версии, а поверх версии трёхдневный давности… что всё равно лучше, чем если она поверх версии годичной давности и «merge commit» переписывает половину кода…
                                                                        +1
                                                                        А почему неуозможны-то? Что может мешать?

                                                                        Иногда в коде не может быть следов новой фичи до окончательного релиза, чтобы игроки не получили спойлер до того, как отдел маркетинга начнет свою работу.
                                                                          +1
                                                                          А почему неуозможны-то?

                                                                          Как ниже написали, а ещё в реальном мире живем — если не всё покрыто тестами, то feature toggle рискованнее ветки.
                                                                          всё равно лучше, чем если она поверх версии годичной давности и «merge commit» переписывает половину кода

                                                                          Для кого лучше? Мы вот в команде решили, что не лучше. Во-первых нет смысла тратить время на rebase если он никому не нужен. Во-вторых иногда куда полезнее видеть реальную историю, чем гадать, откуда что-то взялось и зачем.
                                                                  0
                                                                  100 наверно перебор, но 50 вполне.
                                                                    0
                                                                    Но… Зачем? Что вы такого делаете, что нельзя разбить на несколько подфич и вливать по 5-7 коммитов?

                                                                    Да, пару раз в год у меня случатся хитрые фичи, которые нельзя разбить на 10 мини-фич… ну так пару раз в год можно и подождать 4 часа.

                                                                    А так — чем меньше фича, тем лучше для ревьюера.
                                          0
                                          А что вы используете если вашу фичу месяц не хотят принимать, если не rebase???
                                          Как-то долго, вам не кажется?

                                          А какие проблемы с мерджем, если месяц не мерджить и если были конфликты? На Гитхабе в Пул Реквестах все норм.
                                            +2
                                            А что вы используете если вашу фичу месяц не хотят принимать, если не rebase???
                                            Как-то долго, вам не кажется?
                                            Зависит от проекта. У разработчиков ядра — это суперскорость-когда-фича-позарез-нужна-очень-срочно.

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

                                            То есть по объёму ваш «финальный» мёрдж будет как половина от 10-20-50 компотов, вашу фичу реализующих. Ну и как это ревьюить, извините?
                                              0
                                              Ну и как это ревьюить, извините?
                                              Так же, как и ребейз.
                                                +2
                                                Отлично. Я, ревьюер, cмотрю на первый коммит, вижу, что там используется функция Foo, которой больше нет в мастере, прошу её заменить на более новую Bar (которая есть в мастере, но которой нет в той версии, в которой вы начали разрабатывать вашу фичу).

                                                Ваши дальнейшие действия?
                                                  –1
                                                  Мердж из мастера в фиче-ветку, замена Фоо на Бар, проверка, коммит, пуш.
                                                  На гитхабе автоматически обновился пул-реквест.
                                                    +3
                                                    Вы не поняли. Мердж вы уже сделали, но ревьювер смотрит старый коммит…
                                                      0
                                                      Зачем?
                                                        +3
                                                        Чтобы понять что он делает, очевидно. А про функцию Foo я давно забыл и желания вспоминать про то, как она работала у меня нет никакого.

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

                                                        Мне интересно знать как она будет работать в моей подсистеме сегодня. Ревьюер в ядре — как правило майнтейнер соответствующей подсистемы и это ему (или ей) этот под поддерживать если вы вдруг исчезните (да даже если и нет).
                                                          0
                                                          Вы пользовались когда-нибудь пул-реквестами на Гитхабе? Я понимаю, что с велосипеда можно снять сидушку и жаловаться, что неудобно, но зачем?
                                                            +3

                                                            А вы пользовались? Если пользовались, то должны знать, что там именно что отдельные коммиты на ревью попадают. Поэтому перед тем как делать PR очень желательно сделать rebase.

                                                              –2
                                                              Там, конечно, есть список коммитов, которые вошли, но основная часть — это изменения, разница между «до» и «после». Ни один адекватный ревьюер не будет заходить в первый коммит и его ревьюить без контекста остальных без необходимости
                                                                +4

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


                                                                Почему вы не желаете немного помочь ему и убрать из своего PR мусорную информацию?

                                                                  0
                                                                  А как ему этот самый контекст получить, когда в последнем коммите — краткая подборка всех изменений из основной ветки проекта за последний месяц?
                                                                  Таки не пользовались? Чего вы привязались вообще к коммитам?
                                                                    +2
                                                                    Чего вы привязались вообще к коммитам?
                                                                    Потому что именно на них я смотрю?

                                                                    И да, каждый из них должен иметь смысл, не должен быть слишком большим (если он больше 100 строк, то его могут попросить разбить) и так далее.

                                                                    В ядре есть ещё сложность что разные люди пользуются разными инструментами, так что можете посмотреть примерно как это Chromium делает. Там инструмент у всех один…

                                                                    Инструменты у разработчиков ядра, Chrimium, Android, LLVM — всё разные. Но принцип один: каждый коммит ревьюится отдельно. И должен иметь смыслотдельно.

                                                                    А иначе что делать после Git Bisect.
                                                                      0
                                                                      И да, каждый из них должен иметь смысл, не должен быть слишком большим
                                                                      И как по такой логике влазит месячная фича, слепленная в один коммит ребейзом?
                                                                        +2
                                                                        Никак разумеется. Какой же идиот большую фичу склеивает в один коммит? Наоборот: скорее её нужно будет интерактивным ребейзом дополнительно на части делать — чтобы ревью было удобнее делать.
                                                                          +3
                                                                          Это не ребейз такие коммиты порождает, а мерж. Когда вы делаете слияние мастера в вашу фиче-ветку, вы порождаете коммит, который, с точки зрения вашей ветки, выглядит как месячная история слепленная вместе.

                                                                          И она-то и мешает ревью.
                                                                            0
                                                                            Мешает ревью не этот коммит, а просто тот факт, что rebase не сделан.

                                                                            Ведь, собственно, почему все эти замены Foo на Bar появляются? Чтобы помочь вам вашу фичу реализовать.

                                                                            То есть, к примеру: если вы хотите сериализовать какой-то объект, но есть шанс, что этот объект «под вами» менять будут — его можно попробовать изменить так, чтобы он был immutable. И проблемы синхронизации исчезнут. Но для этого — его нужно будет создавать по-другому.

                                                                            А когда вы, после всего этого выкатываете на ревью версию «с костылями»… Ну это просто неуважение к ревьюерам, которые для вас, собственно, всю эту работу и проделали.

                                                                            Рассказывать после такого «плевка в лицо» о «работе в команде»… Ну как-то глупо это…
                                                                    0
                                                                    Он не просто туда «зайдёт». Он его рассмотрит, напишет замечания и на этом, скорее всего успокоится. Ибо какой смысл ревьюить последующие коммиты, если неизвестно как будут исправлены проблемы, отмеченные в первом?
                                                                      0
                                                                      Зачем, если можно ревьюить результат пул-реквеста?
                                                                        0
                                                                        Кто мне разобьёт «результат пул-руквеста» на отдельные маленькие кусочки? И что мне делать с компотами, на которые я никогда не смотрел, если на них git biset укажет?
                                                                  0
                                                                  Причём тут пулл-реквесты на гитхабе? Я, как ревьюер, отвечаю за каждый отдельный коммит. Ибо на нём мой signoff стоять будет.

                                                                  И если меня коммит не устраивает — я signoff не поставлю. Вот так вот просто.

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

                                                                  Такое в массе крупных проектов просто «не прокатывает»: если я даю «добро» на включение чего-то в проект — то это я должен быть готов править ошибку, совершённых в любом из показанных мне коммитов, если git bisect на этот коммит укажет.

                                                                  Как GitHub pull-реквесты помогут мне в этом — я не понимаю.
                                                                    –2
                                                                    Github вообще энфорсит совсем другую модель. Leftpad-стайл, условно говоря: я беру у вас фичу и не глядя забираю себе. Кто и как при этом будет чинить отвалившуюся другую фичу — науке неведомо.
                                                                    Что? Я вас не понимаю, простите.

                                                                    И если меня коммит не устраивает — я signoff не поставлю. Вот так вот просто.
                                                                    Ну я понял. «будет или по моему или никак». Удачи в работе в команде.
                                                                      0
                                                                      Ну я понял. «будет или по моему или никак». Удачи в работе в команде.
                                                                      Мне-то она зачем? Я вполне нормально работаю.

                                                                      Это вам удача понадобится, если вы вдруг в большой проект (ну, скажем, от 10 миллионов строк и больше) что-то закоммитить решите. Я вот не знаю ни одного, где бы играли по вашим правилам.
                                                                      +1

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


                                                                      Между прочим, github автоматически подписывает все сделанные через веб-интерфейс коммиты.

                                                                        +1
                                                                        От того, что GitHub, от моего имени, подпишет коммиты, которых я в глаза не видел — мне только хуже.
                                                                          +1
                                                                          А зачем вы нажимали кнопку Merge не глядя на коммиты? И почему виноват гитхаб?

                                                                          Так-то можно и самостоятельно коммит слияния подготовить и запушить, если вам так важно чтобы подпись была именно ваша.
                                                                            –3
                                                                            А зачем вы нажимали кнопку Merge не глядя на коммиты?
                                                                            А как иначе? Если я в них посмотрю — то не увижу в них тех изменений, которые я просил сделать. Ибо их просто нельзя сделать без rebase.

                                                                            Остаётся только «не глядя» вливать… И надеяться, что код, который получился — правильно работает…
                                                                              0
                                                                              При чём тут «без rebase»? В этой ветке я оспариваю ваше утверждение, что «Github вообще энфорсит совсем другую модель. Leftpad-стайл».
                                                                        +2
                                                                        все так, только не signed-off, a acked-by или reviewed-by
                                                                          0
                                                                          Извиняюсь, да.
                                                                  –1
                                                                  Мердж вы уже сделали, но ревьювер смотрит старый коммит…
                                                                  Какой дали — такой и смотрю, другого-то нет. Вы же сказали: ревью делать — как при rebase.
                                                                0
                                                                Как насчет workflow, где фича всегда разрабатывается на основе актуальной dev(trunc) ветки? И ревью производится готового кода в составе полного, компилируемого кода в этой ветке.
                                                                  0
                                                                  А что делать если одновременно разрабатываются две фичи?
                                                                    0
                                                                    Вы имеете в виду, что во время разработки одной пришлось вотпрямсрочно перейти на разработку второй? Сохранить изменения — stash или как там это называется в git'е (положить на полку), потом вернуться.
                                                                    В целом, это показатель неоптимального рабочего процесса, кмк.
                                                                      0
                                                                      Я имею в виду, что на проекте более одного разработчика, и у каждого — своя задача.
                                                                        0
                                                                        Простите, но тогда мне не совсем ясен изначальный вопрос: «что делать если одновременно разрабатываются две фичи» — разрабатывать одновременно две фичи. Понятно, что проблема появляется только если области разработки пересекаются, но это решается дроблением задач и частыми коммитами для синхронизации. Синхронизация один-два раза в день вполне достаточна, чтобы не иметь проблем вида «они так все поменяли, что нам надо все переделать».
                                                                          0
                                                                          то ревьюер смотрит их независимо, если всплывает конфликты инвайтит другого разработчика observerом, если нужна интеграция делается интеграционная ветка где есть обе фичи, на ней гоняются тесты и она мерджится в мастер
                                                          +9
                                                          Лучше бы вам merge никогда не надобился, а то очень сложно разобраться в графе истории разработки, где 80% это всякие мержи.
                                                            +1
                                                            Вопрос представления. В IDEA, к примеру, merge commits отрисовываются приглушёнными цветами, а при желании их можно вообще спрятать.
                                                              +4
                                                              А зачем в графе разбираться?

                                                              Я гитом пользуюсь лет 10, и ни разу не приходилось именно разбираться в графе. Грепать логи приходилось, бисектить приходилось, git blame делать приходилось, а вот на граф смотреть — нет.
                                                            0
                                                            Именно так
                                                              0
                                                              del
                                                          +1
                                                          +2
                                                          имелось в виду, если разработчик не знает git на уровне ваших картинок, то такой разработчик не нужен. а вы подменяете «знает на уровне, чтобы работать в команде» на «знает на 100%». ну так спешу вас огорчить, вы ничегошеньки не знаете на 100%. вообще удивлен, что ваш комментарий огрёб столько плюсов.
                                                            –1
                                                            У меня в команде есть ребята, которые без декстопных приложений не смогут отправить свой коммит. Некоторые о git узнали в процессе написания диплома, только потому что нужно было что-то туда писать. Это не делает их плохими разработчиками.
                                                            Извините, но плюсы меня не интересуют. Даже если бы заминусовали, я бы не отказался от своих слов.
                                                              +2
                                                              Это не делает их плохими разработчиками.


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

                                                              В принципе, никакой ракетной техники в git нет — я сам работал на предприятии, где использовался (и, наверное, до сих пор используется) SVN, и переучиться на git стоило, конечно, некоторых усилий, но не то, чтобы запредельных. Но такие мелочи могут накапливаться, и делать предприятие (и, соответственно, строчку в резюме ваших сотрудников) «uncool».
                                                          +23
                                                          можно уметь mercurial, например
                                                            +18
                                                            Занимаюсь программированием с 1988-го года, то есть 30 с лишним лет, с интересом читаю статьи с описанием всяких хитростей Git, думаю «Надо всё же когда-нибудь попробовать! Раз уж от этого Git все так тащатся!», но… Некогда мне Git изучать, работать надо, поэтому пробы всё откладываю и откладываю из раза в раз. Позор мне. Пойду убьюсь об стену.
                                                              +8

                                                              А вы в принципе пользуетесь какой-либо системой контроля версий? Например, CVS или SVN? Если нет, то как вы работаете в команде? Или вы 30 лет с лишним лет программист-одиночка?

                                                                0

                                                                У меня тут на новой работе дали проект из загадчика, парни, он в source safe ещё локальном хранится, вот где Содом.
                                                                Я его через vss2git сконвертировал в git, чтобы историю хотя бы в нормальном виде смотреть...

                                                                  –9
                                                                  Было время я пользовался Microsoft Visual SourceSafe, год, с 2000-го по 2001-й год когда работал в команде, там это был корпоративный стандарт. Но там было просто, мне показали что надо нажимать в начале рабочего дня чтобы скачалась последняя версия проекта и что нажимать в конце рабочего дня чтобы другие увидели что я там за день наделал, это я и нажимал. А ни до этого, ни после этого никакими системами контроля версий я никогда не пользовался, непонятны они мне, а посему неудобны. Сейчас меня закидают тухлыми яйцами, но мне удобно по-старинке: добился работоспособности — «закоммитил» директорию с проектом у себя в ProjectName.dd-mm-yyyy и продолжил делать в ProjectName. Не получается — сделал «checkout» путём переноса из ProjectName.dd-mm-yyyy обратно в ProjectName. Получилось — «закоммитил» директорию с проектом в следующую директорию опять с указанием даты ProjectName.dd-mm-yyyy. И время от времени бекаплю всё это дело на внешний диск, удаляя у себя на локале наиболее старые ProjectName.dd-mm-yyyy, но оставляя на внешнем диске все. И нет никакой головной боли что там лучше делать merge или rebase, и не надо придумывать никакие commit messages, и не надо синхронизировать никакие ветки. А историю изменений по ходу изменений записываю (с указанием что менял и даты) в обычный текстовый файл Changelog.txt в корне проекта. По этому Changelog.txt в случае чего необходимую директорию ProjectName.dd-mm-yyyy найти не просто, а очень просто и без всяких bisect. И да, в команде я с 2001-го года больше не работаю, работаю один. Из git я освоил только clone чтобы иногда скачивать что-нибудь с гитхаба. В принципе init, add, checkout, и commit я могу в Git использовать, но зачем? Если моё версионирование через директории ProjectName.dd-mm-yyyy делает в принципе то же самое, только [для меня] гораздо более прозрачно и устраивает меня на 100%. А вот про всякие cherry-pick, revert, tag, submodule и прочие, а ещё какие-то жуткие, нечеловеческие, сделанные явно для того чтобы в конец запутать способы указания номера коммита через немыслимые HEAD, HEAD~1, HEAD^ и т.д. — я только знаю что такое есть, но что это, зачем это нужно и как этим пользоваться понятия не имею и побаиваюсь. И некогда мне это изучать. Вот как-то так.

                                                                  Сказал как есть и поэтому к приёму очереди из тухлых яиц готов.
                                                                    0

                                                                    Я правильно понимаю, что вы работаете над проектами один?

                                                                      +1
                                                                      И да, в команде я с 2001-го года больше не работаю, работаю один.
                                                                        +12

                                                                        Оттого ваш стиль с версионированием директории ProjectName.dd-mm-yyyy вам подходит. Если бы в команде был хотя бы +1, то вы бы уже давно сознательно переползли на систему контроля версий.

                                                                          +25

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

                                                                            +11
                                                                            У нас был случай в 2001м ~ 2002м, писали софт для такси (на Дельфи ещё), используя ProjectName.dd-mm-yyyy на локальной машине.
                                                                            И вот в один прекрасный день, админ решил обновить на этом компе драйверы для видеокарты nvidia, забыв создать точку восстановления перед установкой…
                                                                            Но что-то пошло не так, решил откатится — и откатился на точку восстановления, сделанную 2 недели назад…
                                                                            Уже на следующий день у нас был отдельный сервер с svn.
                                                                            Вот так незатейливо и началось знакомство нашей компании с системами управления версиями!
                                                                              0
                                                                              Никогда не пользовался восстановлением, что на винде, что в линуксе. Потому что это черный ящик который вообще не понятно как работает, в нем легко ошибиться (ваш случай).
                                                                              По моему, это где-то возле частого форматирования дисков вместе с критически важными дисками каждый день без бэкапов с вероятностью 1% форматнуть не тот диск.
                                                                                0
                                                                                Простите, а проекты лежали в %windir%? Ибо емнип, точки восстановления не затрагивают пользовательские файлы. Или мне нужно очки снять?
                                                                                  0
                                                                                  Обещают-то что не затрагивают, а вот реально я тоже файлы терял. Нет, лежали не в %windir%, а просто в c:\Projects
                                                                                0

                                                                                Кто ж спорит?)

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

                                                                          Непонятны и неудобны потому что видимо не пользовались нормально.


                                                                          Сейчас меня закидают тухлыми яйцами, но мне удобно по-старинке: добился работоспособности — «закоммитил» директорию с проектом у себя в ProjectName.dd-mm-yyyy и продолжил делать в ProjectName. Не получается — сделал «checkout» путём переноса из ProjectName.dd-mm-yyyy обратно в ProjectName.

                                                                          Какой кошмар! Действительно закидают.


                                                                          И нет никакой головной боли что там лучше делать merge или rebase, и не надо придумывать никакие commit messages, и не надо синхронизировать никакие ветки.

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


                                                                          Если моё версионирование через директории ProjectName.dd-mm-yyyy делает в принципе то же самое, только [для меня] гораздо более прозрачно и устраивает меня на 100%.

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


                                                                          А вот про всякие cherry-pick, revert, tag, submodule и прочие, а ещё какие-то жуткие, нечеловеческие, сделанные явно для того чтобы в конец запутать способы указания номера коммита.

                                                                          Использовать эти команды вовсе не обязательно, разбирающимся они только помогают. Что нечеловечного в хеше коммита, тэгах, дате?

                                                                            +8
                                                                            Хеш коммита поначалу действительно страшная вещь, если ты до этого только папочки копировал)

                                                                            Для pfemidi предложение у меня такое:
                                                                            начать использовать Git, создать в директории с вашим проектом рабочую копию через git init, закоммитить все текущие файлы с коммитом «initial»
                                                                            Затем при внесении изменений, вместо создания копии папочки с
                                                                            ProjectName.dd-mm-yyyy
                                                                            вы просто делаете git commit с текстом «ProjectName.dd-mm-yyyy».
                                                                            (меня сейчас закидают тухлыми яйцами уже поклонники Git)
                                                                            т.е. в вашем привычном способе разработки не изменится, но вы сможете использовать некоторые плюшки, как только захотите.
                                                                            Например, посмотреть diff между версиями ;)

                                                                            ну а потом уже и нормальные имена коммитов, и ветки, и все остальное само подтянется. Сабмодули, cherry-pick, для индивидуальной разработки вам вряд ли понадобятся, tag — ну многие проекты их не используют, кстати говоря, revert — если не косячить с коммитами, то и откатывать не надо.

                                                                            В общем я считаю, начинать осваивать гит с одной единственной команды -реально ;)
                                                                              +2
                                                                              Никак не истина, лишь частный случай, но я «один разработчик» и да, я весьма активно использую cherry-pick. Просто софт стал весьма сложным. Некторые подсистемы могут писаться как «экспериментальные» в отдельной ветке. Что-то может быть в разработке и по 3 месяца. А потом принимается решение, что это надо «в основной системе».
                                                                              Приучило не писать монолиты… минимальная связанность — благо «при сборке из кубиков» есть всегда @Override-аннотация и в модулях дает писать «заглушки».
                                                                                0
                                                                                Я тоже как-то 1.5 года был одним разработчиком, и даже бранчами пользовался, хоть и редко. Без гита, хотя бы блэйма и истории, не представляю как вообще код писать. Как домой вечером уходить-то? А если проект занимает сотни мегабайт (либ много, а в современной iOS разработке они все большие, т.к. все статически линкуется) то как без гита, все сотни мегабайт архивировать?
                                                                                  0
                                                                                  Я не возражаю, только дополняю: бывает что несколько дней веду работу «офис-дом» с использованием «удаленного рабочего стола». Пинг хороший.
                                                                                  Такое в ряде ситуаций бывает удобным.
                                                                                    0
                                                                                    либ много, а в современной iOS разработке они все большие, т.к. все статически линкуется

                                                                                    А для этих либ разве нет никакого пакетного менеджера? На PHP достаточно сохранить package.json и composer.lock, на ноде package.json и package-lock.json. Ни разу не было даже мысли архивировать или коммитить зависимости.
                                                                              +4
                                                                              Стоит начать с малого. Просто коммиты, создание/слияние веток.
                                                                              Уверяю, все эти
                                                                              «закоммитил» директорию с проектом у себя в ProjectName.dd-mm-yyyy и продолжил делать в ProjectName. Не получается — сделал «checkout» путём переноса из ProjectName.dd-mm-yyyy обратно в ProjectName. Получилось — «закоммитил» директорию с проектом в следующую директорию опять с указанием даты ProjectName.dd-mm-yyyy.
                                                                              станут выглядеть для Вас, как ССЗБ.

                                                                              Попробуйте Git Extensions (Win).
                                                                                +13
                                                                                Раньше я работал так же, как и вы — архивы по датам, changelog и т.д. А потом стал использовать mercurial, и жизнь значительно упростилась. Более того, мне до сих пор приходится работать с некоторыми системами по-старинке, через архивы (всякие там STEP7 и тому подобное, где код хранится в файлах бинарного формата). По сравнению с нормальными системами контроля версий, это просто адъ. Поэтому скажу пару слов в защиту СКВ. Не имею намерений что-либо навязывать и, тем более, кидать в вас тухлые яйца. Расценивайте мое сообщение как ИМХО.

                                                                                Ваш стиль работы можно очень легко перенести на git или hg, и вы это, похоже, прекрасно понимаете, но не видите преимуществ. В чем профит? В том, что система контроля версий возьмет на себя прорву чисто механической работы. Например, сейчас вы делаете изменения в проекте, потом пишете в changelog «22.01.19 Реализовал фичу XYZ. Изменил aaa.cpp, bbb.cpp, ccc.cpp». А с любой СКВ и GUI-клиентом к ней вы просто набираете в окне сообщение «Реализовал фичу XYZ» и жмете Commit. Все. GUI-клиент типа TortoiseHG или Sourcetree четко показывает вам, что изменилось. Выделили коммит в списке — видите, что этот коммит изменил файлы aaa.cpp, bbb.cpp, ccc.cpp. Выделили файл aaa.cpp — сразу видите, что конкретно поменяли. То есть система ведет максимально подробный «changelog» за вас. Ориентироваться во всем этом вы сможете очень просто, причем безо всяких хитрых команд. Вам не нужен bisect, чтобы читать список изменений.

                                                                                Хотите вернуться к предыдущему состоянию? Выделили коммит и сделали на нем «Update». Нужен бэкап на внешнем винте? Один раз сделали на этом винте клон вашего репозитория а потом периодически делайте туда push. Более того, с git и mercurial вы сможете завести бесплатные аккаунты на сервисах типа github, gitlab, bitbucket и бэкапить туда.

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

                                                                                Размеры репа, если не коммитить туда бинарники, очень скромные, по сравнению с сохранением полного архива ProjectName.dd-mm-yyyy на каждый коммит. Всегда можно держать полную копию истории под рукой, а не на внешнем винте.

                                                                                Если вы работаете в одиночку, то, скорее всего, вы сможете обойтись без веток, и у вас не будет «головной боли что там лучше делать merge или rebase». Жуткие номера коммитов (хэши)? В mercurial можно пользоваться последовательно возрастающим порядковым номером коммита, особенно если вы работаете один. Да и при использовании GUI, в принципе, можно и не заморачиваться этими обозначениями.

                                                                                Некогда все это изучать? В mercurial описанный выше функционал под GUI клиентом можно освоить за день-два. Если не любите GUI и хочется консольного кунг-фу, вероятно, понадобится чуть побольше времени, но не намного. git в целом сложнее, чем mercurial, но на таком уровне особой разницы тоже не будет.
                                                                                  0
                                                                                  Было время я пользовался Microsoft Visual SourceSafe, год, с 2000-го по 2001-й год когда работал в команде, там это был корпоративный стандарт. Но там было просто, мне показали что надо нажимать в начале рабочего дня чтобы скачалась последняя версия проекта и что нажимать в конце рабочего дня чтобы другие увидели что я там за день наделал, это я и нажимал.

                                                                                  Мне кажется, что вы упустили существенную часть — наверное, вам также сказали, что перед тем, как сделать Checkout/Checkin, нужно обязательно сделать Show Differences, чтобы вы своими изменениями вы не затерли чужие.
                                                                                    0
                                                                                    Может быть. Это было давно, с тех пор у меня в этом практики никакой не было и я уже не помню, успешно всё забыл.
                                                                                    +5
                                                                                    Попробуйте Mercurial. Он проще Git в освоении, и отлично подходит для проектов с одним разработчиком. Я сам его использую для сохранения истории разработки каждого из моих хобби-проектов на локальной машине. Удобно изучать историю изменений при помощи TortoiseHg (который на порядок удобнее TortoiseGit из-за Hg Workbench), скажем, через 5 лет после того как они были сделаны, и вы уже не помните что вы там именно делали и меняли.
                                                                                      +3
                                                                                      я пока не проверил 10 раз, думал это пишет мой отец. Вот все сходится — и программировать примерно тогда начал, и одиночка, и все новое и непонятное для него ненавидит! Вероятнее всего, вы сидите на старинных технологиях как и он, и на поддержке какого-то старого монстра, раз прогресс так далеко обходит вас стороной
                                                                                        0
                                                                                        Удваиваю mercurial, в git насильно реализовали сверхценные идеи торвальдса а-ля «головы DAG коммитов, на которые никто не ссылается — мусор» и держатся за них, как за спасательный круг. Что, если подумать, разумно, т.к. выкинь это всё — и git окажется просто ещё одной DVCS, только с неюзабельным интерфейсом.
                                                                                          0
                                                                                          Если вам не нравится путаница с GIT, поставьте локальный SVN, создайте в нем одну ветку, поставьте Tortoise SVN и будет у вас тоже самое, что и сейчас, только гораздо удобнее. Не надо ничего никуда копировать, потом вытягивать и тд. Можно посмотреть различия в версиях файла сейчас и месяц назад. И для этого не надо выкачивать папку с датой и вручную сравнивать. Просто два клика мыши. Работаю над проектом один, а свой репозиторий проще поднять на SVN. С системой контроля версий работа становится намного проще.
                                                                                            0
                                                                                            Вы могли бы использовать любые системы контроля версий — тот же SVN — в таком же стиле, просто используя одни и те же типовые приемы, без «этих ваших всяких непонятных cherry-pick». Но в дополнение получили бы внятную историю (changelog это совсем не то, слишком большая гранулярность). Как минимум. Какой-нибудь blame для старых изменений (посмотреть, в рамках какой задачи/коммита была изменена конкретная строка с сопутствующим комментарием) незаменим, и на директориях так просто этого не сделать.
                                                                                              +2
                                                                                              Не бывает так. Тролят нас!
                                                                                                0
                                                                                                Бывает, увы.
                                                                                                +3
                                                                                                Про VCS не буду ничего говорить — выбор ваш.

                                                                                                Но может стоит хотя бы сменить формат даты на yyyy-mm-dd? С таким форматом даты сортировка по названию будет осмысленной и он стандартизирован — ISO8601.
                                                                                                  –5
                                                                                                  Мне нет никакого дела до этого ISO8601, я в России живу, а в России формат даты ДЕНЬ МЕСЯЦ ГОД.
                                                                                                    +3

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

                                                                                                      –6
                                                                                                      А это уже привычка, в именах файлов/директорий после точки может быть лишь расширение. Но в дате всегда сначала идёт день, после месяц, после год, по-другому — от лукавого.
                                                                                                        +7
                                                                                                        В дате российского формата части всегда разделяются точкой, всё остальное — от лукавого!
                                                                                                          +2
                                                                                                          именах файлов/директорий после точки может быть лишь расширение

                                                                                                          Кто вам эту ересь сказал? Расширение файла это лишь абстракция. И ни одна из известных мне современных файловых систем не реализует эту абстракцию. Она уже уровнем выше реализуется, на уровне приложений. Можно дать файлу имя "big.little.boss", никто этого не запрещает.

                                                                                                            –1
                                                                                                            И ни одна из известных мне современных файловых систем не реализует эту абстракцию.
                                                                                                            Ну знаете. Это уже перебор. Оригинальный FAT (который в MS-DOS), FDOS, файловые RSX-11 — они это всё очень хорошо реализуют…

                                                                                                            Можно дать файлу имя «big.little.boss», никто этого не запрещает.
                                                                                                            Запрещает. Ещё как запрещает! В той же FDOS под имя файла отведено ровно 11 байт, 8 под имя и 3 под расширение, так ещё и от каждого байта старший бит занят под расширение. Да и даже в старой версии Minix вы такой файл не создатите (не более 14 символов в имени файла, однако).
                                                                                                              +1
                                                                                                              современных файловых систем

                                                                                                              Часто вы используете оригинальную fat? А может вы под minix программируете?


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

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

                                                                                                              Так что для меня всё что после точки то расширение.
                                                                                                                0

                                                                                                                Тогда извиняюсь, недопонимание вышло.

                                                                                                                  0
                                                                                                                  Наследие DOS, наследие 8.3. Я и к тому что имя файла может быть более чем 8 символов с трудом привык лишь лет пять назад. Против других ничего не имел, но свои называл строго не выходя за рамки восьми символов на имя.
                                                                                                                    0
                                                                                                                    DOS не такая уж и старая операционка. Парралельно существовал вполне развитый Unix, файловая система которого уже тогда была case sensitive, уже тогда не имела такого ограничения на длину имени, и расширение как отдельный элемент также отсутствовало.
                                                                                                                  +1
                                                                                                                  А если mydocument.2011.12.11.txt, то где у вас расширение?
                                                                                                            0
                                                                                                            Какое вам дело до предпочтений других жителей России, если вы работаете над проектами один? Год в начале сделает удобнее вам (логичная сортировка) и из-за стандартизированности удобнее работу из кода с этим хранилищем ("%F" против "%d-%m-%Y" и т.п.).
                                                                                                              0
                                                                                                              Зачем git, если есть архиватор.
                                                                                                              Зачем сортировки по имени в своей же файлопомойке, если есть total commander.
                                                                                                                0
                                                                                                                Ещё раз. Я живу в России и для меня предпочтительнее принятый в России порядок день, месяц, год. Да, сортировка будет лучше, но у меня нет ни одного долгостроя, который продолжался бы более года, так что у меня сортировка не страдает. И т.к. я работаю один, то предпочтения других мне совсем не интересны.
                                                                                                                  +5
                                                                                                                  Похоже, у вас даже долгостроя в месяц не было, раз проблем с сортировкой не испытываете.
                                                                                                                    +5
                                                                                                                    но у меня нет ни одного долгостроя, который продолжался бы более года

                                                                                                                    То есть ни один проект не прожил больше года, раз поддержкой не занимаетесь? Или пишете сразу идеальный софт без единой ошибки?
                                                                                                                      0
                                                                                                                      Почему же, живут больше года, гораздо. Только поддержкой старого не занимаюсь, это да. Специфичные проекты просто.
                                                                                                                        +4

                                                                                                                        Работал я как-то над "специфичным проектом". На Delphi.
                                                                                                                        Небольшой модуль для обработки изображений.


                                                                                                                        Переменные были объявлены с "запасом".


                                                                                                                        Около 60 переменных объявлено, из которых использовалсь около 20. У и по классике: они назывались x1, x2, x2, ..., a1, a2...


                                                                                                                        Что бы не иметь проблем с выходом за границу, массивы были объявлены размером в 10 раз больше нужного.


                                                                                                                        Кусок кода размером более 1000 строк состоял из 3 процедур (не функций). Передача результата через глобальные переменные.


                                                                                                                        Естественно никакого версионирования, все по папочкам.


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


                                                                                                                        Я пытался указать на ошибки, однако получит в ответ что-то вроде: "Я 30 лет программирую, у меня 600 патентов, больше 100 реализованных проектов. Я к.ф.-м.н. Да тебе лет меньше, чем я в отрасли". На чем мои попытки благополучно закончились.

                                                                                                                          +3
                                                                                                                          по классике: они назывались x1, x2, x2, ..., a1, a2...


                                                                                                                          Человеческий детёныш, воспитанный диким Fortran-ом ;)
                                                                                                                          Знакомо.
                                                                                                                          Таблицы у нас именовались незатейливо: m1,m2,..m199… (сотни их было)
                                                                                                                          Поля в таблицах — по аналогичной схеме: R01,R02…
                                                                                                                          3 разработчика, никакого VCS.
                                                                                                                          Теперь то я понял, что это был своеобразный developer lock.
                                                                                                                            –2
                                                                                                                            За это Дельфи и убили — что даже такой человек мог выдавать относительно работающий код, который можно было относительно легко читать и понимать. Правда, всё — равно таких программистов, как в вашем примере много. В куче игр каждое сохранение по 10-20 мегабайт, при том, что реальной информации и на 1 Кб не наберётся. Но теперь их легко вычисляют и берут осознанно для экономии.
                                                                                                                      +6
                                                                                                                      ГОСТ ИСО 8601-2001 «Представление дат и времени»

                                                                                                                      Сокращенное представление

                                                                                                                      1. Определенная дата в рассматриваемом столетии
                                                                                                                      Основной формат
                                                                                                                      YYMMDD
                                                                                                                      Расширенный формат
                                                                                                                      YY-MM-DD
                                                                                                                    +2
                                                                                                                    Если вы работаете один, вам вообще не нужны ни ребайзы ни черрипики, вообще базовый гит, который за два часа можно освоить

                                                                                                                    Просто банальные git commit, git diff, git log и отдельно git branch, git merge
                                                                                                                    Потом внезапно еще освоите git clone/git pull/git push и сможете легко работать с любой машины, а не только с одной.
                                                                                                                      0
                                                                                                                      Боюсь угадать, это не какая-нибудь (около)государственная контора, для которой вы пишете проекты?
                                                                                                                        –1
                                                                                                                        Не бойтесь, не угадали.
                                                                                                                        +3
                                                                                                                        По этому Changelog.txt в случае чего необходимую директорию ProjectName.dd-mm-yyyy найти не просто, а очень просто и без всяких bisect

                                                                                                                        Бисект (бинарный поиск по коммитам) нужен, когда вы не знаете, в каком коммите ошибка. Не знаете, в какой день она допущена, и при изменении какого куска кода.
                                                                                                                        +2
                                                                                                                        Я когда впервые пришел на работу то обменивались через USB-флешку)) Потом работали или по очереди или над разными модулями выгружая/загружая все на продакшен. Я тоже долго откладывал знакомство с Git, но когда познакомился, то вспоминал былые времена как страшный сон. Жалел что раньше не познакомился, тогда я бы в Git держал бы и курсовые (а не копия, новая копия новая копия 2)
                                                                                                                        +5
                                                                                                                        За 30 лет то можно было найти время. Ничего там сложного нет, особенно на базовом уровне.
                                                                                                                          +4
                                                                                                                          Вместо этого удалось как-то найти проект (или проекты), где можно работать одному. Это, я считаю, куда больший подвиг, чем изучение Git'а или там китайского языка.

                                                                                                                          Так-то я никогда не сталкивался с проектами, которые можно годами «пилить» одному. В моей практике как-то так получалось что либо проект «взлетает» и над ним работают 3-5-10-100 человек (в зависимости от того, как хорошо он «взлетел»), либо падает — а тогда там ни одного разработчика не нужно.

                                                                                                                          Про уникальный проект, где можно годами работать одному можно, видимо поэму написать — это ж редкость невероятная.
                                                                                                                            +1

                                                                                                                            Работа над проектом в одиночку уже считается подвигом? Что за проект то хотя бы?

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

                                                                                                                              А что за проект — мне тоже интересно узнать…
                                                                                                                                +3
                                                                                                                                Если проект в какой-нибудь госконторе, то это почти типичное явление. Я уж молчу про 1С (7.7) и небольшие магазины, ТСЖ и т.п. К сожалению, часто вижу небольшие фирмы, где всё так устроено и руки чешутся им помочь (хотя возможно это аллергия на old-school-legacy).
                                                                                                                                  +3
                                                                                                                                  Понятно… Что можно сказать…

                                                                                                                                  Если вы собираетесь в такой компании работать до пенсии… то не всё ли вам равно — что о вас думают в других местах?
                                                                                                                                    +3
                                                                                                                                    Вы-то можете собираться работать там до пенсии, но компания может обанкротиться, вы можете попасть под сокращение, или сменится руководство и работать станет невозможно, или еще что, вариантов сотни. А пенсия всё еще не прям завтра.
                                                                                                                                    И вот вам уже резко станет не все равно что о вас думают в других местах, когда выяснится, что вы с вашим весьма узкоспецифическим багажом мало где нужны.
                                                                                                                                      +1
                                                                                                                                      Люди, смотрящие так далеко вперёд обычно в компании, где нет никакого роста (компании, не человека) не сидят.
                                                                                                                                  +1
                                                                                                                                  Не автор, но,… платформа «автоматизации тестирования» (AST).
                                                                                                                                  Java (+ Hibernate, Maven, WebDriver, Jersey, OAuth2)
                                                                                                                                  PHP (+ Smarty, Composer, SafeMySQL)
                                                                                                                                  JS (+ NPM, Webpack, Babel, Vue)
                                                                                                                                  SCSS-препроцессинг (для веб-интерфейса), микросервисы, динамическое распределение нагрузки (самописный балансир).

                                                                                                                                  В марте будет как 6 лет работы «в одного».
                                                                                                                                    0
                                                                                                                                    У меня знакомый один работает уже 10 лет над одним проектом. Начал магазин с PHP и MySQL, а сейчас уже NodeJS, Angular 4, PostgreSQL… И владелец сайта доволен и человек всегда при работе и получает очень неплохие деньги.
                                                                                                                                      0
                                                                                                                                      Вот про это было бы интереснее узнать. Что госконтора может годами не меняться — это примерно понятно. Но как сайт умудряется и не вырасти с одного разработчика до сотни (за 10-то лет!) и не закрыться (за 10-то лет!) — решительно непонятно…
                                                                                                                                        0
                                                                                                                                        Сколько вам потребуется время для того, чтобы запилить качественный сайт в одиночку? Например, фрилансеры на апворке с хорошей статой — за полтора месяца. Ну вот, он запилил, доделывал какие-то вещи, а потом с нуля второй, третий и тд, пока на современные технологии не переехал. И процесс продолжается. Посетителей у него где-то 10 тысяч в день, а больше и не надо. Человек не гонится за ростом особо. Ну а вообще, хотелось бы у вас узнать сколько айти людей надо, чтобы поддерживать сайт? Я так представлю себе: один фронт, один бэк, может быть еще SQLщика одного и рекламщика. Ну и первые три из этой компании могут быть замещены опытным фулл-стэком, а последнего можно на стороне нанять, чтоб рекламки делал, вот и всё.
                                                                                                                                          0
                                                                                                                                          Если сайт у вас некоммерческий, то там и одного человека час в месяц может хватить.

                                                                                                                                          А если у вас магазин, то вам нужно либо расширяться, либо, если это не удастся, вас сожрут. Представить себе интернет-магазин, который 10 лет остаётся на том же уровне продаж мне довольно сложно, потому и возникает интерес: что за магазин, зачем ему новые технологии (если он продаёт что-то уникальное на что в природе тысяча покупателей ежемесячно и больше — нет и не будет, то зачем ему редизайн?) и так далее.

                                                                                                                                          Просто уж очень необычный случай, вот и всё.
                                                                                                                                            0
                                                                                                                                            Допустим, вы торгуете элитной мебелью где-нибудь в Андалусии, Испания. У вас есть интернет магазин, который скорее не магазин, а онлайн-каталог, потому что в основном все любят потрогать, пощупать. Конкурентов у вас не так много, поскольку вы работаете напрямую с изготовителями и сделать мебель дешевле уже не получится. Вы не хотите идти в большой бизнес, потому что там надо много людей нанимать, управлять всем этим и тд, а вам же хочется, чтоб хватало на свой дом у моря, пару машин, да семью содержать. Вы находите очень хорошего программиста и предлагаете ему заниматься сайтом в долгосрочной перспективе, поддерживая его красивым, современным и тд, ведь это элитная мебель, значит и впечатления от сайта должны быть соответствующие. Этот программист берется за работу, периодически нанимает дизайнеров для обновлений внешнего вида, и обновляет начинку сайта, дабы все это работало быстро и как надо. Все остальное время программист задействован в поддержании всего этого добра на плаву, меняя, обновляя и модифицируя по надобности. Вы, как владелец счастливы, потому что ваш онлайн магазин всегда под присмотром и работает как надо. При этом вы не платите много какой-то левой компании, которой надо кормить 10 менеджеров и оплачивать работу такого-же одного программиста.
                                                                                                                                            Вы, как человек, который знает половину дизайнеров и строительных компаний в этой самой Андалусии, без заказов точно не останетесь, а если делаете свою работу хорошо, так и подавно.
                                                                                                                                            Ну а теперь, возвращаясь к вашему вопросу, вы — это тот самый владелец магазина, о котором я писал, а программист одиночка — мой знакомый. Живёт в той самой Андалусии и работает уже больше 10 лет над одним проектом.
                                                                                                                                              0
                                                                                                                                              Спасибо. Да, пожалуй что в этом случае такой подход может и сработать. До кризиса в Андалусии, понятно, но тут уж непонятно: некоторые мелкие княжества в Европе умудряются существовать столетиями, не разваливаясь от глобальных кризисов.

                                                                                                                                              Так что случай реальный, но слегка экзотический…
                                                                                                                                      0
                                                                                                                                      Можно даже показывать, но всё равно работать в одиночку. Есть у меня один такой проект…
                                                                                                                                +2
                                                                                                                                А на работе что используется? FTP-шечка с CHANGELOG.txt?)
                                                                                                                                  +1

                                                                                                                                  Может быть вам стоит посмотреть вот этот интерактивный учебник: https://learngitbranching.js.org/. Поверьте, Git — это мощный и удобный инструмент, который не потребует от вас каких-то специфических знаний. Если вам сложно в консоли с ним работать — есть отличные инструменты встроенные в VisuaStudio, Intelij IDEA и прочие IDE, так же есть GUI инструменты для работы с ветками и коммитами — https://git-scm.com/download/gui/linux, некоторые из них позволяют разрешать конфликты слияний прямо внутри себя.


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


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

                                                                                                                                    –1
                                                                                                                                    есть отличные инструменты встроенные в VisuaStudio
                                                                                                                                    Брехня про отличные.
                                                                                                                                    0
                                                                                                                                    Удивительно что этот комментарий собрал столько плюсов, хотя дальше в дискуссии такой подход только раскритиковали.
                                                                                                                                      0
                                                                                                                                      Я сам удивлён, ожидал тонны минусов и полный кармагеддон сразу же после написания именно этого комментария. Но на него почему-то пошли плюсы. Зато тонны минусов посыпались на последующие. Ну да ладно, «каждый кулик своё болото хвалит», я сказал как у меня, народ сказал (минусами и понижением кармы) как у него. Так что дискуссию считаю завершённой, пойду дальше делать бекапы исходя из конкретной даты. Потому что мне так удобнее и слава богу работодатели не требуют от меня изучения ни git, ни hg, ни svn, им надо не шашечки, а ехать.
                                                                                                                                        +4
                                                                                                                                        Уточнение: вы не только сказали что вам так удобнее (хотя это уже странно), но и наговорили кучу глупостей о гите. А когда вам попробовали подсказать как можно сделать всё еще удобнее чем было — и вовсе начали огрызаться, даже не попытавшись разобраться в том что вам говорят.
                                                                                                                                          0
                                                                                                                                          1) Я не говорил «кучу глупостей о гите», я говорил о том, как его вижу. А вижу я его именно как средство для искусственного усложнения того, чего можно сделать (и я делаю) гораздо проще.
                                                                                                                                          2) Я не начал огрызаться, я просто сказал как я делаю, а в последующих комментариях я просто повторил как я делаю специально для тех, кто с первого раза не понял и начал меня учить чтобы я попробовал то, попробовал сё, изменил свой подход и т.д.

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

                                                                                                                                            Исходный комментарий заплюсовали (и я в том числе) потому, что он біл ответом на некорректное утверждение что кто не знает гит — не профессионал. Остальные заминусовали потому, что дальнейшие попытки доказать, что гит не нужен вообще, выглядят странно для тех, кто гит знает. Можете пробовать гит, можете не пробовать, дело Ваше.
                                                                                                                                            Примерно так выглядит со стороны Ваше утверждение про можно сделать удобнее
                                                                                                                                            image
                                                                                                                                              +3
                                                                                                                                              А вижу я его именно как средство для искусственного усложнения того, чего можно сделать (и я делаю) гораздо проще.


                                                                                                                                              Простите, но как
                                                                                                                                              git commit
                                                                                                                                              может быть сложнее
                                                                                                                                              rar a file_with_new_version_name.rar /myproject/dir

                                                                                                                                              Тем более, что по времени выполнения и занимаемому месту git будет однозначно быстрее. Вдобавок я просто не представляю сколько времени вы тратите на то, чтобы сделать сравнение версий.
                                                                                                                                                0

                                                                                                                                                Уточнение: git commit --all -m "new_version_name"

                                                                                                                                                  +2
                                                                                                                                                  Тогда уж -m «fixed some bugs, implemented some features»
                                                                                                                                                    +3
                                                                                                                                                    Т-с-с! Не пугайте динозавра.
                                                                                                                                                    +1
                                                                                                                                                    ну если придираться, еще и git add и git rm может понадобиться, --all сам по себе файлы не добавляет.
                                                                                                                                              +2
                                                                                                                                              слава богу работодатели не требуют от меня изучения ни git, ни hg, ни svn, им надо не шашечки, а ехать.

                                                                                                                                              У вас просто очень узкоспецифичный и редкий случай с командой продукта из 1-го человека.
                                                                                                                                              А в остальных же случаях в том-то и дело, что VCS нужны как раз-таки чтобы ехать. Картинка с круглыми и квадратными колесами ниже весьма метко характеризует ситуацию :)
                                                                                                                                                +2
                                                                                                                                                Знаете…
                                                                                                                                                Недавно я столкнулся с проблемой, которую решить пока не сумел. Хороший знакомый, всплывший из длительного необщения, сотворил систему работы с данными, как ему удобнее.

                                                                                                                                                Я, собственно, не столько критиковать, сколько поделиться. Есть чертова уйма офисных файлов и (кажется) ПДФок. С большим количеством значимого текста.
                                                                                                                                                Помимо этого есть куча папок, в которых лежат ярлыки — ссылки на нужные фрагменты нужных файлов. Папки тематические, они тоже связаны уймой перекрестных ссылок, реализованных тоже ярлыками. На каждый файл могут быть сотни таких ярлыков в разных папках, указывающие на разные места файла. Вся организация информации реализована на этих, мать их, ярлыках.
                                                                                                                                                Ему так удобнее. Это цитата, да.

                                                                                                                                                Файлов много, он реально работающий биолог. То есть, тысячи, может быть первые десятки тысяч. Библиотека на жестком диске, плюс его собственные данные. Творил он это все лет десять, и после перехода с XP на семерку вся эта радость работать перестала.
                                                                                                                                                Совсем.

                                                                                                                                                И что с этим адочком делать, я в душе не чаю. Зато ему было удобнее, долго было…
                                                                                                                                                  +1
                                                                                                                                                  ссылки на нужные фрагменты нужных файлов.

                                                                                                                                                  Семёрка (и Виста) не поддерживает фрагменты. Здесь видится такой вариант, что может потребоваться написать специализированную базу данных с импортёром, который можно было бы запустить на XP, и он бы перегнал shs-файлы (с помощью shscrap.dll) в эту базу.

                                                                                                                                                    0
                                                                                                                                                    Спасибо, покурю в этом направлении. Может, что получится.
                                                                                                                                                      0

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

                                                                                                                                                    +1
                                                                                                                                                    И что с этим адочком делать, я в душе не чаю. Зато ему было удобнее, долго было…

                                                                                                                                                    Ставить XP в виртуальной машине, думаю.

                                                                                                                                                      0
                                                                                                                                                      Пробовал, не взлетело.
                                                                                                                                                      Что-то ему не занравилось в возможных способах обмена файлами гостевой и хостовой систем. Пробовали XP Mode, пробовали VmWare: неудобно.

                                                                                                                                                      В итоге он все же засел за пересмотр своих воззрений. Жду, к чему пересмотр приведет.
                                                                                                                                                        0
                                                                                                                                                        ЧТО там может непонравится? общая папка, и тупо работает…
                                                                                                                                                          0
                                                                                                                                                          Вот чтоб я помнил… эти эксперименты в сентябре были.
                                                                                                                                                          Общий смысл в том, что какой-то привычный для него способ не работал. То ли нельзя было ярлык из гостевой на хост вытащить мышкой, то ли что в этом роде. Человек очень умный, но очень специфический. К сожалению, это довольно часто связанные характеристики.
                                                                                                                                                            –1
                                                                                                                                                            Замапить общую папку на одинаковый диск X, и ярлыки начинают работать вообще на всех машинах =)
                                                                                                                                                              +1

                                                                                                                                                              Но не фрагменты.

                                                                                                                                                0
                                                                                                                                                Я исторически с Subversion больше знаком. Использую его и на работе и дома для личных проектов. Хочу поделиться одной его фичей (возможно она есть и в других системах управления версиями).

                                                                                                                                                В Subversion можно любую папку на компьютере превратить в «локальный репозиторий». После этого вы с ним работаете как с обычным репозиторием любым удобным способом и используете все бонусы управления версиями. Саму папку-репозиторий периодически бэкапите привычным вам способом.

                                                                                                                                                Для разработчиков-ретроградов это простейший способ приобщиться к «современной» методологии управления кодом, проектами и ресурсами:
                                                                                                                                                • все ваши цифровые «ценности» концентрируются в одном месте, за которым проще ухаживать
                                                                                                                                                • вы можете работать оффлайн как привыкли и не завязаны на внешние интернет-сервисы
                                                                                                                                                  0

                                                                                                                                                  Любая современная система контроля версий умеет точно так же.

                                                                                                                                                    0
                                                                                                                                                    В Git эта идея доведена до апофигея. Кроме «папки — локального репозитория» там никаких других репозиториев-то и нету. Все репозитории равноправны и тот репозиторий, который хранится у вас на роутере — ничуть не хуже (и не лучше!) того репозитория, который у вас на GitHub или GitLab.

                                                                                                                                                    P.S. На самом деле, конечно, это только абстракция. «Большие дяди» хранят часто Git-репозитории не просто как папки в файловой сетеме, а используют специализированную базу данных. Но с точки зрения Git-клиента этого не видно: он по-прежнему считает, что общается с точно таким же клиентом, у которого есть точно такая же папка… только на сервер и побольше…
                                                                                                                                                      0
                                                                                                                                                      В Git эта идея доведена до апофигея.

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

                                                                                                                                                        0
                                                                                                                                                        Я бы сказал что то, что вы описываете есть вещь совершенно не связанная с возможностью превращения любой папки в «локальный репозиторий».

                                                                                                                                                        Что-то выкачать из SVN и потом туда коммитить локально, без подключения к серверу, нельзя вообще — никак. Хоть папка, хоть дедка.
                                                                                                                                                          –4
                                                                                                                                                          Можно конечно.
                                                                                                                                                          Надо только svn сервер себе поставить для этого. Комитьте туда сколько хотите а потом можно смержить результат наверх. Или можно сделать rebase если мержить не всё сразу, а по одному коммиту (хотя из коробки в один клик такого кажется в svn клиентах нету, но это лишь вопрос пользовательского интерфейса).
                                                                                                                                                          Не надо это записывать в минусы по сравнению с гитом: просто в гите этот функционал всегда идёт в комплекте, вне зависимости от его реальной надобности.
                                                                                                                                                            +1
                                                                                                                                                            Можно конечно.
                                                                                                                                                            Надо только svn сервер себе поставить для этого. Комитьте туда сколько хотите а потом можно смержить результат наверх.

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


                                                                                                                                                            Или можно сделать rebase если мержить не всё сразу, а по одному коммиту

                                                                                                                                                            Вот тут точно, если удалённый репозиторий — svn, локально надо ставить git, иначе будет очень тяжело.


                                                                                                                                                            хотя из коробки в один клик такого кажется в svn клиентах нету

                                                                                                                                                            А в git при работе с удалённым сервером svn такое из коробки есть.


                                                                                                                                                            но это лишь вопрос пользовательского интерфейса

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

                                                                                                                                                              0
                                                                                                                                                              Поставить svn сервер, сделать локальный репозиторий, потом скопировать туда директорию, выкачанную из удалённого репозитория, закомитить её, потом сделать дополнительные коммиты в локальный репозиторий, потом скопировать содержимое в удалённый репозиторий и закомитить

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


                                                                                                                                                              Насчёт того, что с локальным гитом это удобнее — может и так (сам не пробовал это ни с гитом ни с свн).


                                                                                                                                                              А вот это


                                                                                                                                                              легче реализовать отдельной локалькой копией для каждого коммита в связке с утилитой patch, чем с помощью локального svn, это не вопрос интерфейса, это вопрос отсутствующих фич.

                                                                                                                                                              точно нет. Всё же хранить "локальные копии коммитов" в vcs всяко удобнее чем вне её. И функционал "утилиты patch" там тоже есть встроенный.

                                                                                                                                                                +2
                                                                                                                                                                Насчёт того, что с локальным гитом это удобнее — может и так (сам не пробовал это ни с гитом ни с свн).

                                                                                                                                                                Что не пробовали, заметно. Я пробовал, гитом легче.


                                                                                                                                                                точно нет [точно не легче реализовать воркфлоу с ребейс отдельной локалькой копией для каждого коммита в связке с утилитой patch, чем с помощью локального svn ] .

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


                                                                                                                                                                Всё же хранить "локальные копии коммитов" в vcs всяко удобнее чем вне её.

                                                                                                                                                                Хранить да, удобнее. Встраивать их в описанный вами воркфлоу с rebase — вот это ад.

                                                                                                                                                            0
                                                                                                                                                            Что-то выкачать из SVN и потом туда коммитить локально, без подключения к серверу, нельзя вообще — никак. Хоть папка, хоть дедка.

                                                                                                                                                            Подождите, здесь нужны дополнительные ограничения, иначе рассуждеия идут слишком «в общем».
                                                                                                                                                            Выше говорилось о локальных репозиториях — мы же можем выкачать удаленный тем или иным способом, создать копию в локальном и работать с ним без доступа к серверу. Нет?
                                                                                                                                                              0
                                                                                                                                                              формально можно — svk плюс «репозиторий» в локальной ФС
                                                                                                                                                              другой вопрос, что svk сейчас вряд ли поддерживается
                                                                                                                                                                0
                                                                                                                                                                Что-то выкачать из SVN и потом туда коммитить локально, без подключения к серверу, нельзя вообще — никак. Хоть папка, хоть дедка.


                                                                                                                                                                Секундочку, сервер не обязателен.
                                                                                                                                                                в SVN также как и в гит поддерживается локальный file протокол.
                                                                                                                                                                  +1
                                                                                                                                                                  Секундочку, сервер не обязателен.

                                                                                                                                                                  Обязателен


                                                                                                                                                                  в SVN также как и в гит поддерживается локальный file протокол.

                                                                                                                                                                  От того, что сервер работает по file протоколу он не перестаёт быть сервером.

                                                                                                                                                                  0
                                                                                                                                                                  Я бы сказал что то, что вы описываете есть вещь совершенно не связанная с возможностью превращения любой папки в «локальный репозиторий».

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

                                                                                                                                                          +2
                                                                                                                                                          Оборот «уметь в» — вообще характерный признак продвинутого разработчика. :D
                                                                                                                                                            0
                                                                                                                                                            Умею нажимать в русской версии VisualStudio «Синхронизировать», что автоматизирует последовательность «принести», «вытянуть», «отправить»
                                                                                                                                                            ЧЯДНТ?
                                                                                                                                                              +1
                                                                                                                                                              Вы путаете «не умеет» с «не хочет»
                                                                                                                                                              +3

                                                                                                                                                              Интервью Кузнецова было на opennet(это тот мужик, который написал сетевой стек Linux) — он там про гит и Линуса рассказывал, говорил что при всех недостатках, Торвальдс умеет видеть далеко вперёд, и там где многие разработчики видели навоз (так он называл bitkeeper), Линус смог разглядеть бриллиант и сделать на этих идеях git.

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

                                                                                                                                                                (Где-то ещё было сравнение git с навороченным гоночным мотоциклом, на котором легко убиться, но можно и безопасно ездить вокруг гаража.)