LINUX.ORG.RU

10 советов и приемов для начинающих по использованию Git

 ,


0

0

В Git есть так много возможностей и вариантов, что это ошеломляет начинающих. Автор статьи составил список советов и приемов, которые помогут им лучше управлять Git проектами.

>>> Подробности

★★★

Проверено: maxcom ()

Ответ на: комментарий от tailgunner

>> С SVN?

Боже мой, ей еще кто-то пользуется? O_O

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

Распределённость - это, в принципе достоинство. Но во-первых, она нужна не всегда и не везде, а во-вторых, влечёт усложнение системы и появление новых проблем.

hobbit ★★★★★
()
Ответ на: комментарий от kraw

> Просто GIT предназначен для работы в определенных условиях. А когда у тебя один единый репозиторий, то какой смысл?

+1024

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

> Представьте себе, пользуется очень много народу. Когда нужен результат работы,

Когда нужен результат, пользуются подходящими инструментами. Я вижу ровно одну ситуацию, где SVN имеет преимущество перед современной системой - большой унаследованный репозиторий c хитрой структурой (если что, я пользовался SVN с версии 0.14 до 1.2.x).

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

И что плохого в крутых инструментах? А насчет моды - это к гитофагам, я использую Mercurial.

Распределённость - это, в принципе достоинство.

Ты либо не пользовался DVCS, либо не понял, зачем она нужна. Ее основной пойнт вовсе не в распределенности и наличии кучи репозиториев..

tailgunner ★★★★★
()
Ответ на: комментарий от sv75

> Для первой встречи с системами контроля версий он не очень подходит, мне кажется.

А для тех, кто знаком различными VCS?

Мне в GIT не нравится паршивая (так говорят пользователи) поддержка Windows. В этом отношении тот же Mercurial весьма хорош.

andreyu ★★★★★
()
Ответ на: комментарий от Voker57

> в условиях DVCS любая другая схема нежизнеспособна

Во-первых, жизнеспособна (доказано BK); во-вторых, можно сделать как в Mercurial - есть нормальные номера ревизий - они валидны только локально, но работа в основном происходит как раз локально.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Во-первых, жизнеспособна (доказано BK);

Ссылка про номера в BK есть? А то у них на сайте одна чушь маркетоидная.

во-вторых, можно сделать как в Mercurial - есть нормальные номера ревизий - они валидны только локально, но работа в основном происходит как раз локально.

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

Voker57 ★★
()
Ответ на: комментарий от tailgunner

>Git предназначен для работы Линуса. Если ты не Линус (и не хочешь им быть) - он тебе не нужен.

Т. е. ты всерьез полагаешь, что кроме Линуса он никому не нужен?

Такой, что у тебя автоматически имеется свой бранч, и ты можешь редактировать коммиты.

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

kraw ★★★★
()
Ответ на: комментарий от tailgunner

>И что плохого в крутых инструментах?

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

kraw ★★★★
()
Ответ на: комментарий от kraw

>> Git предназначен для работы Линуса. Если ты не Линус (и не хочешь им быть) - он тебе не нужен.

Т. е. ты всерьез полагаешь, что кроме Линуса он никому не нужен?

Да.

Такой, что у тебя автоматически имеется свой бранч, и ты можешь редактировать коммиты.

И для чего это нужно, при наличии единственного репозитория?

«Я не могу ответить тебе в терминах Зодиака^Wрепозитория, потому что Зодиак^Wрепозиторий тут не причем.» почти (с)

Редактировать коммиты нужно, если ты разбиваешь свою работу на относительно небольшие независимые куски, и не всегда всё делаешь с первого раза. Если не разбиваешь или не ошибаешься, тебе это не нужно.

И что плохого в крутых инструментах?

В сложности использования.

Ты, кажется, судишь о DVCS по Git (который и правда сделан инопланетянами для порабощенных ими землян). А на самом деле, в DVCS нет никаких концепций, котороые в том или ином виде отсуствуют в централизованных VCS. Mercurial в использовании не сложнее SVN, то же и для Bazaar-NG (хотя последний раз, когда я смотрел, он был неюзабельно тормознут).

tailgunner ★★★★★
()

IMHO, новичку можно смело ставить git cola. Очень упрощает жизнь.

Vit ★★★★★
()
Ответ на: комментарий от Voker57

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

Как это бесполезны?? Есть ветка, есть номер ревизии в ней. Если я кому-то говорю номер ревизии, то у него есть доступ к соответствующей ветке, иначе и номер ему ни к чему.

А в Git — нечитабельная каша из символов. К тому же, хэши бесполезны относительно друг друга.

sinister666 ★★
()
Ответ на: комментарий от sinister666

> Как это бесполезны?? Есть ветка, есть номер ревизии в ней. Если я кому-то говорю номер ревизии, то у него есть доступ к соответствующей ветке, иначе и номер ему ни к чему. А в Git — нечитабельная каша из символов. К тому же, хэши бесполезны относительно друг друга.

