Как узнать в git, на какой тег у вас сейчас переключена рабочая копия ?

На помощь приходит команда:
git log --decorate

Результатом будет что-то похожее на это:

commit a8662ef8bf021ea349dbf56970fd9f62f97093fb (HEAD, tag: test-live-0.0.2, tag: live-0.0.2)
Author: Vasya Pupkin <v.pupkin@gmail.com>
Date:   Fri May 11 09:25:15 2012 +0300

    Some message

commit 43a6228d4bf5839aa934b541c35d19b897b35056 (tag: live-0.0.1)
Author: Vasya Pupkin <v.pupkin@gmail.com>
Date:   Thu May 10 17:47:23 2012 +0300

    Some message



Если же вы сейчас свичнуты на один из коммитов ветки мастер, то вы увидите что-то такое:

commit ab39d94c48d4ef31bb2dbe16bce77c389c2c3c4d (HEAD, origin/master, origin/HEAD, master)
Author: Vasya Pupkin <v.pupkin@gmail.com>
Date:   Fri May 11 10:46:55 2012 +0300

    Some message

commit a8662ef8bf021ea349dbf56970fd9f62f97093fb (tag: test-live-0.0.2, tag: live-0.0.2)
Author: Vasya Pupkin <v.pupkin@gmail.com>
Date:   Fri May 11 09:25:15 2012 +0300

    Some message

commit 43a6228d4bf5839aa934b541c35d19b897b35056 (tag: live-0.0.1)
Author: Vasya Pupkin <v.pupkin@gmail.com>
Date:   Thu May 10 17:47:23 2012 +0300

    Some message

Very useful "core.sharedRepository" property in config file of Git repository for sharing repository with another users

The quote from 'git help config':


core.sharedRepository
When group (or true), the repository is made shareable between several users in a group (making sure all the files and objects are group-writable). When all (or world or everybody), the repository will be readable by all users, additionally to being group-shareable. When umask (or false), git will use permissions reported by umask(2). When 0xxx, where 0xxx is an octal number, files in the repository will have this mode value.  0xxx will override user’s umask value (whereas the other options will only override requested parts of the user’s umask value). Examples: 0660 will make the repo read/write-able for the owner and group, but inaccessible to others (equivalent to group unless umask is e.g.  0022). 0640 is a repository that is group-readable but not group-writable. See git-init(1). False by default.

Как восстановить в git файл, удаленный с помощью git rm ?

Октябрь 24, 2011

Предположим, что мы для некого файла выполнили команду git rm.
А потом вдруг неожиданно решили, что этот файл нам все-таки нужен!

Спасенье есть! Вот оно:

git checkout – <deleted_file>

P.S.: 
Есть еще замечательная команда:

git ls-files --deleted 

, возвращает список удаленных файлов.

Октябрь 19, 2011

11:31 am: (Git) Revert files with changed mode, not content
(repost http://www.commandlinefu.com/commands/view/3527/git-revert-files-with-changed-mode-not-content)

Скрипт модифицирован.
git diff --numstat | awk '{if (($1 == "0" && $2 == "0") || ($1 == "-" && $2 == "-")) print }' | cut -c 5- | sed 's%^\(.*\)$%"\1"%' | xargs git checkout HEAD

Как с помощью git создать патч, а потом применить его не используя git ?

Август 30, 2011

Создание патча
git diff --no-prefix > some_thing.patch

Применение патча
patch -p0 < some_thing.patch

И не забывайте про опцию -pN. От нее зависит в какой директории вы должны находиться при выполнении команды patch

Она задает кол-во слешей, которое будет "отброшено" при определении пути к файлу, который нужно пропатчить (см. содержимое файла some_thing.patch)

Детальную информацию про patch можно почитать тут:
https://www.evernote.com/shard/s27/sh/3ac87731-9990-4e4c-870d-9a970a359fea/188b8af9e105e7431bb706f6d784ad4c

Решена проблема с поломкой конфигурационных файлов в /etc в Linux

Март 3, 2011

Обычная проблема -- установили систему. Потом что-то где-то поменяли и все перестало работать.
Иногда помогает, если сделал копию конфигурационных файлов, перед тем, как что-то меняешь...
Но это же так впадло иногда бывает...

В общем вот выход из ситуации.
- Устанавливаете Linux. Устанавливаете git.
- Переходите в директорию /etc.
- Создаете репозитогий git:
git init
- Добавляете все файлы:
git add
- Делаете коммит:
git commit

Все! Теперь любые изменения можно увидеть выполнив команду
git diff

И снова git. Однострочник на shell. Список всех измененных файлов за 3 последних коммита

Январь 25, 2011

git log --name-only HEAD^^^..HEAD --format=format:""|sort|uniq

Git. "Для тех, кто в танке..."

Январь 6, 2011

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

Несколько заметок.

1. Как я понял, gitosis служит для того, чтобы реализовывать нормальные права доступа к git-репозитариям для разных пользователей. В противном случае (при использовании ssh и если gitosis не использовать) все пользователи будут иметь права на запись в репозитарий. Хотя может быть я что-то не так понял. Я не уверен на счет вышенаписанного.

gitosis работает следующим образом. В когда мы добавили в файл /home/git/.ssh/autorized_keys ключ для пользователя, который имеет права администрирования репозитариев, то в данный файл не просто добавился ключ,а добавилась команда, которая будет запускаться при входе через ssh на данный сервер. Т.е. при входе через ssh на сервере запускается команда gitosis-serve, которая перехватывает соединение и обрабатывает все последующие команды. Таким образом мы не можем зайти с помощью клиента ssh на сервер под пользователем git (для которого настроен gitosis). Под данным пользователем может работать только git.

2. Есть возможность более тонкой настройки прав. Для этого можно использовать Gitolite.
http://progit.org/book/ch4-8.html
Gitolite allows you to specify permissions not just by repository, but also by branch or tag names within each repository. That is, you can specify that certain people (or groups of people) can only push certain “refs” (branches or tags) but not others.

3. Книга про git.
http://progit.org/book/