FPC git/ru

│ English (en) │ русский (ru) │

Настройка Git

Расположение репозитория Git

Репозитории Git размещены на Gitlab:

Компилятор FPC, RTL, пакеты и утилиты находятся здесь:

https://gitlab.com/freepascal.org/fpc/source

URL-адрес для клонирования репозитория:

https://gitlab.com/freepascal.org/fpc/source.git

git clone https://gitlab.com/freepascal.org/fpc/source.git

Репозиторий документации Git находится здесь:

https://gitlab.com/freepascal.org/fpc/documentation

URL-адрес для клонирования репозитория документации:

https://gitlab.com/freepascal.org/fpc/documentation.git

git clone https://gitlab.com/freepascal.org/fpc/documentation.git

Репозиторий Git веб-сайта находится здесь:

https://gitlab.com/freepascal.org/fpc/website

URL-адрес для клонирования репозитория веб-сайта:

https://gitlab.com/freepascal.org/fpc/website.git

git clone https://gitlab.com/freepascal.org/fpc/website.git

Ваша идентификация в git

Чтобы ваши коммиты были распознаны, настройте локальный (а еще лучше глобальный) git Установка, чтобы использовать адрес, связанный с вашей учетной записью gitlab.

git config --global user.email your.email.user@youremail.host

Это установит ваш адрес электронной почты для всех репозиториев git, которые вы используете, и позволит интерфейсу gitlab правильно связывать коммиты с пользователями в своем HTML-интерфейсе.

Если у вас несколько учетных записей gitlab (или даже github), вы можете предпочесть установить этот адрес электронной почты только локально:

git config --local user.email your.email.user@youremail.host

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

HTTP-доступ и учетные данные

Если вы получаете доступ к репозиторию с помощью HTTPS, по умолчанию git запрашивает имя пользователя и пароль. Вы можете указать git хранить их постоянно, введите следующую команду:

git config --global credential.helper store

Есть и другие возможности для хранения этой информации. Более подробную информацию можно найти на

https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage

Использование токенов доступа

Вы можете использовать токен доступа и доступ по протоколу HTTPS, это имеет некоторые преимущества. Это поддерживается большинством современных клиентов git:

https://knasmueller.net/gitlab-authenticate-using-access-token

и здесь вы можете увидеть, как это сделать на gitlab:

https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html

Преимущество использования токена доступа заключается в том, что ему могут быть предоставлены ограниченные права на gitlab, например, только доступ к репозиторию. Это также означает, что вы можете легко включить 2FA (двухфакторная аутентификация) для своей учетной записи gitlab.

Модель ветвления

На первом этапе будет использоваться модель ветвления, используемая в Subversion: исправления вносятся в основной ветке, а затем объединяются в ветку исправлений.

На более позднем этапе модель ветвления может быть изменена на одну из многих схем ветвления git.

Git-клиенты Windows

В macOS, Linux и BSD команда git устанавливается вместе с системным диспетчером пакетов (в macOS необходимо установить инструменты командной строки XCode). В Windows необходимо установить отдельный клиент git. Их много, но наиболее популярными являются следующие:

• Git для Windows: клиент командной строки с оболочкой bash, поэтому вы можете копировать и вставлять команды, которые вы найдете в Интернете:

https://gitforwindows.org/

• TortoiseGit интегрируется с проводником Windows, как и TortoiseSVN:

https://tortoisegit.org/

если у вас уже установлен TortoisSVN, оба могут работать бок о бок.

• Sourcetree - бесплатный клиент для Windows и macOS:

https://www.sourcetreeapp.com/

сделано людьми из bitbucket.

• Smartgit работает в Windows, Linux и macOS:

https://www.syntevo.com/smartgit/

• Редакторы VSCode и Atom имеют встроенную поддержку git.

Понятия и различия между SVN и GIT

Несколько "полезных" отличий: FPC_git_concepts

Общие операции SVN в Git

Check out

Получение новой копии репозитория в git называется «клонированием».

git clone https://gitlab.com/freepascal.org/testconversion

Как и в случае с Subversion, вы можете дать ему другое имя:

git clone https://gitlab.com/freepascal.org/testconversion myconversion

Эта операция может занять некоторое время, исходная база FPC большая.

Update

Обновление исходного кода с учетом изменений в отдаленном репозитории в git называется 'pulling'(вытягивание, извлечение):

git pull

Обратите внимание, что в отличие от subversion, git всегда обновляет весь репозиторий.

  Примечание: В то время как git будет извлекать и применять изменения ко всем отдаленным веткам с помощью этой команды, из всех локальных веток он обновит только ту, которая в настоящее время проверяется (для получения дополнительной информации об отдаленных/локальных ответвлениях см. ls (listing branches)). Чтобы обновить другие локальные ветки, вам нужно switch(переключиться) на них и либо снова выполнить git pull, либо выполнить rebase/merge (будет задокументировано, как только мы решим, какую стратегию использовать).

