Инструменты пользователя

Инструменты сайта


git

Назад

Учебник Хороший гайд

Источник

Начало работы с Bitbucket

Bitbucket - сервис хостинга и совместной разработки проектов (Git и Mercurial). Аналог всем известного GitHub. Основное его отличие - возможность создания закрытых бесплатных хранилищ (до 5 пользователей).

Bitbucket идеально подходит для работы над личным проектом (не показывая его всему миру) или для работы в небольшой команде.

Регистрация на сервисе очень простая: Bitbucket поддерживает OpenID, а это значит, что зарегистрироваться в Bitbucket можно через учетную запись, например в Google, Facebook или Twitter. При регистрации сервис предложит выбрать тип учетной записи: личная или комманда. Выбираем в зависимости от проекта. После регистрации у вас спросят, будете ли вы пользоваться паролем, или файл-ключем для доступа к системе. Проще выбрать пароль, безопаснее key-файл. После этого вам предложат создать свое первое хранилище в системе.

Работа с Bitbucket

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

Для создания нового проекта

Создаем в папку проекта

 mkdir /path/to/your/project

Переходим в нее

cd /path/to/your/project

Создаем репозиторий

git init

Устанавливаем сервер для синхронизации

git remote add origin https://имя_аккаунта@bitbucket.org/имя_аккаунта/имя_хранилища.git

Готовую ссылку можно скопировать из Bitbucket.

После этого необходимо наш проект за комитеть

git commit -m "coment"

Отправим файлы проекта на сервер

git push -u origin --all

Мои шпаргалки черновик

Как смотреть историю

git log --pretty=oneline --all				//Все
git log --pretty=oneline  				//однострочный формат
git log --pretty=oneline --max-count=2 			//Показать 2 последних
git log --pretty=oneline --since='5 minutes ago' 	//За последнии 5 минут
git log --pretty=oneline --until='5 minutes ago' 	//После 5 минут 
git log --pretty=oneline --author='your name'		//По автору
git log --graph 					//Просмотр лога Граф
git log --name-only -2 //Посмотреть список последних двух изменяемых коммитов

Alias

При неполном вводе команды Git не пытается догадаться, что за команду вы имели в виду. Но если мысль о вводе длинных команд вас не привлекает, команда git config позволяет легко создать псевдоним для любой из них. Вот пара примеров ее применения:

$ git config --global alias.co checkout
$ git config --global alias.br branch
$ git config --global alias.ci commit
$ git config --global alias.st status

Теперь вместо команды git commit достаточно будет ввести git ci.

.git/config

Или можно добавлять в файле .git/config:

[alias]
	co = checkout
	ci = commit
	st = status
	br = branch
	hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short
	type = cat-file -t
	dump = cat-file -p

Запуск сторонних программ

А что делать в случае, когда нужно запустить внешнюю команду, а не команду, встроенную в Git.

Такую команду следует начинать с символа !. Этот прием часто применяется при написании собственных инструментов для работы с Git-репозиторием. Вот пример создания псевдонима для команды git visual, служащей для запуска gitk:

git config --global alias.visual "!gitk"

Получение старых версий

git checkout <hash> - Передаем хеш версии 
git checkout master - Возвращаемся к последней версии («master» — имя ветки по умолчанию. Переключая имена веток, вы попадаете на последнюю версию выбранной ветки.)
git checkout hello.html - Отменить правки у текущего файла

Отмена индексирования

Предположим, вы отредактировали два файла и хотели бы зафиксировать их в двух разных коммитах, но случайно набрали команду git add *, что привело к их одновременному индексированию. Как отменить индексирование одного из них?

Сразу под текстом Changes to be committed написано, что для отмены индексирования следует воспользоваться командой git reset HEAD <имя файла>

git reset HEAD hello.html //Тут мы указали какой файл не должен идти в комит

