Pull to refresh

Comments 65

UFO just landed and posted this here
Ой! :) И правда. Спасибо огромное, поправил.
Отличный мануал, буду делится им со всеми знакомыми кто еще не перешел на GIT и говорят «а зачем нам парится, нас все устраивает» :)
в случаях, если кто-то сделает push c --force, pull будет работать не всегда правильно. В этом случае для мастер ветки надо заменить «git pull» на «git fetch origin; git reset --hard origin/master» и «git rebase master» на «git rebase -i master»
Предполагается, что master ветку никогда не трогают с --force, причем это зарезано на уровне gitolite.
Инструкция, она для начинающих разработчиков, а не Tips & Tricks.
Исключительно из этих соображений я опустил моменты «выхода из самосозданной задницы».
Данным аспектам вполне уместно было бы оказаться в предисловии публикуемой инструкции.
* Объяснить зачем это нужно разработчикам и руководству
это вот всё-таки важный, но нераскрытый момент :) Особенно в контексте «зачем нужно руководству».

Краткий ответ: потому что не появляются задержки от работы с системой контроля версий.

Это не слишком весомый аргумент. Задержки на связь с локальным хранилищем при 100% работе в рамках офиса — фактически никакие.

А переход на новую систему контроля версий — это сама по себе задержка/время/деньги.
К сожалению, в случае с SVN это не так. Для того, чтобы создать новую ветку, слить ветки, выгрузить версию, загрузить версию, на любой коммит — уходит время, причем довольно ощутимое даже в локальной сети — на каждый чих вычисляются диффы.
В нашем случае, хранилище находится не в локальной сети на на серверах в Интернете (офисы децентрализованы и разбросаны по нескольким странам и городам), что добавляет еще бОльшие задержки.
Работая с DVCS этих задержек нет, любые изменения и телодвижения происходят без задержек.
Потери времени на переход на другую SCM были практически нулевыми — только на изучение инструкции, и сделать checkout нового репозитория в понедельник утром.
Разработчики они всё-таки умные люди, и потому сменить TortoiseSVN на TortoiseGIT не так сложно, а «лишние» телодвижение на создание ветки и ревью кода окупаются снижением ошибок в продакшене.
А что, кто-то бранчит в свине? :-)
Да, но только для действительно мажорных работ.
Чуть не забыл ответить на главное! «Особенно в контексте «зачем нужно руководству».»
Руководству надо одно — чтобы процесс шел. Причем процесс шел лучше, чем был.
А инструкция — она для разработчиков, зачем это надо им.
А вообще может ли кто поделиться сравнением всех основных систем контроля версий: CVS, SVN, Git, Mercurial? Так получилось, что я не работал ни с одной из них и даже не представляю, с какой начинать знакомство.
CVS сразу забыть как архивную, и сразу смотреть на SVN как хороший пример централизованной системы («старого типа» в моём понимании).
Git или Mercurial представители DVCS и по сути близки, о разнице между ними писали много в том числе на хабре.
Для себя я сделал выбор в сторону Git, но разницы с чем начинать жить нет никакой — изучение базовых команд занимает день, углубление в дебри идёт естественным путём в процессе по мере столкновения.
у нас не практикуется массовое использование бранчей, поэтому один раз кликнуть коммит удобнее, чем собирать коммиты в пачку и затем пушить на сервер.
Основной плюс «массовых бранчей» — история мастера плоская, но при просмотре дерева истории сразу видно когда какой баг решался.
Основной плюс «пачки коммитов» — можно во-1х проследить логику разработчика (упрощает жизнь ревьюера), во-2х очень бегло смотреть на некоторые изменения типа «добавил в дерево готовый фреймворк», которые добавляют много файла, и мешают читать основной дифф.
GIT хорошая штука.

Я вообще-то приверженец CVS, поскольку ну хватало нам его всегда раньше.
Когда была война кланов CVS и SVN и молодость победила, я в общем то не понимал принципиальных отличий между работой под CVS и SVN. Ну да, ну действительно шуршало оно сервером, когда происходили многочисленные коммиты и вообще в процессе работы, ну и что :-).

А вот GIT это действительно революционная штука.

