# Процессы Ресурсы Цикл разработки ПО Waterfall RUP Agile Kanban Управление Архитектура Ресурсы ПО для Архитектора Кто архитекторы? Архитектурные слои язык Archimate GAP-анализ SOA Типы интеграции Vision (Концепция) Проектное решение ESB Микросервисы и service mesh HTTP/REST RPC DDD Анализ Ресурсы ПО для Аналитика Кто аналитики? Бизнес-процесс Требования Уровни и типы Источники Стейкхолдеры Нотации Сервисы DevOps CI/CD/CDP VM и Docker Контракты API Оценка задачи git Frontend Apache Регулярка Linux Тестирование Ресурсы QA и QC Цикл тестирования Уровни тестирования Виды тестирования Баг-репорт Тестирование требований Тест-анализ и тест дизайн Интеграционное, API, E2E Тест план Метрики качества Автотесты Selenium XPATH Нагрузочное Данные Ресурсы MDM Big data Об информации SQL intro MongoDB intro Библиотека Системная инженерия Станислав Лем Экстраполяция в будущее Политэкономия Сознание, интеллект

/ АНАЛИЗ АРХИТЕКТУРА ДАННЫЕ DevOps: + DevOps + Frontend + Apache web-server + Регулярные выражения - git | Почерпнуть мудрость | Установка git | ПО для работы с git посредством GUI | Терминология | Команды | Обычная схема работы | Создание проекта в GitLab | Правила синтаксиса gitignore | Изменения, коммиты | Проект с git + October + Apache + Javascript + Perl + Python + Ruby + Rust + Полезности в Windows + Linux Gaming Библиотека ПРОЦЕССЫ ТЕСТИРОВАНИЕ
git
latest update of the page: 27-01-2024, 09:53 UTC
Пользуясь git, легко прострелить себе ногу, но зато потом легко восстановить предыдущую ногу и слить её с бедром.
Почерпнуть мудрость
Установка git
sudo apt-get install git
ПО для работы с git посредством GUI
Терминология

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 не трогаем.
Что почитать на тему:
Создание проекта в GitLab
  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
  • Одна строчка — одно правило
  • Пустые строки игнорируются
  • Комментарии доступны через решётку(#) в начале строки
  • Символ "/" в начале строки указывает, что правило применяется только к файлам и папкам, которые располагаются в той же папке, что и сам файл .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

Проект с git + October + Apache
  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 .