• Работа с git, обширная статья
• Git Rebase: руководство по использованию
• 30 команд Git, необходимых для освоения интерфейса командной строки Git
• Gitlab CI для linux
• Создание, настройка и использование собственного Git-сервера

sudo apt-get install git

• Sourcetree
• gitk — git repository browse
  Графическая утилита, которая показывает граф версий. Установка:sudo apt-get install gitk

index — область зафиксированных изменений, т.е. всё то, что вы подготовили к сохранению в репозиторий;
HEAD — указатель на commit, в котором мы находимся;
master — имя ветки по-умолчанию, это тоже указатель на определённый коммит;
origin — имя удалённого репозитория по умолчанию (можно дать другое);

init	Create an empty Git repository or reinitialize an existing one. Создаёт пустой репозиторий в виде директории .git, в которой будет храниться вся информация о ходе разработки проекта
status	Show the working tree status. Показывает состояние вашего рабочей копии репозитория и где вы находитесь. Выводит информацию обо всех изменениях, внесённых в дерево директорий проекта по сравнению с последним коммитом рабочей ветки; отдельно выводятся внесённые в индекс и неиндексированные файлы Также указывает файлы с неразрешёнными конфликтами слияния (merge) и файлы, игнорируемые git.
add	Add file contents to the index git add . — добавить все локальные изменения в индекс (. = текущая папка) git add [path_to_file] — добавить конкретный файл в индекс
rm	Remove files from the working tree and from the index git rm [path_to_file] — убрать файл из рабочего древа и из индекса git rm 'd/*' — убрать всё содержимое папки d git rm 'd*' — убрать папки d, d2 и их содержимое
commit	Record changes to the repository git commit -a — сделать коммит, автоматически индексируя изменения в файлах проекта. Новые файлы при этом индексироваться не будут! Удаление же файлов будет учтено. git commit -m "commentary for commit" — добавить к коммиту комментарий прямо в командной строке, а не через текстовый редактор
bisect	Find by binary search the change that introduced a bug
branch	List, create, or delete branches git branch — показать список веток git branch <branchname> — создать ветку с именем branchname git branch -D [branch_name] — удалить локальную ветку со всеми изменениями
checkout	Checkout a branch or paths to the working tree (взять из репозитория какое-либо его состояние) git checkout [commit_hash or tag] — переключиться на коммит или тег git checkout [filename] — отменить локальные изменения по конкретному файлу (текущая ветка) git checkout [some-branch-name] [file-name] — откатить локальные изменения по файлу до определённой ветки git checkout [some-commit-hash] [file-name] — откатить локальные изменения по файлу до определённого коммита
clean	git clean -d -f — удалить все добавленные файлы и каталоги
clone	Clone a repository into a new directory
diff	Show changes between commits, commit and working tree, etc git diff — все отличия с последнего коммита git diff [path_to_file] — все отличия в конкретном файле с последнего коммита
fetch	Download objects and refs from another repository. Получить изменения. Однако, локально никаких изменений не будет. Git не тронет рабочую копию,ветки и т.д. Будут скачаны новые коммиты, обновлены только удалённые (remote) ветки и тэги. Это полезно потому, что перед обновлением своего репозитория можно посмотреть все изменения, которые "пришли" к вам.
grep	Print lines matching a pattern
log	Show commit logs. Войти в режим чтения лога. PgUp/PgDown — листать, Q — выйти.
merge	Join two or more development histories together
mv	Move or rename a file, a directory, or a symlink
pull	Fetch from and integrate with another repository or a local branch. (git fetch + git merge) Выполнение git pull как правило извлекает (fetch) данные с сервера, с которого вы изначально склонировали, и автоматически пытается слить (merge) их с кодом, над которым вы в данный момент работаете.
push	Update remote refs along with associated objects
rebase	Forward-port local commits to the updated upstream head git rebase -i HEAD~3 — открыть для редактирования историю коммитов — 3 последних коммита. Чтобы удалить коммит — нужно полностью удалить его строку (pick ...).
reset	Reset current HEAD to the specified state git reset --hard — удалить все локальные изменения, без возможности вернуть их git reset --hard origin/master — удалить все локальные изменения и вернуть локаль на точно то состояние в каком находится в удалённом репозитории (в данном, с именем origin) ветка master
restore	a tool to revert non-commited changes like: changes in your working copy or content in your index (a.k.a. staging area). git restore [--worktree] <file> git restore folder/mojolicious.pl — удалить все локальные изменения в файле mojolicious.pl
show	Show various types of objects
tag	Create, list, delete or verify a tag object signed with GPG git tag -d <tagname> — удалить локально тэг <tagname>; git tag -l | xargs git tag -d — удалить все локально хранящиеся тэги;

