как узнать какие ветки есть в git

Управление ветками

Теперь, когда вы уже попробовали создавать, объединять и удалять ветки, пора познакомиться с некоторыми инструментами для управления ветками, которые вам пригодятся, когда вы начнёте использовать ветки постоянно.

Команда git branch делает несколько больше, чем просто создаёт и удаляет ветки. При запуске без параметров, вы получите простой список имеющихся у вас веток:

Вы всегда можете указать дополнительный аргумент для вывода той же информации, но относительно указанной ветки предварительно не извлекая и не переходя на неё.

Переименование ветки

Не переименовывайте ветки, которые всё ещё используются другими участниками. Не переименовывайте ветку в master/main/mainline, не прочитав раздел «Изменение имени главной ветки».

Теперь проверим, где мы сейчас находимся:

Теперь старое имя ветки полностью заменено исправленным.

Изменение имени главной ветки

Изменение имени ветки, например master/main/mainline/default, сломает интеграции, службы, вспомогательные утилиты и скрипты сборки, которые использует ваш репозиторий. Прежде чем сделать это, обязательно проконсультируйтесь с коллегами. Также убедитесь, что вы выполнили тщательный поиск в своём репозитории и обновили все ссылки на старое имя ветки в вашем коде или скриптах.

Переименуйте локальную ветку master в main с помощью следующей команды:

В итоге, состояние репозитория становится следующим:

Теперь, для завершения перехода на новую ветку перед вами стоят следующие задачи:

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

Обновите конфигурацию всех запускаемых тестов.

Исправьте скрипты сборки и публикации артефактов.

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

Обновите документацию, исправив ссылки, указывающие на старую ветку.

Слейте или отмените запросы на слияние изменений, нацеленные на старую ветку.

Источник

GitHub: работа с ветками и коммитами

В предыдущих статьях мы рассказывали, что такое GitHub, как его настроить и как опубликовать свой проект. Но это лишь малая часть его инструментов. Одним из ключевых моментов для GitHub является работа с ветками — разбираемся с ними в этой статье.

Ветка (branch) — это история коммитов. Давайте сначала разберемся, что это такое.

Коммит (commit) — это информация об измененных файлах. Коммит состоит из автора коммита, измененных файлов, HEAD и времени. Для примеров мы будем использовать репозиторий и сделаем первый коммит, который отправим на сервер. Он нужен для того, чтобы разграничивать задачки. Так будет понятно, какой код в истории относится к той или иной задаче, чтобы потом мы могли быстро понять суть.

Например, у нас задача — сделать блок формы. Для этого мы сделаем нужные изменения в файле index.html & style.css, и даже через месяц сможем при помощи истории изменений просмотреть измененные куски кода именно для этого блока.

При помощи команды git log в консоли мы можем отслеживать историю коммитов в ветке.

На самом GitHub мы можем увидеть последний коммит в файле и последний коммит в ветке. Всю историю мы можем просмотреть, кликнув по кнопке n commits, где n — количество запущенных на сервер коммитов. У нас в ветке пока что один коммит, поэтому на ссылке надпись 1 commit.

Сама история будет выглядеть как список коммитов без подробностей об изменённых файлах. Здесь давайте подробнее остановимся на том, что такое HEAD коммита. Это специальный указатель, при помощи которого вы можете гибко управлять коммитами — например, склеивать или сбрасывать до нужного момента.

Если вы кликните по сообщению в коммите, в нашем случае это add first commit, то попадёте в список всех изменённых файлов.

Теперь подробнее разберем, как создавать коммит. Для начала нам нужно будет поменять файлы или добавить новые, чтобы было что коммитить, так как коммит — это история изменений. Как правило, в коммит включают изменения по одной задаче.

В нашем примере мы изменим содержание страницы index.html и добавим стили в style.css.

Изменения, не включенные в коммит, мы можем просмотреть при помощи команды git status.

Чтобы добавить файлы в коммит, мы будем использовать git add. Здесь мы можем указать нужные нам файлы для коммита, например, index.html. Если после этого мы сделаем git status, то эти файлики подсветятся зелёным — это означает, что мы можем добавить их к коммиту.

