Удалённые репозитории — это модификации проекта, которые хранятся в интернете или ещё где-то в сети. Их может быть несколько, каждый из которых, как правило, доступен для вас либо только на чтение, либо на чтение и запись. Совместная работа включает в себя управление удалёнными репозиториями и помещение (push) и получение (pull) данных в и из них тогда, когда нужно обменяться результатами работы.
1) Есть "главный" репозиторий. Как правило, в этом репозитории есть несколько веток. доступ к главному репозиторию по ключу, нужен аккаунт на гитхабе, в котором
прописан ключ
https://github.com/abak-press/selenium_blizko
2) Каждый разработчик может создавать собственные ветки. Но чтобы не загаживать ими основной репозиторий, каждый из разработчиков должен работать в пределах собственного репозитория. Что значит "форкнуть" проект на гитхабе? Это значит создать полную копию репозитория. Что ж, форкнем его и получим еще один удаленный репозиторий :
https://github.com/grebenschikova/selenium_blizko
3) В гитхабе мы не можем запушить свои изменения в "главный" репозиторий, а можем лишь сделать пулл-реквест. Если он будет одобрен, ваши коммиты будут применены. Для этого и нужно иметь удаленную копию. Ведь иначе можно было создать у себя на машине локальную копию "главного" репозитория, делать изменения, да пушить их.
4) Вот мы и форкнули весь проект. Теперь нам нужно заиметь его на собственном компьютере. Сейчас будет создан еще один репозиторий (уже третий). Этот репозиторий будет условно "локальным". Для этого клонируем его себе на локальную машину из своего репозитория на гитхабе
git clone git@github.com:grebenschikova/selenium_blizko.git
Чтобы просмотреть, какие удалённые серверы у вас уже настроены, следует выполнить команду git remote. Она перечисляет список имён-сокращений для всех уже указанных репозиториев. Если вы склонировали ваш репозиторий, у вас должен отобразиться, по крайней мере, origin — это имя по умолчанию, которое Git присваивает серверу, с которого вы склонировали.
$ git remote
originЧтобы посмотреть, какому URL соответствует сокращённое имя в Git, можно указать команде опцию -v:
$ git remote -v
origin git@github.com:grebenschikova/selenium_blizko.git
Если у вас больше одного удалённого репозитория, команда покажет их все.
$ git remote -v
origin git@github.com:grebenschikova/selenium_blizko.git
upstream git://github.com/abak-press/selenium_blizko.git
Это означает, что мы легко можем получить изменения от любого из этих пользователей. Но, заметьте, что origin — это единственный удалённый сервер прописанный как SSH-ссылка, поэтому он единственный, в который я могу помещать свои изменения
Чтобы добавить новый удалённый Git-репозиторий под именем-сокращением, к которому будет проще обращаться, выполните git remote add [сокращение] [url].
git remote add
upstream git://github.com/abak-press/selenium_blizko.git
Этой командой мы сказали "сделай у нашего текущего репозитория ссылку на удаленный репозиторий и для удобства дай этой ссылке понятное имя
upstream . Теперь мы всегда будем знать что
upstream это ссылка на наш удаленный репозиторий.
Теперь вы можете использовать в командной строке имена origin и upstream вместо полного URL. Например, если вы хотите извлечь (fetch) всю информацию, которая есть в репозитории, но нет в вашем, вы можете выполнить git fetch upstream
Данная команда связывается с указанным удалённым проектом и забирает все те данные проекта, которых у вас ещё нет.
Ветка master глобального репозитория теперь доступна локально как upstream/master. Вы можете слить (merge) её в одну из своих веток
Вы можете использовать команду git pull. Она как правило, извлекает (fetch) данные с сервера, с которого вы изначально склонировали, и автоматически пытается слить (merge) их с кодом, над которым вы в данный момент работаете.
Для переименования ссылок в новых версиях Git'а можно вылолнить git remote rename, это изменит сокращённое имя, используемое для удалённого репозитория. Например, если вы хотите переименовать pb в paul, вы можете сделать это следующим образом:
$ git remote rename pb paul
5) Создаёте новую ветку в своем локальном репозитории (в форке наследуются ветки родителя, так что если форкаете то ветку можно не создавать - master уже будет)
git checkout -b feature
Чтобы посмотреть существующие ветки, введем:
git branch
6) Работаете, делаете коммиты, в случае необходимости отслеживания изменений в «родителе», сливаете изменения с него и вливаете в свою ветку таким образом:
git fetch upstream
git pull upstream master
git merge master
7) Когда работу сделали, заливаете изменения в свой github-репозиторий в свою ветку:
git add .
git commit
git push origin
8) Теперь идёте на гитхаб, в свой репозиторий и жмёте вверху кнопочку «Pull request»
9) Слева выбираете в какую ветку будут вливаться изменения в родительском репозитории, справа — какие изменения будут браться с вашего репозитория. По примеру: справа abak-press/master, слева grebenschikova/master.
ВАЖНО: Договоритесь с владельцем «родительского» репозитория, в какую ветку будете вливать изменения (он может написать это в README)
10) Заполняете название и описание (название потом попадёт в описание мёрдж-коммита и станет достоянием общественности, учтите это).
11) Нажимаете Send Pull Request
Вуаля, вы его отправили. Владелец рассмотрит ваши изменения и, возможно, их примет и вольёт к себе.
На практике, лучше перед посылкой пулл-реквестов, вручную синхронизироваться с веткой, в которую будете посылать изменения, чтобы у владельца merge прошёл гладко (больше шансов, что пулл примут)
Не забудьте потом сделать git pull upstream master, чтобы увидеть изменения у себя.
Дописать - что делать после принятия пулреквеста.
