Git, часть 2 – конфигурация, возможности и работа

Сегодня мы поговорим про систему контроля версий — Git.
git-scm.com/
Вы еще думаете использовать ли Git как систему контроля версий, при разработке собственных проектов, но не приняли окончательного решения?
Может моя новая статья вам поможет… :) Во всяком случае мне уже многократно помогала находить ошибки между разными версиями кода в проектах, но использовать git можно как для программистов также и для инженеров, в общем для чего угодно. :)
В общем, недавно написал на своем сайте следующую статейку про Git, некое подобие продолжения той что была написана пол года назад, но эта с углублением в некоторые тонкости, в общем встречайте:
— "Git, часть 2 – конфигурация, возможности и работа"
Если вы только собираетесь использовать Git или присматриваетесь к нему, то эта статейка вам поможет принять решение.
Польза ее в том, что можно быстренько (и почти на практике) рассмотреть минимальный набор основных возможностей.
Так что если кому интересно, милости просим :)
Но как вы понимаете для более детального прощупывания вам нужно будет установить git на свой компьютер и самим попробовать. Git есть и под Linux и так же и под всем привычную Windows (и под чтото там ещё… :) )
Ставится он в пару кликов под Windows, под Linux еще проще (даже нет смысла говорить как).

PS: самом собой разумеется, эта статейка не покрывает все,… в родной документации по git информации куда намного больше и ее читать просто необходимо.
… кстати, Git написан создателем и идеологом ОС Линукc — Линусом Торвальдсом (ну и щас еще несколько человек ему помогают).
  • 0
  • 26 февраля 2012, 00:19
  • uschema

Комментарии (49)

RSS свернуть / развернуть
ну дык и размести статью здесь (лучше обе), а не давай линк на свой блог. помнится, недавно уже была дискуссия на тему подобного…
0
Я разместил в личном блоге, что бы не писать в раздел.
Кому интересно тот не поленится перейти по ссылке, кому лень — не перейдет. Делов то.
Да и зачем мне размещать статью полностью тут, когда у меня есть свой сайт, и я уже на нем создал, тратить личное время вторично под этой сайт не вижу смыла.
0
хех. а смысл тогда писать кучку букАвАк на стороннем ресурсе? попиарить свой блог/ресурс?..
размести статью в личном блоге. простым копипастом. в чем сложности?..