Если мы запушим наш результат на GitHub, то увидим наш коммит.

После того, как мы поменяли наш коммит локально, запушим его на сервер при помощи ключа force. Обычный push не сработает, так как у нас уже есть коммит на сервере — здесь будьте аккуратны, ведь вы меняете историю не только локально, но и удалённо.

Теперь поговорим про ветки (branch). Ветка — это история изменений. Сейчас у в репозитории одна ветка main, в которой хранится стабильная версия. Как правило, новые задачи делаются в новых ветках, а потом вливаются в main после ревью кода.

Посмотрим, как выглядит наша ветка с двумя коммитами в графике.

Ветки можно просматривать при помощи команды git branch.

Пробежимся git log и сравним наши ветки.

Тем не менее, если мы зайдем на GitHub, то обнаружим, что у нас там только одна ветка — main. Так происходит, потому что ветка form-index существует пока только на нашем компьютере, то есть локально.

Чтобы наша новая ветка появилась на сервере, нам нужно запушить наши изменения.

Если посмотрим на историю коммитов в form, то увидим, что она отличается от main на один коммит.

Мы можем создавать новые ветки не только из main, но и из других веток — так делают редко. Самое главное здесь понять, что если мы создали новую ветку из другой ветки, то мы наследуем историю коммитов ветки, из которой создали ветвление, но только в момент создания.

Давайте создадим ветку form-index-fix и посмотрим на историю коммитов в ней.

Теперь поэкспериментируем и посмотрим, что будет, если мы внесём изменение в ветку и забудем их закоммитить: обычный механизм через checkout не сработает, консоль попросит закоммитить изменения.

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

Команды для консоли

В предыдущих статьях мы рассказывали, что такое GitHub, как его настроить и как опубликовать свой проект. Но это лишь малая часть его инструментов. Одним из ключевых моментов для GitHub является работа с ветками — разбираемся с ними в этой статье.

Ветка (branch) — это история коммитов. Давайте сначала разберемся, что это такое.

Коммит (commit) — это информация об измененных файлах. Коммит состоит из автора коммита, измененных файлов, HEAD и времени. Для примеров мы будем использовать репозиторий и сделаем первый коммит, который отправим на сервер. Он нужен для того, чтобы разграничивать задачки. Так будет понятно, какой код в истории относится к той или иной задаче, чтобы потом мы могли быстро понять суть.

Например, у нас задача — сделать блок формы. Для этого мы сделаем нужные изменения в файле index.html & style.css, и даже через месяц сможем при помощи истории изменений просмотреть измененные куски кода именно для этого блока.

При помощи команды git log в консоли мы можем отслеживать историю коммитов в ветке.

На самом GitHub мы можем увидеть последний коммит в файле и последний коммит в ветке. Всю историю мы можем просмотреть, кликнув по кнопке n commits, где n — количество запущенных на сервер коммитов. У нас в ветке пока что один коммит, поэтому на ссылке надпись 1 commit.

Сама история будет выглядеть как список коммитов без подробностей об изменённых файлах. Здесь давайте подробнее остановимся на том, что такое HEAD коммита. Это специальный указатель, при помощи которого вы можете гибко управлять коммитами — например, склеивать или сбрасывать до нужного момента.

Если вы кликните по сообщению в коммите, в нашем случае это add first commit, то попадёте в список всех изменённых файлов.

Теперь подробнее разберем, как создавать коммит. Для начала нам нужно будет поменять файлы или добавить новые, чтобы было что коммитить, так как коммит — это история изменений. Как правило, в коммит включают изменения по одной задаче.

В нашем примере мы изменим содержание страницы index.html и добавим стили в style.css.

Изменения, не включенные в коммит, мы можем просмотреть при помощи команды git status.

Чтобы добавить файлы в коммит, мы будем использовать git add. Здесь мы можем указать нужные нам файлы для коммита, например, index.html. Если после этого мы сделаем git status, то эти файлики подсветятся зелёным — это означает, что мы можем добавить их к коммиту.

Если мы запушим наш результат на GitHub, то увидим наш коммит.