Спасибо за статью!
Исходя из моего опыта, гит лучше понимается и воспринимается, если изучать его снизу вверх: начиная с комманд git cat-file, git update-ref, git write-tree, git reflog, git rev-parse и т.д. Даже есть вот такой туториал на аглицком: ftp.newartisans.com/pub/git.from.bottom.up.pdf.
Сам гит может быть, но вот с точки зрения пользователя, это убийство веником и взрыв мозга бедного девеолпера, который еще вчера писал всё в одного для самого себя любимого не используя VCS.
Для работы с Git под Windows самое удобное – использовать TortoiseGit.

SmartGit гораздо удобней.
Нет, довольный юзер. Вообще этот клиент бесплатен для персонального использования.
Ну у меня не персональное использование, и честно, лично я пользуюсь командной строкой даже в винде.
Черепах удобен виндузятникам просто потому, что они пересаживаются с TortoiseSVN, а потому им просто запомнить новые три буквы.
Я пересел с SmartSVN :)

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

Но я только одного не пойму, разве для этого необходимо переходить на Git? Почему в Subversion тоже самое нельзя сделать? При этом я подразумеваю, что создание нового бранча — это не часы, а минут 10. Или в Git'е реализована еще более крутая система автомерджинга?

Чтобы понять в чем отличие работы с ветками в GIT и SVN надо попробовать там и там.
После этого на SVN возвращаться не захочется.
UFO just landed and posted this here
UFO just landed and posted this here
Посыпаю голову пеплом :( Был уверен что присылал.
UFO just landed and posted this here
1) Плоская история. Отсутствуют merge коммиты вносящие какие-либо разрешения конфликтов.
Это позволяет локализовать, отменять отдельные фичи и прочие вещи без создания дополнительных конфликтов.
2) Разрешение конфликтов самим разработчиком. Ты стартовал используя мастер от утра понедельника, сдаёшь в обед среды. За это время в мастере могло поменяться много чего. Ты сам производишь разрешение всех конфликтов в своём коде так, как будто ты только что в среду начал и сразу же сдал. Протестировав относительно самого последнего кода.
В целом, используя такой подход (сливать только чистые изменения), история проекта становится сухой и шелковистой.

При работе классическим образом, сливая просто ветки «как есть», процесс разрешения конфликтов либо падает на review'ера, либо история становится «косичкой» — сделали вилку из мастера в ветку A, потом слили в мастер ветку B, потом слили в A новый мастер, потом результат опять слили в мастер. Получается косичка, в которой не всегда ясно что откуда пришло и какое изменение создало проблемы.

Если история «плоская», всегда существует точка, которая вводит баг. И git bisect становится панацеей.
UFO just landed and posted this here
В мастер слияние производит не автор кода, а ревьюер, который вычитывает и проверяет работоспособность кода. Если код основан не на последнем мастере, возможны конфликты которые надо будет решить в момент merge.
Как еще можно обновить код чтобы он соответствовал последнему мастеру, оставляя его в ветке, кроме «merge master» или «rebase master»?

В случае косички видно, что начинали делать относительно определённого кода, в момент слияния с мастером потребовались такие-то изменения.
В случае ребейза информация о том, что потребовался какой-то микрорефакторинг просто исчезает, так как она не является информативной.

Например, мы делили апельсин поменяли все функции класса, добавив им в конце парметр (, Request=None).
Это изменение уже в мастере.

В ветке мы писали новый метод этого класса, причем начали писать до этого изменения.
Если мы мержим — у нас появляется доп коммит типа «add Request argument, as introduced in solution to bug #Y».
Если мы делаем rebase, мы напарываемся на конфликт в момент ребейза уже на самом первом коммите, добавляем прямо там этот аргумент, и делаем rebase continue.
На выходе — ветка, в которой этот аргумент _был изначально_. Тем самым, мы избавляемся от непонятного лишнего неинформативного коммита.
UFO just landed and posted this here
В мастере _есть_ мержи всех веток, так как они туда мержатся после ребейза с --no-ff.
Поэтому откатывается _весь_ мерж.
Ребейз не уничтожает информацию о связанных коммитах — цепочка как была так и осталась.
Судя по вопросам, вы ни разу не пользовали ребейз?
UFO just landed and posted this here
Ребейз меняет родителя у цепочки коммитов.
То есть было: A=>B=>C=>D
Стало: Q=>B'=>C'=>D'
UFO just landed and posted this here
Вредность функции в том, что ребейз можно делать только пока ты полностью контролируешь ветку.
А если есть некая ветка, в которой A=>B=>C=>D, её кто-то слил к себе и сделал E.
После ребейза у тебя стало Q=>B'=>C'=>D'
А E по-прежнему основывается на D а не на D'.
Вот это и есть проблема.

