# ПРОЦЕССЫ Ресурсы Цикл разработки ПО Waterfall RUP Agile Kanban Управление АРХИТЕКТУРА Ресурсы ПО для Архитектора Кто архитекторы? Архитектурные слои язык Archimate GAP-анализ SOA Типы интеграции Проектное решение ESB Микросервисы и service mesh HTTP/REST RPC DDD АНАЛИЗ Ресурсы ПО для Аналитика Кто аналитики? Бизнес-процесс Требования Уровни и типы Источники Стейкхолдеры Нотации Vision (Концепция) Сервисы 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: 01-03-2023, 21:31 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 .