|
|
|
GIT - в чем прикол распределенности, если все равно нужен центральный сервер?
|
|||
|---|---|---|---|
|
#18+
Сколько дней читаю статью вида GIT vs SVN, вижу аргументы в пользу GIT вида "да он же децентрализованный!!!", "можно коммитить локально!". Насчет "коммитить локально, когда нет связи с центральным сервером" - а что мешает пользователю SVN писать код на своей машине, может даже создавать ветки, когда нет соединения с сервером, а потом разом все залить? Я так понимаю, что Гитовцы все равно рано или поздно должны кооперироваться, как бы долго они не делали локальные коммиты. То есть все равно рано или поздно надо делать pull. По сути, как SVN, только операции слиянии отложенные. Насчет децентрализованный - как правило, все равно используют центральный сервер для заливки боевого кода. Например, гитхаб, если я правильно понимаю, создан для таких целей - центральный сервер децентрализованного гита). Зачем тогда распределенность, если все равно центр нужен? Единственное объяснение, которое пришло в голову - если 3 человека работают над одним проектом, бывает ситуация кодового конфликта у 2-х, а третий не при чем. В случае СВН, третий все равно будет видеть конфликты других, так как все решается через сервер, хотя это ему ни к чему и мешает работе. А в случае с ГИТ, оба чувака сами, пир-ту-пир решают свои проблемы, а третий спокойно работает. Мне это кажется бредом) Но я недавно начал изучать, другого объяснения необходимости распределенности не вижу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2014, 10:36 |
|
||
|
GIT - в чем прикол распределенности, если все равно нужен центральный сервер?
|
|||
|---|---|---|---|
|
#18+
Ситуация: ты что-то у себя пишешь, а коллеги что-то закоммитили в центральный репозиторий и теперь тебе надо закоммитить свои изменения. В случае с SVN сначала нужно будет сделать Update своей локальной версии. При этом изменения с сервера накладываются на твои изменения. И всё, обратной дороги нет. Если какие-то конфликты или "что-то пошло не так", то это вселенская боль и тоска. В случае с Git/Mercurial ты спокойно коммитишь свои изменения в локальный репозиторий и потом отдельно, чинно и спокойно, делаешь мердж. Вообще без шансов потерять свою работу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2014, 11:13 |
|
||
|
GIT - в чем прикол распределенности, если все равно нужен центральный сервер?
|
|||
|---|---|---|---|
|
#18+
НахлобучПри этом изменения с сервера накладываются на твои изменения Вы имеете в виду, что мои изменения "затрутся" серверной версией? Разве не будет такого, что и мой новый код и новый код моих коллег будет присутствовать на моей машине после Update, а мне останется просто поресолвить конфликты - оставить оба кода? НахлобучВ случае с Git/Mercurial ты спокойно коммитишь свои изменения в локальный репозиторий и потом отдельно, чинно и спокойно, делаешь мердж Если заливка с сервера затирает мои изменения, тогда все понятно. Если как я писал выше, в СВН ничего не затирается, а просто приходит и код коллег и остается мой, тогда ресолвинг конфликтов и есть гитовский мердж - я просто оставляю оба кода=>сливаю коллеговский и свой код=>делаю мердж. Тогда не вижу разницы. Или все таки затираются? Я работал в CVS, SVN не знаю, но в CVS вроде как ничего не затиралось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2014, 12:56 |
|
||
|
GIT - в чем прикол распределенности, если все равно нужен центральный сервер?
|
|||
|---|---|---|---|
|
#18+
BaurzhanSВы имеете в виду, что мои изменения "затрутся" серверной версией? Разве не будет такого, что и мой новый код и новый код моих коллег будет присутствовать на моей машине после Update, а мне останется просто поресолвить конфликты - оставить оба кода?Будет так, что в файлы, которые изменены локально, добавятся изменения из репозитория. И вернуть их в состояние "до Update, но со всеми моими изменениями" нельзя. BaurzhanSЕсли заливка с сервера затирает мои изменения, тогда все понятно. Если как я писал выше, в СВН ничего не затирается, а просто приходит и код коллег и остается мой, тогда ресолвинг конфликтовЕще раз: SVN не дает права на ошибку; там нельзя откатить команду Update. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2014, 13:06 |
|
||
|
GIT - в чем прикол распределенности, если все равно нужен центральный сервер?
|
|||
|---|---|---|---|
|
#18+
НахлобучСитуация: ты что-то у себя пишешь, а коллеги что-то закоммитили в центральный репозиторий и теперь тебе надо закоммитить свои изменения. В случае с SVN сначала нужно будет сделать Update своей локальной версии. При этом изменения с сервера накладываются на твои изменения. И всё, обратной дороги нет. Если какие-то конфликты или "что-то пошло не так", то это вселенская боль и тоска. В случае с Git/Mercurial ты спокойно коммитишь свои изменения в локальный репозиторий и потом отдельно, чинно и спокойно, делаешь мердж. Вообще без шансов потерять свою работу. рукалицо:on аффтыра GIT и его адептов не научили пользоваться бренчами и merge в SVN, пичаль, пичаль! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2014, 13:11 |
|
||
|
GIT - в чем прикол распределенности, если все равно нужен центральный сервер?
|
|||
|---|---|---|---|
|
#18+
BaurzhanSНо я недавно начал изучать, другого объяснения необходимости распределенности не вижу. Блин, укроп петрушка. Единственный смысл существования git перед svn - это то, что у тебя локальная копия ВСЕГО репозитория, а не отдельных веток. Т.е. ты можешь забрать репозиторий, сесть с бункер, где нет интернетов, и при этом ходить по всяким тегам и смотреть blame и прочие хистори, не затрагивая сервер. И... все, больше никакого практического смысла существования git нет. А вот с большими проектами с кучей народу - самый главный минус SVN - это то, что он сериализирует коммиты - пока один зайчик заливает блоб на 100 метров по диалапу - все остальные сидят и втыкают. Это была вторая причина на взгромождение git-а Торвальдса просто парило все это анальное рабство на централизованный SVN сервер, лаги оного, плюс параноя. Вот он и запилил свой блекджек. Но для проекта с числом зайчиков менее 20 и быстрыми интернетами никакого смысла городить себе git нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2014, 13:17 |
|
||
|
GIT - в чем прикол распределенности, если все равно нужен центральный сервер?
|
|||
|---|---|---|---|
|
#18+
Спасибо, вроде догнал. Если я правильно понял, то Будет так, что в файлы, которые изменены локально, добавятся изменения из репозитория - это не страшно, это можно замерджить в SVN, нормальный рабочий процесс. А вот самое важное, это - И вернуть их в состояние "до Update, но со всеми моими изменениями" нельзя.. То есть, в ГИТ-е можно закоммитить свое обновление локально, потом замерджиться с коллегами, передумать делать это, а так как ГИТ все хранит децентрализованно, у себя вернуться к состоянию "без изменений от коллег", сделать фиксы багов, из-за которых, собственно, передумал мерджиться, и потом уже пофикшенную версию мерджить с кодом коллег. Правильно я понял? Ну и тогда мне интересно, а как люди в SVN работают, без права на ошибку? Получается, там если что-то залил с сервера и это мешает тебе разрабатывать дальше, например, какой-то логический конфликт с кодом коллег, придется вручную искать новый код коллег и выпиливать его? А перед Update никак нельзя сохранять текущую версию в ветку, чтобы когда надо, можно было вернуть их в состояние "до Update, но со всеми моими изменениями" ? Видимо, в SVN так и решают проблему "нет права на ошибку"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2014, 13:27 |
|
||
|
GIT - в чем прикол распределенности, если все равно нужен центральный сервер?
|
|||
|---|---|---|---|
|
#18+
nolocky аффтыра GIT и его адептов не научили пользоваться бренчами и merge в SVN, пичаль, пичаль! то есть здесь я правильно написал - BaurzhanSА перед Update никак нельзя сохранять текущую версию в ветку, чтобы когда надо, можно было вернуть их в состояние "до Update, но со всеми моими изменениями"? Видимо, в SVN так и решают проблему "нет права на ошибку"? Короче, Нахлобуч говорит, что "вернуть их в состояние до Update, но со всеми моими изменениями" нельзя в СВН, вы видимо, имеете в виду, что просто делай бранч перед заливкой и все. Но Нахлобуч, видимо, имеет в виду, что в ГИТ-е вообще не надо делать бранч чтобы сохранить состояние, там и так все хранится. бл*, е***ь в голове каша ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2014, 13:32 |
|
||
|
GIT - в чем прикол распределенности, если все равно нужен центральный сервер?
|
|||
|---|---|---|---|
|
#18+
nolocky, Единственный смысл существования git перед svn - это то, что у тебя локальная копия ВСЕГО репозитория, а не отдельных веток.. А можно на этом месте поподробней, у меня и на SVN есть ВЕСЬ код проекта - и мой, и других участников разработки. Вообще говоря, у меня есть та версия, которая есть на сервере, после каждого апдейта. Или Вы имеете в виду, что у меня есть только транк всего кода(основная ветка), а всяких бранчей от коллег у меня нет? Но нахрена мне бранчи коллег, если у меня есть локальная мастер ветка, а она у меня есть, все, мне больше ничего не надо вроде, нет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2014, 13:45 |
|
||
|
GIT - в чем прикол распределенности, если все равно нужен центральный сервер?
|
|||
|---|---|---|---|
|
#18+
BaurzhanSНо нахрена мне бранчи коллег, если у меня есть локальная мастер ветка, а она у меня есть, все, мне больше ничего не надо вроде, нет?Ну типа если не надо лично вам, то это еще не значит, что не надо никому ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2014, 15:09 |
|
||
|
GIT - в чем прикол распределенности, если все равно нужен центральный сервер?
|
|||
|---|---|---|---|
|
#18+
nolockyаффтыра GIT и его адептов не научили пользоваться бренчами и merge в SVN, пичаль, пичаль!И как они тебе тут помогут? Предлагаешь каждому разработчику персональный бранч заиметь? И потом всё это в разные стороны мержить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2014, 15:49 |
|
||
|
GIT - в чем прикол распределенности, если все равно нужен центральный сервер?
|
|||
|---|---|---|---|
|
#18+
BaurzhanSТо есть, в ГИТ-е можно закоммитить свое обновление локально, потом замерджиться с коллегами, передумать делать это, а так как ГИТ все хранит децентрализованно, у себя вернуться к состоянию "без изменений от коллег", сделать фиксы багов, из-за которых, собственно, передумал мерджиться, и потом уже пофикшенную версию мерджить с кодом коллег. Правильно я понял?Абсолютно. BaurzhanSНу и тогда мне интересно, а как люди в SVN работают, без права на ошибку?Один из способов -- сделать Patch с текущими изменениями, положить его рядом и потом начинать процесс апдейта. Если что-то отваливается, то делать реверт, обновляться начисто и потом накладывать свой патч. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2014, 15:51 |
|
||
|
GIT - в чем прикол распределенности, если все равно нужен центральный сервер?
|
|||
|---|---|---|---|
|
#18+
BaurzhanSnolocky аффтыра GIT и его адептов не научили пользоваться бренчами и merge в SVN, пичаль, пичаль! то есть здесь я правильно написал - BaurzhanSА перед Update никак нельзя сохранять текущую версию в ветку, чтобы когда надо, можно было вернуть их в состояние "до Update, но со всеми моими изменениями"? Видимо, в SVN так и решают проблему "нет права на ошибку"? Короче, Нахлобуч говорит, что "вернуть их в состояние до Update, но со всеми моими изменениями" нельзя в СВН, вы видимо, имеете в виду, что просто делай бранч перед заливкой и все. Но Нахлобуч, видимо, имеет в виду, что в ГИТ-е вообще не надо делать бранч чтобы сохранить состояние, там и так все хранится. бл*, е***ь в голове каша Нахлобуч напрочь некомпетентен, начнем с этого, и водит тебя за нос. В git можно сделать "коммит" в свою локальную копию репозитория, но в центральную все равно придется делать merge и разрешать конфликты. На кой хрен делать коммит в локальную копию - я без понятия, это все равно что бекап винта сделать на тот-же винт: глупо и бессмысленно, от потери винта это не спасет, разве что можно надеяться, что можно будет восстановиться на предыдущее состояние. Обновиться из центральной, чтоб не развалить свои правки и не разбирать конфликты - аналогично, не получится - чудесов нет, все они прыгают вокруг команды patch, хоть как саму VCS не называй. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2014, 16:16 |
|
||
|
GIT - в чем прикол распределенности, если все равно нужен центральный сервер?
|
|||
|---|---|---|---|
|
#18+
BaurzhanSnolocky, Единственный смысл существования git перед svn - это то, что у тебя локальная копия ВСЕГО репозитория, а не отдельных веток.. А можно на этом месте поподробней, у меня и на SVN есть ВЕСЬ код проекта - и мой, и других участников разработки. Вообще говоря, у меня есть та версия, которая есть на сервере, после каждого апдейта. Или Вы имеете в виду, что у меня есть только транк всего кода(основная ветка), а всяких бранчей от коллег у меня нет? Но нахрена мне бранчи коллег, если у меня есть локальная мастер ветка, а она у меня есть, все, мне больше ничего не надо вроде, нет? Бранч нужен для локализации (изоляции) изменений. А для чего их друг от друга изолировать - это еще тот вопрос, каждая команда решает его сама - есть такие, что бренчуют по девелоперам, есть - по задачам в трекере, есть по проектам, короч, тут кто во что гаразд. Что такое локальная мастер ветка - без понятия, в SVN нет такого понятия. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2014, 16:18 |
|
||
|
GIT - в чем прикол распределенности, если все равно нужен центральный сервер?
|
|||
|---|---|---|---|
|
#18+
Нахлобучnolockyаффтыра GIT и его адептов не научили пользоваться бренчами и merge в SVN, пичаль, пичаль!И как они тебе тут помогут? Предлагаешь каждому разработчику персональный бранч заиметь? И потом всё это в разные стороны мержить? Обычно именно так и происходит - бранч заводится или под задачу, или под девелопера. Цель - не разрушать друг другу билды. Если у вас не так - тогда ой, см. выше про некомпетентность. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2014, 16:19 |
|
||
|
GIT - в чем прикол распределенности, если все равно нужен центральный сервер?
|
|||
|---|---|---|---|
|
#18+
О, ща профессионалы нас всех на место-то поставят! nolockyВ git можно сделать "коммит" в свою локальную копию репозитория, но в центральную все равно придется делать merge и разрешать конфликты.Ты понимаешь, чем концептуально различаются "merge before commit" и "commit before merge"? nolockyНа кой хрен делать коммит в локальную копию - я без понятия, это все равно что бекап винта сделать на тот-же винт: глупо и бессмысленно, от потери винта это не спасет, разве что можно надеяться, что можно будет восстановиться на предыдущее состояние.Локальные коммиты позволяют "сохраняться" гораздо чаще и дробить работу на когерентные куски. Так и историю проще отслеживать, и, если что, откатывать изменения. nolockyОбновиться из центральной, чтоб не развалить свои правки и не разбирать конфликты - аналогично, не получится - чудесов нет, все они прыгают вокруг команды patch, хоть как саму VCS не называй.В распределенных системах нельзя непреднамеренно потерять свою работу (и развалить свои правки) во время слияния. Поработай с Mercurial, что ли, на досуге. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2014, 17:48 |
|
||
|
GIT - в чем прикол распределенности, если все равно нужен центральный сервер?
|
|||
|---|---|---|---|
|
#18+
nolockyОбычно именно так и происходит - бранч заводится или под задачу, или под девелопера. Цель - не разрушать друг другу билды.Ну вот есть у нас задача, под нее ветка, и в эту ветку коммитят дизайнер и девелопер. Получаем ровно ту же ситуацию: я не могу сделать локальный Update не рискуя потерять свои изменения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2014, 17:49 |
|
||
|
GIT - в чем прикол распределенности, если все равно нужен центральный сервер?
|
|||
|---|---|---|---|
|
#18+
НахлобучНу вот есть у нас задача, под нее ветка, и в эту ветку коммитят дизайнер и девелопер. Получаем ровно ту же ситуацию: я не могу сделать локальный Update не рискуя потерять свои изменения. По логике тех, кто знает только SVN, вы должны были сделать 2 ветки: для себя и для дизайнера, и иметь счастье мерджиться чтобы проверить любое изменение дизайна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2014, 18:45 |
|
||
|
GIT - в чем прикол распределенности, если все равно нужен центральный сервер?
|
|||
|---|---|---|---|
|
#18+
BaurzhanS, Например, Git корректно понимает различные комбинации переименований папок, перемещений и переименований файлов, да еще и с внесением изменений в часть из них. SVN при этом выдаст Tree Conflict, с которым разрабочики будут мучатся очень долго... По поводу децентрализации. У вас может быть несколько удаленных серверов , что в SVN исключено. В том числе с разными ветками на разных серверах. В Git принципиально другая внутренняя система храниния информации. SVN хранит различия файлов, привязанные к именам файлов. Git хранит различия снимков папок (snapshot) привязанные к хешсуммам содержимого блоков, это система принципиально более высокого уровня. А вообще, с Git надо поработать на серьезном проекте, тогда поймете его преимущества, а то так и будете думать, что лучше SVN ничего нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2014, 18:53 |
|
||
|
GIT - в чем прикол распределенности, если все равно нужен центральный сервер?
|
|||
|---|---|---|---|
|
#18+
HoBTIDНахлобучНу вот есть у нас задача, под нее ветка, и в эту ветку коммитят дизайнер и девелопер. Получаем ровно ту же ситуацию: я не могу сделать локальный Update не рискуя потерять свои изменения. По логике тех, кто знает только SVN, вы должны были сделать 2 ветки: для себя и для дизайнера, и иметь счастье мерджиться чтобы проверить любое изменение дизайна.Вообще-то, "по логике" надо бы на каждое изменение дизайна (или реалиации функции) делать отдельную ветку, а в конце все ветки должны быть слиты в финальную... И при этом следует не забывать, что часть из этих веток в "финал" никогда не пойдет... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2014, 18:59 |
|
||
|
GIT - в чем прикол распределенности, если все равно нужен центральный сервер?
|
|||
|---|---|---|---|
|
#18+
sphinx_mvВообще-то, "по логике" надо бы на каждое изменение дизайна (или реалиации функции) делать отдельную ветку, а в конце все ветки должны быть слиты в финальную... И при этом следует не забывать, что часть из этих веток в "финал" никогда не пойдет...Прекрасный совет, как не надо делать. Впрочем так никто и не делает, из-за слишком большой трудоемкости данного метода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2014, 23:04 |
|
||
|
GIT - в чем прикол распределенности, если все равно нужен центральный сервер?
|
|||
|---|---|---|---|
|
#18+
HoBTIDBaurzhanS, Например, Git корректно понимает различные комбинации переименований папок, перемещений и переименований файлов, да еще и с внесением изменений в часть из них. SVN при этом выдаст Tree Conflict, с которым разрабочики будут мучатся очень долго...SVN, вообщем-то, не стоИт на месте . Приведена ссылка на черновик документации версии 1.7 . Актуальная - 1.8 . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2014, 23:09 |
|
||
|
GIT - в чем прикол распределенности, если все равно нужен центральный сервер?
|
|||
|---|---|---|---|
|
#18+
HoBTIDsphinx_mvВообще-то, "по логике" надо бы на каждое изменение дизайна (или реалиации функции) делать отдельную ветку, а в конце все ветки должны быть слиты в финальную... И при этом следует не забывать, что часть из этих веток в "финал" никогда не пойдет...Прекрасный совет, как не надо делать. Впрочем так никто и не делает, из-за слишком большой трудоемкости данного метода."Проблемы индейцев шерифа не волнуют" (с) Невменяемые трудности подобной методики на SVN - это к Git'у совершенно никаким боком не относится. Потому что нет никакой трудоемкости в этом при работе с Git. То есть - ВООБЩЕ! :) Три-четыре варианта реализации некоторого нетривиального функционала - вполне реальная ситуация. И иметь ветки под каждый из вариантов - очень неплохо рулится. С использованием Git. Переключение с ветки на ветку - пальцы даже не надо мочить. Даже коммитить текущую работу перед этим нет необходимости. "Увлекательное чтиво", например, тут ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2014, 23:55 |
|
||
|
GIT - в чем прикол распределенности, если все равно нужен центральный сервер?
|
|||
|---|---|---|---|
|
#18+
НахлобучnolockyОбычно именно так и происходит - бранч заводится или под задачу, или под девелопера. Цель - не разрушать друг другу билды.Ну вот есть у нас задача, под нее ветка, и в эту ветку коммитят дизайнер и девелопер. Получаем ровно ту же ситуацию: я не могу сделать локальный Update не рискуя потерять свои изменения. Ты просто дурак или прикалываешься? Все твои несовместимые апдейты пойдут как конфликты, сиди себе и через kdiff3 какой разруливай, потерянный ты наш. На предыдущий твой пост я не стал отвечать, там одно ослоумие твое, откровенно лень проводить ликбез. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2014, 01:18 |
|
||
|
GIT - в чем прикол распределенности, если все равно нужен центральный сервер?
|
|||
|---|---|---|---|
|
#18+
HoBTIDBaurzhanS, Например, Git корректно понимает различные комбинации переименований папок, перемещений и переименований файлов, да еще и с внесением изменений в часть из них. SVN при этом выдаст Tree Conflict, с которым разрабочики будут мучатся очень долго... По поводу децентрализации. У вас может быть несколько удаленных серверов , что в SVN исключено. В том числе с разными ветками на разных серверах. В Git принципиально другая внутренняя система храниния информации. SVN хранит различия файлов, привязанные к именам файлов. Git хранит различия снимков папок (snapshot) привязанные к хешсуммам содержимого блоков, это система принципиально более высокого уровня. А вообще, с Git надо поработать на серьезном проекте, тогда поймете его преимущества, а то так и будете думать, что лучше SVN ничего нет. Правда твоя, переименование файлов и особенно каталогов - это тотальная попоболь в случае SVN. Чудикам с java, которые создают over 25 каталогов на каждый чих, и потом норовят рефакторить - SVN противопоказан категорически, это непреложный факт. Впрочем, петь дифирамбы git-у в части совсем уже радужной поддержки переименований файлов я бы тоже не стал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2014, 01:20 |
|
||
|
|

start [/forum/topic.php?fid=16&msg=38658562&tid=1341330]: |
0ms |
get settings: |
7ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
158ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
73ms |
get tp. blocked users: |
1ms |
| others: | 200ms |
| total: | 471ms |

| 0 / 0 |