и да, теперь о статье (несколько дней назад уже ознакомился...) — похоже тема гита становится популярной… «статьи» про него плодятся и множатся. строго говоря, твоя как и многие подобные — практически перевод и пересказ мана своими словами. я не говорю что она плоха или не нужна. просто ни нового ничего, ни тонкостей использования. ни даже во вводной не было сказано ни слова про преимущества явные или надуманные. надеюсь, пока не было. с нетерпением ждем дальнейших частей.
0
Ссылки для того и существуют что бы можно было ими пользоваться, и к пиару ни какого отношения не имеет. Блин да что всем вечно какие то пиары кажутся. Заинтересован ли я в посещении моего сайта — конечно, в этом нет ни чего плохого.
Тема гита действительно популярна, но и не панацея, но меня зацепил гит, так как по моему он реально удобен среди децентрализованных систем контроля версий. Раньше приходилось на работе иметь дело с ClearCase, мощная штука, и удобная когда хорошо настроенная, но сложная и централизированная, и отсюда куча неудобств, так вот если сравнивать клеркейс и гиг, я бы посоветовал гит.
Я могу с вами поспорить на ящик сникерсов ;) что моя статья это не перевод, а полностью само-писная по личному опыту, и исходя из опыта написал то с чем чаще всего приходилось сталкиваться. И к каким-либо переводам она не относится.
Тонкости, тонкости — это вещь сугубо индивидуальная, и статьями это не описать и не покрыть, так как у кого-то тонкостями называются ньюансы при мерже или при черепиках, а у кого-то в чем-то другом, я в этой статье обращаю больше внимание на конфигурацию. Я лично сторонник избегать тонкостей при возможности… ;)
0
строго говоря, я не против даже пиара. и гит — достаточно актуальная тема.
но просто пойми простой момент. намного удобнее прочитать статью без хождений по ссылкам. плюс, один сайт может умереть в любой момент (как projects.org.ua, например ;) ), а если статья будет _физически_ размещена на нескольких ресурсах — она не пропадет…
ну кто тебе мешает разместить (да даже тупо скопипастить) статью сюда и где-нить разместить линк в теле? лень? не верю! ты и так уже наваял много слов. так чего тогда? я могу сделать только один вывод — тупой сеошный пиар. за то и нападаю. как и на того кренделя с линком на линк на хабр нападал. статья и материал — полезные. но форма подачи никуда не годится.
0
у тебя много заблуждений, во всяком случае относительно меня, щас поясню
projects.org.ua не умер, он попросту переехал на новый домен uschema.com, как раз для того что бы быть доступным, так как домены официально воруют, у меня уже украли dp.org.ua и ledi.org.ua. Так что твои выводы как минимум не имеют оснований, без обид. После переезда на новый домен даже база вся осталась прежняя, и юзера итд… И единственное что изменилось, так это обновился движок форума и в БД обновил ссылки на новый сайт.
— пиаром я не страдаю, хотя и люблю кидать ссылки на свой сайт, и это нормально для любого хозяина сайта, куда намного ненормальнее кидать ссылки на чужой сайт имея при этом свой. Тут все ж ясно.
— Пиаром не страдаю, так как главное — я не зарабатывал на сайте (в отличии от этого сайта) до прошлой недели, хоть и хочется, и по этому только щас начал двигаться, так как хватит быть альтруистом, люди это ни когда не ценили и не оценят.
— лень тут не причем, это принцип, если мне нужно будет что-то важное всем донести, вот тогда я буду делать копи-паст, а в данном случае это как минимум излишне. Я уже делал сюда несколько своих копи-пастов, что? Один из ярких примеров — это оповещение про STM32F4 (которых благодаря буйному обсуждению уже даже продаваться начал в космодромах и прочих) — как результат ни одной благодарности за извещение, это даже не обида, это полное непонимание что творится… Хотя за менее полезные статейки — репутация вся в плюсах, так что из за отсутствия логики и благодарности я не хочу этого делать.
— да и вообще, я не собираюсь преклоняться этому сайте как бы хорош он не был, у меня есть свой сайт и лучше буду заниматься им, и вкладывать статьи свои в него…

что касабельно предыдущей статьи — во прошли бы по ссылке и нашли бы ее, а так вам же лень… пиары кажутся… ладно, пусть дальше кажутся, людям свойственно иметь стадное мнение, я даже подогрею почву для этого — Работа с Git, часть1 – Введение
0
кстате.
Может моя новая статья вам поможет… :)
эээ… а где предыдущие статьи, посвященные гиту, размещенные здесь? я не видел… %)
0
Давно используем perforce. Бесплатный на два пользователя. Так что если выбираете систему контроля версий то посмотрите и на нее.
Со своей стороны замечу, что программы написанные с использованием VCS отличаются от написанных без оных. Чем не могу сказать, но что-то в них есть такое — красивое.
0
А что в нем хорошего? Судя по сравнениям, он не отличается ни децентрализованностью, ни простотой изучения. Из плюсов самого перфорса помню только производительность, но для двух юзеров это неактуально. Да и закрытый он. И платить придется при желании подключить к разработке кого-то еще.
Из централизованных для дома ИМХО куда лучше SVN — открытый и простой.
0
Каждый инструмент хорош для своего применения. У нас perforce используется именно как централизованная VCS. Для дома конечно не так актуально, но возможно пригодится легкость ведения ветвей и их слияния.
Открытый-закрытый для дома не имеет никакого значения, да и вообще открытость кода то же не бог весть какое преимущество в этом случае. Я думаю мало кто полезет копаться в коде VCS, для построения своих примочек, лучше использовать API.
0
Вот я и спрашиваю — чем хорош? Чем не устроил, например, SVN?
У нас perforce используется именно как централизованная VCS.
Тогда, вероятно, двух юзеров недостаточно и оно становится платным?
Открытый-закрытый для дома не имеет никакого значения
Смотря для кого. Значение идеологическое, кроме того, SVN несколько дешевле, если более 2 юзеров)
но возможно пригодится легкость ведения ветвей и их слияния.
Легче, чем в SVN? Ну в SVN говорят сливать ветви — большой геморрой, но отличается ли в этом перфорс? И как оно в этом плане в сравнении с mercurial или git, в которых, говорят, слияние очень простое и удобное?
0
Честно говоря, не вижу необходимости использовать svn даже для домашнего централизованного применения. Локальные коммиты, удобство ведения множества бранчей, удобство сливания бранчей и портирования изменений между ними (cherry pick) дополненое скоростью работы делают git весьма предпочтительным инструментом даже для однопользовательского режима.
0
Об этом уже наслышан. Но тут меня интересует SVN vs P4. Да и мне в данный момент централизованный вариант больше нравится. Разве что было бы неплохо некоторые РК коммитить одновременно в репозиторий на гуглькоде и в локальный. Бранчами не пользуюсь, коммиты и так локальные (за исключением тех, что на гуглкод).