С параметром –hard команда git reset может привести к опасным последствиям,так как в этом случае затрагиваются файлы в рабочей папке. Без этого параметра команда git reset совершенно безопасна, так как затрагивает только область индексирования.

Изменение последнего коммита

Скажем, если после фиксации очередной версии вы обнаружили, что забыли проиндексировать изменения в одном из файлов, который планировалось включить в новый коммит, можно сделать так:

git commit -m "изначальный коммит"
git add forgotten_file
git commit --amend

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

Перемещение файлов

mkdir lib
git mv hello.html lib

Игнорирование файлов .gitignore

Бывает так, что некоторый класс файлов вы не хотите ни автоматически добавлять в репозиторий, ни видеть в списке неотслеживаемых.

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

Вот правила для паттернов, которые можно вставлять в файл .gitignore.

  • Игнорируются пустые строки и строки, начинающиеся с символа #
  • Работают стандартные глобальные паттерны
  • Паттерны можно заканчивать слешем (/), указывая папку
  • Можно инвертировать паттерн, начав его с восклицательного знака (!)
# комментарий – это игнорируется
*.a # пропускать файлы, заканчивающиеся на .a
!lib.a # но отслеживать файлы lib.a, несмотря на пропуск файлов на .a
/TODO # игнорировать только корневой файл TODO, а не файлы вида subdir/TODO
build/ # игнорировать все файлы в папке build/
doc/*.txt # игнорировать doc/notes.txt, но не doc/server/arch.txt

--cached

Если нам надо удалить файл из журнала регистрации.

git rm --cached <file-name>

Теги

Git позволяет помечать определенные моменты истории тегами. Как правило, эту функциональность задействуют для пометки выходящих версий (v1.0 и т. п.).

Вывод списка тегов:

$ git tag
v0.1
v1.3

Кроме того, искать теги можно по шаблону. Предположим, вас интересуют только выпуски 1.8.5:

$ git tag -l ‚v1.8.5*'
v1.8.5
v1.8.5-rc0
v1.8.5-rc1
v1.8.5-rc2
v1.8.5-rc3
v1.8.5.1
v1.8.5.2
v1.8.5.3
v1.8.5.4
v1.8.5.5

Создание тегов

В Git используются два основных типа тегов: легковесные и снабженные комментарием.

Легковесный тег (lightweight tag) во многом напоминает не меняющуюся ветку — это просто указатель на конкретный коммит.

А вот теги с комментариями (annotated tags) хранятся в базе данных Git как полноценные объекты. Они обладают контрольной суммой; содержат имя человека, поставившего тег, адрес его электронной почты и дату создания; снабжены комментарием.

Теги с комментариями

$ git tag -a v1.4 -m 'my version 1.4'
$ git tag
v0.1
v1.3
v1.4

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

Для просмотра данных тега вместе с помеченным им коммитом служит команда git show:

$ git show v1.4
tag v1.4
Tagger: Ben Straub <ben@straub.cc>
Date: Sat May 3 20:19:12 2014 -0700
my version 1.4
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <schacon@gee-mail.com>
Date: Mon Mar 17 21:52:11 2008 -0700
changed the verison number

Легковесные теги

Для создания легковесного тега достаточно опустить параметры -a, -s и -m:

$ git tag v1.4-lw
$ git tag
v0.1
v1.3
v1.4
v1.4-lw

Ветки

Список веток

git branch

Создание новой ветки:

git branch testing

Смена веток

git checkout testing

Слияния веток

$ git checkout master //переходим на ветку master
$ git merge hotfix    //Мержим ветку hotfix с веткой master

После внедрения важного исправления можно вернуться к прерванной работе. Но сначала следует удалить ветку hotfix, так как она нам больше не понадобится, — на этот коммит уже указывает ветка master. Для этого достаточно добавить параметр -d к команде git branch:

$ git branch -d hotfix
Deleted branch hotfix (3a0874c).

Принудительно удалить ветку

$ git branch -D hotfix