Adding a remote repository
To add a new remote, use the git remote add command on the terminal, in the directory your repository is stored at.
The git remote add command takes two arguments:
- A remote name, for example,
origin - A remote URL, for example,
https://github.com/user/repo.git
For example:
$ git remote add origin https://github.com/USER/REPO.git
# Set a new remote
$ git remote -v
# Verify new remote
> origin https://github.com/USER/REPO.git (fetch)
> origin https://github.com/USER/REPO.git (push)For more information on which URL to use, see «About remote repositories.»
Troubleshooting: Remote origin already exists
This error means you’ve tried to add a remote with a name that already exists in your local repository.
$ git remote add origin https://github.com/octocat/Spoon-Knife.git
> fatal: remote origin already exists.To fix this, you can:
- Use a different name for the new remote.
- Rename the existing remote repository before you add the new remote. For more information, see «Renaming a remote repository» below.
- Delete the existing remote repository before you add the new remote. For more information, see «Removing a remote repository» below.
Changing a remote repository’s URL
The git remote set-url command changes an existing remote repository URL.
The git remote set-url command takes two arguments:
- An existing remote name. For example,
originorupstreamare two common choices. - A new URL for the remote. For example:
- If you’re updating to use HTTPS, your URL might look like:
https://github.com/USERNAME/REPOSITORY.git - If you’re updating to use SSH, your URL might look like:
git@github.com:USERNAME/REPOSITORY.git
- If you’re updating to use HTTPS, your URL might look like:
Switching remote URLs from SSH to HTTPS
- Open TerminalTerminalGit Bash.
- Change the current working directory to your local project.
- List your existing remotes in order to get the name of the remote you want to change.
$ git remote -v > origin git@github.com:USERNAME/REPOSITORY.git (fetch) > origin git@github.com:USERNAME/REPOSITORY.git (push) - Change your remote’s URL from SSH to HTTPS with the
git remote set-urlcommand.$ git remote set-url origin https://github.com/USERNAME/REPOSITORY.git - Verify that the remote URL has changed.
$ git remote -v # Verify new remote URL > origin https://github.com/USERNAME/REPOSITORY.git (fetch) > origin https://github.com/USERNAME/REPOSITORY.git (push)
The next time you git fetch, git pull, or git push to the remote repository, you’ll be asked for your GitHub username and password. When Git prompts you for your password, enter your personal access token. Alternatively, you can use a credential helper like Git Credential Manager. Password-based authentication for Git has been removed in favor of more secure authentication methods. For more information, see «Creating a personal access token.»
You can use a credential helper so Git will remember your GitHub username and personal access token every time it talks to GitHub.
Switching remote URLs from HTTPS to SSH
- Open TerminalTerminalGit Bash.
- Change the current working directory to your local project.
- List your existing remotes in order to get the name of the remote you want to change.
$ git remote -v > origin https://github.com/USERNAME/REPOSITORY.git (fetch) > origin https://github.com/USERNAME/REPOSITORY.git (push) - Change your remote’s URL from HTTPS to SSH with the
git remote set-urlcommand.$ git remote set-url origin git@github.com:USERNAME/REPOSITORY.git - Verify that the remote URL has changed.
$ git remote -v # Verify new remote URL > origin git@github.com: USERNAME/REPOSITORY.git (fetch) > origin git@github.com: USERNAME/REPOSITORY.git (push)
Troubleshooting: No such remote ‘[name]’
This error means that the remote you tried to change doesn’t exist:
$ git remote set-url sofake https://github.com/octocat/Spoon-Knife
> fatal: No such remote 'sofake'Check that you’ve correctly typed the remote name.
Renaming a remote repository
Use the git remote rename command to rename an existing remote.
The git remote rename command takes two arguments:
- An existing remote name, for example,
origin - A new name for the remote, for example,
destination
Example of renaming a remote repository
These examples assume you’re cloning using HTTPS, which is recommended.
$ git remote -v
# View existing remotes
> origin https://github.com/OWNER/REPOSITORY.git (fetch)
> origin https://github.com/OWNER/REPOSITORY.git (push)
$ git remote rename origin destination
# Change remote name from 'origin' to 'destination'
$ git remote -v
# Verify remote's new name
> destination https://github.com/OWNER/REPOSITORY.git (fetch)
> destination https://github.com/OWNER/REPOSITORY.git (push)Troubleshooting: Could not rename config section ‘remote.[old name]’ to ‘remote.[new name]’
This error means that the old remote name you typed doesn’t exist.
You can check which remotes currently exist with the git remote -v command:
$ git remote -v
# View existing remotes
> origin https://github.com/OWNER/REPOSITORY.git (fetch)
> origin https://github.com/OWNER/REPOSITORY.git (push)Troubleshooting: Remote [new name] already exists
This error means that the remote name you want to use already exists. To solve this, either use a different remote name, or rename the original remote.
Removing a remote repository
Use the git remote rm command to remove a remote URL from your repository.
The git remote rm command takes one argument:
- A remote name, for example,
destination
Removing the remote URL from your repository only unlinks the local and remote repositories. It does not delete the remote repository.
Example of removing a remote repository
These examples assume you’re cloning using HTTPS, which is recommended.
$ git remote -v
# View current remotes
> origin https://github.com/OWNER/REPOSITORY.git (fetch)
> origin https://github.com/OWNER/REPOSITORY.git (push)
> destination https://github.com/FORKER/REPOSITORY.git (fetch)
> destination https://github.com/FORKER/REPOSITORY.git (push)
$ git remote rm destination
# Remove remote
$ git remote -v
# Verify it's gone
> origin https://github.com/OWNER/REPOSITORY.git (fetch)
> origin https://github.com/OWNER/REPOSITORY.git (push)Note: git remote rm does not delete the remote repository from the server. It simply
removes the remote and its references from your local repository.
Troubleshooting: Could not remove config section ‘remote.[name]’
This error means that the remote you tried to delete doesn’t exist:
$ git remote rm sofake
> error: Could not remove config section 'remote.sofake'Check that you’ve correctly typed the remote name.
Further reading
- «Working with Remotes» from the Pro Git book
Одна из самых распространенных систем управления версиями – Git. Ее ядро добавляет в систему ряд консольных команд, предназначенных для управления репозиториями. В самих же репозиториях хранятся важные каталоги, конфигурационные файлы, журналы и прочие связанные элементы.
Далее я расскажу, как создать, клонировать и удалить эти репозитории.
Следующие инструкции предназначены для тех, кто уже установил Git на свой сервер. Если вы еще не сделали этого, используйте руководство с GitHub, которое поможет разобраться с выполнением поставленной задачи.
Подробнее: How to install Git
Создание Git-репозитория
Сначала рассмотрим создание репозитория. Представим, что у вас уже есть папка для хранения файлов, но она еще не находится под контролем Git.
Откройте «Командную строку» (Windows) или Терминал (Linux/macOS) и перейдите по пути данной папки.
В Linux выполните команду:
cd /home/user/directory
В macOS:
cd /Users/user/directory
В Windows:
cd C:/Users/user/directory
Остается только ввести нижеуказанную команду, чтобы завершить первый этап.
Благодаря этой команде создается структура подкаталога со всеми необходимыми файлами. Кстати, все они расположены в подпапке с названием .git. Пока что проект не находится под контролем учета версий, поскольку в него добавлены только нужные элементы для работы Git. Для добавления файлов в репозиторий будем использовать git add. Команда git commit является заключительной:
git add git commit -m 'initial project version'
Теперь у вас есть Git-репозиторий со всеми необходимыми составляющими и отслеживаемыми файлами.
Комьюнити теперь в Телеграм
Подпишитесь и будьте в курсе последних IT-новостей
Подписаться
Клонирование существующего репозитория
Второй вариант создания директории для контроля версий – копирование существующего проекта с другого сервера. Это актуально, когда осуществляется доработка готового проекта или вы желаете внедрить его компоненты в свой. В этом поможет команда git clone, о которой и пойдет речь далее.
При использовании упомянутой команды вы получаете клоны всех версий файлов, а значит, можете использовать любые из них, если что-то пойдет не так. Это же пригождается, когда требуется вернуть предыдущую версию проекта, что осуществимо благодаря файлам, помещенным под версионный контроль.
Для клонирования существующего репозитория понадобится ввести git clone <url>. Пример такой команды вы видите ниже:
git clone https://github.com/rep/rep
Данная команда позволила вам получить клон всех версий указанного репозитория (в качестве примера было взято название rep). Теперь на вашем сервере создана директория с указанным названием. К ней подключена поддержка контроля версий, то есть появилась папка .git.
При использовании вышеуказанной команды репозиторий клонируется с текущим названием. Если же оно должно отличаться, используйте следующую вариацию команды:
git clone https://github.com/rep/rep myrep
Завершим этот раздел статьи описанием содержимого, которое появляется в консоли при выполнении команды. Данный вывод соответствует успешному клонированию:
Cloning into 'Git'... remote: Counting objects: 46, done. remote: Compressing objects: 100% (25/25), done. remote: Total 46 (delta 7), reused 43 (delta 4), pack-reused 0 Unpacking objects: 100% (46/46), done. Checking connectivity... done.
Удаление локального Git-репозитория
Если с созданием и клонированием репозиториев все понятно, то как быть, когда папка с проектом уже существует, но в нее нужно поместить новые данные, удалив предыдущие, или когда Git-репозиторий на сервере больше не нужен. В таком случае осуществляется стандартное удаление.
В корне каталога с проектом необходимо избавиться от папки .git, о которой уже шла речь выше. Так вы удаляете только ту информацию, которая связана с Git, но сам проект остается. В Linux через Терминал вы должны перейти к каталогу с проектом и ввести следующую команду:
Еще один вариант – удаление .gitignore и .gitmodules в случае их наличия. Тогда команда меняет свой вид на:
Остается только убедиться в отсутствии скрытой папки, которая может помешать инсталляции новой. Для этого существует простая команда ls -lah, выполнить которую необходимо с указанием того же каталога.
Только что мы разобрались с основами создания, клонирования и удаления Git-репозитория. Удачи!
Работа с удалёнными репозиториями
Для того, чтобы внести вклад в какой-либо Git-проект, вам необходимо уметь работать с удалёнными репозиториями.
Удалённые репозитории представляют собой версии вашего проекта, сохранённые в интернете или ещё где-то в сети.
У вас может быть несколько удалённых репозиториев, каждый из которых может быть доступен для чтения или для чтения-записи.
Взаимодействие с другими пользователями предполагает управление удалёнными репозиториями, а также отправку и получение данных из них.
Управление репозиториями включает в себя как умение добавлять новые, так и умение удалять устаревшие репозитории, а также умение управлять различными удалёнными ветками, объявлять их отслеживаемыми или нет и так далее.
В данном разделе мы рассмотрим некоторые из этих навыков.
|
Примечание |
Удаленный репозиторий может находиться на вашем локальном компьютере. Вполне возможно, что удалённый репозиторий будет находиться на том же компьютере, на котором работаете вы. |
Просмотр удалённых репозиториев
Для того, чтобы просмотреть список настроенных удалённых репозиториев, вы можете запустить команду git remote.
Она выведет названия доступных удалённых репозиториев.
Если вы клонировали репозиторий, то увидите как минимум origin — имя по умолчанию, которое Git даёт серверу, с которого производилось клонирование:
$ git clone https://github.com/schacon/ticgit
Cloning into 'ticgit'...
remote: Reusing existing pack: 1857, done.
remote: Total 1857 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (1857/1857), 374.35 KiB | 268.00 KiB/s, done.
Resolving deltas: 100% (772/772), done.
Checking connectivity... done.
$ cd ticgit
$ git remote
originВы можете также указать ключ -v, чтобы просмотреть адреса для чтения и записи, привязанные к репозиторию:
$ git remote -v
origin https://github.com/schacon/ticgit (fetch)
origin https://github.com/schacon/ticgit (push)Если у вас больше одного удалённого репозитория, команда выведет их все.
Например, для репозитория с несколькими настроенными удалёнными репозиториями в случае совместной работы нескольких пользователей, вывод команды может выглядеть примерно так:
$ cd grit
$ git remote -v
bakkdoor https://github.com/bakkdoor/grit (fetch)
bakkdoor https://github.com/bakkdoor/grit (push)
cho45 https://github.com/cho45/grit (fetch)
cho45 https://github.com/cho45/grit (push)
defunkt https://github.com/defunkt/grit (fetch)
defunkt https://github.com/defunkt/grit (push)
koke git://github.com/koke/grit.git (fetch)
koke git://github.com/koke/grit.git (push)
origin git@github.com:mojombo/grit.git (fetch)
origin git@github.com:mojombo/grit.git (push)Это означает, что мы можем легко получить изменения от любого из этих пользователей.
Возможно, что некоторые из репозиториев доступны для записи и в них можно отправлять свои изменения, хотя вывод команды не даёт никакой информации о правах доступа.
Обратите внимание на разнообразие протоколов, используемых при указании адреса удалённого репозитория; подробнее мы рассмотрим протоколы в разделе Установка Git на сервер главы 4.
Добавление удалённых репозиториев
В предыдущих разделах мы уже упоминали и приводили примеры добавления удалённых репозиториев, сейчас рассмотрим эту операцию подробнее.
Для того, чтобы добавить удалённый репозиторий и присвоить ему имя (shortname), просто выполните команду git remote add <shortname> <url>:
$ git remote
origin
$ git remote add pb https://github.com/paulboone/ticgit
$ git remote -v
origin https://github.com/schacon/ticgit (fetch)
origin https://github.com/schacon/ticgit (push)
pb https://github.com/paulboone/ticgit (fetch)
pb https://github.com/paulboone/ticgit (push)Теперь вместо указания полного пути вы можете использовать pb.
Например, если вы хотите получить изменения, которые есть у Пола, но нету у вас, вы можете выполнить команду git fetch pb:
$ git fetch pb
remote: Counting objects: 43, done.
remote: Compressing objects: 100% (36/36), done.
remote: Total 43 (delta 10), reused 31 (delta 5)
Unpacking objects: 100% (43/43), done.
From https://github.com/paulboone/ticgit
* [new branch] master -> pb/master
* [new branch] ticgit -> pb/ticgitВетка master из репозитория Пола сейчас доступна вам под именем pb/master.
Вы можете слить её с одной из ваших веток или переключить на неё локальную ветку, чтобы просмотреть содержимое ветки Пола.
Более подробно работа с ветками рассмотрена в главе Ветвление в Git.
Получение изменений из удалённого репозитория — Fetch и Pull
Как вы только что узнали, для получения данных из удалённых проектов, следует выполнить:
$ git fetch [remote-name]Данная команда связывается с указанным удалённым проектом и забирает все те данные проекта, которых у вас ещё нет.
После того как вы выполнили команду, у вас должны появиться ссылки на все ветки из этого удалённого проекта, которые вы можете просмотреть или слить в любой момент.
Когда вы клонируете репозиторий, команда clone автоматически добавляет этот удалённый репозиторий под именем «origin».
Таким образом, git fetch origin извлекает все наработки, отправленные на этот сервер после того, как вы его клонировали (или получили изменения с помощью fetch).
Важно отметить, что команда git fetch забирает данные в ваш локальный репозиторий, но не сливает их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент.
Вам необходимо вручную слить эти данные с вашими, когда вы будете готовы.
Если ветка настроена на отслеживание удалённой ветки (см. следующий раздел и главу Ветвление в Git чтобы получить больше информации), то вы можете использовать команду git pull чтобы автоматически получить изменения из удалённой ветки и слить их со своей текущей.
Этот способ может для вас оказаться более простым или более удобным.
К тому же, по умолчанию команда git clone автоматически настраивает вашу локальную ветку master на отслеживание удалённой ветки master на сервере, с которого вы клонировали репозиторий.
Название веток может быть другим и зависит от ветки по умолчанию на сервере.
Выполнение git pull, как правило, извлекает (fetch) данные с сервера, с которого вы изначально клонировали, и автоматически пытается слить (merge) их с кодом, над которым вы в данный момент работаете.
|
Примечание |
Начиная с версии 2.27, команда Если хотите использовать поведение Git по умолчанию (простое смещение вперёд если возможно — иначе создание коммита слияния): Если хотите использовать перебазирование при получении изменений: |
Отправка изменений в удаленный репозиторий (Push)
Когда вы хотите поделиться своими наработками, вам необходимо отправить их в удалённый репозиторий.
Команда для этого действия простая: git push <remote-name> <branch-name>.
Чтобы отправить вашу ветку master на сервер origin (повторимся, что клонирование обычно настраивает оба этих имени автоматически), вы можете выполнить следующую команду для отправки ваших коммитов:
Эта команда срабатывает только в случае, если вы клонировали с сервера, на котором у вас есть права на запись, и если никто другой с тех пор не выполнял команду push.
Если вы и кто-то ещё одновременно клонируете, затем он выполняет команду push, а после него выполнить команду push попытаетесь вы, то ваш push точно будет отклонён.
Вам придётся сначала получить изменения и объединить их с вашими и только после этого вам будет позволено выполнить push.
Обратитесь к главе Ветвление в Git для более подробного описания, как отправлять изменения на удалённый сервер.
Просмотр удаленного репозитория
Если хотите получить побольше информации об одном из удалённых репозиториев, вы можете использовать команду git remote show <remote>.
Выполнив эту команду с некоторым именем, например, origin, вы получите следующий результат:
$ git remote show origin
* remote origin
Fetch URL: https://github.com/schacon/ticgit
Push URL: https://github.com/schacon/ticgit
HEAD branch: master
Remote branches:
master tracked
dev-branch tracked
Local branch configured for 'git pull':
master merges with remote master
Local ref configured for 'git push':
master pushes to master (up to date)Она выдаёт URL удалённого репозитория, а также информацию об отслеживаемых ветках.
Эта команда любезно сообщает вам, что если вы, находясь на ветке master, выполните git pull, ветка master с удалённого сервера будет автоматически влита в вашу сразу после получения всех необходимых данных.
Она также выдаёт список всех полученных ею ссылок.
Это был пример для простой ситуации и вы наверняка встречались с чем-то подобным.
Однако, если вы используете Git более интенсивно, вы можете увидеть гораздо большее количество информации от git remote show:
$ git remote show origin
* remote origin
URL: https://github.com/my-org/complex-project
Fetch URL: https://github.com/my-org/complex-project
Push URL: https://github.com/my-org/complex-project
HEAD branch: master
Remote branches:
master tracked
dev-branch tracked
markdown-strip tracked
issue-43 new (next fetch will store in remotes/origin)
issue-45 new (next fetch will store in remotes/origin)
refs/remotes/origin/issue-11 stale (use 'git remote prune' to remove)
Local branches configured for 'git pull':
dev-branch merges with remote dev-branch
master merges with remote master
Local refs configured for 'git push':
dev-branch pushes to dev-branch (up to date)
markdown-strip pushes to markdown-strip (up to date)
master pushes to master (up to date)Данная команда показывает какая именно локальная ветка будет отправлена на удалённый сервер по умолчанию при выполнении git push.
Она также показывает, каких веток с удалённого сервера у вас ещё нет, какие ветки всё ещё есть у вас, но уже удалены на сервере, и для нескольких веток показано, какие удалённые ветки будут в них влиты при выполнении git pull.
Удаление и переименование удалённых репозиториев
Для переименования удалённого репозитория можно выполнить git remote rename.
Например, если вы хотите переименовать pb в paul, вы можете это сделать при помощи git remote rename:
$ git remote rename pb paul
$ git remote
origin
paulСтоит упомянуть, что это также изменит имена удалённых веток в вашем репозитории.
То, к чему вы обращались как pb/master, теперь стало paul/master.
Если по какой-то причине вы хотите удалить удаленный репозиторий — вы сменили сервер или больше не используете определённое зеркало, или кто-то перестал вносить изменения — вы можете использовать git remote rm:
$ git remote remove paul
$ git remote
originПри удалении ссылки на удалённый репозиторий все отслеживаемые ветки и настройки, связанные с этим репозиторием, так же будут удалены.
Продолжаю изучение темы Git и GitHub. На повестке дня стоит вопрос — каким образом можно изменить ссылку существующего репозитория?
Нет — не так! Попробую зайти с другой стороны и сказать иначе. Имеется готовый репозиторий Template, размещенный на сервере GitHub. Этот репозиторий является шаблоном (template starter) при создании разнообразных проектов. Нечто похожим на известный HTML5 Boilerplate.
Репозиторий Template клонируется на локальную машину с именем разрабатываемого проекта, такой командой:
$ git clone https://github.com/gearmobile/template.git projectЗатем в созданном репозитории Project разрабатывается требуемый проект.
Но есть одно НО — необходимо преобразовать видоизмененный репозиторий Project в отдельный, самостоятельный репозиторий. Конечно, по большому счету, это уже и есть отдельный, самостоятельный репозиторий.
Но вот ссылка у репозитория Project указывает на оригинал — репозиторий Template. И если произвести
на GitHub, то произойдет обновление репозитория Template.
А этого крайне нежелательно допустить, так как этот репозиторий является стартовым, чистым листом для всех новых проектов!
У меня же стоит такая задача — скопировать стартовый репозиторий Template на локальную машину, преобразовать его в конкретный проект, вновь залить на GitHub уже как самостоятельный репозиторий с именем проекта в качестве имени репозитория. Как поступить?
Можно решить вопрос несколькими способами. Ниже приведу пару из них — самых простых и доступных для моего понимания вечного newbie в GitGitHub. Может быть, по мере освоения темы дополню статью более универсальным и грамотным способом.
Правка config
У клонированного на локальную машину репозитория ссылка на его удаленный оригинал размещена в конфигурационном файле
по пути
1 |
.git/config |
, в секции
1 |
[remote "origin"] |
, в переменной с именем
1 |
url |
:
$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
precomposeunicode = true
[remote "origin"]
url = https://github.com/gearmobile/template.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/masterПоэтому в локальном репозитории Project можно просто изменить эту ссылку с помощью любого текстового редактора.
Отредактирую файл
и изменю в нем ссылку с
https://github.com/gearmobile/template.gitна
https://github.com/gearmobile/project.git… где последняя — это ссылка на новый пустой репозиторий Project, который я создал на GitHub.
Теперь конфигурационный файл
для локального репозитория Project будет выглядеть таким образом (обратить внимание на переменную
1 |
url |
):
$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
precomposeunicode = true
[remote "origin"]
url = https://github.com/gearmobile/project.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/masterВсе — теперь локальный репозиторий Project является абсолютно самостоятельным и уникальным репозиторием, связанным ссылкой со своей удаленной копией на сервере GitHub.
Осталось только сделать
, чтобы залить на GitHub. Правда, здесь придется воспользоваться ключом
1 |
-f |
(как это описано в предыдущей статье Откат коммитов на GitHub):
$ git push -fКоманда set-url
Второй способ практически идентичен предыдущему за тем лишь исключением, что он более правильный, так как для изменения url-адреса репозитория используется предназначенная для этого консольная команда Git —
.
Точно также создаю на локальной машине копию Another Project удаленного репозитория Template:
$ git clone https://github.com/gearmobile/template.git another-projectСсылка в новом репозитории Another-Project все также указывает на свой оригинал — репозиторий Template:
$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
precomposeunicode = true
[remote "origin"]
url = https://github.com/gearmobile/template.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/masterСоздаю на GitHub новый репозиторий Another-Project, который будет удаленной копией локального (уже существующего) репозитория Another-Project. И изменяю ссылку на вновь созданный удаленный репозиторий Another-Project:
$ git remote set-url origin https://github.com/gearmobile/another-project.gitПроверяю, изменилась ли ссылка в конфигурационном файле
(переменная
1 |
url |
):
$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
precomposeunicode = true
[remote "origin"]
url = https://github.com/gearmobile/another-project.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/masterДа, ссылка была успешно изменена на новый удаленный репозиторий Another-Project. Можно вносить изменения и выполнять
на GitHub.
Небольшое заключение
Преимущество двух описанных выше способ в том, что не теряется история коммитов.
На этом пока все.
I’ve recently cloned a repo to my local drive, but now I’m trying to push all changes to a complete new repo. However, git keeps telling me that permission is denied, and that’s because it’s trying to push to the originally-cloned repo.
DETAILS:
I originally cloned from https://github.com/taylonr/intro-to-protractor (i.e. based on a Pluralsight course at https://app.pluralsight.com/library/courses/protractor-introduction/table-of-contents ) .
Now that I’ve completed the course, I’d like to push my finalized code up to my own git repo (which I just created on github):
https://github.com/robertmazzo/intro-to-protractor
When I use the following git command:
git remote add origin https://github.com/robertmazzo/intro-to-protractor.git
it tells me remote origin already exists , which I guess is fine because I already created it on github.com.
However, when I push my changes up I’m getting an exception.
git push origin master
remote: Permission to taylonr/intro-to-protractor.git denied to robertmazzo.
fatal: unable to access 'https://github.com/taylonr/intro-to-protractor.git/':
The requested URL returned error: 403
So I’m investigating how I can switch to my new repository, but this is exactly where my issue is. I cannot figure this part out.
user229044♦
229k40 gold badges329 silver badges336 bronze badges
asked Sep 6, 2016 at 14:31
1
Before you can add a new remote named «origin», you need to either delete the old one, or simply rename it if you still need access to it for some reason.
# Pick one
git remote remove origin # delete it, or ...
git remote rename origin old-origin # ... rename it
# Now you can add the new one
git remote add origin https://github.com/robertmazzo/intro-to-protractor.git
answered Sep 6, 2016 at 14:34
chepnerchepner
479k70 gold badges502 silver badges653 bronze badges
origin is only an alias to identify your remote repository.
You can create a new remote reference and push
git remote add new_origin https://github.com/robertmazzo/intro-to-protractor.git
git push new_origin master
If you want to remove the previous reference
git remote remove origin
answered Sep 6, 2016 at 14:34
lubilislubilis
3,8424 gold badges32 silver badges54 bronze badges
Either add a new remote
git remote add <name> <url>
or, if you completely want to remove the old origin, first do
git remote remove origin
and then
git remote add origin <url>
Note that the message remote origin already exists is not fine. It tells you that the operation failed, i.e. it could not set the new remote.
answered Sep 6, 2016 at 14:33
Martin NyoltMartin Nyolt
4,3043 gold badges26 silver badges35 bronze badges
I’ve recently cloned a repo to my local drive, but now I’m trying to push all changes to a complete new repo. However, git keeps telling me that permission is denied, and that’s because it’s trying to push to the originally-cloned repo.
DETAILS:
I originally cloned from https://github.com/taylonr/intro-to-protractor (i.e. based on a Pluralsight course at https://app.pluralsight.com/library/courses/protractor-introduction/table-of-contents ) .
Now that I’ve completed the course, I’d like to push my finalized code up to my own git repo (which I just created on github):
https://github.com/robertmazzo/intro-to-protractor
When I use the following git command:
git remote add origin https://github.com/robertmazzo/intro-to-protractor.git
it tells me remote origin already exists , which I guess is fine because I already created it on github.com.
However, when I push my changes up I’m getting an exception.
git push origin master
remote: Permission to taylonr/intro-to-protractor.git denied to robertmazzo.
fatal: unable to access 'https://github.com/taylonr/intro-to-protractor.git/':
The requested URL returned error: 403
So I’m investigating how I can switch to my new repository, but this is exactly where my issue is. I cannot figure this part out.
user229044♦
229k40 gold badges329 silver badges336 bronze badges
asked Sep 6, 2016 at 14:31
1
Before you can add a new remote named «origin», you need to either delete the old one, or simply rename it if you still need access to it for some reason.
# Pick one
git remote remove origin # delete it, or ...
git remote rename origin old-origin # ... rename it
# Now you can add the new one
git remote add origin https://github.com/robertmazzo/intro-to-protractor.git
answered Sep 6, 2016 at 14:34
chepnerchepner
479k70 gold badges502 silver badges653 bronze badges
origin is only an alias to identify your remote repository.
You can create a new remote reference and push
git remote add new_origin https://github.com/robertmazzo/intro-to-protractor.git
git push new_origin master
If you want to remove the previous reference
git remote remove origin
answered Sep 6, 2016 at 14:34
lubilislubilis
3,8424 gold badges32 silver badges54 bronze badges
Either add a new remote
git remote add <name> <url>
or, if you completely want to remove the old origin, first do
git remote remove origin
and then
git remote add origin <url>
Note that the message remote origin already exists is not fine. It tells you that the operation failed, i.e. it could not set the new remote.
answered Sep 6, 2016 at 14:33
Martin NyoltMartin Nyolt
4,3043 gold badges26 silver badges35 bronze badges
При разработке собственного проекта, рано или поздно, приходится задуматься о том, где хранить исходный код и как поддерживать работу с несколькими версиями. В случае работы на компанию, обычно это решается за вас и необходимо только поддерживать принятые правила. Есть несколько общеупотребимых систем контроля версий, и мы рассмотрим одну из самых популярных — это Git и сервис Github.
Система Git появилась, как средство управления исходными текстами в операционной системе Linux и завоевала множество поклонников в среде Open Source.
Сервис Github предоставляет хостинг (хранение) исходных текстов как на платной, так и на бесплатной основе. Это одна из крупнейших систем, которую любят Open Source пользователи. Основное отличие платной версии — это возможность создания частных репозиториев (хранилищ) исходных текстов и если вам скрывать нечего, то можете спокойно пользоваться бесплатной версией.
После того, как вы начали работу над проектом и написали какой-то работающий прототип, у вас появится желание сохранить результаты работы. Это так же может быть полезно в случае, если вы захотите продолжить работу на другом компьютере. Самое простое решение — это сохранить все на флешке. Этот вариант неплохо работает, но если есть подключение к интернету (а сейчас у кого его нет), то удобно воспользоваться системами Git/Github.
В этой статье будут описаны базовые сценарии использования систем Git/Github при работе над проектом в среде Linux с помощью командной строки. Все примеры проверялись на системе с Linux Ubuntu 14.04 и Git 1.9.1. Если вы пользуетесь другим дистрибутивом, то возможны отличия.
Создание локального репозитория
Предположим, что ваш проект находится в папке /home/user/project. Перед тем, как сохранять исходники, можно посмотреть, нет ли временных файлов в папке с проектом и по возможности их удалить.
Для просмотра папки удобно воспользоваться командой tree, которая покажет не только содержимое каждой папки, но и древовидную структуру директорий.
Часто временные файлы содержат специфические суффиксы, по которым их легко обнаружить и в последствии удалить. Для поиска таких файлов можно воспользоваться командой find. В качестве примера посмотрим, как найти все файлы, которые генерируются компилятором Python и имеют расширение .pyc
Переходим в папку с проектом /home/user/project:
cd /home/user/project
И показываем список файлов с расширением .pyc:
find . -name *.pyc
Эта команда выведет список всех файлов с расширением .pyc в текущей директории и в ее поддиректориях. Для удаления найденных файлов, достаточно добавить ключ -delete к этой команде:
find . -name *.pyc -delete
Очень рекомендуется не спешить и сразу ключ этот не добавлять. Первый раз вызвать команду для просмотра файлов и только убедившись, что в список не попало ничего полезного добавить ключ удаления.
Создадим локальный репозиторий в папке с проектом:
git init
После выполнения этой команды появится новая папка с именем .git. В ней будет несколько файлов и поддиректориев. На данный момент система управления версиями еще не видит наших файлов.
Добавление файлов в локальный репозиторий
Для добавления файлов используется команда:
git add readme
После выполнения команды, файл readme будет добавлен в систему управления версий (конечно если он уже был то этого в проекте). При добавлении файла генерируется хеш значение, которое выглядит примерно так:
9f2422325cef705b7682418d05a538d891bad5c8
Добавленные файлы хранятся в папке .git/objects/xx/yyyyyyyy, при этом первые 2 цифры хеша ипользуются для указания директории, а остальное хеш значение является именем файла. Наш добавленный файл будет находится здесь:
.git/objects/9f/2422325cef705b7682418d05a538d891bad5c8
Что легко увидеть с помощью команды:
ls .git/objects
Сам файл является архивом, который легко распаковать и вывести на экран, указав полное значение хеша.
git cat-file -p 9f2422325cef705b7682418d05a538d891bad5c8
Для того, чтобы добавить все файлы из текущей директории введите:
git add .
Если нужно добавить файлы из текущей директории и из всех поддиректориев, то используйте:
git add --all
Для того, чтобы в систему не попадали временные файлы, можно их занести в файл .gitignore, который нужно создать самостоятельно и разместить в корневом каталоге проекта (на том же уровне, что и .git директория).
Например, если в в файл .gitignore добавить следующую строчку *.pyc, то все файлы с расширением .pyc не будут добавляться в репозиторий.
После добавления файлов, все изменения находятся в так называемой staging (или cached) area. Это некоторое временнное хранилище, которое используется для накопления изменений и из которого создаются собственно версии проектов (commit).
Для просмотра текущего состояния можно воспользоваться командой:
git status
После выполнения команды мы увидим, что в stage area находится наш файл:
new file: readme
Если вы продолжите вносить изменения в файл readme, то после вызова команды git status вы увидите две версии файла.
new file: readme
modified: readme
Чтобы добавить новые изменения достаточно повторить команду. Команда git add не только добавляет новые файлы, но и все изменения файлов, которые были добавлены ранее.
git add readme
Можно отменить добавления файла readme в staging area с помощью команды:
git rm --cached readme
После выполнения команды, файл readme отметится, как неизмененный системой.
Создание версии проекта
После того, как мы добавили нужные файлы в staging area мы можем создать версию проекта. С помощью команды:
git commit -m "comment"
Каждая новая версия сопровождается комментарием.
После коммита, мы сможем найти два новых объекта внутри .git репозитория.
.git/objects/9f/2422325cef705b7682418d05a538d891bad5c8
.git/objects/65/7ab4c07bd3914c7d66e4cb48fe57f5c3aa7026
.git/objects/da/c6721c3b75fcb3c9d87b18ba4cef2e15e0a3d3
Посмотрим, что внутри:
git cat-file -t 657ab4c07bd3914c7d66e4cb48fe57f5c3aa7026
Ключ -t показывает тип объекта. В результате мы видим:
commit
Для второго объекта:
git cat-file -t dac6721c3b75fcb3c9d87b18ba4cef2e15e0a3d3
Результат:
tree
Для самого первого файла:
git cat-file -t 9f2422325cef705b7682418d05a538d891bad5c8
Мы видим:
blob
Если мы будем дальше изучать содержимое этих файлов, то обнаружим древовидную структуру. От каждого коммита можно по ссылкам пройти по всем измененным файлам. Для практического применения это не очень нужно, но возможно так будет легче понять, что происходит при работе с системой Git.
Самую первую версию отменить нельзя. Ее можно только исправить. Если вы хотите добавить изменения в последнюю версию, то после выполнения команды commit, добавляете необходимые изменения и вызываете:
git commit -m "comment" --amend
Или так:
git commit --amend --no-edit
Ключ —no-edit нужен, чтобы не вводить заново комментарий.
Можно просмотреть изменения, которые вы внесли последним коммитом:
git show
Или так:
git show --name-only
Ключ —name-only нужен, чтобы показывать только имена измененный файлов. Без него по каждому измененнному файлу будет выдан список всех изменений.
Если вы продолжили работать и изменили только те файлы, которые были уже добавлены в систему командой git add, вы можете сделать коммит одной командой:
git commit -a -m "comment"
Для просмотра списка всех коммитов, воспользуйтесь командой:
git log
Или так:
git log --oneline
Ключ —oneline нужен, чтобы уменьшить количество информации выдаваемой на экран. С этим ключем каждый коммит показывается в одну строчку. Например:
2b82e80 update
657ab4c first
Для того, чтобы просмотреть изменения по конкретному коммиту, достаточно в команду git show добавить хеш значение коммита, которое можно получить с помощью предыдущей команды.
git show 657ab4c
Для отмены последнего коммита (кроме самого первого) можно воспользоваться следующей командой:
git reset HEAD~1
Для того чтобы удалить все файлы в папке, которые не относятся к проекту и не сохранены в репозитории, можно воспользоваться командой:
git clean -df
Создание репозитория на Github
До текущего момента мы работали с локальным репозиторием, который сохранялся в папке на компьютере. Если мы хотим иметь возможность сохранения проекта в интернете, создадим репозиторий на Github. Для начала нужно зарегистрироваться на сайте github.com под именем myuser (в вашем случае это может быть любое другое имя).
После регистрации нажимаем кнопочку «+» и вводим название репозитория. Выбираем тип Public (репозиторий всегда Public для бесплатной версии) и нажимаем Create.
В результате мы создали репозиторий на сайте Github. На экране мы увидим инструкцию, как соединить наш локальный репозиторий со вновь созданным. Часть команд нам уже знакома.
Добавляем удаленный репозиторий (по протоколу SSH) под именем origin (вместо origin можно использовать любое другое имя).
git remote add origin git@github.com:myuser/project.git
Можем просмотреть результат добавления с помощью команды:
git remote -v
Если все было правильно сделано, то увидим:
origin git@github.com:myuser/project.git (fetch)
origin git@github.com:myuser/project.git (push)
Для того, чтобы отменить регистрацию удаленного репозитария введите:
git remote rm origin
Это может понадобиться, если вы захотите поменять SSH доступ на HTTPS. После этого можно добавить его опять, например под именем github и протоколом HTTPS.
git remote add github https://github.com/myuser/project.git
Следующей командой вы занесете все изменения, которые были сделаны в локальном репозитории на Github.
git push -u github master
Ключ -u используется для того, чтобы установить связь между удаленным репозиторием github и вашей веткой master. Все дальнейшие изменения вы можете переносить на удаленный репозиторий упрощенной командой.
git push
Перенос репозитория на другой компьютер
После того, как репозиторий был создан на Github, его можно скопировать на любой другой компьютер. Для этого применяется команда:
git clone https://github.com/myuser/project.git
Результатом выполнения этой команды будет создание папки project в текущем каталоге. Эта папка также будет содержать локальный репозиторий (то есть папку .git).
Так же можно добавить название папки, в которой вы хотите разместить локальный репозиторий.
git clone https://github.com/myuser/project.git <myfolder>
Работа с одним репозиторием с разных компьютеров
С одним репозиторием с разных компьютеров может работать несколько разработчиков или вы сами, если например работаете над одним и тем же проектом дома и на работе.
Для получения обновлений с удаленного репозитория воспользуйтесь командой:
git pull
Если вы изменили ваши локальные файлы, то команда git pull выдаст ошибку. Если вы уверены, что хотите перезаписать локальные файлы, файлами из удаленного репозитория то выполните команды:
git fetch --all
git reset --hard github/master
Вместо github подставьте название вашего удаленного репозитория, которое вы зарегистрировали командой git push -u.
Как мы уже знаем, для того чтобы изменения выложить на удаленный репозиторий используется команда:
git push
В случае, если в удаленном репозитории лежат файлы с версией более новой, чем у вас в локальном, то команда git push выдаст ошибку. Если вы уверены, что хотите перезаписать файлы в удаленном репозитории несмотря на конфликт версий, то воспользуйтесь командой:
git push -f
Иногда возникает необходимость отложить ваши текущие изменения и поработать над файлами, которые находятся в удаленном репозитории. Для этого отложите текущие изменения командой:
git stash
После выполнения этой команды ваша локальная директория будет содержать файлы такие же, как и при последнем коммите. Вы можете загрузить новые файлы из удаленного репозитория командой git pull и после этого вернуть ваши изменения которые вы отложили командой:
git stash pop
Заключение
Мы рассмотрели базовые сценарии работы с системами Git и Github. Каждая приведенная выше команда имеет значительно больше ключей и соответственно возможностей. Постепенное их изучение даст вам возможность легко оберегать свои иходники и больше концентрироваться непосредственно на разработке.
In this article we’ll follow simple steps to change a remote Git repository using the command line.
- List your existing remotes
- Change a remote Git repository
1. List your existing remotes
To list the existing remotes we open the terminal and type in the following command:
$ git remote -v
If you copied the link to the repository from Clone with SSH in your GitLab, the output should look something like this:
origin This email address is being protected from spambots. You need JavaScript enabled to view it.:user/repository.git (fetch)
origin This email address is being protected from spambots. You need JavaScript enabled to view it.:user/repository.git (push)
If you copied the link to the repository from Clone with HTTPS in your GitLab, the output should look something like this:
origin https://your.git.repo.example.com/user/repository.git (fetch)
origin https://your.git.repo.example.com/user/repository.git (push)
Note: To find the SSH and HTTPS URLs, go to your GitLab, select your project, and click on Clone.
We can change the remote repository by using git remote set-url command:
$ git remote set-url origin This email address is being protected from spambots. You need JavaScript enabled to view it.:user/repository2.git
The command takes two arguments: existing name of the remote (in our case origin) and a new remote URL (in our case This email address is being protected from spambots. You need JavaScript enabled to view it.:user/repository2.git)
In case you change your remote repository to https URL, you will be prompted for your username and password next time you use git fetch, git pull or git push.
If you try to use a link to a non-existing remote, you will get the following error:
> fatal: No such remote 'origin'
When this happens, recheck your URL and make sure it matches the one in your GitLab or GitHub.
If you’d like to learn about Git make sure to check the following articles:
- Push identical code into two git remote repositories
- How to git revert a commit
В системе SVN используется единый централизованный репозиторий, служащий центром связи для разработчиков. Совместная работа ведется путем передачи наборов изменений между рабочими копиями разработчиков и центральным репозиторием. Однако модель распределенной совместной работы в Git предполагает, что каждый разработчик использует собственную копию репозитория со своей локальной историей и структурой веток. Обычно пользователи делятся не отдельными наборами изменений, а сериями коммитов. Вместо того чтобы выполнять коммит одного набора изменений из рабочей копии в центральный репозиторий, Git позволяет передавать между репозиториями целые ветки.
Команда git remote входит в состав системы, отвечающей за синхронизацию изменений. Записи, зарегистрированные с помощью команды git remote, используются в сочетании с командами git fetch, git push и git pull. Все эти команды отвечают за свою часть работы по выполнению синхронизации. Подробнее можно узнать, пройдя по соответствующим ссылкам.
git remote
Команда git remote позволяет создавать, просматривать и удалять подключения к другим репозиториям. Удаленные подключения скорее похожи на закладки, чем на прямые ссылки на другие репозитории. Они служат удобными именами, с помощью которых можно сослаться на не очень удобный URL-адрес, а не предоставляют доступ к другому репозиторию в режиме реального времени.
Например, на следующем рисунке изображены два удаленных подключения из вашего репозитория к центральному репозиторию и репозиторию другого разработчика. Вместо того, чтобы ссылаться на них по их полным URL-адресам, вы можете передавать командам Git только ярлыки origin и john.
Обзор использования git remote
По сути, команда git remote — это интерфейс для управления списком записей об удаленных подключениях, которые хранятся в файле /.git/config репозитория. Для просмотра текущего состояния списка удаленных подключений используются следующие команды.
Просмотр конфигураций удаленных репозиториев Git
Список ваших удаленных подключений к другим репозиториям.
Аналогично команде выше, но включает URL-адрес каждого подключения.
Создание и изменение конфигураций удаленных репозиториев Git
Команда git remote также предоставляет удобный способ изменения файла /.git/config репозитория. Перечисленные ниже команды позволяют управлять подключениями к другим репозиториям и изменять файл /.git/config репозитория. Такого же результата можно достичь, напрямую отредактировав файл /.git/config с помощью текстового редактора.
git remote add <name> <url>Создание нового подключения к удаленному репозиторию. После добавления удаленного репозитория имя ＜name＞ можно использовать в качестве удобного ярлыка для адреса ＜url＞ в других командах Git.
Удаление подключения к удаленному репозиторию с именем ＜name＞.
git remote rename <old-name> <new-name>Переименование удаленного подключения с имени ＜old-name＞ на ＜new-name＞.
Обсуждение git remote
Git предоставляет каждому разработчику полностью изолированную среду разработки. Информация не передается между репозиториями автоматически. Вместо этого разработчикам нужно вручную загружать вышестоящие коммиты в локальный репозиторий или вручную отправлять локальные коммиты обратно в центральный репозиторий. Команда git remote представляет собой простой способ передачи URL-адресов в эти команды обмена.
Удаленное подключение к origin
В процессе клонирования с помощью команды git clone автоматически создается удаленное подключение к исходному репозиторию (такое соединение называется origin). Это позволяет разработчикам, создающим локальную копию центрального репозитория, легко загружать вышестоящие изменения или публиковать локальные коммиты. Именно поэтому большинство проектов на основе Git называют свой центральный репозиторий origin.
URL-адреса репозиториев
Git поддерживает различные способы ссылки на удаленный репозиторий. Два наиболее простых способа доступа к удаленному репозиторию: протоколы HTTP и SSH. Протокол HTTP — простой способ разрешить к репозиторию анонимный доступ только для чтения. Пример ниже.
http://host/path/to/repo.gitОднако HTTP-адрес, как правило, не позволяет отправлять коммиты (в любом случае вы не захотите разрешать анонимную отправку изменений с помощью команды push). Чтобы использовать доступ для чтения и записи следует использовать протокол SSH:
ssh://user@host/path/to/repo.gitВам понадобится лишь действующий аккаунт SSH на хост-машине, а в остальном Git поддерживает аутентифицированный доступ через SSH по умолчанию. Необходимые URL-адреса предоставляются современными безопасными решениями для хостинга от сторонних провайдеров, например Bitbucket.com.
Команды git remote
Команда git remote — одна из многих команд Git, которые принимают дополнительные «подкоманды». Ниже рассмотрены наиболее часто используемые подкоманды git remote.
Добавляет запись к ./.git/config для удаленного репозитория с именем ＜name＞ по URL-адресу ＜url＞.
Принимает параметр -f, который запустит команду git fetch сразу после создания записи об удаленном репозитории.
Принимает параметр --tags, который немедленно запустит команду git fetch и импортирует все теги из удаленного репозитория.
Обновляет ./.git/config для переименования записи с ＜OLD＞ на ＜NEW＞. При этом обновляются все удаленно отслеживаемые ветки и настройки конфигурации удаленного репозитория.
Изменяет ./.git/config и удаляет удаленный репозиторий с именем ＜NAME＞. При этом удаляются все удаленно отслеживаемые ветки и настройки конфигурации удаленного репозитория.
Вывод URL-адресов для записи об удаленном репозитории.
Принимает параметр --push, поскольку URL-адреса чаще отправляют с помощью команды push, а не извлекают с помощью fetch.
При указании параметра --all будут перечислены все URL-адреса для данного удаленного репозитория.
Выводит общую информацию об удаленном репозитории с именем ＜NAME＞.
Удаляет из репозитория ＜NAME＞ все локальные ветки, которые отсутствуют в удаленном репозитории.
Принимает параметр --dry-run, который выводит список удаляемых веток, но на самом деле не удаляет их.
Примеры git remote
Зачастую бывает удобно иметь подключение не только к репозиторию origin, но и к репозиториям коллег. Например, если ваш коллега Джон поддерживает общедоступный репозиторий на dev.example.com/john.git, вы можете добавить подключение следующим образом:
git remote add john http://dev.example.com/john.gitДоступа к индивидуальным репозиториям разработчиков позволяет вести совместную работу за пределами центрального репозитория. Это может быть очень полезно для небольших команд, работающих над большим проектом.
Просмотр удаленных репозиториев
По умолчанию команда git remote отображает ранее сохраненные удаленные подключения к другим репозиториям. Создается однострочный список закладок с именами удаленных репозиториев.
$ git remote
origin
upstream
other_users_repoПри вызове git remote с параметром -v будет выведен список закладок с именами и соответствующими URL-адресами репозиториев. Параметр -v расшифровывается как «verbose» — подробный. Ниже приведен пример подробного вывода команды git remote.
git remote -v
origin git@bitbucket.com:origin_user/reponame.git (fetch)
origin git@bitbucket.com:origin_user/reponame.git (push)
upstream https://bitbucket.com/upstream_user/reponame.git (fetch)
upstream https://bitbucket.com/upstream_user/reponame.git (push)
other_users_repo https://bitbucket.com/other_users_repo/reponame (fetch)
other_users_repo https://bitbucket.com/other_users_repo/reponame (push) Добавление удаленных репозиториев
Команда git remote add используется для создания записи о новом подключении к удаленному репозиторию. После добавления удаленного репозитория имя можно использовать в качестве удобного ярлыка для адреса в других командах Git. Дополнительные сведения о принятом синтаксисе URL-адресов см. в разделе «URL-адреса репозиториев» ниже. Эта команда создаст новую запись в файле ./.git/config репозитория. Ниже приведен пример обновления этого файла конфигурации.
$ git remote add fake_test https://bitbucket.com/upstream_user/reponame.git; [remote "remote_test"]
url = https://bitbucket.com/upstream_user/reponame.git
fetch = +refs/heads/*:refs/remotes/remote_test/*
Проверка удаленного репозитория
Для получения подробного вывода о конфигурации удаленного репозитория к команде git remote можно добавить подкоманду show. Вывод будет содержать список веток, связанных с удаленным репозиторием, а также конечных точек, подключенных для извлечения (fetch) и отправки (push).
git remote show upstream
* remote upstream
Fetch URL: https://bitbucket.com/upstream_user/reponame.git
Push URL: https://bitbucket.com/upstream_user/reponame.git
HEAD branch: main
Remote branches:
main tracked
simd-deprecated tracked
tutorial tracked
Local ref configured for 'git push':
main pushes to main (fast-forwardable) Получение и извлечение данных из удаленных репозиториев Git
После настройки записи об удаленном репозитории с помощью команды git remote с этим репозиторием можно связываться, передавая его имя в качестве аргумента другим командам Git. Для чтения данных из удаленного репозитория можно использовать и git fetch, и git pull. Эти команды выполняют разные операции (более подробную информацию можно узнать, пройдя по соответствующим ссылкам).
Отправка данных в удаленные репозитории Git
Для записи данных в удаленный репозиторий используется команда git push.
git push <remote-name> <branch-name>В этом примере состояние локальной ветки ＜branch-name＞ передается в удаленный репозиторий, обозначенный как ＜remote-name＞.
Переименование и удаление удаленных репозиториев
git remote rename <old-name> <new-name>Принцип работы команды git remote rename очевиден из названия. В результате ее выполнения происходит переименование удаленного подключения с имени ＜old-name＞ на ＜new-name＞. Кроме того, изменяется контент ./.git/config для переименования записи для удаленного репозитория.
Команда git remote rm удаляет подключение к удаленному репозиторию, обозначенному с помощью параметра ＜name＞. Чтобы показать работу команды, «отменим» добавление из последнего примера. После выполнения команды git remote rm remote_test мы увидим, что запись [remote "remote_test"] удалена из контента ./.git/config.
В последние годы популярность git демонстрирует взрывной рост. Эта система контроля версий используется различными проектами с открытым исходным кодом.
Новичков часто пугает большое количество замысловатых команд и сложных аргументов. Но для начала все они и не нужны. Можно начать с изучения наиболее часто используемых команд, и после этого постепенно расширять свои знания. Именно так мы и поступим в этой статье. Поехали!
Основы
Git — это набор консольных утилит, которые отслеживают и фиксируют изменения в файлах (чаще всего речь идет об исходном коде программ, но вы можете использовать его для любых файлов на ваш вкус). Изначально Git был создан Линусом Торвальдсом при разработке ядра Linux. Однако инструмент так понравился разработчикам, что в последствии, он получил широкое распространение и его стали использовать в других проектах. С его помощью вы можете сравнивать, анализировать, редактировать, сливать изменения и возвращаться назад к последнему сохранению. Этот процесс называется контролем версий.
Для чего он нужен? Ну во-первых, чтобы отследить изменения, произошедшие с проектом, со временем. Проще говоря, мы можем посмотреть как менялись файлы программы, на всех этапах разработки и при необходимости вернуться назад и что-то отредактировать. Часто бывают ситуации, когда, во вполне себе работающий код, вам нужно внести определенные правки или улучшить какой-то функционал, по желанию заказчика. Однако после внедрения нововведений, вы с ужасом понимаете, что все сломалось. У вас начинается судорожно дергаться глаз, а в воздухе повисает немой вопрос: “Что делать?” Без системы контроля версий, вам надо было бы долго напряженно просматривать код, чтобы понять как было до того, как все перестало работать. С Гитом же, все что нужно сделать — это откатиться на коммит назад.
Во-вторых он чрезвычайно полезен при одновременной работе нескольких специалистов, над одним проектом. Без Гита случится коллапс, когда разработчики, скопировав весь код из главной папки и сделав с ним задуманное, попытаются одновременно вернуть весь код обратно.
Git является распределенным, то есть не зависит от одного центрального сервера, на котором хранятся файлы. Вместо этого он работает полностью локально, сохраняя данные в директориях на жестком диске, которые называются репозиторием. Тем не менее, вы можете хранить копию репозитория онлайн, это сильно облегчает работу над одним проектом для нескольких людей. Для этого используются сайты вроде github и bitbucket.
Установка
Установить git на свою машину очень просто:
- Linux — нужно просто открыть терминал и установить приложение при помощи пакетного менеджера вашего дистрибутива. Для Ubuntu команда будет выглядеть следующим образом:
sudo apt-get install git
- Windows — мы рекомендуем git for windows, так как он содержит и клиент с графическим интерфейсом, и эмулятор bash.
- OS X — проще всего воспользоваться homebrew. После его установки запустите в терминале:
brew install git
Если вы новичок, клиент с графическим интерфейсом(например GitHub Desktop и Sourcetree) будет полезен, но, тем не менее, знать команды очень важно.
Настройка
Итак, мы установили git, теперь нужно добавить немного настроек. Есть довольно много опций, с которыми можно играть, но мы настроим самые важные: наше имя пользователя и адрес электронной почты. Откройте терминал и запустите команды:
git config --global user.name "My Name" git config --global user.email myEmail@example.com
Теперь каждое наше действие будет отмечено именем и почтой. Таким образом, пользователи всегда будут в курсе, кто отвечает за какие изменения — это вносит порядок.
Git хранит весь пакет конфигураций в файле .gitconfig, находящемся в вашем локальном каталоге. Чтобы сделать эти настройки глобальными, то есть применимыми ко всем проектам, необходимо добавить флаг –global. Если вы этого не сделаете, они будут распространяться только на текущий репозиторий.
Для того, чтобы посмотреть все настройки системы, используйте команду:
git config --list
Для удобства и легкости зрительного восприятия, некоторые группы команд в Гит можно выделить цветом, для этого нужно прописать в консоли:
git config --global color.ui true git config --global color.status auto git config --global color.branch auto
Если вы не до конца настроили систему для работы, в начале своего пути — не беда. Git всегда подскажет разработчику, если тот запутался, например:
- Команда git —help — выводит общую документацию по git
- Если введем git log —help — он предоставит нам документацию по какой-то определенной команде (в данном случае это — log)
- Если вы вдруг сделали опечатку — система подскажет вам нужную команду
- После выполнения любой команды — отчитается о том, что вы натворили
- Также Гит прогнозирует дальнейшие варианты развития событий и всегда направит разработчика, не знающего, куда двигаться дальше
Тут стоит отметить, что подсказывать система будет на английском, но не волнуйтесь, со временем вы изучите несложный алгоритм ее работы и будете разговаривать с ней на одном языке.
Создание нового репозитория
Как мы отметили ранее, git хранит свои файлы и историю прямо в папке проекта. Чтобы создать новый репозиторий, нам нужно открыть терминал, зайти в папку нашего проекта и выполнить команду init. Это включит приложение в этой конкретной папке и создаст скрытую директорию .git, где будет храниться история репозитория и настройки.
Создайте на рабочем столе папку под названием git_exercise. Для этого в окне терминала введите:
$ mkdir Desktop/git_exercise/ $ cd Desktop/git_exercise/ $ git init
Командная строка должна вернуть что-то вроде:
Initialized empty Git repository in /home/user/Desktop/git_exercise/.git/
Это значит, что наш репозиторий был успешно создан, но пока что пуст. Теперь создайте текстовый файл под названием hello.txt и сохраните его в директории git_exercise.
Определение состояния
status — это еще одна важнейшая команда, которая показывает информацию о текущем состоянии репозитория: актуальна ли информация на нём, нет ли чего-то нового, что поменялось, и так далее. Запуск git status на нашем свежесозданном репозитории должен выдать:
$ git status On branch master Initial commit Untracked files: (use "git add ..." to include in what will be committed) hello.txt
Сообщение говорит о том, что файл hello.txt неотслеживаемый. Это значит, что файл новый и система еще не знает, нужно ли следить за изменениями в файле или его можно просто игнорировать. Для того, чтобы начать отслеживать новый файл, нужно его специальным образом объявить.
Подготовка файлов
В git есть концепция области подготовленных файлов. Можно представить ее как холст, на который наносят изменения, которые нужны в коммите. Сперва он пустой, но затем мы добавляем на него файлы (или части файлов, или даже одиночные строчки) командой add и, наконец, коммитим все нужное в репозиторий (создаем слепок нужного нам состояния) командой commit.
В нашем случае у нас только один файл, так что добавим его:
$ git add hello.txt
Если нам нужно добавить все, что находится в директории, мы можем использовать
$ git add -A
Проверим статус снова, на этот раз мы должны получить другой ответ:
$ git status On branch master Initial commit Changes to be committed: (use "git rm --cached ..." to unstage) new file: hello.txt
Файл готов к коммиту. Сообщение о состоянии также говорит нам о том, какие изменения относительно файла были проведены в области подготовки — в данном случае это новый файл, но файлы могут быть модифицированы или удалены.
Фиксация изменений
Как сделать коммит
Представим, что нам нужно добавить пару новых блоков в html-разметку (index.html) и стилизовать их в файле style.css. Для сохранения изменений, их необходимо закоммитить. Но сначала, мы должны обозначить эти файлы для Гита, при помощи команды git add, добавляющей (или подготавливающей) их к коммиту. Добавлять их можно по отдельности:
git add index.html
git add css/style.css
или вместе — всё сразу:
git add .
Конечно добавлять всё сразу удобнее, чем прописывать каждую позицию отдельно. Однако, тут надо быть внимательным, чтобы не добавить по ошибке ненужные элементы. Если же такое произошло изъять оттуда ошибочный файл можно при помощи команды
git reset:
git reset css/style.css
Теперь создадим непосредственно сам коммит
git commit -m 'Add some code'
Флажок -m задаст commit message — комментарий разработчика. Он необходим для описания закоммиченных изменений. И здесь работает золотое правило всех комментариев в коде: «Максимально ясно, просто и содержательно обозначь написанное!»
Как посмотреть коммиты
Для просмотра все выполненных фиксаций можно воспользоваться историей коммитов. Она содержит сведения о каждом проведенном коммите проекта. Запросить ее можно при помощи команды:
git log
В ней содержится вся информация о каждом отдельном коммите, с указанием его хэша, автора, списка изменений и даты, когда они были сделаны. Отследить интересующие вас операции в списке изменений, можно по хэшу коммита, при помощи команды git show :
git show hash_commit
Ну а если вдруг нам нужно переделать commit message и внести туда новый комментарий, можно написать следующую конструкцию:
git commit --amend -m 'Новый комментарий'
В данном случае сообщение последнего коммита перезапишется. Но злоупотреблять этим не стоит, поскольку эта операция опасная и лучше ее делать до отправки коммита на сервер.
Удаленные репозитории
Сейчас наш коммит является локальным — существует только в директории .git на нашей файловой системе. Несмотря на то, что сам по себе локальный репозиторий полезен, в большинстве случаев мы хотим поделиться нашей работой или доставить код на сервер, где он будет выполняться.
1. Что такое удаленный репозиторий
Репозиторий, хранящийся в облаке, на стороннем сервисе, специально созданном для работы с git имеет ряд преимуществ. Во-первых — это своего рода резервная копия вашего проекта, предоставляющая возможность безболезненной работы в команде. А еще в таком репозитории можно пользоваться дополнительными возможностями хостинга. К примеру -визуализацией истории или возможностью разрабатывать вашу программу непосредственно в веб-интерфейсе.
Клонирование
Клонирование — это когда вы копируете удаленный репозиторий к себе на локальный ПК. Это то, с чего обычно начинается любой проект. При этом вы переносите себе все файлы и папки проекта, а также всю его историю с момента его создания. Чтобы склонировать проект, сперва, необходимо узнать где он расположен и скопировать ссылку на него. В нашем руководстве мы будем использовать адрес https://github.com/tutorialzine/awesome-project, но вам посоветуем, попробовать создать свой репозиторий в GitHub, BitBucket или любом другом сервисе:
git clone https://github.com/tutorialzine/awesome-project
При клонировании в текущий каталог, там будет создана папка, в которую поместятся все проектные файлы и скрытая директория .git, с самим репозиторием, или с необходимой информацией о нем. В такой ситуации, для клонируемого репозитория, по умолчанию, будет создана папка с одноименным названием, но его можно залить и в другую директорию, например:
git clone https://github.com/tutorialzine/awesome-project new-folder
2. Подключение к удаленному репозиторию
Чтобы загрузить что-нибудь в удаленный репозиторий, сначала нужно к нему подключиться. Регистрация и установка может занять время, но все подобные сервисы предоставляют хорошую документацию.
Чтобы связать наш локальный репозиторий с репозиторием на GitHub, выполним следующую команду в терминале. Обратите внимание, что нужно обязательно изменить URI репозитория на свой.
# This is only an example. Replace the URI with your own repository address.
$ git remote add origin https://github.com/tutorialzine/awesome-project.git
Проект может иметь несколько удаленных репозиториев одновременно. Чтобы их различать, мы дадим им разные имена. Обычно главный репозиторий называется origin.
3. Отправка изменений на сервер
Сейчас самое время переслать наш локальный коммит на сервер. Этот процесс происходит каждый раз, когда мы хотим обновить данные в удаленном репозитории.
Команда, предназначенная для этого — push. Она принимает два параметра: имя удаленного репозитория (мы назвали наш origin) и ветку, в которую необходимо внести изменения (master — это ветка по умолчанию для всех репозиториев).
$ git push origin master Counting objects: 3, done. Writing objects: 100% (3/3), 212 bytes | 0 bytes/s, done. Total 3 (delta 0), reused 0 (delta 0) To https://github.com/tutorialzine/awesome-project.git * [new branch] master -> master
Эта команда немного похожа на git fetch, с той лишь разницей, что при помощи fetch мы импортируем коммиты в локальную ветку, а применив push, мы экспортируем их из локальной в удаленную. Если вам необходимо настроить удаленную ветку используйте git remote. Однако пушить надо осторожно, ведь рассматриваемая команда перезаписывает безвозвратно все изменения. В большинстве случаев, ее используют, чтобы опубликовать выгружаемые локальные изменения в центральный репозиторий. А еще ее применяют для того, чтобы поделиться, внесенными в локальный репозиторий, нововведениями, с коллегами или другими удаленными участниками разработки проекта. Подытожив сказанное, можно назвать git push — командой выгрузки, а git pull и git fetch — командами загрузки или скачивания. После того как вы успешно запушили измененные данные, их необходимо внедрить или интегрировать, при помощи команды слияния git merge.
В зависимости от сервиса, который вы используете, вам может потребоваться аутентифицироваться, чтобы изменения отправились. Если все сделано правильно, то когда вы посмотрите в удаленный репозиторий при помощи браузера, вы увидите файл hello.txt
4. Запрос изменений с сервера
Если вы сделали изменения в вашем удаленном репозитории, другие пользователи могут скачать изменения при помощи команды pull.
$ git pull origin master From https://github.com/tutorialzine/awesome-project * branch master -> FETCH_HEAD Already up-to-date.
Так как новых коммитов с тех пор, как мы склонировали себе проект, не было, никаких изменений доступных для скачивания нет.
Как удалить локальный репозиторий
Вам не понравился один из ваших локальных Git-репозиториев и вы хотите стереть его со своей машины. Для этого вам всего лишь надо удалить скрытую папку «.git» в корневом каталоге репозитория. Сделать это можно 3 способами:
- Проще всего вручную удалить эту папку «.git» в корневом каталоге «Git Local Warehouse».
- Также удалить, не устраивающий вас, репозиторий можно на github. Открываете нужный вам объект и переходите в пункт меню Настройки. Там, прокрутив ползунок вниз, вы попадете в зону опасности, где один из пунктов будет называться «удаление этого хранилища».
- Последний метод удаления локального хранилища через командную строку, для этого в терминале необходимо ввести следующую команду:
cd repository-path/ rm -r .git
Ветвление
Во время разработки новой функциональности считается хорошей практикой работать с копией оригинального проекта, которую называют веткой. Ветви имеют свою собственную историю и изолированные друг от друга изменения до тех пор, пока вы не решаете слить изменения вместе. Это происходит по набору причин:
- Уже рабочая, стабильная версия кода сохраняется.
- Различные новые функции могут разрабатываться параллельно разными программистами.
- Разработчики могут работать с собственными ветками без риска, что кодовая база поменяется из-за чужих изменений.
- В случае сомнений, различные реализации одной и той же идеи могут быть разработаны в разных ветках и затем сравниваться.
1. Создание новой ветки
Основная ветка в каждом репозитории называется master. Чтобы создать еще одну ветку, используем команду branch <name>
$ git branch amazing_new_feature
Это создаст новую ветку, пока что точную копию ветки master.
2. Переключение между ветками
Сейчас, если мы запустим branch, мы увидим две доступные опции:
$ git branch amazing_new_feature * master
master — это активная ветка, она помечена звездочкой. Но мы хотим работать с нашей “новой потрясающей фичей”, так что нам понадобится переключиться на другую ветку. Для этого воспользуемся командой checkout, она принимает один параметр — имя ветки, на которую необходимо переключиться.
$ git checkout amazing_new_feature
В Git ветка — это отдельная линия разработки. Git checkout позволяет нам переключаться как между удаленными, так и меду локальными ветками. Это один из способов получить доступ к работе коллеги или соавтора, обеспечивающий более высокую продуктивность совместной работы. Однако тут надо помнить, что пока вы не закомитили изменения, вы не сможете переключиться на другую ветку. В такой ситуации нужно либо сделать коммит, либо отложить его, при помощи команды git stash, добавляющей текущие незакоммиченные изменения в стек изменений и сбрасывающей рабочую копию до HEAD’а репозитория.
3. Слияние веток
Наша “потрясающая новая фича” будет еще одним текстовым файлом под названием feature.txt. Мы создадим его, добавим и закоммитим:
$ git add feature.txt $ git commit -m "New feature complete.”
Изменения завершены, теперь мы можем переключиться обратно на ветку master.
$ git checkout master
Теперь, если мы откроем наш проект в файловом менеджере, мы не увидим файла feature.txt, потому что мы переключились обратно на ветку master, в которой такого файла не существует. Чтобы он появился, нужно воспользоваться merge для объединения веток (применения изменений из ветки amazing_new_feature к основной версии проекта).
$ git merge amazing_new_feature
Теперь ветка master актуальна. Ветка amazing_new_feature больше не нужна, и ее можно удалить.
$ git branch -d awesome_new_feature
Если хотите создать копию удаленного репозитория — используйте git clone. Однако если вам нужна только определенная его ветка, а не все хранилище — после git clone выполните следующую команду в соответствующем репозитории:
git checkout -b <имя ветки> origin/<имя ветки>
После этого, новая ветка создается на машине автоматически.
Бывают ситуации, когда после слива каких-то изменений из рабочей ветки в исходную версию проекта, ее, по правилам хорошего тона, необходимо удалить, чтобы она более не мешалась в вашем коде. Но как это сделать?
Для локально расположенных веток существует команда:
git branch -d local_branch_name
где флажок -d являющийся опцией команды git branch — это сокращенная версия ключевого слова —delete, предназначенного для удаления ветки, а local_branch_name – название ненужной нам ветки.
Однако тут есть нюанс: удалить текущую ветку, в которую вы, в данный момент просматриваете — нельзя. Если же вы все-таки попытаетесь это сделать, система отругает вас и выдаст ошибку с таким содержанием:
Error: Cannot delete branch local_branch_name checked out at название_директории
Так что при удалении ветвей, обязательно переключитесь на другой branch.
Дополнительно
В последней части этого руководства мы расскажем о некоторых дополнительных трюках, которые могут вам помочь.
1. Отслеживание изменений, сделанных в коммитах
У каждого коммита есть свой уникальный идентификатор в виде строки цифр и букв. Чтобы просмотреть список всех коммитов и их идентификаторов, можно использовать команду log:
$ git log commit ba25c0ff30e1b2f0259157b42b9f8f5d174d80d7 Author: Tutorialzine Date: Mon May 30 17:15:28 2016 +0300 New feature complete commit b10cc1238e355c02a044ef9f9860811ff605c9b4 Author: Tutorialzine Date: Mon May 30 16:30:04 2016 +0300 Added content to hello.txt commit 09bd8cc171d7084e78e4d118a2346b7487dca059 Author: Tutorialzine Date: Sat May 28 17:52:14 2016 +0300 Initial commit
Как вы можете заметить, идентификаторы довольно длинные, но для работы с ними не обязательно копировать их целиком — первых нескольких символов будет вполне достаточно. Чтобы посмотреть, что нового появилось в коммите, мы можем воспользоваться командой show [commit]
$ git show b10cc123 commit b10cc1238e355c02a044ef9f9860811ff605c9b4 Author: Tutorialzine Date: Mon May 30 16:30:04 2016 +0300 Added content to hello.txt diff --git a/hello.txt b/hello.txt index e69de29..b546a21 100644 --- a/hello.txt +++ b/hello.txt @@ -0,0 +1 @@ +Nice weather today, isn't it?
Чтобы увидеть разницу между двумя коммитами, используется команда diff (с указанием промежутка между коммитами):
$ git diff 09bd8cc..ba25c0ff diff --git a/feature.txt b/feature.txt new file mode 100644 index 0000000..e69de29 diff --git a/hello.txt b/hello.txt index e69de29..b546a21 100644 --- a/hello.txt +++ b/hello.txt @@ -0,0 +1 @@ +Nice weather today, isn't it?
Мы сравнили первый коммит с последним, чтобы увидеть все изменения, которые были когда-либо сделаны. Обычно проще использовать git difftool, так как эта команда запускает графический клиент, в котором наглядно сопоставляет все изменения.
2. Возвращение файла к предыдущему состоянию
Гит позволяет вернуть выбранный файл к состоянию на момент определенного коммита. Это делается уже знакомой нам командой checkout, которую мы ранее использовали для переключения между ветками. Но она также может быть использована для переключения между коммитами (это довольно распространенная ситуация для Гита — использование одной команды для различных, на первый взгляд, слабо связанных задач).
В следующем примере мы возьмем файл hello.txt и откатим все изменения, совершенные над ним к первому коммиту. Чтобы сделать это, мы подставим в команду идентификатор нужного коммита, а также путь до файла:
$ git checkout 09bd8cc1 hello.txt
3. Исправление коммита
Если вы опечатались в комментарии или забыли добавить файл и заметили это сразу после того, как закоммитили изменения, вы легко можете это поправить при помощи commit —amend. Эта команда добавит все из последнего коммита в область подготовленных файлов и попытается сделать новый коммит. Это дает вам возможность поправить комментарий или добавить недостающие файлы в область подготовленных файлов.
Для более сложных исправлений, например, не в последнем коммите или если вы успели отправить изменения на сервер, нужно использовать revert. Эта команда создаст коммит, отменяющий изменения, совершенные в коммите с заданным идентификатором.
Самый последний коммит может быть доступен по алиасу HEAD:
$ git revert HEAD
Для остальных будем использовать идентификаторы:
$ git revert b10cc123
При отмене старых коммитов нужно быть готовым к тому, что возникнут конфликты. Такое случается, если файл был изменен еще одним, более новым коммитом. И теперь git не может найти строчки, состояние которых нужно откатить, так как они больше не существуют.
4. Разрешение конфликтов при слиянии
Помимо сценария, описанного в предыдущем пункте, конфликты регулярно возникают при слиянии ветвей или при отправке чужого кода. Иногда конфликты исправляются автоматически, но обычно с этим приходится разбираться вручную — решать, какой код остается, а какой нужно удалить.
Давайте посмотрим на примеры, где мы попытаемся слить две ветки под названием john_branch и tim_branch. И Тим, и Джон правят один и тот же файл: функцию, которая отображает элементы массива.
Джон использует цикл:
// Use a for loop to console.log contents.
for(var i=0; i<arr.length; i++) {
console.log(arr[i]);
}
Тим предпочитает forEach:
// Use forEach to console.log contents.
arr.forEach(function(item) {
console.log(item);
});
Они оба коммитят свой код в соответствующую ветку. Теперь, если они попытаются слить две ветки, они получат сообщение об ошибке:
$ git merge tim_branch Auto-merging print_array.js CONFLICT (content): Merge conflict in print_array.js Automatic merge failed; fix conflicts and then commit the result.
Система не смогла разрешить конфликт автоматически, значит, это придется сделать разработчикам. Приложение отметило строки, содержащие конфликт:
<<<<<<< HEAD // Use a for loop to console.log contents. for(var i=0; i<arr.length; i++) { console.log(arr[i]); } ======= // Use forEach to console.log contents. arr.forEach(function(item) { console.log(item); }); >>>>>>> Tim's commit.
Над разделителем ======= мы видим последний (HEAD) коммит, а под ним — конфликтующий. Таким образом, мы можем увидеть, чем они отличаются и решать, какая версия лучше. Или вовсе написать новую. В этой ситуации мы так и поступим, перепишем все, удалив разделители, и дадим git понять, что закончили.
// Not using for loop or forEach. // Use Array.toString() to console.log contents. console.log(arr.toString());
Когда все готово, нужно закоммитить изменения, чтобы закончить процесс:
$ git add -A $ git commit -m "Array printing conflict resolved."
Как вы можете заметить, процесс довольно утомительный и может быть очень сложным в больших проектах. Многие разработчики предпочитают использовать для разрешения конфликтов клиенты с графическим интерфейсом. (Для запуска нужно набрать git mergetool).
5. Настройка .gitignore
В большинстве проектов есть файлы или целые директории, в которые мы не хотим (и, скорее всего, не захотим) коммитить. Мы можем удостовериться, что они случайно не попадут в git add -A при помощи файла .gitignore
- Создайте вручную файл под названием .gitignore и сохраните его в директорию проекта.
- Внутри файла перечислите названия файлов/папок, которые нужно игнорировать, каждый с новой строки.
- Файл .gitignore должен быть добавлен, закоммичен и отправлен на сервер, как любой другой файл в проекте.
Вот хорошие примеры файлов, которые нужно игнорировать:
- Логи
- Артефакты систем сборки
- Папки node_modules в проектах node.js
- Папки, созданные IDE, например, Netbeans или IntelliJ
- Разнообразные заметки разработчика.
Файл .gitignore, исключающий все перечисленное выше, будет выглядеть так:
*.log build/ node_modules/ .idea/ my_notes.txt
Символ слэша в конце некоторых линий означает директорию (и тот факт, что мы рекурсивно игнорируем все ее содержимое). Звездочка, как обычно, означает шаблон.
Git bash и git.io
Руководствуясь часто встречающимися, при изучении системы, вопросами новичков, разберем еще несколько непонятных словосочетаний.
- Git Bash(Bourne Again Shell) — это приложение, являющееся эмулятором командной строки и предоставляющее, операционной системе, некоторые распространенные утилиты bash и собственно саму систему Git. Это терминал, используемый для взаимодействия с персональным компьютером, посредством письменных команд.
- URL-адреса хранилищ на Гитхабе могут быть довольно длинными, из-за больших имен репозиториев и файлов. Работать с такими ссылками очень не удобно. Поэтому сайт github.io создал git.io — неплохой сервис по преобразованию этих длинных и беспорядочных URL-адресов в более короткие и понятные. Сайт был создан в 2011 году и вплоть до недавнего времени отлично справлялся со своими обязанностями. Однако в начале этого года компания Гитхаб, из-за участившихся попыток хакеров использовать сайт в злонамеренных целях, остановила работу сервиса, а чем известила пользователей в своем блоге. Разработчики популярного ресурса рекомендуют пользоваться другими URL-cutter’ами, пока работа сервиса не будет налажена.
Заключение.
Вот и все! Наше руководство окончено. Мы очень старались собрать всю самую важную информацию и изложить ее как можно более сжато и кратко.
Git довольно сложен, и в нем есть еще много функций и трюков. Если вы хотите с ними познакомиться, вот некоторые ресурсы, которые мы рекомендуем:
- Официальная документация, включающая книгу и видеоуроки – тут.
- “Getting git right” – Коллекция руководств и статей от Atlassian – тут.
- Список клиентов с графическим интерфейсом – тут.
- Онлайн утилита для генерации .gitignore файлов – тут.
Оригинал статьи доступен на сайте http://tutorialzine.com
Другие статьи по теме
10 полезных Git команд, которые облегчат работу
Шпаргалка по Git, в которой представлены основные команды