HPUNIX Сайт о ОС и не только!

Моя шпаргалка по работе с Git

28 января 2011 - unix
Моя шпаргалка по работе с Git

 

Недавно я открыл для себя Git. И понимаете, я проникся. По-настоящему проникся.

Сейчас я использую Git не только лишь на работе (где я с ним, фактически, познакомился), да и для собственных проектиков, которые я стал хранить на BitBucket. Последний начал поддерживать Git относительно не так давно. В отличии от GitHub, BitBucket позволяет совсем безвозмездно создавать как открытые, так и закрытые репозитории.

В чем состоит отличие Git от Subversion?

Главное отличие Git от Subversion состоит в том, что Git — распределенная система контроля версий. Звучит ужасающе, но на практике это значит очень ординарную вещь. Каждый разработчик держит у себя на диске отдельный репозиторий.

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

Пока мы работаем в рамках собственного репозитория, все происходит в точности, как в Subversion. Мы коммитим и откатываем конфигурации, создаем, мерджим и удаляем бранчи, разрешаем конфликты и тд.

Кроме этого, предусмотрены команды для работы с репозиториями на удаленных машинах. К примеру, «git push» значит мердж локальных конфигураций в удаленный репозиторий, а «git pull» — напротив, мердж конфигураций из удаленного репозитория в локальный. Обмен данными по сети обычно происходит с внедрением протокола SSH.

В итоге имеем:

 
  • Git присущи все те же достоинства от использования VCS, что мы получаем в Subversion.
  • Git дает нам обычное шифрование «из коробки», безо всяких танцев с бубнами, как в случае с Subversion.
  • Если сервер с «главным» репозиторием, куда пушат свои конфигурации все разработчики (хотя формально в Git нет никакого «главного» репозитория), вдруг прилег — ничего ужасного. Делаем коммиты в локальный репозиторий и ждем, когда сервер возвратится.
  • Даже если сервер доступен, все равно удобнее сделать пяток локальных коммитов, а потом выслать их на сервер одним пушем.
  • Сервер вообщем не нужен. Вы сможете использовать Git только локально. И не непременно для работы с исходниками. К примеру, можно использовать Git для того, чтоб иметь возможность откатиться к предшествующим версиям файлов (каких-нибудь электрических таблиц) либо возвратить случаем удаленные. А в этой заметке рассказывается, как хранить git-репозиторий на флешке.
  • Git не раскидывает по каталогам служебную информацию (помните «.svn»?), заместо этого она хранится исключительно в корне репозитория.
  • Git сегодня очень моден (хотя это далековато не единственная распределенная система контроля версий, к примеру, есть Mercurial и Darcs), в связи с чем вырастает число разработчиков, использующих его. Как следствие, используя Git, легче получить помощь на каком-нибудь форуме либо собрать команду разработчиков, знакомых с этой VCS.
  • Существует огромное количество нужных утилит для работы с Git — Qgit, gitk, gitweb и другие. «Из коробки» есть импорт и экспорт в/из Subversion/CVS.
  • Git поддерживают многие хостинги репозиториев (GitHub, BitBucket, SourceForge, Гугл Code, …) — есть из чего избрать.
  • Большой популярностью пользуется GitHub. Используя Git, вы увеличиваете возможность того, что кто-то захотит безвозмездно написать патч для вашего OpenSource проекта.

Пример использования Git

Я использовал Git при написании программки из заметки Генерация практически осмысленных текстов на Haskell, сидя под собственной возлюбленной FreeBSD. Так приблизительно смотрелась моя работа с Git.

Сначала нужно поставить Git:

pkg_add -r git

Потом создаем пару ssh ключей, если не делали ее ранее:

ssh-keygen
cat ~/.ssh/id_rsa.pub

Заходим на БитБакет, создаем git-репозиторий под новый проект, а в свойствах аккаунта прописываем собственный открытый ssh-ключ. Потом клонируем репозиторий:

cd ~/projects/haskell
git clone git@bitbucket.org:afiskon/hs-textgen.git
cd hs-textgen

Делаем какие-то конфигурации:

echo test > TODO.TXT

Добавляем новый файл в репозиторий и делаем коммит:

git add TODO.TXT
git commit -a

Так как я не указал описание коммита, запускается редактор VIM, при помощи которого я и ввожу описание. Потом я отправляю все изготовленные мною конфигурации на БитБакет:

git push origin

Допустим, сейчас я желаю сделать некие конфигурации в проекте, но не уверен, выйдет ли из этого что-то не плохое. В таких случаях создается новенькая ветка:

git branch new_feature
git checkout new_feature

Работаем с этой веткой. Если ничего неплохого не вышло, возвращаемся к основной ветке (она же «trunk» либо «ствол»):

git checkout master

Если вышло что-то не плохое, мерджим ветку в master (о разрешении конфликтов поведано в последующем параграфе):

git commit -a # делаем коммит всех конфигураций в new_feature

Моя шпаргалка по работе с Git

git checkout master # переключаемся на master
git merge new_feature # мерджим ветку new_feature

Не забываем временами отправлять наш код на BitBucket:

git push origin

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

git pull origin

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

Одна из традиционных ошибок при начале работы с Git заключается в push’е всех ветвей, а не только лишь той, с которой вы работали. Вообщем я бы рекомендовал 1-ое время перед выполнением каждого push делать паузу с тем, чтоб помыслить, что и куда на данный момент уйдет.

Для большей безопасности советую при генерации ssh-ключей указать пароль. Тогда каждый запрос пароля со стороны Git будет вам сигналом «Эй, ты делаешь что-то, что затронет других».

Для работы с Git под Windows можно пользоваться клиентом TortoiseGit. Если память не изменяет, для обычной работы ему нужен MSysGit. Для генерации ключей можно пользоваться утилитой PuTTyGen, только не забудьте экспортировать открытый ключ в правильном формате, «Conversions → Export OpenSSH key».

Необходимо подчеркнуть, что мне лично TortoiseGit показался каким-то глючноватым и вообщем не очень комфортным. Может быть, это всего только дело привычки, но мне кажется намного удобнее работать с Git из консоли, чем при помощи контекстного меню в Проводнике.

Так что по способности я бы рекомендовал работать с Git в Юниксах. В последнем случае можно поставить виртуальную машину, установить под ней FreeBSD (безо всяких GUI) и работать в этой виртуальной машине.

Шпаргалка по командам

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

Сделать новый репозиторий:

git init project-name

Клонировать репозиторий с удаленной машины:

git clone git@bitbucket.org:afiskon/hs-textgen.git

Добавить файл в репозиторий:

git add text.txt

Моя шпаргалка по работе с Git

Удалить файл:

git rm text.txt

Текущее состояние репозитория (конфигурации, неразрешенные конфликты и тп):

git status

Сделать коммит:

git commit -a -m "Commit description"

Сделать коммит, введя его описание при помощи $EDITOR:

git commit -a

Замерджить все ветки локального репозитория на удаленный репозиторий:

git push origin

Аналогично предшествующему, но делается пуш только ветки master:

git push origin master

Запушить текущую ветку, не вводя полностью ее заглавие:

git push origin HEAD

Замерджить все ветки с удаленного репозитория:

git pull origin

Аналогично предшествующему, но накатывается только ветка master:

Моя шпаргалка по работе с Git

git pull origin master

Накатить текущую ветку, не вводя ее длинноватое имя:

git pull origin HEAD

Скачать все ветки с origin, но не мерджить их в локальный репозиторий:

git fetch origin

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

git fetch origin master

Начать работать с веткой some_branch (уже имеющейся):

git checkout -b some_branch origin/some_branch

Сделать новый бранч (ответвится от текущего):

git branch some_branch

Переключиться на другую ветку (из числа тех, с которыми уже работаем):

git checkout some_branch

Получаем перечень ветвей, с которыми работаем:

git branch # звездочкой отмечена текущая ветвь

Просмотреть все имеющиеся ветки:

git branch -a # | grep something

Замерджить some_branch в текущую ветку:

git merge some_branch

Удалить бранч (после мерджа):

git branch -d some_branch

Просто удалить бранч (тупиковая ветвь):

git branch -D some_branch

Последние конфигурации:

git log

История определенного файла:

git log file.txt

Аналогично предшествующему, но с просмотром изготовленных конфигураций:

git log -p file.txt

История с названиями файлов и псевдографическим изображением бранчей:

git log --stat --graph

Конфигурации, изготовленные в данном коммите:

git show d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4

Поглядеть, кем в последний раз правилась любая строчка файла:

git blame file.txt

Удалить бранч из репозитория на сервере:

git push origin :branch-name

Откатиться к определенному коммиту (хэш смотрим в «git log»):

git reset --hard d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4

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

git reset --soft d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4

Попробовать направить данный commit (но почаще употребляется branch/reset + merge):

git revert d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4

Просмотр конфигураций (суммарных, а не всех по очереди, как в «git log»):

git diff # подробности см в "git diff --help"

Используем vimdiff в качестве программки для разрешения конфликтов (mergetool) по дефлоту:

git config --global merge.tool vimdiff

Отключаем диалог «какой mergetool вы желали бы использовать»:

git config --global mergetool.prompt false

Разрешение конфликтов (когда оные появляются в итоге мерджа):

git mergetool

Создание тэга:

git tag some_tag # за тэгом можно указать хэш коммита

Удаление untracked files:

git clean -f

«Упаковка» репозитория для ускорения работы с ним:

git gc

Необходимо подчеркнуть, что Git позволяет использовать маленькую запись хэшей. Заместо «d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4» можно писать «d8578edf» либо даже «d857».

Создание блога на PHP часть 2: Git

Дополнительные материалы

В качестве источников дополнительной инфы я бы рекомендовал следующие:

  • Why Git is Better than X;
  • Хабростатья «Почему Git?»;
  • Хабровопрос о преимуществах Git и других DVCS;
  • Книжка «Pro Git» на российском языке;
  • Книжка «Волшебство Git» на российском языке;
  • How To Create a Remote Shared Git Repository;

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

Дополнение: См также заметку Как я выбирал меж GitHub и BitBucket.

 

Похожие статьи

  • Мой 1-ый опыт работы с Subversion

    Я издавна знал, что воспользоваться системой контроля версий — верно и полезно. Но все было как-то неохота. Ну вы в курсе, как это бывает.

    И вот, чуть раньше, лень удалось побороть. Выбор...

  • Уголок кэпа Восемь тыщ двести двенадцать о поиске работы, собеседованиях и тп

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

  • Шпаргалка по работе с DBIxClass

    Отлично обмысленный ORM может значительно упростить жизнь программеру. Но если это так, то откуда берутся клики, что «ORM — это антипаттерн»? Думается, дело в том, что не все ORM идиентично неплохи...

  • Моя шпаргалка по работе в Vim

    Самое главное — побороть боязнь белоснежного листа. Я всегда говорю это для себя, когда необходимо начать работу над кое-чем и не знаешь, как подступиться. Так что я решил не разламывать голову над тем, о чем будет пе...

  • Мысли вслух о работе и искусстве

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

Рейтинг: +12 Голосов: 248 3499 просмотров
Комментарии (1)
Дмитрий # 29 декабря 2015 в 04:38 0
Полезная статья, спасибо. Но когда читал, было стойкое ощущение, что автор статьи Кличко - очень похож стиль изложения) Без обид)
Найти на сайте: параметры поиска

Windows 7

Среда Windows 7 на первых порах кажется весьма непривычной для многих.

Windows 8

Если резюмировать все выступления Microsoft на конференции Build 2013.

Windows XP

Если Windows не может корректно завершить работу, в большинстве случаев это

Windows Vista

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