То же самое с --amend.
Но если ты единственный и неповторимый контроллер ветки, то делай с ней всё что угодно — хоть rebase, хоть amend коммитов прошлых — всё будет в порядке.

Советую вкурить оригинальную документацию и мысли Линуса на тему чистой истории
Еще по теме:
www.jarrodspillers.com/2009/08/19/git-merge-vs-git-rebase-avoiding-rebase-hell/
blog.experimentalworks.net/2009/03/merge-vs-rebase-a-deep-dive-into-the-mysteries-of-revision-control/
UFO just landed and posted this here
Толи еще будет когда вы узнаете про «git rebase -i» ;)
UFO just landed and posted this here
В мастере поддерживается прямая история, состоящая из мержей с --no-ff.
То есть выглядит это так:
*------*-----*-----*
_`----' `---' `---'

Где * — это коммиты в мастере, merge'ы, а петельки под ним — непосредственно ветки по каждой фиче-багу
UFO just landed and posted this here
Я с удовольствием буду иметь в наличии такую же инструкцию для Mercurial, если подготовите.
Ничего против hg не имею, кроме чуть меньшего удобства бранчей в нём.
Поясните мне, пользователю SVN с многолетним стажем, спросить пару вещей о git:

1. Коммит происходит в локальный репозиторий. В мастер-ветку делается push только по окончанию разработки некоторой фичи (что вполне может занять пару дней или даже неделю). Так вот — не страшно ли, что в это время винт на машине разработчика сдохнет и всё пойдет прахом (на SVN-сервере всяко есть и бекапы и RAID, а иначе это и не сервер никакой)?
2. Если коммит происходит в локальный репозиторий — как мне работать над фичей с разных машин (например, с работы и из дому)?
3. Если фича касается нескольких разных людей (например — какой-нибудь протокол, поддержка которого должна параллельно наращиваться клиентом и сервером, которые разрабатываются разными людьми) — как над этим вообще работать? В SVN люди могут поочередно добавлять запросы-ответы в репозиторий, тестируя каждый свою часть кода, а тут у каждого — свой репозиторий. Как взаимодействовать?
1. В инструкции я как раз и пишу, чтобы пуш делали минимум раз в день — перед уходом, либо если переключаются надолго на другую ветку.
2. Пуш ветки перед уходом, дома pull эту ветку и продолжил работу.
3. У нас как правило получается так, что сервер делает фичу, тестирует, заливает, после этого ставится задача фронтенду и бэкенду на поддержку. Они делают у себя фичу, тестируют, заливают.

Да, можно в одну ветку по очереди коммитить а-ля svn, тогда перед каждым коммитом делается так:
git stash
git pull origin specialbranch
git stash pop
git add/rm
git commit
git push origin specialbranch
получится как в svn — все изменения по очереди накладываются разными людьми в общую ветку на сервере.
Спасибо, Вы очень хорошо объяснили. Я понял, что некоторые вещи я раньше не так понимал.
При работе с разных машин делаю так:
git fetch && git reset --keep origin/my
При этом, если по случайности исправил один файл там и тут, то комманда не проходит, и дальше можно решать, как мёрджить.
Статья великолепная. В приложение к ней обязательно к применению: git-flow
Да, сейчас все переходят на DVCS, и это правильно. Но вот я недавно на одной конференции слышал как докладчик с упоением рассказывал как круто они используют для синхронизации кода между разработчиками… Dropbox! Про SVN, или, боже упаси, GIT, они вообще, наверное, не слышали… Вот так вот люди делают игры для социальных сетей.
З.Ы. Имелась в виду конференция SocialDev в Питере.
Спасибо за труд, отличная дока!.. Поможет многим сомневающимся начать использовать git.
Ссылки на pdf и odt побились. Можете перезалить куда-нибудь?
временные трудности — поднять свой блог как всегда некогда :)
pdfку пока взять можно тут
«Твой костоломовский почерк по сводкам узнаю». Ну действительно, к кому и идти с такими вопросами, как не к лучшему другу. :-)
Only those users with full accounts are able to leave comments. Log in, please.

Articles