Difference between revisions of "FPC git/ru"

From Free Pascal wiki
Jump to navigationJump to search
Line 125: Line 125:
 
Если у вас есть конфликты в svn после обновления или слияния, вы исправляете конфликты, а затем сообщаете svn, что все в порядке, с помощью команды ''resolved''(урегулировано, разрешено).
 
Если у вас есть конфликты в svn после обновления или слияния, вы исправляете конфликты, а затем сообщаете svn, что все в порядке, с помощью команды ''resolved''(урегулировано, разрешено).
  
В git конфликты обычно возникают при [[FPC_git#merge_.28merging_the_changes_in_2_branches.29|merging]] (слиянии) или при применении [[FPC_git#shelve_.28temporarily_undo_changes.29|shelved/stashed]] (отложенных/спрятанных) изменений.
+
В git конфликты обычно возникают при [[FPC_git#merge_.28merging_the_changes_in_2_branches.29|merging]] (слиянии) или при применении [[FPC_git#shelve_.28temporarily_undo_changes.29|shelved/stashed]] (отложенных/заплаированные) изменений.
  
 
Когда возникают конфликты, то
 
Когда возникают конфликты, то
  
# Изменения в файлах, которые не конфликтуют, будут [[FPC_git#commit|staged]] (поэтапными).
+
# Изменения в файлах, которые не конфликтуют, будут [[FPC_git#commit|staged]] (запланированными).
 
# Изменения в файлах, которые конфликтуют, будут применены без промежуточной обработки к рабочей копии (так что простой [[FPC_git#diff_.28show_changes_to_working_copy.29|diff]] будет показывать только конфликтующие изменения)
 
# Изменения в файлах, которые конфликтуют, будут применены без промежуточной обработки к рабочей копии (так что простой [[FPC_git#diff_.28show_changes_to_working_copy.29|diff]] будет показывать только конфликтующие изменения)
  

Revision as of 17:26, 8 August 2021

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 всегда обновляет весь репозиторий.

Light bulb  Примечание: В то время как 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, поэтому изменения теперь становятся «совершаемые поэтапно»). Вы можете добавить столько файлов, сколько захотите, вот так.

Light bulb  Примечание: Легко помнить, что svn требует того же для вновь добавленных файлов. Git распространяет это на все изменения, потому что таким образом вы можете не только выборочно планировать отдельные новые файлы для следующего коммита, но и вносить изменения в существующие файлы. Противоположность git add - это git reset (без параметра --hard!)
Light bulb  Примечание: Чтобы увидеть изменения, которые были 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 (listing branches)

To get a list of branches in Subversion, you use the 'ls' command with a server URL. By convention, all directories under '/branches' are the names of branches. Branches always exist both on the client(s) and server.

In git, branches are formalised as part of the version control system: commands deal specifically with branches rather than with paths that are treated as branches. Additionally, git differentiates between remote branches (branches that exist in the repository that you cloned, i.e., in this case on the gitlab server), and local branches (branches that you created on your machine after cloning). The repository that you cloned is referenced using the alias "origin" by default, and the names of remote branches are prepended by this alias.

The list of local branches can be obtained using:

git branch 

By default, the only local branch you will have is main, which corresponds to svn trunk. This local branch is automatically created when performing the initial clone operation.

The list of remote branches can be obtained using:

git branch -r

By default, the remote branches are the branches that exist in the repository on the gitlab server, whose alias is "origin". The local main branch automatically tracks (~ is linked to) the remote origin/main branch. Because of this tracking, executing git pull resp. git push commands while you have your local main branch checked out will synchronise the two from resp. to gitlab. See switch on how to create more local branches and how to link them to remote branches.

Light bulb  Примечание: While git always downloads all branches and their commits by default when cloning or pulling and while you can use their content without a network connection, you cannot directly work on remote branches (since they're remote and not local). Instead, you have to create a local branch that "tracks" this remote branch.
Light bulb  Примечание: Do not directly checkout a remote branch. That will put you in a so-called "detached HEAD" state: your working copy will contain the contents from that branch, but you can't commit anything as you can only commit to local branches. You can get out of a "detached HEAD" state by simply checking out another branch.

copy (creating a branch)

To create a branch from the current working directory situation, you can create a branch like this:

git branch mybugfix

this will create a branch mybugfix from the currently checked out branch at the current commit. But it does not yet make this the active branch.

You need to check out the newly made branch first:

git checkout mybugfix

The two operations can also be combined with one command:

git checkout -b mybugfix

switch (checking out a branch)

To switch to an existing local branch mybugfix, you can use the checkout command:

git checkout mybugfix

this will check out branch mybugfix. If there are any uncommitted changes which would cause a conflict, git will refuse the checkout.


To switch to a remote branch `mybugfix2`, which does not exist yet locally, you can also use the checkout command:

git checkout mybugfix2

this will check out branch mybugfix2 and automatically set it up to track the remote branch. Here again, if there are any uncommitted changes which would cause a conflict, git will refuse the checkout.

Note that if the branch does not exist remotely, this will simply create a new branch locally. It is better to be explicit:

git checkout -b mybugfix2 --track origin/mybugfix2

If you created a branch locally which does not yet exist on the server, made some modifications, and you wish to push this branch to the server, you must tell this to git when pushing:

git push -u origin/mybugfix mybugfix

the -u origin/mybugfix tells git all it needs to know to connect the local with the remote branch.

revert

Revert the entire working tree

If you have made some changes locally and wish to undo them, you can do a hard reset in git:

git reset --hard

This will undo any changes you made in the entire checkout, including any staged changes.

Revert changes to specific files/directories

You cannot undo changes to individual files with git reset --hard. Instead, use

git checkout <pathspec>

pathspec can be any combination of files and directories. Note that if the files had staged changes, this command will restore the staged version rather than the last committed version.

Light bulb  Примечание: At first sight, the git checkout command replaces an arbitrary collection of svn commands. The reason is that its operation is defined as "update the files in my working tree to match the specified staged/committed version of the files". So switching to a branch corresponds to getting the version of the files from that branch, while reverting corresponds to the latest version of the files from the current branch.

merge (merging the changes in 2 branches)

To merge changes in 2 branches, you use the merge command. If we want to merge the changes in mybugfix to fixes then we do:

git checkout fixes
git merge mybugfix

blame (check who made modifications)

To see who changes what line (and in what commit) svn offers you the 'blame' command. The same command exists in git.

git blame yourfile.pas

status (check status of files)

To see whether there are any changed files in your working repository, svn offers the 'status' command. The same command exists in git.

git status 

will present you with all changed, staged and new files in the repository.

If you want only the status of files below a certain directory, you can specify the name of the directory. So to get the changes in the current working directory (or below) that would be:

git status .

will present you with all changed, staged and new files in the current directory. This is the default behaviour of svn.

shelve (temporarily undo changes)

Subversion has an (experimental) feature that allows to temporarily set aside changes to your working copy : shelve. This feature exists since a long time in git and is called stash:

git stash 

will set aside any changes to the working copy, and restore the working copy to the state it would be in if you did a 'git pull' (or svn update).

To reapply the changes you set aside to the working copy, and to remove them from the list of stashes at the same time, you can execute the following command:

git stash pop

If any conflicts occur, you can

In either case, the stash will not be touched when conflicts occurred while applying it. If you still with to remove it, you can do so with

git stash drop

info (get working dir and server info)

In subversion, you can get information about the current working directory and remote server configuration using svn info. Since git is a distributed system, no direct equivalent of the info command exists: there is no single server, and the revision number as known in subversion does not exist.

The following script attempts to display similar information as the svn info command:

#!/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

Note that this script will also work in the Windows environment if you have the windows git client installed, because it comes with a minimal unix environment.

file properties (EOL handling etc.)

Subversion allows you to set some properties on files. There are 'reserved' properties that svn itself uses, for example to handle EOL handling and file type. Because git operates on diffs and not on files, no similar concept exists.

However, git does allow you to set global or local attributes for classes of files. These are in the .gitattributes file. That file should be located in the root of your repository, and can contain some attributes. For example:

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

This is a regular file which you can (and must) add with git add so it is saved for all users.