После того, как мы поменяли наш коммит локально, запушим его на сервер при помощи ключа force. Обычный push не сработает, так как у нас уже есть коммит на сервере — здесь будьте аккуратны, ведь вы меняете историю не только локально, но и удалённо.

Теперь поговорим про ветки (branch). Ветка — это история изменений. Сейчас у в репозитории одна ветка main, в которой хранится стабильная версия. Как правило, новые задачи делаются в новых ветках, а потом вливаются в main после ревью кода.

Посмотрим, как выглядит наша ветка с двумя коммитами в графике.

Ветки можно просматривать при помощи команды git branch.

Пробежимся git log и сравним наши ветки.

Тем не менее, если мы зайдем на GitHub, то обнаружим, что у нас там только одна ветка — main. Так происходит, потому что ветка form-index существует пока только на нашем компьютере, то есть локально.

Чтобы наша новая ветка появилась на сервере, нам нужно запушить наши изменения.

Если посмотрим на историю коммитов в form, то увидим, что она отличается от main на один коммит.

Мы можем создавать новые ветки не только из main, но и из других веток — так делают редко. Самое главное здесь понять, что если мы создали новую ветку из другой ветки, то мы наследуем историю коммитов ветки, из которой создали ветвление, но только в момент создания.

Давайте создадим ветку form-index-fix и посмотрим на историю коммитов в ней.

Теперь поэкспериментируем и посмотрим, что будет, если мы внесём изменение в ветку и забудем их закоммитить: обычный механизм через checkout не сработает, консоль попросит закоммитить изменения.

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

Источник

Как создать и составить список локальных и удаленных веток Git

Филиалы — это часть процесса разработки программного обеспечения и одна из самых мощных функций Git. Ветви по сути являются указателями на определенную фиксацию.

При исправлении ошибки или работе над новой функцией разработчики создают новую ветку, которую позже можно будет объединить с основной кодовой базой.

В этой статье объясняется, как создавать и перечислять локальные и удаленные ветки Git.

Список веток Git

Создание ветки Git

Создание новой ветки — это не что иное, как создание указателя на данный коммит.

Команда не вернет никаких результатов. Если ветка с таким именем уже существует, вы увидите следующее сообщение об ошибке:

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

Команда выведет сообщение о том, что ветвь переключена:

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

Отсюда вы можете использовать стандартные команды git add и git commit для добавления git commit в новую ветку.

Чтобы отправить новую ветку в удаленный репозиторий, используйте команду git push за которой следует имя удаленного репо и имя ветки:

Выводы

Мы показали вам, как составлять список и создавать локальные и удаленные ветки Git. Ветви являются ссылкой на снимок ваших изменений и имеют короткий жизненный цикл.

С помощью команды git branch вы также можете переименовывать и удалять локальные и удаленные ветки Git.

Если вы столкнулись с проблемой или хотите оставить отзыв, оставьте комментарий ниже.

Источник

Шпаргалка по Git

Шпаргалка по Git

Как выписать репозиторий с github

Как выписать ветку с github

С помощью команды «checkout» можно выписать уже существующую ветку с github:

Или так, что намного надежнее:

Если команда не сработала, нужно попробовать выполнить обновление:

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

Т.е. сначала мы создаем новую ветку, а затем вливаем в нее изменения из ветки на github.

Как создать новую ветку в локальном репозитории

2. Публикуем ее на github:

Как переключиться на другую ветку в git

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

Как посмотреть список веток

Команда «branch» позволяет посмотреть список веток в локальном репозитории. Текущая ветка будет помечена звездочкой:

Как сделать commit

Создаем новую ветку, выполняем в ней нужные изменения.

2. Подготавливаем коммит, добавляя в него файлы командой:

Или удаляем устаревшие файлы:

3. Выполняем коммит:

4. Как правило, в репозитории существует две основные ветки — dev и master. Dev — общая ветка разработчиков и тестировщиков. Именно в нее добавляются все новые разработки перед очередным релизом. Master — ветка для выкладки продукта на боевые сервера.

После коммита надо влить в нашу ветку изменения из ветки dev и master:

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