Эта «нечитаемая каша из символов» криптографически гарантирует, что ты указываешь на конкретный коммит и всю стоящую за ним историю. А названия веток и номер ревизии легко можно сменить, не меняя содержания, и наоборот. Они, как правильно заметили выше, имеют значение только локально.

Voker57 ★★
()
Ответ на: комментарий от Voker57

>Эта «нечитаемая каша из символов» криптографически гарантирует, что ты указываешь на конкретный коммит и всю стоящую за ним историю.

Да я, в общем-то, в курсе. И вся эта каша должна быть «под капотом». Хотя, кончено, можно корчить из себя робота и оперировать неудобными величинами.

Они, как правильно заметили выше, имеют значение только локально.


Сдается мне, что замечания вы читаете лишь выборочно.

sinister666 ★★
()
Ответ на: комментарий от tailgunner

А на самом деле, в DVCS нет никаких концепций, котороые в том или ином виде отсуствуют в централизованных VCS

Вы наверное судите о DVCS по Mercurial, если в нём нет нормальных бранчей и до сих пор пишется бредятина типа:

pulling from URL
searching for changes
abort: repository is unrelated

это не значит что во всех DVCS так же :)

Eshkin_kot ★★
()
Ответ на: комментарий от tailgunner

и да, про --force после которого история выглядит как появившаяся «из ничего»:

changeset:   1:57ddb1d39687
tag:         tip
parent:      -1:000000000000

я слышал :)

Eshkin_kot ★★
()
Ответ на: комментарий от Eshkin_kot

В других еще хуже (ну может быть кроме darcs, но его считать не будем).

anonymous
()
Ответ на: комментарий от Eshkin_kot

а «из чего» оно должно было появится?

anonymous
()
Ответ на: комментарий от sinister666

> Есть ветка, есть номер ревизии в ней. Если я кому-то говорю номер ревизии, то у него есть доступ к соответствующей ветке, иначе и номер ему ни к чему.

Это удобно когда у тебя две-три ветки. А когда у каждого разработчика несколько своих - возникает путаница. Но важные для всех ветки можно назвать именами.

А в Git — нечитабельная каша из символов.

Меня не напрягало, потому что в больших проектах столько коммитов в день, что номер всё равно не запоминаемым делается. Кстати, чтобы было удобнее - можно всять 4-6 первых символов - их в 99.9% случаев хватает для уникальной идентификации комита.

К тому же, хэши бесполезны относительно друг друга.

Не понял. Можно пояснить?

alt-x ★★★★★
()
Ответ на: комментарий от tailgunner

>Ты, кажется, судишь о DVCS по Git (который и правда сделан инопланетянами для порабощенных ими землян). А на самом деле, в DVCS нет никаких концепций, котороые в том или ином виде отсуствуют в централизованных VCS. Mercurial в использовании не сложнее SVN, то же и для Bazaar-NG (хотя последний раз, когда я смотрел, он был неюзабельно тормознут).

Hg-фанбой детектед. :) Может быть несколько лет назад Mercurial и был удобнее git, но сейчас - в чём разница? Даже большинство повседневных команд одинаково называются.

Подозреваю, что у Mercurial два преимущества: лучшая интеграция с svn, и лучше плагин для Eclipse. Нужно соответсвенно тем, кто использует svn и Eclipse.

У git преимущества свои - например, более удобный rebase. Но, по большому счёту, для многих проектов и стилей работы hg и git одинаково удобны.

alt-x ★★★★★
()
Ответ на: комментарий от kraw

>>Такой, что у тебя автоматически имеется свой бранч, и ты можешь редактировать коммиты.

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

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

alt-x ★★★★★
()
Ответ на: комментарий от Sphinx

git круче всего, потому что на си и нахакать под него что-нибудь проще всего.

b4dhead
()
Ответ на: комментарий от sv75

>> Совет 1. Начинающие, не используйте git!

но иногда без него некуда деваться

kto_tama ★★★★★
()
Ответ на: комментарий от kamre

> А насколько хорошо в Git организованна работа с submodules?

А то subrepos в Mercurial до сих пор не доделаны: даже нельзя посмотреть статус рекурсивно по всему дереву subrepos.

Хм... не знаю. Но сейчас subtree допиливают. Вот то что мне нужно. Но только думаю будет через пол годика - годик.

anonymous
()
Ответ на: комментарий от tailgunner

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

И что плохого в крутых инструментах? А насчет моды - это к гитофагам, я использую Mercurial.

Ну нет. Мода это как раз Mercurial и любители питона.

Мне пофигу чем пользоваться. Перед новым проектом прошелся по всем системам. Посмотрел фичи. Выделил полезные для себя. Нашел глюки в Mercurial. Вынужден был перейти на git. Буду начинать новый проект, опять просмотрю все системы. Возможно вернусь на Mercurial. Если в нем будет полезная для меня фича и он не будет глючить, или начнет глючить Git.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.