И почему именно git? Mercurial все это тоже умеет.
0
Mercurial даже Торвальдс хвалит так как с Mercurial-ом он имел большой опыт, но в тоже время Mercurial платный, хотя для России… )))
0
Платный разве? Я думал он тоже открытый. И в сравнении SVN/git/hg/P4 ЕМНИП платный был только P4.
0
хм, точно, GPL, перепутал значит…
пардон за дезинформацию, память подвела :)
0
Он bitkeeper хвалил, помнится.
0
Совершенно ничего не мешает использовать git как централизованный.

Не только mercurial это умеет. Есть еще, как минимум, bazaar. git удобнее просто потому, что для него поддержка в том же еклипсе лучше и активнее используется (а значит более вылизана на предмет багов). Ну и github, конечно.
0
пардон, а как это git можно использовать как централизованный?
в нем разве такое заложено?
первый раз слышу…
0
Не то, чтоб совсем централизованный, но аналогичный централизованным системам workflow на нем организовать не проблема. Как и на mercurial'е, впрочем. В этом плане распределенные VCS гибче.
0
… так и аналогичный централизованному тоже не получится, так как точка объединения некого централизирования это мерж, причем даже не локальный, а в репозитории и не иначе. Если я все верно понимаю, то следовательно, он не может быть централизованным, поправьте плз если где-то ошибаюсь.
во всяком случае я сужу по опыту работы с clearcase, который только централизированный.
0
Любому репозиторию можна указать (условно) «удаленного мастера». Тогда по push изменения будут попадать из локального репозитория в удаленный. С CC не работал, но если сравнивать, скажем, с svn, то сценарий и поведение очень похожи (ну +локальные бранчи и коммиты у git, понятное дело).
0
Мерж всегда можно сделать локально. Вот тут описано как такое делается. Если в конце этого сценария добавить push, то получится, как раз, локальный мерж с последующей заливкой.