5. Переключаемся на ветку dev:

6. Вливаем в dev изменения из ветки проекта:

7. Заливаем последнюю версию ветки dev на удаленный сервер:

push может не пройти, потому что удалённый origin/dev обогнал локальную его копию.

Как решить конфликт бинарных файлов

Допустим, при слиянии с другой веткой git выдал ошибку. Команда git status возвращает информацию о конфликте:

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

Чтобы решить такой конфликт, надо просто выбрать — какая версия файла будет использоваться: ваша или из вливаемой ветки. Чтобы использовать свой вариант файла, вводим команду:

Если мы выбираем версию из вливаемой ветки:

« ours » — от английского «наш», « theirs » — от английского «их».

Как посмотреть историю изменений

git log — просмотр логов.

Вывод данных о каждом коммите в одну строку:

Для вывода информации git log использует просмотрщик, указанный в конфиге репозитория.

Поиск по ключевому слову в комментариях к коммиту:

Команда «git show» позволяет просмотреть, какие именно изменения произошли в указанном коммите:

Можно посмотреть построчную информацию о последнем коммите, имя автора и хэш коммита:

git annotate, выводит измененные строки и информацию о коммитах, где это произошло:

Как сделать откат

Можно откатить до последней версии ветки:

После того, как откат сделан, и выполнен очередной локальный коммит, при попытке сделать push в удаленный репозиторий, git может начать ругаться, что версия вашей ветки младше чем на github и вам надо сделать pull. Это лечится принудительным коммитом:

Как выполнить слияние с другой веткой

git merge выполняет слияние текущей и указанной ветки. Изменения добавляются в текущую ветку.

git pull забирает изменения из ветки на удаленном сервере и проводит слияние с активной веткой.

git pull отличается от git merge тем, что merge только выполняет слияние веток, а pull прежде чем выполнить слияние — закачивает изменения с удаленного сервера. merge удобно использовать для слияния веток в локальном репозитории, pull — слияния веток, когда одна из них лежит на github.

Создание нового локального репозитория

git cherry-pick

git cherry-pick помогает применить один-единственный коммит из одной ветки к дереву другой.

3. Выполнить команду, указать код коммита:

4. После этого обновить ветку на сервере:

Как раскрасить команды git

Чтобы раскрасить вывод git, можно добавить в файл блок [color] :

git clone
clone the repository specified by ; this is similar to «checkout» in
some other version control systems such as Subversion and CVS

Add colors to your

[color] ui = auto
[color «branch»] current = yellow reverse
local = yellow
remote = green
[color «diff»] meta = yellow bold
frag = magenta bold
old = red bold
new = green bold
[color «status»] added = yellow
changed = green
untracked = cyan

Highlight whitespace in diffs

[color] ui = true
[color «diff»] whitespace = red reverse
[core] whitespace=fix,-indent-with-non-tab,trailing-space,cr-at-eol

Add aliases to your

git config —global user.name ‘John Doe’
git config —global user.email [email protected]
sets your name and email for commit messages

git config branch.autosetupmerge true
tells git-branch and git-checkout to setup new branches so that git-pull(1)
will appropriately merge from that remote branch. Recommended. Without this,
you will have to add —track to your branch command or manually merge remote
tracking branches with «fetch» and then «merge».

git config core.autocrlf true
This setting tells git to convert the newlines to the system’s standard
when checking out files, and to LF newlines when committing in

git config —list
To view all options

git config apply.whitespace nowarn
To ignore whitespace

