Как работать с github с разных компьютеров

Обновлено: 04.07.2024

На текущий момент у нас есть репозиторий с двумя коммитами. Содержимое директории hexlet-git выглядит так:

Создайте репозиторий на Гитхабе. Назовите его hexlet-git. Важно, чтобы репозиторий создавался пустым, поэтому не отмечайте галочки, добавляющие файлы.

На странице репозитория вы увидите готовые команды для подключения созданного репозитория на Гитхабе к уже существующему репозиторию у вас на компьютере.

В действительности это разные репозитории. Git относится к так называемым распределённым системам контроля версий. У git нет какого-то центрального места, где бы лежал один главный репозиторий, а разработчики работали бы с ним со своих компьютеров. В git у каждого разработчика и даже на Github находится свой собственный полноценный репозиторий. Эти репозитории git связывает между собой общей историей и возможностью обмениваться изменениями. В примере выше именно команда git push отправляет изменения во вновь созданный репозиторий.

Репозиторий, созданный на Github, — публичный. Любой человек может клонировать его к себе на компьютер и начать работать с ним так, как будто это его личный репозиторий. Единственное ограничение — он не сможет запушить изменения, так как Github не даёт напрямую менять чужие репозитории.

Клонирование — базовая операция при работе с удалёнными репозиториями. Проекты, над которыми работают программисты, всегда находятся в системах, подобных Github. Для работы с ними нужно клонировать репозиторий к себе на компьютер. Делается это с помощью команды git clone . Полную команду для клонирования можно получить на странице репозитория. Для этого нажмите большую кнопку Code, перейдите на вкладку SSH и скопируйте содержимое.

Мы получили точную копию репозитория, который был у нас до удаления директории hexlet-git.

Получение изменений с Github

Разработчики не только отправляют изменения на Гитхаб, но и забирают изменения оттуда. Чаще всего это изменения, сделанные другими разработчиками проекта, но необязательно. Бывает такое, что один разработчик работает над одним проектом с разных компьютеров, на каждом из которых своя собственная копия репозитория (git работает только так). В таком случае, перед началом работы нужно всегда выполнять команду git pull --rebase , которая скачивает из внешнего репозитория новые коммиты и добавляет их в локальный репозиторий.

Обычно, в статьях пишут, что достаточно вызывать git pull, но это может приводить к созданию ненужных merge-коммитов, ухудшающих историю изменений. Правильная работа с git pull требует знания таких вещей, как ветвление и git rebase. Они довольно сложны для новичков и рассматриваются позже, когда появится хоть какой-то опыт работы с git.

Итого

Подведём некоторый итог. Мы создали репозиторий с несколькими коммитами. Этот репозиторий добавлен на Гитхаб и может быть склонирован для дальнейшей разработки. Какую пользу из git мы можем извлечь к текущему моменту? У нас есть запасная копия (бекап) кода на сайте Github. Как минимум, не страшно потерять код. Теперь его легко восстановить при случае и поделиться с другими.

Отдельно стоит сказать, что Гитхаб это хоть и самая популярная, но не единственная площадка для хостинга репозиториев. Кроме него особенно известны Bitbucket и Gitlab. Последний можно даже поставить к себе на сервер и "хостить" репозитории внутри своей компании, что многие и делают по соображениям безопасности или экономии.

Допустим я начал проект на компе, потом продолжил с ноутбука. При этом проект обновлялся бы на сервере через git pull .

Как сохранять изменения в проект с двух компов?

11.8k 2 2 золотых знака 13 13 серебряных знаков 26 26 бронзовых знаков то есть, рассказать, как коммитить (commit) и пушить (push) ? "При этом проект обновлялся бы на сервере через git pull" - вы явно путаетесь в терминологии. pull может быть выполнен только на локальной рабочей копии, и если вы на сервере делаете pull, то с точки зрения git эта машина такой же клиент как и остальные.

Работа с одним репозиторием с разных компьютеров

С одним репозиторием с разных компьютеров может работать несколько разработчиков или вы сами, если например работаете над одним и тем же проектом дома и на работе.

Для получения обновлений с удаленного репозитория воспользуйтесь командой:

Если вы изменили ваши локальные файлы, то команда git pull выдаст ошибку. Если вы уверены, что хотите перезаписать локальные файлы, файлами из удаленного репозитория то выполните команды:

Вместо github подставьте название вашего удаленного репозитория, которое вы зарегистрировали командой git push -u .

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

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

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

После выполнения этой команды ваша локальная директория будет содержать файлы такие же, как и при последнем коммите. Вы можете загрузить новые файлы из удаленного репозитория командой git pull и после этого вернуть ваши изменения которые вы отложили командой:

Рассмотрим в этом уроке как получить проект из GitHub на локальную машину и как работать с проектом на двух компьютерах, например, из дома и с работы.

Клонирование - получение всего репозитория. На гитхабе раньше была кнопка Clone or Download. Но затем этот блок изменили и теперь есть кнопка Code при нажатии на которую появляются инструменты клонирования и скачивания.


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

