10 советов и приемов для начинающих по использованию Git (перевод статьи на rus-linux.net)

[sash-kan]

Оригинал: "10 Git Tips and Tricks for Beginners"
Автор: Jason Gilmore
Дата публикации: June 4, 2010
Перевод: Н.Ромоданов
Дата перевода: 15 июня 2010 г.

Существует тенденция, благодаря которой новые технологии становятся катализатором внедрения в основное русло технологического развития конкретных парадигм разработок и лучших практических приемов. Назовем этот феномен "Can't Buy Me Love" ("Любовь не купить") в честь фильма 80-х годов, в котором один школьный умник для повышения собственной популярности нанимает понравившуюся ему девушку для того, чтобы она изображала его подружку. Возможно, что последним примером такого феномена является появление и использование Git - системы управления версиями, имеющей открытый код и существенно повышающей уровень формализации при управлении версиями исходного кода. Я в течение нескольких лет пользовался другими решениями, такими как системы контроля версий CVS и Subversion, но Git, как средство управления исходным кодом, более естественно вписался в мой технологический процесс.

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

источник.

[serzh-z]

Ха, почитал - ничего особенного, чего бы не было в официальном PDF. Но для столь непростой системы, как Git, лишние десять советов в качестве шпаргалки простым языком - это здорово.

[sash-kan]

столь непростой системы, как Git

не стереотип ли это?
как пользователь svn со стажем, я считаю, что — стереотип.

[serzh-z]

как пользователь svn со стажем, я считаю, что — стереотип.

Как пользователь со стажем RCS, CVS, SVN и Git (дома), скажу, что не стереотип. Возможно, что до сих пор не могу отучиться мыслить критериями первой троицы.

[sash-kan]

Как пользователь со стажем RCS, CVS, SVN и Git

ксати, только как пользователь (checkouts) или как разработчик (checkins)?
если как разработчик, то трудность понятна — мозги промыты хорошо.
мне, кстати, хорошим подспорьем послужила вычитанная где-то в начале освоения мысль: git — это vcs, совершенно отличная от других. из этого я и исходил. постарался воспринимать всё «с чистого листа». примерно как при переходе с ms/windows на gnu/linux.

и сейчас, немного освоившись с git-ом, вижу картину где-то так:
для работы пассивного checkouter-а разницы между svn и git нет вообще никакой.
для повседневной работы разработчика (в примитивном варианте использования git-а) — разница исчезающе мала.
а вот если пользоваться git-ом «на полную катушку», тогда да, разница есть. сложные задачи оказываются проще, а невозможные — вполне реализуемыми.
(под сложными подразумеваю работу с ветками. под невозможными — работу одновременно с несколькими внешними репозиториями).

[serzh-z]

ксати, только как пользователь (checkouts) или как разработчик (checkins)?

Как разработчик.

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

Возможно, ибо стаж использования RCS-подобными VCS (CVS, SVN) значительно превышает таковый для Git/Bazaar-подобных.

а вот если пользоваться git-ом «на полную катушку», тогда да, разница есть. сложные задачи оказываются проще, а невозможные — вполне реализуемыми.

Не знаю про какие именно задачи ты говоришь, но проблема с Git в том, что он использует другую идеологию. Связка "рабочий каталог - промежуточный индекс aka кеш - само хранилище" и работа с нею, лично мне, просто выносит мозг.

для работы пассивного checkouter-а разницы между svn и git нет вообще никакой.

Даже здесь она есть (если пользователь правит файлы в рабочем каталоге), ибо работа с тегами и бранчами отличается, из-за использования промежуточного индекса.

[watashiwa_daredeska]

Связка "рабочий каталог - промежуточный индекс aka кеш - само хранилище"

«самого хранилища» нет.

[serzh-z]

«самого хранилища» нет.

Дерево блобов.

[watashiwa_daredeska]

Дерево блобов.

Я не про то. Есть рабочий каталог, есть репозиторий (дерево блобов) или «промежуточный индекс aka кеш», как ты его назвал. Больше нет ничего. Нет никакого «самого хранилища». Есть куча репозиториев, как они логически организованы — это дело тех, кто ими пользуется.

P.S. А, допёр. Ты про git'овский index, в который добавляется командой git add. Ну, я не нашел ему полезного для себя применения, поэтому не пользуюсь им. :)

[serzh-z]

Есть рабочий каталог, есть репозиторий (дерево блобов) или «промежуточный индекс aka кеш»

Так вот. Индекс и дерево блобов - это не одно и тоже. Как вижу - ты тоже уже в этом запутался. =)

поэтому не пользуюсь им. :)

Это как так?

[watashiwa_daredeska]

Индекс и дерево блобов - это не одно и тоже. Как вижу - ты тоже уже в этом запутался. =)

Нет, не запутался. Я просто не понял сразу, о чем вообще речь, думал, что ты о том, что есть репозиторий у каждого разработчика, и есть некоторый «центральный», в который стекаются изменения от разработчиков и с которым все синхрятся, но это всего лишь один из возможных способов работы с DVCS.

Это как так?

commit -a и алиасы решают. У меня алиас ci (привык в свое время с svn) на commit -a. git add я использую только для новых файлов; то, что эта команда на самом деле добавляет в какой-то там индекс, мне, в общем, не важно, главное — при git ci оно попадет в репозиторий. Логика, в общем, получается неотличимая от того же SVN.

[sash-kan]

serzh-z
на самом деле index, оно же staging area, оно же «плацдарм» (это просто русский перевод термина staging area, им никто не пользуется, я привёл его из-за красоты), есть во всех vcs-ах. только он(-а|-о) скрыт от пользователя.

возьмём тот же svn.
если создан новый файл, его надо сначала «добавить» (svn add). верно?
а потом уже коммитить. вот в промежутке между add и commit изменения и находятся на этом самом «плацдарме».
если же просто внесены правки в уже добавленный файл, достаточно просто сделать коммит. никаких задержек на «плацдарме».

в git получается ровно то же самое, если к git commit добавлять опцию -a.
а чтобы её каждый раз не писать, можно сделать удобный тебе git alias.
например:
$ git config --global alias.ci commit -a
теперь команда
$ git ci
полностью идентична команде
$ git commit -a
причём, благодаря наличию --global, это будет актуально во всех репозиториях в твоём ~/

commit -a и алиасы решают. У меня алиас ci (привык в свое время с svn) на commit -a. git add я использую только для новых файлов; то, что эта команда на самом деле добавляет в какой-то там индекс, мне, в общем, не важно, главное — при git ci оно попадет в репозиторий. Логика, в общем, получается неотличимая от того же SVN.

о, не разглядел этого, прежде чем начал писать.

для работы пассивного checkouter-а разницы между svn и git нет вообще никакой.

Даже здесь она есть (если пользователь правит файлы в рабочем каталоге), ибо работа с тегами и бранчами отличается, из-за использования промежуточного индекса.

однако не согласен я с тобой. покажи, пожалуйста, на примере, каким образом наличие явного, а не скрытого «плацдарма» оказывает влияние на работу с тэгами и бранчами.

[sash-kan]

serzh-z
скорее, верно будет урезать твоё высказывание до этих слов:

работа с тегами и бранчами отличается

вот с этим я полностью согласен. потому что единственная общая черта у git-овских и, например, svn-овских и mercurial-овских бранчей и тэгов, — это только название. в git-е это совершенно иные сущности.

[serzh-z]

на самом деле index, оно же staging area, оно же «плацдарм» (это просто русский перевод термина staging area, им никто не пользуется, я привёл его из-за красоты), есть во всех vcs-ах. только он(-а|-о) скрыт от пользователя.

Отнюдь. В Git "плацдарм" - это, фактически, частичный (или полный) снепшот рабочего дерева. Не стоит его так прямо сравнивать с теми служебными каталогами, что есть у SVN. В Git имеется возможность "прибрать" в индекс некоторые правки, переключиться на другой бранч, после чего вернуть из индекса эти самые правки в рабочее дерево и продолжить с ними работать - заметь, содержмое репозитория (дерева блобов) при этом не меняется.

каким образом наличие явного, а не скрытого «плацдарма» оказывает влияние на работу с тэгами и бранчами.

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

[sash-kan]

Отнюдь. В Git "плацдарм" - это, фактически, частичный (или полный) снепшот рабочего дерева. Не стоит его так прямо сравнивать с теми служебными каталогами, что есть у SVN. В Git имеется возможность "прибрать" в индекс некоторые правки, переключиться на другой бранч, после чего вернуть из индекса эти самые правки в рабочее дерево и продолжить с ними работать - заметь, содержмое репозитория (дерева блобов) при этом не меняется.

или ты путаешь index со stash-ем («тайником»), или я неправильно понимаю, в каком смысле ты употребляешь слово «прибрать».

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

вполне можно игнорировать управляемость index-а. просто не обращать внимание на то, что он управляем.
ещё раз повторю: staging area, как промежуточное звено между рабочей копией и репозиторием, существует, afaik, во всех vcs. только вне git-а ею нельзя напрямую манипулировать. вот и всё.

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

изменил файл file. добавил эту правку в index командой git add file. после этого создаю новый branch:

Shell

$ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: file # $ git checkout -b new M file Switched to a new branch 'new' $ git status # On branch new # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: file # $

как видишь, никаких дополнительных действий, кроме команды checkout, не потребовалось.

[/dev/random]

Лично я предпочитаю думать об индексе как о "недоделанном коммите". Он уже хранится в репозитории, но ещё может быть изменён перед добавлением в "историю".

[sash-kan]

плацдарм для «сборки» коммита.