You can add «—global» after «git config» to any of these commands to make it
apply to all git repos (writes to

Info
—-
git reflog
Use this to recover from *major* mess ups! It’s basically a log of the
last few actions and you might have luck and find old commits that
have been lost by doing a complex merge.

git diff
show a diff of the changes made since your last commit
to diff one file: «git diff — »
to show a diff between staging area and HEAD: `git diff —cached`

git status
show files added to the staging area, files with changes, and untracked files

git log
show recent commits, most recent on top. Useful options:
—color with color
—graph with an ASCII-art commit graph on the left
—decorate with branch and tag names on appropriate commits
—stat with stats (files changed, insertions, and deletions)
-p with full diffs
—author=foo only by a certain author
—after=»MMM DD YYYY» ex. («Jun 20 2008″) only commits after a certain date
—before=»MMM DD YYYY» only commits that occur before a certain date
—merge only the commits involved in the current merge conflicts

also to show the contents of a file at a specific revision, use
git show :
this is similar to cat-file but much simpler syntax.

git show —name-only
show only the names of the files that changed, no diff information.

git blame
show who authored each line in

git blame
show who authored each line in as of (allows blame to go back in
time)

git gui blame
really nice GUI interface to git blame

git diff head path/to/fubar
show the diff between a file on the current branch and potentially another branch

git diff —cached [ ] shows diff for staged (git-add’ed) files (which includes uncommitted git cherry-pick’ed files)

git ls-files
list all files in the index and under version control.

git ls-remote [HEAD] show the current version on the remote repo. This can be used to check whether
a local is required by comparing the local head revision.

git add
add all files under directory to the project, including subdirectories

Either way you need to add patterns to exclude to these files.

git reset HEAD …
remove the specified files from the next commit

git commit —amend
edit the commit message of the most recent commit

git branch
list all local branches

create a new branch named
, referencing the same point in history as
the current branch

git push :refs/heads/

create a new remote branch named
, referencing on the
remote. Repo is the name of the remote.
Example: git push origin origin:refs/heads/branch-1
Example: git push origin origin/branch-1:refs/heads/branch-2
Example: git push origin branch-1 ## shortcut

git branch —track

create a tracking branch. Will push/pull changes to/from another repository.
Example: git branch —track experimental origin/experimental

git branch —set-upstream
(As of Git 1.7.0)
Make an existing branch track a remote branch
Example: git branch —set-upstream foo origin/foo

delete the branch
; if the branch you are deleting points to a
commit which is not reachable from the current branch, this command
will fail with a warning.

even if the branch points to a commit not reachable from the current branch,
you may know that that commit is still reachable from some other branch or
tag. In that case it is safe to use this command to force git to delete the
branch.

make the current branch
, updating the working directory to reflect
the version referenced by

removes a branch from a remote repository.
Example: git push origin :old_branch_to_be_deleted

Checkout a file from another branch and add it to this branch. File
will still need to be added to the git branch, but it’s present.
Eg. git co remote_at_origin__tick702_antifraud_blocking …./…nt_elements_for_iframe_blocked_page.rb

Eg. git show remote_tick702 — path/to/fubar.txt
show the contents of a file that was created on another branch and that
does not exist on the current branch.

git show :
Show the contents of a file at the specific revision. Note: path has to be
absolute within the repo.

merge branch
into the current branch; this command is idempotent
and can be run as many times as needed to keep the current branch
up-to-date with changes in

git merge
—no-commit
merge branch
into the current branch, but do not autocommit the
result; allows you to make further tweaks

git merge
-s ours
merge branch
into the current branch, but drops any changes in

, using the current tree as the new tree

git cherry-pick [—edit] [-n] [-m parent-number] [-s] [-x]
selectively merge a single commit from another local branch
Example: git cherry-pick 7300a6130d9447e18a931e898b64eefedea19544

git hash-object
get the blob of some file whether it is in a repository or not

Find the commit in the repository that contains the file blob:

Squashing
———
WARNING: «git rebase» changes history. Be careful. Google it.

git rebase —interactive HEAD

10
(then change all but the first «pick» to «squash»)
squash the last 10 commits into one big commit

git mergetool
work through conflicted files by opening them in your mergetool (opendiff,
kdiff3, etc.) and choosing left/right chunks. The merged result is staged for
commit.

For binary files or if mergetool won’t do, resolve the conflict(s) manually
and then do:

Once all conflicts are resolved and staged, commit the pending merge with:

git fetch
update the remote-tracking branches for (defaults to «origin»).
Does not initiate a merge into the current branch (see «git pull» below).

git push
update the server with your commits across all branches that are *COMMON*
between your local copy and the server. Local branches that were never
pushed to the server in the first place are not shared.

update the server with your commits made to
since your last push.
This is always *required* for new branches that you wish to share. After
the first explicit push, «git push» by itself is sufficient.

git push origin
:refs/heads/

E.g. git push origin twitter-experiment:refs/heads/twitter-experiment
Which, in fact, is the same as git push origin
but a little
more obvious what is happening.

git revert
reverse commit specified by and commit the result. This does *not* do
the same thing as similarly named commands in other VCS’s such as «svn
revert» or «bzr revert», see below

Fix mistakes / Undo
——————-

git reset —hard
abandon everything since your last commit; this command can be DANGEROUS.
If merging has resulted in conflicts and you’d like to just forget about
the merge, this command will do that.

git reset —hard ORIG_HEAD or git reset —hard origin/master
undo your most recent *successful* merge *and* any changes that occurred
after. Useful for forgetting about the merge you just did. If there are
conflicts (the merge was not successful), use «git reset —hard» (above)
instead.

git reset —soft HEAD^
forgot something in your last commit? That’s easy to fix. Undo your last
commit, but keep the changes in the staging area for editing.

git commit —amend
redo previous commit, including changes you’ve staged in the meantime.
Also used to edit commit message of previous commit.

git stash
git stash save
save your local modifications to a new stash (so you can for example
«git svn rebase» or «git pull»)

git stash apply
restore the changes recorded in the stash on top of the current working tree
state

git stash pop
restore the changes from the most recent stash, and remove it from the stack
of stashed changes

git stash list
list all current stashes

git stash drop [ ] delete the stash

git stash clear
delete all current stashes

git remote add
adds a remote repository to your git config. Can be then fetched locally.
Example:
git remote add coreteam git://github.com/wycats/merb-plugins.git
git fetch coreteam

git push :refs/heads/

delete a branch in a remote repository

git push :refs/heads/
create a branch on a remote repository
Example: git push origin origin:refs/heads/new_feature_name

git push + :
replace a branch with
think twice before do this
Example: git push origin +master:my_branch

git remote show
show information about the remote server.

git push
For branches that are remotely tracked (via git push) but
that complain about non-fast forward commits when doing a
git push. The pull synchronizes local and remote, and if
all goes well, the result is pushable.

git fetch
Retrieves all branches from the remote repository. After
this ‘git branch —track …’ can be used to track a branch
from the new remote.

add the given repository at the given path. The addition will be part of the
next commit.

git submodule update [—init] Update the registered submodules (clone missing submodules, and checkout
the commit specified by the super-repo). —init is needed the first time.

git submodule foreach
Executes the given command within each checked out submodule.

Updating submodules
To update a submodule to a new commit:
1. update submodule:
cd

git pull
2. commit the new version of submodule:
cd

git format-patch HEAD^
Generate the last commit as a patch that can be applied on another
clone (or branch) using ‘git am’. Format patch can also generate a
patch for all commits using ‘git format-patch HEAD^ HEAD’
All page files will be enumerated with a prefix, e.g. 0001 is the
first patch.

git format-patch ^..
Generate a patch for a single commit. E.g.
git format-patch d8efce43099^..d8efce43099
Revision does not need to be fully specified.

Applies the patch file generated by format-patch.

git archive master | bzip2 > source-tree.tar.bz2
Will export archive as bz2

git archive —format zip —output /full/path master
Will export as zip

git instaweb —httpd=webrick [—start | —stop | —restart]

GIT_DIR
Location of the repository to use (for out of working directory repositories)

GIT_WORKING_TREE
Location of the Working Directory — use with GIT_DIR to specifiy the working directory root
or to work without being in the working directory at all.

Change author for all commits with given name

git filter-branch —commit-filter ‘
if [ «$GIT_COMMITTER_NAME» = «

» ];
then
GIT_COMMITTER_NAME=» »;
GIT_AUTHOR_NAME=» »;
GIT_COMMITTER_EMAIL=» »;
GIT_AUTHOR_EMAIL=» »;
git commit-tree «[email protected]»;
else
git commit-tree «[email protected]»;
fi’ HEAD

Источник