Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 67
Отличный мануал, буду делится им со всеми знакомыми кто еще не перешел на GIT и говорят «а зачем нам парится, нас все устраивает» :)
в случаях, если кто-то сделает push c --force, pull будет работать не всегда правильно. В этом случае для мастер ветки надо заменить «git pull» на «git fetch origin; git reset --hard origin/master» и «git rebase master» на «git rebase -i master»
* Объяснить зачем это нужно разработчикам и руководству
это вот всё-таки важный, но нераскрытый момент :) Особенно в контексте «зачем нужно руководству».
Это не слишком весомый аргумент. Задержки на связь с локальным хранилищем при 100% работе в рамках офиса — фактически никакие.
А переход на новую систему контроля версий — это сама по себе задержка/время/деньги.
это вот всё-таки важный, но нераскрытый момент :) Особенно в контексте «зачем нужно руководству».
Краткий ответ: потому что не появляются задержки от работы с системой контроля версий.
Это не слишком весомый аргумент. Задержки на связь с локальным хранилищем при 100% работе в рамках офиса — фактически никакие.
А переход на новую систему контроля версий — это сама по себе задержка/время/деньги.
К сожалению, в случае с SVN это не так. Для того, чтобы создать новую ветку, слить ветки, выгрузить версию, загрузить версию, на любой коммит — уходит время, причем довольно ощутимое даже в локальной сети — на каждый чих вычисляются диффы.
В нашем случае, хранилище находится не в локальной сети на на серверах в Интернете (офисы децентрализованы и разбросаны по нескольким странам и городам), что добавляет еще бОльшие задержки.
Работая с DVCS этих задержек нет, любые изменения и телодвижения происходят без задержек.
Потери времени на переход на другую SCM были практически нулевыми — только на изучение инструкции, и сделать checkout нового репозитория в понедельник утром.
Разработчики они всё-таки умные люди, и потому сменить TortoiseSVN на TortoiseGIT не так сложно, а «лишние» телодвижение на создание ветки и ревью кода окупаются снижением ошибок в продакшене.
В нашем случае, хранилище находится не в локальной сети на на серверах в Интернете (офисы децентрализованы и разбросаны по нескольким странам и городам), что добавляет еще бОльшие задержки.
Работая с DVCS этих задержек нет, любые изменения и телодвижения происходят без задержек.
Потери времени на переход на другую SCM были практически нулевыми — только на изучение инструкции, и сделать checkout нового репозитория в понедельник утром.
Разработчики они всё-таки умные люди, и потому сменить TortoiseSVN на TortoiseGIT не так сложно, а «лишние» телодвижение на создание ветки и ревью кода окупаются снижением ошибок в продакшене.
Чуть не забыл ответить на главное! «Особенно в контексте «зачем нужно руководству».»
Руководству надо одно — чтобы процесс шел. Причем процесс шел лучше, чем был.
А инструкция — она для разработчиков, зачем это надо им.
Руководству надо одно — чтобы процесс шел. Причем процесс шел лучше, чем был.
А инструкция — она для разработчиков, зачем это надо им.
А вообще может ли кто поделиться сравнением всех основных систем контроля версий: CVS, SVN, Git, Mercurial? Так получилось, что я не работал ни с одной из них и даже не представляю, с какой начинать знакомство.
CVS сразу забыть как архивную, и сразу смотреть на SVN как хороший пример централизованной системы («старого типа» в моём понимании).
Git или Mercurial представители DVCS и по сути близки, о разнице между ними писали много в том числе на хабре.
Для себя я сделал выбор в сторону Git, но разницы с чем начинать жить нет никакой — изучение базовых команд занимает день, углубление в дебри идёт естественным путём в процессе по мере столкновения.
Git или Mercurial представители DVCS и по сути близки, о разнице между ними писали много в том числе на хабре.
Для себя я сделал выбор в сторону Git, но разницы с чем начинать жить нет никакой — изучение базовых команд занимает день, углубление в дебри идёт естественным путём в процессе по мере столкновения.
у нас не практикуется массовое использование бранчей, поэтому один раз кликнуть коммит удобнее, чем собирать коммиты в пачку и затем пушить на сервер.
Основной плюс «массовых бранчей» — история мастера плоская, но при просмотре дерева истории сразу видно когда какой баг решался.
Основной плюс «пачки коммитов» — можно во-1х проследить логику разработчика (упрощает жизнь ревьюера), во-2х очень бегло смотреть на некоторые изменения типа «добавил в дерево готовый фреймворк», которые добавляют много файла, и мешают читать основной дифф.
Основной плюс «пачки коммитов» — можно во-1х проследить логику разработчика (упрощает жизнь ревьюера), во-2х очень бегло смотреть на некоторые изменения типа «добавил в дерево готовый фреймворк», которые добавляют много файла, и мешают читать основной дифф.
GIT хорошая штука.
Я вообще-то приверженец CVS, поскольку ну хватало нам его всегда раньше.
Когда была война кланов CVS и SVN и молодость победила, я в общем то не понимал принципиальных отличий между работой под CVS и SVN. Ну да, ну действительно шуршало оно сервером, когда происходили многочисленные коммиты и вообще в процессе работы, ну и что :-).
А вот 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.
Ссылка не работает. Там в конце лишняя точка. Вот правильная: ftp.newartisans.com/pub/git.from.bottom.up.pdf
Сам гит может быть, но вот с точки зрения пользователя, это убийство веником и взрыв мозга бедного девеолпера, который еще вчера писал всё в одного для самого себя любимого не используя VCS.
Для работы с Git под Windows самое удобное – использовать TortoiseGit.
SmartGit гораздо удобней.
Абсолютно согласен с вашими постулатами по работе с кодом.
Но я только одного не пойму, разве для этого необходимо переходить на Git? Почему в Subversion тоже самое нельзя сделать? При этом я подразумеваю, что создание нового бранча — это не часы, а минут 10. Или в Git'е реализована еще более крутая система автомерджинга?
Но я только одного не пойму, разве для этого необходимо переходить на Git? Почему в Subversion тоже самое нельзя сделать? При этом я подразумеваю, что создание нового бранча — это не часы, а минут 10. Или в Git'е реализована еще более крутая система автомерджинга?
Чтобы понять в чем отличие работы с ветками в GIT и SVN надо попробовать там и там.
После этого на SVN возвращаться не захочется.
После этого на SVN возвращаться не захочется.
Как думаете Вы, я адекватно понял ключевую чаcть отличия GIT от SVN?
Вот там: habrahabr.ru/blogs/development_tools/82084/
Вот там: habrahabr.ru/blogs/development_tools/82084/
Не всем ;)
1) Плоская история. Отсутствуют merge коммиты вносящие какие-либо разрешения конфликтов.
Это позволяет локализовать, отменять отдельные фичи и прочие вещи без создания дополнительных конфликтов.
2) Разрешение конфликтов самим разработчиком. Ты стартовал используя мастер от утра понедельника, сдаёшь в обед среды. За это время в мастере могло поменяться много чего. Ты сам производишь разрешение всех конфликтов в своём коде так, как будто ты только что в среду начал и сразу же сдал. Протестировав относительно самого последнего кода.
В целом, используя такой подход (сливать только чистые изменения), история проекта становится сухой и шелковистой.
При работе классическим образом, сливая просто ветки «как есть», процесс разрешения конфликтов либо падает на review'ера, либо история становится «косичкой» — сделали вилку из мастера в ветку A, потом слили в мастер ветку B, потом слили в A новый мастер, потом результат опять слили в мастер. Получается косичка, в которой не всегда ясно что откуда пришло и какое изменение создало проблемы.
Если история «плоская», всегда существует точка, которая вводит баг. И git bisect становится панацеей.
Это позволяет локализовать, отменять отдельные фичи и прочие вещи без создания дополнительных конфликтов.
2) Разрешение конфликтов самим разработчиком. Ты стартовал используя мастер от утра понедельника, сдаёшь в обед среды. За это время в мастере могло поменяться много чего. Ты сам производишь разрешение всех конфликтов в своём коде так, как будто ты только что в среду начал и сразу же сдал. Протестировав относительно самого последнего кода.
В целом, используя такой подход (сливать только чистые изменения), история проекта становится сухой и шелковистой.
При работе классическим образом, сливая просто ветки «как есть», процесс разрешения конфликтов либо падает на review'ера, либо история становится «косичкой» — сделали вилку из мастера в ветку A, потом слили в мастер ветку B, потом слили в A новый мастер, потом результат опять слили в мастер. Получается косичка, в которой не всегда ясно что откуда пришло и какое изменение создало проблемы.
Если история «плоская», всегда существует точка, которая вводит баг. И git bisect становится панацеей.
В мастер слияние производит не автор кода, а ревьюер, который вычитывает и проверяет работоспособность кода. Если код основан не на последнем мастере, возможны конфликты которые надо будет решить в момент merge.
Как еще можно обновить код чтобы он соответствовал последнему мастеру, оставляя его в ветке, кроме «merge master» или «rebase master»?
В случае косички видно, что начинали делать относительно определённого кода, в момент слияния с мастером потребовались такие-то изменения.
В случае ребейза информация о том, что потребовался какой-то микрорефакторинг просто исчезает, так как она не является информативной.
Например, мыделили апельсин поменяли все функции класса, добавив им в конце парметр (, Request=None).
Это изменение уже в мастере.
В ветке мы писали новый метод этого класса, причем начали писать до этого изменения.
Если мы мержим — у нас появляется доп коммит типа «add Request argument, as introduced in solution to bug #Y».
Если мы делаем rebase, мы напарываемся на конфликт в момент ребейза уже на самом первом коммите, добавляем прямо там этот аргумент, и делаем rebase continue.
На выходе — ветка, в которой этот аргумент _был изначально_. Тем самым, мы избавляемся от непонятного лишнего неинформативного коммита.
Как еще можно обновить код чтобы он соответствовал последнему мастеру, оставляя его в ветке, кроме «merge master» или «rebase master»?
В случае косички видно, что начинали делать относительно определённого кода, в момент слияния с мастером потребовались такие-то изменения.
В случае ребейза информация о том, что потребовался какой-то микрорефакторинг просто исчезает, так как она не является информативной.
Например, мы
Это изменение уже в мастере.
В ветке мы писали новый метод этого класса, причем начали писать до этого изменения.
Если мы мержим — у нас появляется доп коммит типа «add Request argument, as introduced in solution to bug #Y».
Если мы делаем rebase, мы напарываемся на конфликт в момент ребейза уже на самом первом коммите, добавляем прямо там этот аргумент, и делаем rebase continue.
На выходе — ветка, в которой этот аргумент _был изначально_. Тем самым, мы избавляемся от непонятного лишнего неинформативного коммита.
В мастере _есть_ мержи всех веток, так как они туда мержатся после ребейза с --no-ff.
Поэтому откатывается _весь_ мерж.
Ребейз не уничтожает информацию о связанных коммитах — цепочка как была так и осталась.
Судя по вопросам, вы ни разу не пользовали ребейз?
Поэтому откатывается _весь_ мерж.
Ребейз не уничтожает информацию о связанных коммитах — цепочка как была так и осталась.
Судя по вопросам, вы ни разу не пользовали ребейз?
Ребейз меняет родителя у цепочки коммитов.
То есть было: A=>B=>C=>D
Стало: Q=>B'=>C'=>D'
То есть было: A=>B=>C=>D
Стало: Q=>B'=>C'=>D'
Вредность функции в том, что ребейз можно делать только пока ты полностью контролируешь ветку.
А если есть некая ветка, в которой 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/
А если есть некая ветка, в которой 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/
По-моему mercurial лучше
Поясните мне, пользователю SVN с многолетним стажем, спросить пару вещей о git:
1. Коммит происходит в локальный репозиторий. В мастер-ветку делается push только по окончанию разработки некоторой фичи (что вполне может занять пару дней или даже неделю). Так вот — не страшно ли, что в это время винт на машине разработчика сдохнет и всё пойдет прахом (на SVN-сервере всяко есть и бекапы и RAID, а иначе это и не сервер никакой)?
2. Если коммит происходит в локальный репозиторий — как мне работать над фичей с разных машин (например, с работы и из дому)?
3. Если фича касается нескольких разных людей (например — какой-нибудь протокол, поддержка которого должна параллельно наращиваться клиентом и сервером, которые разрабатываются разными людьми) — как над этим вообще работать? В SVN люди могут поочередно добавлять запросы-ответы в репозиторий, тестируя каждый свою часть кода, а тут у каждого — свой репозиторий. Как взаимодействовать?
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 — все изменения по очереди накладываются разными людьми в общую ветку на сервере.
2. Пуш ветки перед уходом, дома pull эту ветку и продолжил работу.
3. У нас как правило получается так, что сервер делает фичу, тестирует, заливает, после этого ставится задача фронтенду и бэкенду на поддержку. Они делают у себя фичу, тестируют, заливают.
Да, можно в одну ветку по очереди коммитить а-ля svn, тогда перед каждым коммитом делается так:
git stash
git pull origin specialbranch
git stash pop
git add/rm
git commit
git push origin specialbranch
получится как в svn — все изменения по очереди накладываются разными людьми в общую ветку на сервере.
Вот ещё эпическая статья, про то как правильно использовать git. Всем очень советую к прочтению.
nvie.com/posts/a-successful-git-branching-model/
nvie.com/posts/a-successful-git-branching-model/
Статья великолепная. В приложение к ней обязательно к применению: git-flow
Да, сейчас все переходят на DVCS, и это правильно. Но вот я недавно на одной конференции слышал как докладчик с упоением рассказывал как круто они используют для синхронизации кода между разработчиками… Dropbox! Про SVN, или, боже упаси, GIT, они вообще, наверное, не слышали… Вот так вот люди делают игры для социальных сетей.
З.Ы. Имелась в виду конференция SocialDev в Питере.
З.Ы. Имелась в виду конференция SocialDev в Питере.
Спасибо за труд, отличная дока!.. Поможет многим сомневающимся начать использовать git.
Ссылки на pdf и odt побились. Можете перезалить куда-нибудь?
временные трудности — поднять свой блог как всегда некогда :)
pdfку пока взять можно тут
pdfку пока взять можно тут
спасибо, теперь нашлось! )
«Твой костоломовский почерк по сводкам узнаю». Ну действительно, к кому и идти с такими вопросами, как не к лучшему другу. :-)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Инструкция-шпаргалка для начинающих