То, что вы описали (мерж только в удаленном репозитории) это из особенностей accurev-а, которая создает невероятное количество головняка в реальной жизни.
0
Мерж кстати и в SVN локальный. Только там это необходимый этап работы — обновились из репозитория, слили свои изменения с тамошними, только после этого можно залить обратно.
0
А, собственно, в чем проблема? Договариваемся, что вот этот репозиторий у нас «главный», а все остальные создаем от него.
0
Согласен, я частенько его тоже для одно-пользовательского использую, что бы потом было легко найти где же случаем накосячил костылей…
уже несколько раз выручало и экономило много времени.
0
Для кода, в большинстве случаев слияние и разрешение конфликтов в p4 сводится к просмотру кода получившегося после обработки merge tools. Хуже конечно со всякими бинарными файлами типа word-документов и прочего. Тут уже без человека не обойтись.
Насчет платности — эффективность предприятия измеряется прибылью, а прибыль это и затраты времени в том числе. А отсюда вытекает скорость работы с инструментом, сэкономив на бесплатном 20 тыс. одномоментно, получим потери 100 тыс. на обучении и обходе багов. Вообщем все относительно.
0
Все верно, открытость и бесплатность это не панацея и не нужно ставить во главе всего. ибо время важнее. Но у открытых систем есть большой бонус которого лишены закрытые продукты — скорость реакции закрытия багов и скорость написания новых фич, следовательно на открытых системах больше вкусностей. Что мы и можем наблюдать, смотря как стремительно развиваются опен-сорс продукты. Но время экономить нужно, так это самое ценное, это наша жизнь.
0
Ну здесь по большей части обсуждаются вопросы любительского использования. А тут актуальны цена и доступность сторонних онлайн-репозиториев. Для P4 я таких вообще не знаю.
0
получим потери 100 тыс. на обучении и обходе багов.
Гм, если верить этому, то в плане обучения Р4 еще хуже гита. Багами тот же SVN вроде особо не страдает, а вот вопрос слияния бранчей — уже существенней. А различия в скорости работы существенную роль в таких условиях играют?
Для кода, в большинстве случаев слияние и разрешение конфликтов в p4 сводится к просмотру кода получившегося после обработки merge tools.
В SVN так не получается?
0
Скорость существенную роль играет — очень часто заказчик хочет получить фичу «позавчера», но готов заплатить за это кучу бабок. В этом случае делается branch под него и правится код. И таких branch в проекте бывает тащится до десятка. По мере возможности они сливаются в релиз и вот тут без хорошего resolv никак не обойтись, и p4 нас пока ни разу не подвел.
SVN использовал очень мало и не могу сказать как там делается resolving.
Кстати такой вопрос — в GT появилась опция переименования файлов и каталогов?
0
Скорость существенную роль играет — очень часто заказчик хочет получить фичу «позавчера», но готов заплатить за это кучу бабок. В этом случае делается branch под него и правится код.
Ну это опять же про бранчинг (и если верить любителям git'а — он в этом плане всех заруливает), а я в данном случае спрашивал именно про скорость выполнения операций — таких как коммит или апдейт (в терминах SVN), точнее про ее существенность.
0
Моя твоя не понимай — сама операция, например принятия изменений, занимает очень мало времени. На моей памяти больше 5 секунд для двух-трех десятков файлов никогда не было.
0
Просто единственное, что я помню из сравнения SVN и P4 (от авторов самого P4) — это то, что P4 шустрее работает. Они на это изрядно упирали.

И еще, P4 сам слияние проводит, или оно делается прилагаемой к нему утилитой для 3-way merge? (Собсна, из-за этой утилиты я про него и узнал — про нее немало положительных отзывов, и ее можно интегрировать в TortoiseSVN).
0
этак мы в глубины p4 уйдем, утилит этих немерено. Если вам надо решить какую-то задачу, то вы идете на perforce.com ищете там ПО под свою задачу. Пока ни разу чего-то своего не требовалось. Все оттуда качали, от Eclips до Delphi :)
0
В git-е обе операции выполняются быстро. svn субъективно делает это медленнее, но врядли эта разница существенна.
0
siy@stan:~> git
...
The most commonly used git commands are:
...
   mv         Move or rename a file, a directory, or a symlink