Даже если кто-то украдет ваш ключ, вы просто удалите его из Гитхаба в Настройках (Settings) и зададите новый.

Мы выбираем SSH. Копируем на github адрес и вставляем в терминал:

Вот так проходит процесс клонирования:


Теперь посмотрим лог:

Мы увидим все коммиты:


Также мы видим, что находимся в ветке master. Кроме того есть еще два дополнительных указателя - origin/master и origin/HEAD.

Указатель origin - это имя удаленного репозитория и так принято его называть в мире разработчиков. Мы можем проверить это таким образом:

В гитхабе HEAD всегда будет указывать на master, если вы не измените этого сами в настройках репозитория на самом Гитхабе.

Отправляем новые изменения следующей командой:

Этот процесс займет немного времени и терминал выведет:


Если мы создаем ветки и коммиты локально, что они не появляются на Гитхабе автоматически. Если мы создаем ветку comments, то команда отправки на Гитхаб всех изменений будет выглядеть так:

И мы увидим отчет в терминале, что изменения отправлены:


При этом мы теперь на самом GitHub сможем выбрать нужную нам ветку:


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

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

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

Команда branch может переименовывать, создавать и удалять ветки.

Справка. Команда git checkout -b branch-name создаст ветку с указанным именем и автоматически переключится на неё. Для переключения на существующую ветку выполните команду git checkout . Для переключения, например, на ветку testing используем команду $ git checkout testing . В результате указатель HEAD переместится на ветку testing.

Чтобы нам наглядно посмотреть ветки в CMDER мы используем команду:

Допустим, вы сделали коммиты на рабочем компьютере и теперь хотите поработать дома. Нам нужно получить эти коммиты на домашний компьютер.

Если нам нужно получить изменения ветки master, значит нам нужно быть в ветке master. Для этого убеждаемся, что мы находимся в ветке master:

И далее вводим команду:

Что делать, если кроме ветки master нам нужна ветка, которая создана в удаленном репозитории и про которую локальный Git ничего не знает?

Для этого мы используем команду fetch (рус. -получить, принести):

Эта команда позволит забрать изменения из удаленной ветки:


Схематично это выглядит так:


Указатели origin/master и origin/comments (из примера) нельзя удалить или переименовать.

Теперь для примера мы создадим ветку comments, которая будет указывать на тот же коммит, что и origin/comments:

Для ветки comments мы можем написать следующую команду:

Но что, если мы хотим всё время пушить comments в comments на GitHub, а локальный master в удаленный master? У нас есть возможность связать локальную ветку с удаленной:

В примере выше вместо origin/comments вы можете указать имя удаленной ветки с которой вы хотите связать текущую.

Теперь находясь в этой ветке нет необходимости писать названия веток для команды git push или git pull.

Чтобы посмотреть какие локальные ветки связаны с удаленными мы используем:

Терминал нам покажет какие ветки с какими связаны:


Видно, что comments связана с веткой origin/comments и отмечена звездочкой - мы в ней находимся, а master связан с origin/master.

При разработке собственного проекта, рано или поздно, приходится задуматься о том, где хранить исходный код и как поддерживать работу с несколькими версиями. В случае работы на компанию, обычно это решается за вас и необходимо только поддерживать принятые правила. Есть несколько общеупотребимых систем контроля версий, и мы рассмотрим одну из самых популярных — это 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:


И показываем список файлов с расширением .pyc:


Эта команда выведет список всех файлов с расширением .pyc в текущей директории и в ее поддиректориях. Для удаления найденных файлов, достаточно добавить ключ -delete к этой команде:


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

Создадим локальный репозиторий в папке с проектом:


После выполнения этой команды появится новая папка с именем .git. В ней будет несколько файлов и поддиректориев. На данный момент система управления версиями еще не видит наших файлов.

Добавление файлов в локальный репозиторий

Для добавления файлов используется команда:


После выполнения команды, файл readme будет добавлен в систему управления версий (конечно если он уже был то этого в проекте). При добавлении файла генерируется хеш значение, которое выглядит примерно так:


Добавленные файлы хранятся в папке .git/objects/xx/yyyyyyyy, при этом первые 2 цифры хеша ипользуются для указания директории, а остальное хеш значение является именем файла. Наш добавленный файл будет находится здесь:


Что легко увидеть с помощью команды:


Сам файл является архивом, который легко распаковать и вывести на экран, указав полное значение хеша.


Для того, чтобы добавить все файлы из текущей директории введите:


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


Для того, чтобы в систему не попадали временные файлы, можно их занести в файл .gitignore, который нужно создать самостоятельно и разместить в корневом каталоге проекта (на том же уровне, что и .git директория).

Например, если в в файл .gitignore добавить следующую строчку *.pyc, то все файлы с расширением .pyc не будут добавляться в репозиторий.