• Ветка master всегда эквивалентна Продакшену
• Ветка develop предназначена для Разработки
  Перед релизом обязательно сливаться в master.
  Также полезным будет слить master в develop.
  Если develop не сливать в master, то через несколько итераций расхождение веток может стать критическим.
• Ветка issue-123 создается по тикету #123.
  Создается из master и мерджится в develop.
  Если ей для работы нужны другие задачи, то они мерджатся в нее.
  Ни в коем случае нельзя в нее мерджить develop, ибо может потребоваться выкатить эту задачу до полного релиза с мерджем develop в master, а в этот момент в develop может быть еще не доработанная или не до тестированная фича.
• Ветка fix-456 hotfix по тикиту #456 со срочными правками.
  Создается из master и мерджится в master, develop и другие активные ветки по необходимости.
  Далее выкатывается master с hotfix-ами.
  Ветку develop не трогаем.

1. Создаём пустой проект на GitLab
2. Опционально, глобальные настройки для локальной машины: git config --global user.name "GreatUserName" git config --global user.email "email@email.em"
3. Заходим в каталог с проектом
4. git init
5. git remote add origin git@gitlab.com:GitAccountUsername/GitProjectName.git
6. Добавляем всё содержимое текущего каталога в гит-индекс: git add .
7. Например, мне нужно игнорировать подкаталог /log, потому что на локалке у меня одно, а на рабочем сервере — другое. Для этого открываем для редактирования файл .git/info/exclude — и добавляем туда правило, например log/: nano .git/info/exclude ВАЖНОЕ ПРИМЕЧАНИЕ. Все правила исключений прописанные в exclude — распространяются только на проект на текущей локальной машине.
   Для того чтобы, например, такие же правила работали и у тех кто будет стягивать (pull) проект чтобы затем его править и заливать (push) в общий репозиторий — надо уже создать файл .gitignore в корневой каталог проекта, в котором прописать это же правило, чтобы этот файл при моём push залился в общий репозиторий, чтобы при pull он появился у тех кто это делает, и при их push'ах у них тоже игнорился подгаталог log.
   Правила синтаксиса gitignore
8. Чтобы работать с удалённым общим репозиторием, нужен SSH-ключ.
   Смотрим, есть ли у нас уже готовый: cat ~/.ssh/id_rsa.pub Если ключ уже есть, то копируем и на gitlab добавляем его в profile-->SSH keys.
9. Если нет, то генерируем: ssh-keygen -t rsa -C "email@email.em"
10. Смотрим его cat ~/.ssh/id_rsa.pub Копируем и на gitlab добавляем его в profile-->SSH keys.
11. Записываем изменения в локальный репозиторий (гитовский каталог .git в каталоге проекта) git commit Нас попросят ввести описание коммита. Вводим, сохраняем.
12. Заливаем изменения в локальной репозитории в репозиторий gitlab в ветку master: git push -u origin master Выполнив команду git push -u origin master вы устанавливаете связь между той веткой, в которой вы находитесь и веткой master на удалённом сервере. Команду требуется выполнить единожды, чтобы потом можно было отправлять/принимать изменения лишь выполняя git push из ветки без указания всяких алиасов для сервера и удалённых веток. Это сделано для удобства.