...
0
Большое спасибо.
0
Это один из возможных вариантов ведения сорсов. Альтернативой является классический подход — бранч на релиз, а транке текущая разработка. В таком случае отпадает необходимость мержить много бранчей в транк. Фиксы делаются в бранче и бекпортятся в транк (можно избирательно замержить). В git-е на подобные случаи есть еще rebase, тогда проблема мержа фиксов вообще отпадает.
0
сэкономив на бесплатном 20 тыс. одномоментно, получим потери 100 тыс. на обучении и обходе багов.
Увы, платность не гарантирует ни экономии ни отсутствия багов. И наоборот, бесплатность вовсе не обязательно приводит к потерям и необходимости обходить баги. Скорее наоборот. Широко распространенный фри софт зачастую более вылизан сугубо по причине широкой user base и огромного числа людей, которые эти баги ловят и фиксят. С обучением все еще интереснее. Скажем, навык использования git или svn я могу поставить в требованиях кандидату на позицию и смело гонять его по всем вопросам на интервью. А знание какого-нибудь accurev могу только в список желательных добавить. И когда человек выйдет на работу его придется учить с вероятностью много девяток после запятой, потому как для подавляющего большинства даже это название не знакомо. О багах и скорости их исправления у разных контор это вообще отдельная больная тема. Кто реально сталкивался, тот поймет о чем я.
0
Как это связано с электроникой, зачем это тут?
-1
  • avatar
  • Urvin
  • 26 февраля 2012, 11:21
VCS полезны не только для управления программными кодами, но и практически для любых разрабатываемых документов, включая радиотехнические (платы, схемы и т.д.), их даже некоторые писатели используют для текстов книг.
Кроме того, сообщество имеет уклон в конструкции на программно-управляемых микросхемах (МК, ПЛИС и так далее), а тут уже вылазит и программирование во всей его красе.
0
понимаете ли в чем дело, современные реалии электроники стали многогранны. И действительно часть вашего вопроса имеет место быть если рассматривать электронику только как поделки на транзисторах и жесткой логике, без участия в этом процессе компьютера. Но как только вы начинаете делать чтото приблежённое к эмбеддеду, в частности с микроконтроллерами, то вы автоматически просто обязаны осознать что от программирования вам не избавиться, а следовательно некоторые моменты с программирования традиционного вам не помешало бы взять на вооружение. Вот одна из таких замечательных вещей области программирования и есть системы контроля версий.
Как это связано — да вот напрямую и связано, и более того в системах контроля версий можно хранить не только текстовые исходники но и любые бинарные. А следовательно любая как система может быть весьма продуктивно связана с системами контроля версий.
Нужная и полезная туковина, поверьте.
0
Я работаю программистом. Я делаю штуковины на микроконтроллерах, которые, в т.ч. связываются или живут внутри компьютеров. Я не то, что верю, я знаю.

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

Я тоже сейчас могу нагнать облаков про… ну пусть HTML. Это тоже будет связано с микроконтроллерами — если мы построим сетевое устройство, то им будет очень удобно управлять не через командную строку, а именно через веб-интерфейс. Веб интерфейс строится на HTML. Давайте писать статьи на тему внедрения HTML5 в микроконтроллеры! Все счастливы и рады.
-1
Епрст, да как же все это надоело, все такие умные, критики… Не хочу вас ни кого убеждать ни в чем, надоело.
В общем господа решайте, если статья была тут лишняя я сношу тему к едрени фени.
Мне в принципе фиолетово.
0
Точно так же про статью о VCS можно написать на ресурсе о программировании — мол «зачем это тут, вы тут лучше пишите как игру написать!».
VCS ничуть не менее полезна при разработке радиотехнических устройств, причем среди радиолюбителей этот класс программ гораздо менее известен.
Я, кстати, тоже писал здесь про VCS.
0
То есть о, например, gcc писать уже не стоит, поскольку он напрямую не связан с электроникой?
0
Наоборот, хорошо, что тут появляются такие статьи. Я например догадывался о существовании таких продуктов. Можно конечно сесть и погуглить, но как и при любом общем вопросе вывалится куча ненужного хлама и придется тратить кучу времени, чтоб его разгребать. А тут все подробно расписано да еще и люди, которые пользуются системой пишут свои отзывы. Экономия времени на лицо.
Хабр — тоже не панацея, и далеко не все туда ходят.
0
Пара ссылочек по теме git'а.
githowto.com/ — пошаговая обучалочка.
whygitisbetterthanx.com/ — сравнение с некоторыми другими VCS.
0
  • avatar
  • Vga
  • 26 февраля 2012, 14:34
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.