Чтобы история коммитов была как можно более линейной и избегала коммитов слиянием (merge commits), рекомендуется выполнять rebase (перебазирование) при извлечении.

git pull --rebase

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

git config pull.rebase true

Resolve

Если у вас есть конфликты в svn после обновления или слияния, вы исправляете конфликты, а затем сообщаете svn, что все в порядке, с помощью команды resolved(урегулировано, разрешено).

В git конфликты обычно возникают при merging (слиянии) или при применении shelved/stashed (временно отложенные/запланированные) изменений.

Когда возникают конфликты, то

1. Изменения в файлах, которые не конфликтуют, будут staged (запланированными).
2. Изменения в файлах, которые конфликтуют, будут применены без промежуточной обработки к рабочей копии (так что простой diff будет показывать только конфликтующие изменения)

Чтобы разрешить конфликты,

1. Если вы хотите зафиксировать урегулированную версию файла, отметьте ее как resolved (улаженную), также сделав ее staging/adding.
2. Если вы хотите просто избавиться от статуса "оба изменены" (= конфликтуют) без добавления файла, используйте git reset file

После того, как все файлы были поставлены или помечены как не конфликтующие, вы можете сделать commit (зафиксировать) (будут зафиксированы только промежуточные файлы).

add (добавление новых файлов)

Subversion использует команду add для добавления файла в систему управления версиями. В git это не исключение: Если вы хотите добавить файл, вы должны сначала добавить его, например:

git add newfile.pas

Затем вы должны (как и в Subversion) сделать commit (зафиксировать) этот только что добавленный файл.

rm (Удаление файлов)

Subversion использует команду rm для удаления файла из системы управления версиями. В git это не исключение:

git rm nolongerneededfile.pas

Затем вы должны (как и в Subversion) сделать commit (зафиксировать) этот удаленный файл.

mv (переименование файлов)

Subversion использует команду rm для переименования файла в системе управления версиями. В git это не исключение:

git mv oldfile.pas newfile.pas

После этого вы должны (как и в Subversion) сделать commit (зафиксировать) это изменение.

Как и в Subversion, вы можете переместить один или несколько файлов в другой каталог:

git mv file1.pas file2.pas somesubdir

commit

Если вы внесли некоторые изменения локально и хотите их зафиксировать, это двухэтапный процесс:

git add myfile.pas

Это планирует фиксацию файла (в git это называется staging(запланированные изменения) - прим.перев: git staging - область, отслеживаемая git, в которой находятся файлы еще не попавшие в commit, поэтому изменения теперь становятся «совершаемые поэтапно»). Вы можете добавить столько файлов, сколько захотите, вот так.

  Примечание: Легко помнить, что svn требует того же для вновь добавленных файлов. Git распространяет это на все изменения, потому что таким образом вы можете не только выборочно планировать отдельные новые файлы для следующего коммита, но и вносить изменения в существующие файлы. Противоположность git add - это git reset (без параметра --hard!)

  Примечание: Чтобы увидеть изменения, которые были staged/scheduled (поставлены/запланированы) для фиксации, используйте git diff --cached. Обычный git diff покажет локальные изменения, которые (пока) не поставлены.

Когда вы будете готовы зафиксировать то, что запланировали, вы можете сделать commit:

git commit -m '* Some nice comment telling what you did'

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

git commit -m '* Some nice comment telling what you did' myfile.pas

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

git commit -m '* Some nice comment telling what you did' -a

Но на самом деле не рекомендуется использовать этот способ, так как он зафиксирует все изменения в вашей локальной копии, а не только в текущем рабочем каталоге.

На этом этапе ваши изменения были сохранены локально, но еще не отправлены в отдаленный репозиторий. Для этого необходимо дополнительно отправить изменения в отдаленный репозиторий. Это называется pushing (публикацией):

git push

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

diff (показать изменения в рабочей копии)

В svn вы можете увидеть изменения, которые были сделаны, но еще не зафиксированы с помощью diff. Это также верно в git:

git diff

Это покажет все изменения в вашей рабочей копии, которые еще не поставлены (не запланированы для фиксации).

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

git diff myfile.pas

Это покажет неустановленные изменения, внесенные в вашу рабочую копию myfile.pas.

Если вы уже запланировали для фиксации один или несколько файлов (т.е. отмечены для включения в следующий коммит), приведенное выше не будет отображать их в сгенерированном файле diff. Если вы хотите видеть запланированные изменения (и только запланированные изменения), используйте параметр командной строки --cached:

git diff --cached

diff (показать изменения, выполненные при коммите)

В svn вы можете увидеть изменения, внесенные коммитом, с помощью svn diff -c <revision>. В git вместо этого вы используете команду show:

git show -p <commit_hash_or_branch_or_tag>

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

log (показать коммиты в ветке)

В svn вы можете увидеть коммиты в ветке с помощью svn log. То же самое работает в git:

git log

Здесь будут перечислены хэши коммитов (строка, которую git использует для идентификации коммитов, аналогично номерам ревизий в svn), за которыми следуют сообщения журнала. Если вы также хотите увидеть, какие файлы были изменены, используйте

git log --stat

ls (список веток)

Чтобы получить список веток в Subversion, вы используете команду 'ls' с URL-адресом сервера. По соглашению, все каталоги в разделе '/branches' являются именами ветвей. Ветки всегда существуют как на клиенте(ах), так и на сервере.

В git ветки формализованы как часть системы управления версиями: команды имеют дело конкретно с ветвями, а не с путями, которые рассматриваются как ветки. Кроме того, git различает remote branches (отдаленные ветки) (ветки, которые существуют в репозитории, который вы клонировали, то есть в данном случае на сервере gitlab), и local branches (локальные ветки) (ветки, которые вы создали на ваша машине после клонирования). Репозиторий, который вы клонировали, по умолчанию упоминается с использованием псевдонима "origin", а имена удаленных ветвей добавляются к этому псевдониму.

Список локальных веток можно получить, используя:

git branch 

По умолчанию единственная локальная ветка, которая у вас будет - это main, что соответствует svn trunk. Эта локальная ветвь создается автоматически при выполнении начальной операции клонирования.

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

git branch -r

По умолчанию отдаленные ветки - это ветки, существующие в репозитории на сервере gitlab, чей псевдоним - "origin". Локальная main ветвь автоматически отслеживает (привязана к) отдаленную origin/main ветвь. Из-за этого отслеживания выполнение git pull отвечает за команду git push, имеющаяся у вас полученная ваша локальная ветка main будет синхронизироваться до gitlab. Посмотрите, как создать больше локальных веток и как связать их с удаленными ветвями. Смотрите switch, как создать больше локальных веток и как связать их с удаленными ветвями.

  Примечание: Хотя git всегда загружает все ветки и их коммиты по умолчанию при клонировании или извлечении, и хотя вы можете использовать их контент без сетевого подключения, вы не можете напрямую работать с отдаленными ветвями (поскольку они отдаленные, а не локальные). Вместо этого вы должны создать локальную ветку, которая «отслеживает» эту отдаленную ветку.

  Примечание: Не проверяйте напрямую отдаленную ветку. Это переведет вас в так называемое состояние «отключенной HEAD»: ваша рабочая копия будет содержать содержимое из этой ветки, но вы не можете ничего зафиксировать, поскольку вы можете фиксировать только локальные ветки. Вы можете выйти из состояния «отключенной HEAD», просто проверив другую ветку.

copy (создание ветки)

Чтобы создать ветку из текущей ситуации с рабочим каталогом, вы можете создать такую ​​ветку:

git branch mybugfix

Это создаст ветку mybugfix из текущей извлеченной ветки при текущей фиксации. Но это еще не делает эту ветку активной.

Сначала вам нужно проверить только что созданную ветку:

git checkout mybugfix

Две операции также можно комбинировать с помощью одной команды:

git checkout -b mybugfix

switch (проверка ветки)

Чтобы переключиться на существующую локальную ветку mybugfix, вы можете использовать команду checkout:

git checkout mybugfix

Это проверит ветку mybugfix. Если есть какие-либо незафиксированные изменения, которые могут вызвать конфликт, git откажется от проверки.

Чтобы переключиться на отдаленную ветку `mybugfix2`, которая еще не существует локально, вы также можете использовать команду checkout:

git checkout mybugfix2

Это проверит ветку mybugfix2 и автоматически настроит ее для отслеживания удаленной ветки. Здесь то же: если есть какие-либо незафиксированные изменения, которые могут вызвать конфликт, git откажется от проверки.

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

git checkout -b mybugfix2 --track origin/mybugfix2

Если вы создали ветку локально, которая еще не существует на сервере, внесли некоторые изменения и хотите отправить эту ветку на сервер, вы должны сообщить об этом git при нажатии:

git push -u origin/mybugfix mybugfix

-u origin/mybugfix сообщает git все, что ему нужно знать, чтобы соединить локальную ветку с удаленной веткой.

revert

Возврат всего рабочего дерева

Если вы внесли некоторые изменения локально и хотите отменить их, вы можете выполнить hard reset в git:

git reset --hard

Это отменит любые изменения, внесенные вами во время полного клонирования, включая любые staged changes.

Отменить изменения в определенных файлах/каталогах

Вы не можете отменить изменения в отдельных файлах с помощью git reset --hard. Вместо этого используйте

git checkout <pathspec>

pathspec может быть любой комбинацией файлов и каталогов. Обратите внимание, что если файлы были staged changes, эта команда восстановит запланированные изменения, а не последнюю зафиксированную версию.

  Примечание: На первый взгляд, команда git checkout заменяет произвольный набор команд svn. Причина в том, что его операция определяется как «обновить файлы в моем рабочем дереве, чтобы они соответствовали указанной запланированной/зафиксированной версии файлов». Таким образом, переключение на ветку соответствует получению версии файлов из этой ветки, а возврат соответствует последней версии файлов из текущей ветки.

merge (объединение изменений в 2-х ветках)

Чтобы объединить изменения в 2 ветках, вы используете команду merge(объединить). Если мы хотим объединить изменения в mybugfix с fixes, мы делаем:

git checkout fixes
git merge mybugfix

blame (проверка, кто внес изменения)

Чтобы увидеть, кто в какой строке (и в каком коммите) что-то поменял, svn предлагает вам команду 'blame'(обвинение :). Такая же команда существует в git.

git blame yourfile.pas

status (проверка статуса файлов)

Чтобы увидеть, есть ли какие-либо измененные файлы в вашем рабочем репозитории, svn предлагает команду 'status'. Такая же команда существует в git.

git status 

представит вам все измененные, запланированные к изменению и новые файлы в репозитории.

Если вам нужен только статус файлов в определенном каталоге, вы можете указать имя каталога. Итак, чтобы получить изменения в текущем рабочем каталоге (или ниже), это будет:

git status .

представит вам все измененные, запланированные к изменению и новые файлы в текущем каталоге. Это поведение svn по умолчанию.

shelve (временная отмена изменений)

В Subversion есть (экспериментальная) функция, которая позволяет временно откладывать изменения в вашей рабочей копии: shelve. Эта функция существует в git давно и называется stash:

git stash 

отменит любые изменения в рабочей копии и восстановит рабочую копию до состояния, в котором она была бы, если бы вы выполнили 'git pull' (или svn update).

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

git stash pop

Если возникнут какие-либо конфликты, вы можете

• resolve (уладить) их, или
• Используя git reset --hard, чтобы снова вернуть все файлы

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

git stash drop

info (получение информации о рабочем каталоге и сервере)

В Subversion вы можете получить информацию о текущем рабочем каталоге и конфигурации удаленного сервера, используя svn info. Поскольку git - это распределенная система, прямого эквивалента команды info не существует: нет единого сервера, и номер версии, известный в Subversion, не существует.

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

#!/bin/bash

# author: Duane Johnson
# email: duane.johnson@gmail.com
# date: 2008 Jun 12
# license: MIT
# 
# Based on discussion at http://kerneltrap.org/mailarchive/git/2007/11/12/406496

pushd . >/dev/null

# Find base of git directory
while [ ! -d .git ] && [ ! `pwd` = "/" ]; do cd ..; done

# Show various information about this git directory
if [ -d .git ]; then
  echo "== Remote URL: `git remote -v`"

  echo "== Remote Branches: "
  git branch -r
  echo

  echo "== Local Branches:"
  git branch
  echo

  echo "== Configuration (.git/config)"
  cat .git/config
  echo

  echo "== Most Recent Commit"
  git --no-pager log  -n1
  echo

  echo "Type 'git log' for more commits, or 'git show' for full commit details."
else
  echo "Not a git repository."
fi

popd >/dev/null

Обратите внимание, что этот сценарий также будет работать в среде Windows, если у вас установлен клиент git для Windows, поскольку он поставляется с минимальной окружением unix.

Свойства файла (обработка EOL и т. д.)

Subversion позволяет вам задавать некоторые свойства файлов. Существуют 'reserved' (зарезервированные) свойства, которые использует сама svn, например, для управления обработки EOL и типа файла. Поскольку git работает с diff'ами, а не с файлами, подобной концепции не существует.

Однако git позволяет вам устанавливать глобальные или локальные атрибуты для классов файлов. Они находятся в файле .gitattributes. Этот файл должен находиться в корне вашего репозитория, и может содержать некоторые атрибуты. Например

*               text=auto
*.txt		text
*.vcproj	text eol=crlf
*.sh		text eol=lf
*.jpg		-text

Это обычный файл, который вы можете (и должны) добавить с помощьюgit add, чтобы он сохранялся для всех пользователей.