LINUX.ORG.RU

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

 ,


0

0

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

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

★★★

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

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

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

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

Voker57 ★★
()

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

AlexVR ★★★★★
()

Service Temporarily Unavailable

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

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

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

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

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

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

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

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

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

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

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

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

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

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

fxd

Voker57 ★★
()

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

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

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

git cherry-pick

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

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

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

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

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

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

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

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

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

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

С SVN?

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

tailgunner ★★★★★
()

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

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

>git cherry-pick

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

Спасибо.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

+1500

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

sv75 ★★★★★
()

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

Sphinx ★★☆☆
()

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

git rm --cached schema-notes.txt

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

TweedleDee
()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

annulen ★★★★★
()

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

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

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



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

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

xintrea
()

таки 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,

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

> Боже мой, ей еще кто-то пользуется? 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. Нравится.

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