Вход:  Пароль:  
FreeSource: RuslanHihin/20повседевныхкомандgit ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |
Это старая версия RuslanHihin/20повседевныхкомандgit за 2008-05-10 16:42:10..

20 повседневных команд git 


Команды работы с [Базисные команды репозитория] нужны всем, у кого есть репозиторий, т.е. любому, работающему с git хранилищем.


Кроме того, важное значение для всех, кто создаёт коммиты, даже если он работает один, важное значение имеют комады [Индивидуальная разработка (Автономный режим)] .


Если вы работаете совместно с другими людьми, вам потребуются команды, перечисленные в разделе [Индивидуальная разработка (Совместный режим)].
Людям, которые играют роль [Интегратора], необходимо знать помимо этого ещё несколько команд..


Команды [Администрирование репозитория] важны для системных администраторов которые несут ответственность за работоспособность git репозиториия.


Базисные команды репозитория


Эти команды повседневно используются при работе с git репозиторием.

git-init(1) и git-clone(1) создают новый репозиторий.

  • git-fsck(1), проверяет репозиторий на ошибки.

  • git-gc(1) to do common housekeeping tasks such as repack and prune.

  • git-gc(1) решает общие задачи сохранения репозитория, такие как переупаковки и «убирание мусора».

    Примеры


    Check health and remove cruft.
    Проверка «здоровья» репозитория и удаление из него мусора.


    $ git fsck (1)
    $ git count-objects (2)
    $ git gc (3)


    1. Даже запуская без full, вы легко и надёжно проверяете «здоровье» репозитория.


    2.


    Проверка, сколько объектов будет потеряно и объём освобождаемого места при перепаковке репозитория.
    3.


    переупаковка локальных репозиториев и другие виды повседневныз задач.


    Упаковка небольших проектов в один пакет.


    $ git gc (1)


    1.


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

    Индивидуальная разработка (Автономный режим)


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

    git-show-branch(1) – посмотреть где вы (в какой ветке).

  • git-log(1) – посмотреть что в логах.

  • git-checkout(1) и git-branch(1) – переключение ветвей.

  • git-add(1) – управление файлом индекса.

  • git-diff(1) и git-status(1) – посмотреть что вы уже сделали в течении работы.

  • git-commit(1) to advance the current branch.

  • git-commit(1) зафиксировать (создать коммит) в текущей ветке.

  • git-reset(1) и git-checkout(1) (с параметрами пути) – отмена последних изменений изменений (откат изменений).

  • git-merge(1) – слить (объединить) локальные ветви репозитория.

  • git-rebase(1) – обновление локальной ветки до заданного репозитория и добавление необходимых коммитов.

  • git-tag(1) – задать именованную метку для коммита (текущей точки).

    Примеры


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


    $ tar zxf frotz.tar.gz


    $ cd frotz


    $ git-init


    $ git add . (1)


    $ git commit -m “import of frotz source tree.”


    $ git tag v2.43 (2)


    1.


    Добавляем все измениия и файлы в текущем директории.
    2.


    Создаём легкий, неаннотированный тег


    Создаём топик (имя) ветки и работаем с ней.


    $ git checkout -b alsa-audio (1)
    $ edit/compile/test
    $ git checkout — curses/ux_audio_oss.c (2)
    $ git add curses/ux_audio_alsa.c (3)
    $ edit/compile/test
    $ git diff HEAD (4)
    $ git commit -a -s (5)
    $ edit/compile/test
    $ git reset --soft HEAD^ (6)
    $ edit/compile/test
    $ git diff ORIG_HEAD (7)
    $ git commit -a -c ORIG_HEAD (8)
    $ git checkout master (9)
    $ git merge alsa-audio (10)
    $ git log --since='3 days ago' (11)
    $ git log v2.43.. curses/ (12)


    1.


    создаем новую ветку с именем (топиком) alsa-audio.
    2. отменяем ваши неудачные изменения в curses/ux_audio_oss.c
    3.


    вам нужно указать git, что вы добавили новый файл; другие удаление и изменения будет не замечены, если сделать git commit.
    4.


    смотрим, какие изменения Вы будете фиксировать при выполнении git-commit.
    5.


    фиксируем всё так-вы проверили, подписывая коммит.
    6.


    отменяем последний коммит, сохраняя его в рабочем дереве.
    7.


    смотрим на изменения сделанные в отменённом нами коммите.
    8.


    возвращаем предыдущий коммит используя при записи сообщение оригинала.
    9.


    переключиться на ветвь master.

  • объединяем ветку топика alsa-audio с веткой master.

  • смотрим логи коммита; другие формы могут ограничивать вывод и комбинироваться и включать --max-count=10 (показать не больше 10 коммитов ), --until=2005–12–10 (до 10 декабря 2005г) и т.д.

  • смотрим изменения, находящиеся в директории curses/ в коммите v2.43

    Индивидуальная разработка (Совместный режим)
    A developer working as a participant in a group project needs to learn how to communicate with others, and uses these commands in addition to the ones needed by a standalone developer.
    Разработчик работая в совместном проекте группы должен уметь общаться с другими участниками и использовать команды, помимо тех, что нужны в Автономной работе :

    git-clone(1) from the upstream to prime your local repository.

  • git-clone(1) – создать точную копию основного репозитория разработки в своём локальном хранилище.

  • git-pull(1) и git-fetch(1) – получает из “origin” основного репозитория и сохраняет изменения в звашем репозитории.

  • git-push(1)to shared repository, if you adopt CVS style shared repository workflow.

  • git-push(1) помещает в общее хранилище, если у вашего общего Git репозитория принят стиль CVS.

  • git-format-patch(1) to prepare e-mail submission, if you adopt Linux kernel-style public forum workflow.

  • git-format-patch(1) готовит патч в представлении e-mail, если у вашего общего репозитория принят стиль «ядра Linux».

    Примеры


    Клонируем основной репозиторий и работаем с ним.
    Передаём изменения в основной репозиторий.


    $ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6
    $ cd my2.6
    $ edit/compile/test; git commit -a -s (1)
    $ git format-patch origin (2)
    $ git pull (3)
    $ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 (4)
    $ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL (5)
    $ git reset --hard ORIG_HEAD (6)
    $ git gc (7)
    $ git fetch --tags (8)


    1.


    повторяем по мере необходимости.
    2.


    извлекаем патчи из вашей ветки в e-mail виде.
    3.


    git pull извлекает из origin (по-умолчанию) и объединяет с текущей веткой.
    4.


    сразу после git pull, смотрим сделанные «апстримом» в последнее время изменения в области кода, которая нас интересует.
    5.


    извлекаем изменения из конкретной ветки конкретного репозитория и объединяем их.
    6.


    возвращаемся через git pull .
    7.


    убираем мусор от оставшихся объектов после git-pull.
    8.


    from time to time, obtain official tags from the origin and store them under .git/refs/tags/ .
    9.


    Время от времени, получать официальные метки из origin и сохраняем их в соответствии в .git/refs/tags/.


    Передача в другой репоззиторий

    satellite$ git clone mothership:frotz frotz (1)
    satellite$ cd frotz
    satellite$ git config --get-regexp '^(remote|branch)\.' (2)
    remote.origin.url mothership:frotz
    remote.origin.fetch refs/heads/*:refs/remotes/origin/*
    branch.master.remote origin
    branch.master.merge refs/heads/master
    satellite$ git config remote.origin.push \
    master:refs/remotes/satellite/master (3)
    satellite$ edit/compile/test/commit
    satellite$ git push origin (4)


    mothership$ cd frotz
    mothership$ git checkout master
    mothership$ git merge satellite/master (5)


    1.


    машина mothership имеет репозиторий frotz в домашний каталоге; клонируем его в репозиторий на машине satellite.
    2.


    клонируем установки конфигурации переменных по умолчанию. Это готовит git pull для извлечения и сохранения ветвей с машины mothership в локальные remotes/origin/* отслеживаемые ветви.
    3.


    готовим git push для отдачи с локальной ветки master в ветку remotes/satellite/master машины mothership.
    4.


    отсылаем результаты нашей работы в remotes/satellite/master отслеживаемую ветку на машине mothership. Вы можете использовать её в качестве запасного хранилища кода.
    5.


    на машине mothership, объединяем наработки с машины satellite в ветку master.


    Ветка вне без специфичного тега.


    $ git checkout -b private2.6.14 v2.6.14 (1)
    $ edit/compile/test; git commit -a
    $ git checkout master
    $ git format-patch -k -m --stdout v2.6.14..private2.6.14 |
    git am -3 -k (2)


    1.


    Создаём приватную ветку на основе на известной (но несколько сзади) метки.
    2.


    forward port all changes in private2.6.14 branch to master branch without a formal “merging”.
    3.


    портируем вперед все изменения в private2.6.14 ветке в ветку мастер без формального «слияние».

    Интегратор


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

    git-am(1) применить патчи в e-mail виде от другого участника.

  • git-pull(1) объединить ветки доверенных лиц.

  • git-format-patch(1) подготовить и направить альтернативные предложения участнику.

  • git-revert(1) отменить неудачные коммиты.

  • git-push(1) опубликовать текущие изменения.

    Примеры


    Мой типичный день с Git.


    $ git status (1)
    $ git show-branch (2)
    $ mailx (3)
    & s 2 3 4 5 ./+to-apply
    & s 7 8 ./+hold-linus
    & q
    $ git checkout -b topic/one master
    $ git am -3 -i -s -u ./+to-apply (4)
    $ compile/test
    $ git checkout -b hold/linus && git am -3 -i -s -u ./+hold-linus (5)
    $ git checkout topic/one && git rebase master (6)
    $ git checkout pu && git reset --hard next (7)
    $ git merge topic/one topic/two && git merge hold/linus (8)
    $ git checkout maint
    $ git cherry-pick master4 (9)
    $ compile/test
    $ git tag -s -m “GIT 0.99.9x” v0.99.9x (10)
    $ git fetch ko && git show-branch master maint 'tags/ko-*' (11)
    $ git push ko (12)
    $ git push ko v0.99.9x (13)


    1.


    смотрю, состояние дел
    2.


    смотрю названия веток, и думаю о том, как из них уже готовы.
    3.


    читаю почту, сохраняю то, что уже применимо, и что не совсем готовы.
    4.


    применяю их, интерактивно, с моей подписью.
    5.


    создаваю топики веток по мере необходимости и применяю, с моей подписью.
    6.


    делаю git rebase для внутренней именованной ветки, которая не была объединена с мастером, и не выставлена как часть стабильной ветви.
    7.


    сброс ветки pu каждый раз, из следующей.
    8.


    и объединяем ветки при их готовности.
    9.


    «бакпортирую» критические исправления.

  • создаю подписанный тег.

  • убеждаюсь, что я случайно не откачу master назад после git push. Где ko – это сокращенная запись точек, в которое я имею на kernel.org, и выглядит подобно этому :


    $ cat .git/remotes/ko
    URL: kernel.org:/pub/scm/git/git.git
    Pull: master:refs/tags/ko-master
    Pull: next:refs/tags/ko-next
    Pull: maint:refs/tags/ko-maint
    Push: master
    Push: next
    Push: +pu
    Push: maint


    В выводе git show-branch, master должно быть все что имеется в ko-master, и next должен всегда иметь ko-next.

  • публикуем изменения ка публичном сервере

  • публикуем также тег.

    Администрирование репозитория


    A repository administrator uses the following tools to set up and maintain access to the repository by developers.


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

    git-daemon(1) разрешает анонимную загрузку из репозитория.

  • git-shell(1) can be used as a restricted login shell for shared central repository users.

  • git-shell(1) может использоваться в качестве ограниченного авторизированного sheel`а в общем центральном репозитории пользователей.

    update hook howto имеет хорошии примеры совместной управления центрального репозитория.


    Примеры


    Мы исходим из следующего /etc/services


    $ grep 9418 /etc/services
    git 9418/tcp # Git Version Control System

    Run git-daemon to serve /pub/scm from inetd.
    Запуск ГИТ-демона как сервиса /pub/scm из inetd.


    $ grep git /etc/inetd.conf
    git stream tcp nowait nobody \
    /usr/bin/git-daemon git-daemon --inetd --export-all /pub/scm


    Актуальная конфигурационная строка должна помещаться в одну строку.

    Запуск git-демона как сервиса /pub/scm из xinetd.


    $ cat /etc/xinetd.d/git-daemon
    # default: off
    # description: The git server offers access to git repositories
    service git
    {
    disable = no
    type = UNLISTED
    port = 9418
    socket_type = stream
    wait = no
    user = nobody
    server = /usr/bin/git-daemon
    server_args = --inetd --export-all --base-path=/pub/scm
    log_on_failure += USERID
    }


    Check your xinetd(8) documentation and setup, this is from a Fedora system.
    Проверьте вашу документацию по xinetd (8) настройки, вышеописанные строки соответсуют Fedora.
    В других дистрибутивах могут быть отличия. Give push/pull only access to developers.
    Дайте права доступа для push/pull только для разработчиков.


    $ grep git /etc/passwd (1)
    alice:x:1000:1000::/home/alice:/usr/bin/git-shell
    bob:x:1001:1001::/home/bob:/usr/bin/git-shell
    cindy:x:1002:1002::/home/cindy:/usr/bin/git-shell
    david:x:1003:1003::/home/david:/usr/bin/git-shell
    $ grep git /etc/shells (2)



    1.


    log-in shell is set to /usr/bin/git-shell, which does not allow anything but git push and git pull .
    2.


    Установите для входа пользователя в качестве shell /usr/bin/git-shell, которывй не позволяет ничего делать пользователю, кроме git push и git pull. Эти пользователи должны иметь ssh доступ к машине.
    3.


    in many distributions /etc/shells needs to list what is used as the login shell.
    4.


    Во многих дистрибутивах в /etc/shells нужно перечислять, какие пользователи используют при входе данный shell.

    Стиль общего CVS-репозитория.


    $ grep git /etc/group (1)
    git:x:9418:alice,bob,cindy,david
    $ cd /home/devo.git
    $ ls -l (2)
    lrwxrwxrwx 1 david git 17 Dec 4 22:40 HEAD -> refs/heads/master
    drwxrwsr-x 2 david git 4096 Dec 4 22:40 branches
    • rw-rw-r 1 david git 84 Dec 4 22:40 config
    • rw-rw-r-- 1 david git 58 Dec 4 22:40 description
    drwxrwsr-x 2 david git 4096 Dec 4 22:40 hooks
    • rw-rw-r-- 1 david git 37504 Dec 4 22:40 index
    drwxrwsr-x 2 david git 4096 Dec 4 22:40 info
    drwxrwsr-x 4 david git 4096 Dec 4 22:40 objects
    drwxrwsr-x 4 david git 4096 Nov 7 14:58 refs
    drwxrwsr-x 2 david git 4096 Dec 4 22:40 remotes

    $ ls -l hooks/update (3)

    • r-xr-xr-x 1 david git 3536 Dec 4 22:40 update
    $ cat info/allowed-users (4)
    refs/heads/master alice\|cindy
    refs/heads/doc-update bob
    refs/tags/v[0–9]* david


    1.


    разработчики должны входить в группу git.
    2.


    делаем общий репозиторий доступный для записиси членам группы.
    3.


    используем update-hook, например, от Carl из Documentation/howto/ для ветки политики контроля.
    4.


    alice and cindy can push into master, only bob can push into doc-update. Алиса и Синди могут делать git-push в master, однако Bob может делать push в doc-update. Давид – это релиз-менеджер и является единственным лицом, которые может создать и помещать теги в версии.

    HTTP-сервер для поддержки протокола передачи.


    dev$ git update-server-info (1)
    dev$ ftp user@isp.example.com (2)
    ftp> cp -r .git /home/user/myproject.git


    1.


    проверьте, что ваши info/refs objects/info/packsи актуальны.
    2.


    upload to public HTTP server hosted by your ISP.
    3.


    загрузите на публичный HTTP-сервер или сервер вашего провайдера.


     
    Файлов нет. [Показать файлы/форму]
    Комментариев нет. [Показать комментарии/форму]