Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 76
Может быть стоит сделать кат? )
Автор, я сломал скролл!
редкий случай когда при чтении поста в гуглоридере хочется кого-то убить…
Я случайно вместо предпросмотра хлопнул «опубликовать». Круто :)
23 экрана!) рекордсмен))
В общем так. У меня нормальная версия этого безобразия, в html, с красивым оглавлением и вообще более симпатичная. Кому надо — пишите лично, вышлю на почту. На хабре такие вещи фиг опубликуешь!
хабракат если вас не затруднит*
Хорошо, что прошлую заметку (о которой идет речь в самом начале поста) не стали квотить :)
Спасибо. После Вашей предыдущей статьи поигрался с git, появились некоторые вопросы, но эта статья большинство вопросов сняла. Остались вот такие:
1. Пусть у нас есть две ветки master и test, в каждой ветке произошли изменения (без конфликтов). Если из мастера я делаю git merge test, то изменения из test перебираются в master. А при этом что изменения из master не добавляются в test?
2. В конфиге я сделал, чтобы кодировка для текста коммитов была Win1251, сделал git clone, а там эта настройка не сохранилась. Можно ли как-нибудь клонировать вместе с настройками?
3. При клонировании файл gitingnore тоже не сохранится в клоне?
1. Пусть у нас есть две ветки master и test, в каждой ветке произошли изменения (без конфликтов). Если из мастера я делаю git merge test, то изменения из test перебираются в master. А при этом что изменения из master не добавляются в test?
2. В конфиге я сделал, чтобы кодировка для текста коммитов была Win1251, сделал git clone, а там эта настройка не сохранилась. Можно ли как-нибудь клонировать вместе с настройками?
3. При клонировании файл gitingnore тоже не сохранится в клоне?
1. Нет, изменения накладываются только на ту ветку, из который был сделан merge. Ветку test, в принципе, можно удалять после завершения работы.
2. Какой именно конфиг?
3. Вообще .gitignore можно добавить в репозитарий, как и любой другой файл в дереве. Однако, он чаще всего уникальный для каждого из клонов, либо на сервере лежит просто начальный шаблон, который каждый затем подстраивает под себя…
Дело в том, что каждая IDE, и некоторые текстовые редакторы, оставляет после себя уникальную кучу мусора, которую не следует пихать в проект. Вы используете Эклипс, я — Емакс, кто-то третий — еще что. Соответственно, каждый должен самостоятельно подрегулировать .gitignore.
Кроме файла .gitignore есть еще где-то в директории .git файлик exclude, общий для проекта; он читается во вторую очередь, имеет тот же формат. По идее, git clone должен забирать эту настройку, но я не уверен и и не могу сейчас проверить, гляньте сами и, если есть возможность, напишите сюда, буду благодарен. :)
2. Какой именно конфиг?
3. Вообще .gitignore можно добавить в репозитарий, как и любой другой файл в дереве. Однако, он чаще всего уникальный для каждого из клонов, либо на сервере лежит просто начальный шаблон, который каждый затем подстраивает под себя…
Дело в том, что каждая IDE, и некоторые текстовые редакторы, оставляет после себя уникальную кучу мусора, которую не следует пихать в проект. Вы используете Эклипс, я — Емакс, кто-то третий — еще что. Соответственно, каждый должен самостоятельно подрегулировать .gitignore.
Кроме файла .gitignore есть еще где-то в директории .git файлик exclude, общий для проекта; он читается во вторую очередь, имеет тот же формат. По идее, git clone должен забирать эту настройку, но я не уверен и и не могу сейчас проверить, гляньте сами и, если есть возможность, напишите сюда, буду благодарен. :)
1. Спасибо, понятно.
2. В папке .git есть файл config. Туда я добавлял строки
[i18n]
commitencoding = Windows-1251
После клонирования в config в новом репозитории этих строк не было.
3. Да, я как раз добавлял маски в .git/info/exclude. Сейчас попробовал, при клонировании из него тоже пропали все маски.
2. В папке .git есть файл config. Туда я добавлял строки
[i18n]
commitencoding = Windows-1251
После клонирования в config в новом репозитории этих строк не было.
3. Да, я как раз добавлял маски в .git/info/exclude. Сейчас попробовал, при клонировании из него тоже пропали все маски.
К сожалению, с ходу не нашел способа решить эту проблему. Если Вы решите ее — поделитесь? :)
Я бы посоветовал использовать UTF-8 в качестве кодировки. Это облегчит будущее, когда Redmond наконец признает дуальность Windows слишком долгоживущей проблемой. Совет не «с потолка», а практика из жизни.
Да я и рад был бы использовать UTF-8, только когда вводишь комментарии к коммиту из консоли, текст получается именно в кодировке Win1251.
можно использовать cygwin и в качестве консоли к нему puttycyg. Это намного удобней чем стандартный cmd
Надо будет попробовать. Я сейчас активно ищу какую-нибудь замену виндовой консоли, но ничего путного пока не попалось.
Cygwin — это не просто консоль, это вроде среды Юникс под Windows. Там будут все утилиты, характерные для Линукса и компании. Наслаждайтесь :))
Уже посмотрел. Как раз из-за того, что там не просто консоль, мне оно и не подходит. В нем не удается скакать по папкам на разных дисках типа cd c:\bla-bla-bla. Да и с русскими буквами проблемы (хотя возможно это настраивается).
Вот если бы putty заставить работать как обычную виндовую консоль, то было бы неплохо.
Вот если бы putty заставить работать как обычную виндовую консоль, то было бы неплохо.
отчего же? Все диски лежат здесь: /cygdrive/
например диск С будет cd /cygdrive/c,
Для удобства можно сделать симлинк ln -s /cygdrive/c /c
теперь что бы попасть на диск C делаем cd /c
Собственно, если будете ставить cygwin, то и git можно поставить через него. И самое главное, это огромное количество мелких утилит, без которых в винде очень тяжко и неудобно.
например диск С будет cd /cygdrive/c,
Для удобства можно сделать симлинк ln -s /cygdrive/c /c
теперь что бы попасть на диск C делаем cd /c
Собственно, если будете ставить cygwin, то и git можно поставить через него. И самое главное, это огромное количество мелких утилит, без которых в винде очень тяжко и неудобно.
Так с путями как-то неудобно работать, потому что я их обычно копирую из FreeCommander-а, а здесь их придется еще изменять. Сейчас разбираюсь с Этой прогой, скорее dcuj она мне больше подойдет.
А утилиты да, вещь полезная.
А утилиты да, вещь полезная.
Что бы не копировать пути, а открывать консоль в нужной папке по правому клику, нашел инструкцию как добавить в контекстное меню:
goingspare.wordpress.com/2007/03/29/adding-open-with-console-to-the-context-menu/
goingspare.wordpress.com/2007/03/29/adding-open-with-console-to-the-context-menu/
Я сам не пробовал (не использую «окна») но посмотрите на PowerShell
У Cmd есть параметр запускающий ее в Unicode режиме
Огромное спасибо за труд!
Сделайте шпаргалку, как vim quick reference card :)
Я иногда ещё пользуюсь
git diff --name-only branch
Получая список изменённых файлов. Подобный ход незаменим, когда разработка ведётся у нас, а у клиента сервер, где не даётся доступ по ssh и есть только ftp (поэтому ни git ни rsync недоступны)
git diff --name-only branch
Получая список изменённых файлов. Подобный ход незаменим, когда разработка ведётся у нас, а у клиента сервер, где не даётся доступ по ssh и есть только ftp (поэтому ни git ни rsync недоступны)
Спасибо огромное. Очень толково и без излишних «сюсюканей» свойственных большинству novice guide.
Спасибо, некоторые новые команды узнал.
Есть чудесная вещица на английском, GIT Magic
Как по мне, в отличие от топика, там приятнее язык и подача материала.
Как по мне, в отличие от топика, там приятнее язык и подача материала.
Дествительно чудесная вещица это peepcode.com/products/git, правда стоит денег. Но там очень все хорошо расказывается и есть видео как пользоваться. Так же есть удобный cheetsheet
А я до конца дочитал. Буду пробовать.
в 4.2.6. не git checkout ли должно быть?
за описание настройки и администрирования общественного репозитария был бы очень признателен
Подскажите как в git проекте добавить вложенный git проект, допустим в уже существующем проекте должна быть папка bin(например) с файлами из другого git проекта.
Как это настроить по уму, нигде не могу откопать. Нужно, чтобы при клонировании основного GIT проекта, в нем появлялась папка bin и чтобы можно было централизованно обновлять и основной проект и вложенные папки с другим проектом. В svn сделал бы через svn:externals. Как сделать в GIT?
Как это настроить по уму, нигде не могу откопать. Нужно, чтобы при клонировании основного GIT проекта, в нем появлялась папка bin и чтобы можно было централизованно обновлять и основной проект и вложенные папки с другим проектом. В svn сделал бы через svn:externals. Как сделать в GIT?
1. можно просто написать git commit -a -m «commit comment», тогда перед коммитом автоматически внесутся в индекс изменения в известных файлах. git add. добавит и измененные известные, и неизвестные системе файлы.
2. Очепятка, уже исправил. Веток, естественно, может быть много, надо указывать, что заливать в ветку.
3. Ничто и никуда не пойдет, если только не указывать явно в параметрах команды git push.
Удаленная ветка ставится в данном случае в соответствие master, и именно оттуда можно сделать git push. Удаленные ветки можно посмотреть командой git branch -r, либо заглянуть в .git/config — там очень простой синтаксис конфигурации, видно, что и чему ставится в соответствие.
2. Очепятка, уже исправил. Веток, естественно, может быть много, надо указывать, что заливать в ветку.
3. Ничто и никуда не пойдет, если только не указывать явно в параметрах команды git push.
Удаленная ветка ставится в данном случае в соответствие master, и именно оттуда можно сделать git push. Удаленные ветки можно посмотреть командой git branch -r, либо заглянуть в .git/config — там очень простой синтаксис конфигурации, видно, что и чему ставится в соответствие.
1. Индекс — сущность, в которой фиксируются изменения, предназначенные для коммита.
2. git reset --hard — полный откат до какого-либо коммита, со сбросом индекса и изменений файлов проекта. Это используется, когда надо просто выбросить изменения.
git reset --soft — этой командой мы откатываемся до какого-либо коммита, делая его «текущим»; само дерево проекта останется в исходном состоянии, а индекс сохранит все изменения, внесенные после «текущего» коммита. Иными словами, файлы не меняются, а индекс вмещает все изменения. Можно таким образом поправить коммит:
Сама по себе git reset просто очистит индекс от изменений. Вы добавили какие-то файлы, но ошиблись (например, файлы логов или левые картинки); эта команда отменяет это действиею.
3. Вернуть файл (или просто вытащить из прошлого коммита) позволяет команда git checkout (она же переключает нас между ветками):
git checkout somefile — вернуть somefile к состоянию последнего коммита
git checkout HEAD~2 somefile — вернуть somefile к состоянию на два коммита назад по ветке.
Естественно, репозитарий при этой не меняется.
2. git reset --hard — полный откат до какого-либо коммита, со сбросом индекса и изменений файлов проекта. Это используется, когда надо просто выбросить изменения.
git reset --soft — этой командой мы откатываемся до какого-либо коммита, делая его «текущим»; само дерево проекта останется в исходном состоянии, а индекс сохранит все изменения, внесенные после «текущего» коммита. Иными словами, файлы не меняются, а индекс вмещает все изменения. Можно таким образом поправить коммит:
Сама по себе git reset просто очистит индекс от изменений. Вы добавили какие-то файлы, но ошиблись (например, файлы логов или левые картинки); эта команда отменяет это действиею.
3. Вернуть файл (или просто вытащить из прошлого коммита) позволяет команда git checkout (она же переключает нас между ветками):
git checkout somefile — вернуть somefile к состоянию последнего коммита
git checkout HEAD~2 somefile — вернуть somefile к состоянию на два коммита назад по ветке.
Естественно, репозитарий при этой не меняется.
У меня сейчас завал на работе, на эксперименты и продолжение серии топиков времени, к огромному моему сожалению, пока нет. Зато будет любопытный опыт практического внедрения git в проекте.
Интересная ситуация. А как вообще вышло так, что «в исходном репозитории не выбрать никакую ветку»?
дополнение про checkout сейчас внесу в топик.
Интересная ситуация. А как вообще вышло так, что «в исходном репозитории не выбрать никакую ветку»?
дополнение про checkout сейчас внесу в топик.
Прошу прощения за задержку.
Опечатку исправил.
Теперь про пуш и пул. Дело в том, что я даже не пробовал такой расклад, как непосредственный пуш в обычный репозитарий, поскольку обычно рекомендуется схема с отдельным открытым для чтения bare-репозитарием и личным.
Работа, как обычно, ведется у себя, потом результат закидывается в «голый», и оттуда уже раздается по коллегам или, скажем, себе домой.
Вообще интересно, надо бы почитать.
Опечатку исправил.
Теперь про пуш и пул. Дело в том, что я даже не пробовал такой расклад, как непосредственный пуш в обычный репозитарий, поскольку обычно рекомендуется схема с отдельным открытым для чтения bare-репозитарием и личным.
Работа, как обычно, ведется у себя, потом результат закидывается в «голый», и оттуда уже раздается по коллегам или, скажем, себе домой.
Вообще интересно, надо бы почитать.
И нет, не достали :) Я человек любопытный, вы человек любопытный, почему бы не узнать что-нибудь новенькое? :)
В мемориз, однозначно! ) Спасибо за чудесный мануал.
В CVS'е же тоже теги есть. И в SVN'е (хотя, технически они ничем и не отличаются о обычных директорий, как и ветки).
Для удобства работы с git было введено дополнительное понятие: тэг.
В CVS'е же тоже теги есть. И в SVN'е (хотя, технически они ничем и не отличаются о обычных директорий, как и ветки).
Отличный мануал, спасибо!
Правильно писать: репОзиторий
спасибо.
Отличный пост! Всё разложено по полочкам и про ВСЁ написано.
2 Работа с локальным репозитарием
Репозиторием.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Git Wizardry