После добавления файлов, все изменения находятся в так называемой staging (или cached) area. Это некоторое временнное хранилище, которое используется для накопления изменений и из которого создаются собственно версии проектов (commit).

Для просмотра текущего состояния можно воспользоваться командой:


После выполнения команды мы увидим, что в stage area находится наш файл:


Если вы продолжите вносить изменения в файл readme, то после вызова команды git status вы увидите две версии файла.


Чтобы добавить новые изменения достаточно повторить команду. Команда git add не только добавляет новые файлы, но и все изменения файлов, которые были добавлены ранее.


Можно отменить добавления файла readme в staging area с помощью команды:


После выполнения команды, файл readme отметится, как неизмененный системой.

Создание версии проекта

После того, как мы добавили нужные файлы в staging area мы можем создать версию проекта. С помощью команды:


Каждая новая версия сопровождается комментарием.

После коммита, мы сможем найти два новых объекта внутри .git репозитория.


Посмотрим, что внутри:


Ключ -t показывает тип объекта. В результате мы видим:


Для второго объекта:


Для самого первого файла:


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


Ключ --no-edit нужен, чтобы не вводить заново комментарий.

Можно просмотреть изменения, которые вы внесли последним коммитом:


Ключ --name-only нужен, чтобы показывать только имена измененный файлов. Без него по каждому измененнному файлу будет выдан список всех изменений.

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


Для просмотра списка всех коммитов, воспользуйтесь командой:


Ключ --oneline нужен, чтобы уменьшить количество информации выдаваемой на экран. С этим ключем каждый коммит показывается в одну строчку. Например:


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


Для отмены последнего коммита (кроме самого первого) можно воспользоваться следующей командой:


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

Создание репозитория на Github

После регистрации нажимаем кнопочку "+" и вводим название репозитория. Выбираем тип Public (репозиторий всегда Public для бесплатной версии) и нажимаем Create.

В результате мы создали репозиторий на сайте Github. На экране мы увидим инструкцию, как соединить наш локальный репозиторий со вновь созданным. Часть команд нам уже знакома.

Добавляем удаленный репозиторий (по протоколу SSH) под именем origin (вместо origin можно использовать любое другое имя).


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


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


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


Следующей командой вы занесете все изменения, которые были сделаны в локальном репозитории на Github.


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

Перенос репозитория на другой компьютер

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


Результатом выполнения этой команды будет создание папки project в текущем каталоге. Эта папка также будет содержать локальный репозиторий (то есть папку .git).

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

Работа с одним репозиторием с разных компьютеров

С одним репозиторием с разных компьютеров может работать несколько разработчиков или вы сами, если например работаете над одним и тем же проектом дома и на работе.

Для получения обновлений с удаленного репозитория воспользуйтесь командой:


Если вы изменили ваши локальные файлы, то команда git pull выдаст ошибку. Если вы уверены, что хотите перезаписать локальные файлы, файлами из удаленного репозитория то выполните команды:


Вместо github подставьте название вашего удаленного репозитория, которое вы зарегистрировали командой git push -u.

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


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


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


После выполнения этой команды ваша локальная директория будет содержать файлы такие же, как и при последнем коммите. Вы можете загрузить новые файлы из удаленного репозитория командой git pull и после этого вернуть ваши изменения которые вы отложили командой:

Я работаю в основном на компьютере Mac, но также есть ноутбук, который я использую, когда вдали от офиса.

Я хочу получить доступ и работать над моими последними файлами html, css, php и python с любого компьютера.

Я думал, что Github - это способ сделать это, но у меня проблема с пониманием "потока", и у меня RTFM! Я не понимаю, должен ли я сначала создать репозиторий на Github, почему, когда я пытаюсь "клонировать" что-то, это не волшебным образом заканчивается на моем локальном компьютер. где хорошая большая красная кнопка с надписью "синхронизация".

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

Итак, если я начну на своем рабочем столе и создам новые файлы, каковы правильные шаги с помощью git или Github (?) поместить эти файлы, где они могут быть доступны с моего ноутбука, а затем объединить файлы на моем ноутбуке обратно в ?Репозиторий Github, чтобы я мог получить доступ к этим файлам с моего рабочего стола.

спасибо всем за ответы и ответы! Рабочий процесс git для моих нужд теперь ясен.

рабочий процесс, представленный wadesworld лаконичен и обзор мне нужен.

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

steelclaw и uDaYответы и ответы были важны, потому что я сделал не понимаю, что не имеет значения, какое РЕПО я создал первым, и добавление и фиксация локально были важными первыми шагами в моем рабочем процессе.

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

после инициализации репозитория обязательно используйте ' add ' и ' commit.- Это сделает файлы официальной версией хранилища. После этого вам нужно использовать "нажмите", чтобы загрузить его в удаленный репозиторий."

ilollarресурс "Git для возрастов 4 и выше" также достоин клика, особенно для таких людей, как я, которые являются визуальными!

Читайте также: