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

Про git blame непонятно написано. Как это работает?
Это бисекция ошибки что ли? А как тестовый набор указать тогда?

Нет, оно показывает, где в файле кто что последний менял. Бисекция - git bisect.

Даже очепятки и потерю форматирования при переводе сохранили :)

Service Temporarily Unavailable

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

А нафига они вообще не статический git.html отдают, а php? Так тоже работает: http://rus-linux.net/MyLDP/algol/git.html

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

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

Совет 0: просто не используйте Git.

Нет, это как раз неверный совет.

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

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

Git только для тех, кто владеет им от рождения?

> Нет, это как раз неверный совет.

Единственно верный. А все остальные советы незримо предваряются фразой: «Но, если вы неудачник и вам приходится использовать Git против своей воли, вот 10 советов, которые сделают вашу жизнь хоть как-то терпимой».

Просто ты уже не начинающий >_<

Ты не поверишь, некоторые (скажем, я) используют гит по своей воле.

Что я принципиально потерял, кроме более хреновой поддержки со стороны trac/bitten (что явялется, в общем-то проблемой trac/bitten)?

не получается его не использовать: уж очень фичаст и популярен.

каковы реальные альтернативы сабжу?

> Совет 1. Альтернативно одаренные, не используйте git!

fxd

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

> Кстати, а можно ли в гите как-нибудь по-простому закоммитить одни и те же изменения сразу в несколько бранчей (если эти изменения не затрагивают те места, в которых бранчи различаются)?

git cherry-pick

> Что я принципиально потерял

Лучше расскажи, что ты приобрел, и зачем тебе это.

А, дзен! Понимаю, кто готов, не послушает вредных советов ;-)

По сравнению с чем? С SVN? Возможность сделать фиксацию вне зависимости от связи с сервером и лучший мерж.

юзай git stash / git stash apply / git add file1 file2

Зачем SVN? Предлагаю с чем-нибудь хорошим сравнить. Например с Mercurial.

>> Лучше расскажи, что ты приобрел, и зачем тебе это.

По сравнению с чем?

С Mercurial, конечно. Впрочем, сравнение с Monotone или DARCS тоже интересно.

С SVN?

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

В закладки, на досуге изучимссссс....

>git cherry-pick

Как я понял, там придётся делать checkout на каждый бранч. Муторно, конечно. Но можно и заскриптить, наверное.

Спасибо.

>> С SVN?

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

Почему нет, особенно для проектов начатых давно.

>юзай git stash / git stash apply / git add file1 file2

Спасибо, но, если изменения уже оформлены в виде коммита, cherry-pick мне кажется более простым решением.

> Почему нет, особенно для проектов начатых давно.

Потому что есть инструменты и трюки, позволяющие использовать DVCS «за спиной» у SVN-сервера. То есть ты работаешь с нормальной VCS, но сливаешь результат в SVN.

Поподробнее пожалуйста, желательно ссылочку

> Поподробнее пожалуйста, желательно ссылочку

Насколько я знаю, для Mercurial самый продвинутый - http://mercurial.selenic.com/wiki/HgSubversion

За Git давно не слежу, но здесь достаточно git-фанбоев %)

Кстати, для тех, кто застрял в SVN, давно уже есть вот такой инструмент: http://svk.bestpractical.com/view/HomePage

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

> уважающие себя разработчики, которым необходимо работать, а не играться с инструментом.

Это такой эвфемизм для «рабы ынтерпрайза»?

а кому делать больше нечего доказывают преимущества их любимой игрушки

В сэкономленное за счет использования этой игрушки время.

P.S. это ты хочешь быть толще меня?

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

+1500

Совет №2 : не юзайте совет по ссылке
«Добавление файлов одновременно с выполнением операции commit»

> С Mercurial, конечно.

Пока не скажу, не прикручено. Как прикрутят --- попробую сразу же %)

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

«Зачем нам это новомодная SVN? Ведь мы прекрасно работали с CVS!» (c) 2010 год

>Совет 0: используйте git

Fixed

костыль какой-то. А если я хочу сохранить коммиты из своей локальной копии? Вдруг любой из них потребуется откатить. Да и следить удобнее

>> С Mercurial, конечно.

Пока не скажу, не прикручено.

Не прикручено к чему?

> костыль какой-то. А если я хочу сохранить коммиты из своей локальной копии?

И что тебе помешает?

Вдруг любой из них потребуется откатить.

Смотря что понимать под «откатить».

К одной используемой мною системе. Прикрутим на неделе.

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

> 5. Удаление из списка зафиксированных новых только что добавленных файлов

git rm --cached schema-notes.txt

Можно просто git reset schema-notes.txt

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

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

>Git только для тех, кто владеет им от рождения?

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

> Просто GIT предназначен для работы в определенных условиях.

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

А когда у тебя один единый репозиторий, то какой смысл?

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

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

Да-да-да! Некогда пилу точить, пилить надо! Знаем мы таких «уважающих себя».

>Как я понял, там придётся делать checkout на каждый бранч. Муторно, конечно

ничего муторного. чекаутишь нужный бранч, потом cherry-pick. Хуже, если конфликты возникают,но при правильной организации работы этого не будет

Ненавижу такие статьи, которые еще больше запутывают. Они только вредят. Переводчику ставлю твердую пару.

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

%>git add . %>git commit -m «Latest commit message»

Это значит, что перед каждым коммитом надо делать «git add .»?

Дальше еще больше вопросов. С этим бы разобраться.

таки git кошмарен. вызывая команду add в интерактивном режиме, я вижу саму команду add аж под четвертым номером!

Я могу запустить процедуру интерактивного добавления, указав параметр -i для команды git add:

%>git add -i

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

*** Commands *** 1: [s]tatus 2: [u]pdate 3: [r]evert 4: [a]dd untracked

5: [p]atch 6: [d]iff 7: [q]uit 8: [h]elp

Но есть и хорошие вещи

По умолчанию это - lighthttpd,

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

*глянул в ~/soft/src*

Scribus, Fontmatrix, Audacity, Ardour, geeqie, JACK, Luminance HDR, MuseScore, PoDoFo, Q[jackctl|sample|synth|midiroute], Ramen, Rosegarden...

А ещё полно народу до сих пор пользуется CVS: FontForge, UFRaw, LinuxSampler, libgig, gigedit...

Для своих проектов пользуюсь Git. Нравится.