• Одна строчка — одно правило
• Пустые строки игнорируются
• Комментарии доступны через решётку(#) в начале строки
• Символ "/" в начале строки указывает, что правило применяется только к файлам и папкам, которые располагаются в той же папке, что и сам файл .gitignore
• Доступно использовать спецсимволы: звёздочка(*) заменяет любое количество символов(ноль или больше), вопросик(?) заменяет от нуля до одного символа. Можно размещать в любом месте правила
• Две звёздочки(**) используются для указания любого количества поддиректорий, подробнее смотри ниже в примерах
• Восклицательный знак(!) в начале строки означает инвертирование правила, необходим для указания исключений из правил игнорирования
• Символ "\" используется для экранирования спецсимволов, например, чтобы игнорировать файл с именем "!readme!.txt", нужно написать такое правило: "\!readme!.txt"
• Для игнорирования всей директории, правило должно оканчиваться на слэш(/), в противном случае правило считается именем файла.

Примеры:

*.zip *.log *.pdf *.xls	Игнорирование по типу файла, будут игнорироваться в АБСОЛЮТНО всех директориях. Например /files/data.zip, /server.log, /uploads/users/data/info.xls
config.php	Игнорирование файла во ВСЕХ директориях. Например /params/db/config.php, /config.php
/config.php	Игнорирование конкретного файла ТОЛЬКО в корне проекта (корнём считается расположение файла .gitignore) Например НЕ БУДЕТ проигнорирован файл /db/config.php
/params/config.php	Игнорирование конкретного файла ТОЛЬКО в указанной директории Например НЕ БУДЕТ проигнорирован файл /prod/params/config.php
/images/*	Игнорирование всех файлов и папок ТОЛЬКО в конкретной директории(включая поддиректории и файлы в них) Например /images/user.jpg, /images/company/logo.png НЕ БУДУТ проигнорированы файлы и папки /prod/images/user.jpg
images/*	Игнорирование всех файлов и папок в ЛЮБЫХ директориях с указанным именем Например /images/user.jpg, /core/images/user.jpg
/private/*.html	Игнорирование ВСЕХ html-файлов в ОДНОЙ КОНКРЕТНОЙ директории(НЕ ВКЛЮЧАЯ поддиректории) Например /private/index.html НЕ БУДУТ проигнорированы файлы в /private/ivan/index.html
/private/**/*.html	Игнорирование ВСЕХ html-файлов в КОНКРЕТНОЙ директории ВКЛЮЧАЯ поддиректории Например /private/info.html, /private/users/ivan/info.html
/secret/* !/secret/free.txt	Исключение из игнорирования Игнорирование ВСЕХ файлов и папок внутри директории /secret, за исключением файла /secret/free.txt, он не будет проигнорирован
\!readme!.txt	Игнорирование файла с именем, содержащим спецсимволы Например !readme!.txt
/images/h?/*.jp?g	Игнорирование всех JPG и JPEG файлов внутри директорий, которые начинаются на "h" и МОГУТ содержать ещё один символ после Например /images/h4/user.jpg, /images/h/company.jpeg

Итак, у вас имеется настоящий Git-репозиторий и рабочая копия файлов для некоторого проекта. Вы будете делать какие-то изменения и фиксировать "снимки" состояния (snapshots) этих изменений в вашем репозитории каждый раз, когда проект достигает состояния, которое вам хотелось бы сохранить.

Каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: под версионным контролем (отслеживаемые) и нет (неотслеживаемые). Отслеживаемые файлы — это те файлы, которые были в последнем слепке состояния проекта (snapshot); они могут быть неизменёнными, изменёнными или подготовленными к коммиту (staged). Неотслеживаемые файлы — это всё остальное, любые файлы в вашем рабочем каталоге, которые не входили в ваш последний слепок состояния и не подготовлены к коммиту. Когда вы впервые клонируете репозиторий, все файлы будут отслеживаемыми и неизменёнными, потому что вы только взяли их из хранилища (checked them out) и ничего пока не редактировали.

Как только вы отредактируете файлы, Git будет рассматривать их как изменённые, т.к. вы изменили их с момента последнего коммита. Вы индексируете (stage) эти изменения и затем фиксируете все индексированные изменения, а затем цикл повторяется.

Основной инструмент для определения состояния файлов — команда git status (помимо прочего — показывает вашу текущую ветку).

Сделать коммит (при этом комментарий к коммиту вам будет предложено ввести в открывшемся консольном редакторе): git commit Сделать коммит, сразу указав комментарий: git commit -m "ваш комментарий к коммиту"

Если гит увидит разницу в отсутствии файла, наличии нового файла, изменение содержания файла — он сообщит об этом. Выглядеть это будет примерно так: ╚>$ git commit On branch master Your branch is up-to-date with 'origin/master'. Changes not staged for commit: modified: templates/git.html modified: templates/index.html no changes added to commit В этом случае, чтобы проиндексировать эти файлы, для каждого из них надо выполнить команду git add [pathtofile/filename] В случае когда файлов много — можно воспользоваться командой git commit -a Гит пройдётся по проекту и найдёт все изменения в файлах и удалённые файлы — и учтёт их.
Однако, он не проиндексирует новые файлы. Для того чтобы добавить в индекс файл, который только появился (раньше не было в репозитории), выполняем команду git add [pathtofile/filename]

Запушить изменения на сервер git'а: git push -u origin master

Ресурсы:

• Углублённо ознакомиться со всеми командами git'а можно этой замечательной статье
• Почитать хелп прямо в консоли можно командой git help [gitcommand], например git help push

1. подготовка всей херни:sudo apt-get install curl git apache2 mysql-server php5 libapache2-mod-php5 php5-cli php5-json php5-curl php5-mcrypt php5-gd php5-mysql
2. клонировать репозиторий кодошколы и зайти в каталог проекта:git clone http://gitlab.pfrus.com/<owner>/<projectname>.git cd <projectfolder>
3. скачать Composer, запустить mcrypt, установить Composer, сгенерить ключ, перезапустить Apache:curl -sS https://getcomposer.org/installer | php sudo php5enmod mcrypt php composer.phar install -vvv php artisan key:generate sudo /etc/init.d/apache2 restart
4. В каталоге config/dev создать файл database.php (скопировать содержимое из database.example.php)cp config/database.example.php config/dev/database.phpоткрыть его для редактированияnano config/dev/database.phpи настроить в нем свою базу, прописав в соответствующих полях имя БД, логин от MySQL юзера (обычно root) и пароль от юзера, например: 'mysql' => [ 'driver' => 'mysql', 'host' => 'localhost', 'port' => '', 'database' => 'projectdb', 'username' => 'root', 'password' => 'passward', 'charset' => 'utf8', 'collation' => 'utf8_unicode_ci', 'prefix' => '', ],
5. В корне проекта создать файл ".env", содержащий следующую строку "APP_ENV = dev". Это чтобы не менять настройки в конфиге на локале и сервере. 2 разных енва — разные настройки. APP_ENV — только для того чтобы вы видели какой энвайромент.
6. Создать бд в MySQL:mysql -u root -pCREATE DATABASE proejctdb;exit;
7. Сделать миграцию в БД:php artisan october:up
8. Создать файл с конфигурацией Apache для хоста проектаsudo nano /etc/apache2/sites-available/project.confстроки: Listen 80 <VirtualHost *:80> ServerName project.dev ServerAdmin webmaster@localhost DocumentRoot /home/progforce/project <Directory /home/progforce/project > Require all granted AllowOverride all </Directory> ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost> Listen 80 ставить только если хотим подосединяться откуда-то извне.
9. Добавить в список хостовsudo nano /etc/hostsстроку:127.0.0.1 project.dev
10. Активация настроек Apache для проектаsudo a2ensite projectВключение rewrite для Apachesudo a2enmod rewriteПерезапуск Apacheservice apache2 reloadsudo /etc/init.d/apache2 restartПоднять Octoberphp artisan october:upНастройка прав и владельцев для папок (Apache является пользователем группы www-data, для него и разграничиваем):sudo chown -R root:www-data .sudo chmod -R 774 .