Git
Comments 76
+13
Может быть стоит всё-таки это предложение написать автору лично через почту?
-1
редкий случай когда при чтении поста в гуглоридере хочется кого-то убить…
0
Я случайно вместо предпросмотра хлопнул «опубликовать». Круто :)
-3
В общем так. У меня нормальная версия этого безобразия, в html, с красивым оглавлением и вообще более симпатичная. Кому надо — пишите лично, вышлю на почту. На хабре такие вещи фиг опубликуешь!
0
ну так может выкладывай куда-нить. (на google pages например) а на хабр просто линк на статью.
-2
Хорошо, что прошлую заметку (о которой идет речь в самом начале поста) не стали квотить :)
0
Спасибо. После Вашей предыдущей статьи поигрался с git, появились некоторые вопросы, но эта статья большинство вопросов сняла. Остались вот такие:

1. Пусть у нас есть две ветки master и test, в каждой ветке произошли изменения (без конфликтов). Если из мастера я делаю git merge test, то изменения из test перебираются в master. А при этом что изменения из master не добавляются в test?

2. В конфиге я сделал, чтобы кодировка для текста коммитов была Win1251, сделал git clone, а там эта настройка не сохранилась. Можно ли как-нибудь клонировать вместе с настройками?

3. При клонировании файл gitingnore тоже не сохранится в клоне?
+1
1. Нет, изменения накладываются только на ту ветку, из который был сделан merge. Ветку test, в принципе, можно удалять после завершения работы.

2. Какой именно конфиг?

3. Вообще .gitignore можно добавить в репозитарий, как и любой другой файл в дереве. Однако, он чаще всего уникальный для каждого из клонов, либо на сервере лежит просто начальный шаблон, который каждый затем подстраивает под себя…

Дело в том, что каждая IDE, и некоторые текстовые редакторы, оставляет после себя уникальную кучу мусора, которую не следует пихать в проект. Вы используете Эклипс, я — Емакс, кто-то третий — еще что. Соответственно, каждый должен самостоятельно подрегулировать .gitignore.

Кроме файла .gitignore есть еще где-то в директории .git файлик exclude, общий для проекта; он читается во вторую очередь, имеет тот же формат. По идее, git clone должен забирать эту настройку, но я не уверен и и не могу сейчас проверить, гляньте сами и, если есть возможность, напишите сюда, буду благодарен. :)
0
1. Спасибо, понятно.

2. В папке .git есть файл config. Туда я добавлял строки

[i18n]
commitencoding = Windows-1251

После клонирования в config в новом репозитории этих строк не было.

3. Да, я как раз добавлял маски в .git/info/exclude. Сейчас попробовал, при клонировании из него тоже пропали все маски.
0
К сожалению, с ходу не нашел способа решить эту проблему. Если Вы решите ее — поделитесь? :)
+1
Я бы посоветовал использовать UTF-8 в качестве кодировки. Это облегчит будущее, когда Redmond наконец признает дуальность Windows слишком долгоживущей проблемой. Совет не «с потолка», а практика из жизни.
0
Да я и рад был бы использовать UTF-8, только когда вводишь комментарии к коммиту из консоли, текст получается именно в кодировке Win1251.
0
можно использовать cygwin и в качестве консоли к нему puttycyg. Это намного удобней чем стандартный cmd
0
Надо будет попробовать. Я сейчас активно ищу какую-нибудь замену виндовой консоли, но ничего путного пока не попалось.
0
Cygwin — это не просто консоль, это вроде среды Юникс под Windows. Там будут все утилиты, характерные для Линукса и компании. Наслаждайтесь :))
0
Уже посмотрел. Как раз из-за того, что там не просто консоль, мне оно и не подходит. В нем не удается скакать по папкам на разных дисках типа cd c:\bla-bla-bla. Да и с русскими буквами проблемы (хотя возможно это настраивается).

Вот если бы putty заставить работать как обычную виндовую консоль, то было бы неплохо.
0
отчего же? Все диски лежат здесь: /cygdrive/
например диск С будет cd /cygdrive/c,

Для удобства можно сделать симлинк ln -s /cygdrive/c /c
теперь что бы попасть на диск C делаем cd /c

Собственно, если будете ставить cygwin, то и git можно поставить через него. И самое главное, это огромное количество мелких утилит, без которых в винде очень тяжко и неудобно.
0
Так с путями как-то неудобно работать, потому что я их обычно копирую из FreeCommander-а, а здесь их придется еще изменять. Сейчас разбираюсь с Этой прогой, скорее dcuj она мне больше подойдет.

А утилиты да, вещь полезная.
0
Я сам не пробовал (не использую «окна») но посмотрите на PowerShell
0
Она так и задумывалась. Будь здесь возможность сделать оглавление…
+1
Я иногда ещё пользуюсь

git diff --name-only branch

Получая список изменённых файлов. Подобный ход незаменим, когда разработка ведётся у нас, а у клиента сервер, где не даётся доступ по ssh и есть только ftp (поэтому ни git ни rsync недоступны)
0
Спасибо огромное. Очень толково и без излишних «сюсюканей» свойственных большинству novice guide.
0
Есть чудесная вещица на английском, GIT Magic
Как по мне, в отличие от топика, там приятнее язык и подача материала.
0
Дествительно чудесная вещица это peepcode.com/products/git, правда стоит денег. Но там очень все хорошо расказывается и есть видео как пользоваться. Так же есть удобный cheetsheet
0
я учился по Git Community Book, там тоже есть скринкасты и очень разжеван материал; потом уже по отдельным howto и справке к командам и руководству к самому git.

0
за описание настройки и администрирования общественного репозитария был бы очень признателен
+1
Мне в ближайшую неделю, если не дни, как раз надо будет поднимать на локальный офис и нескольких удаленных работников репозитарий с довольно сложной настройкой по правам доступа. Думаю, к концу следующей недели будет практический материал и время.
0
Подскажите как в git проекте добавить вложенный git проект, допустим в уже существующем проекте должна быть папка bin(например) с файлами из другого git проекта.

Как это настроить по уму, нигде не могу откопать. Нужно, чтобы при клонировании основного GIT проекта, в нем появлялась папка bin и чтобы можно было централизованно обновлять и основной проект и вложенные папки с другим проектом. В svn сделал бы через svn:externals. Как сделать в GIT?
0
Для этого используется Git Submodules; однако, сам в этой фишке не разбирался и на данный момент надобности и времени нет. Обещать освещение в следующей заметке, к сожалению, не могу.
0
1. Правильно ли я понял, что перед каждым коммитом нужно делать «git add .»? Зачем? Вот в SVN, например, этого делать не надо, SVN сам знает, какие файлы изменились.

2. В главе «4.1 Обычный workflow...» в пункте «12. git merge» не указано, с чем мержить. Это опечатка, или так и должно быть и git как-то сам догадывается, с чем мержить?

3. Делаем «git clone» с оригинального репозитория, что-то там правим и фиксируем коммит. Потом «git branch new», потом «git checkout new», потом изменяем в ветке new какие-то файлы и фиксируем коммит. Теперь, не переключаясь на master и не делая merge, сразу делаем «git push». Что и куда пойдет, какие изменения окажутся в оригинальном репозитории?
0
1. можно просто написать git commit -a -m «commit comment», тогда перед коммитом автоматически внесутся в индекс изменения в известных файлах. git add. добавит и измененные известные, и неизвестные системе файлы.

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

3. Ничто и никуда не пойдет, если только не указывать явно в параметрах команды git push.

Удаленная ветка ставится в данном случае в соответствие master, и именно оттуда можно сделать git push. Удаленные ветки можно посмотреть командой git branch -r, либо заглянуть в .git/config — там очень простой синтаксис конфигурации, видно, что и чему ставится в соответствие.
0
1. Что такое «индекс»?

2. «git reset — сбросить нафиг весь индекс» — что делает эта команда? Попробовал — не вижу никакого эффекта. Что должно произойти?

3. Как откатиться, не трогая репозиторий? Команда «git reset --[soft|hard]» изменяет репозиторий (или я что-то не так понял), а как изменить сами файлы, привести их к состоянию на момент какого-то коммита, не изменяя при этом репозиторий?
+1
1. Индекс — сущность, в которой фиксируются изменения, предназначенные для коммита.

2. git reset --hard — полный откат до какого-либо коммита, со сбросом индекса и изменений файлов проекта. Это используется, когда надо просто выбросить изменения.

git reset --soft — этой командой мы откатываемся до какого-либо коммита, делая его «текущим»; само дерево проекта останется в исходном состоянии, а индекс сохранит все изменения, внесенные после «текущего» коммита. Иными словами, файлы не меняются, а индекс вмещает все изменения. Можно таким образом поправить коммит:

Сама по себе git reset просто очистит индекс от изменений. Вы добавили какие-то файлы, но ошиблись (например, файлы логов или левые картинки); эта команда отменяет это действиею.

3. Вернуть файл (или просто вытащить из прошлого коммита) позволяет команда git checkout (она же переключает нас между ветками):

git checkout somefile — вернуть somefile к состоянию последнего коммита
git checkout HEAD~2 somefile — вернуть somefile к состоянию на два коммита назад по ветке.

Естественно, репозитарий при этой не меняется.
0
Т.е. «git reset» просто сбросит добавленные файлы, и все? Изменения в файлах он же не отменит?
0
Делаю git clone — репозиторий клонируется, файлы появляются, все нормально.

Дальше делаю git pull — а оно мне сообщает:

— You asked me to pull without telling me which branch you
want to merge with, and 'branch..merge' in
your configuration file does not tell me either. Please
name which branch you want to merge on the command line and
try again (e.g. 'git pull ').
See git-pull(1) for details on the refspec.

If you often merge with the same branch, you may want to
configure the following variables in your configuration
file:

branch..remote = branch..merge = <remote-ref>
remote..url = remote..fetch = See git-config(1) for details.
— Что оно от меня хочет? Какие такие сомнения его терзают? И так же вроде понятно, что с чем мержить — исходный репозиторий с активной локальной веткой.
0
Так, отвечаю сам себе.

Перед тем, как клонировать исходный репозиторий, нужно в нем перейти в ветку master. В этом случае при клонировании в новый репозиторий будет скопирована именно ветка master.

Если в исходном репозитории не выбрать никакую ветку, то при клонировании в новый репозиторий будет скопировано нечто, под названием «no branch».

Содержимое этого нечто будет, вроде, идентично ветке master, но не будет связано ни с master, ни с чем-то еще, поэтому сделать далее «git pull» не получится, вылезет приведенное выше сообщение об ошибке с требованием явно указать, какую ветку с какой мержить.
0
У меня сейчас завал на работе, на эксперименты и продолжение серии топиков времени, к огромному моему сожалению, пока нет. Зато будет любопытный опыт практического внедрения git в проекте.

Интересная ситуация. А как вообще вышло так, что «в исходном репозитории не выбрать никакую ветку»?

дополнение про checkout сейчас внесу в топик.
0
Ну, я сделал исходный репозиторий:

git init
git add.
git commit -am 'start'

и все, больше ничего не делал. При этом, я так понимаю, ветка master автоматически выбрана не была.

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

0
1) После того, как в локальном репозитории сделали «git push», как получить эти изменения в удаленном репозитории?

В удаленном репозитории я делаю «git log» и вижу коммит с нужными изменениями, команда «git status» показывает, что имеются модифицированные файлы, но сами файлы при этом остаются старыми. Как их обновить? В SVN я бы сделал «svn update», а тут что нужно сделать?

2. В главе «4.2 Workflow при работе с удаленным репозитарием » пункт «6. git branch master» — не опечатка ли? Не должен ли там быть checkout вместо branch?

3. Надеюсь, я Вас еще не достал? :)
0
Прошу прощения за задержку.

Опечатку исправил.

Теперь про пуш и пул. Дело в том, что я даже не пробовал такой расклад, как непосредственный пуш в обычный репозитарий, поскольку обычно рекомендуется схема с отдельным открытым для чтения bare-репозитарием и личным.

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

Вообще интересно, надо бы почитать.
0
>Работа, как обычно, ведется у себя, потом результат закидывается в «голый», и оттуда уже раздается по коллегам или, скажем, себе домой.

Вы же сначала сказали открытый для чтения?

И вот, скажем, нужна «точка», из которой результат работы нужно показывать заказчику. Нельзя же показывать из личного репозитория разработчика — там же в каждый конкретный момент времени может быть что угодно. Вот я и думаю показывать из центрального репозитория, где всегда будет актуальная работоспособная версия, а для этого нужно туда пушить и после пуша файлы в центральном требуется обновить.
0
И нет, не достали :) Я человек любопытный, вы человек любопытный, почему бы не узнать что-нибудь новенькое? :)
0
По первому вопросу, после push на удаленном репозитарии надо выполнить checkout -f
0
В мемориз, однозначно! ) Спасибо за чудесный мануал.

Для удобства работы с git было введено дополнительное понятие: тэг.

В CVS'е же тоже теги есть. И в SVN'е (хотя, технически они ничем и не отличаются о обычных директорий, как и ветки).
0
А, ну это да. В свое время мне встречались оба варианта.
UFO landed and left these words here
0
Ну… Когда-то было все, теперь же изрядная часть статьи устарела. По Интернету полно актуального материала — им и рекомендую пользоваться.
Only those users with full accounts are able to leave comments.  , please.