Как сделать удаленный репозиторий git

Добавил пользователь Alex
Обновлено: 10.09.2024

В последние годы популярность git демонстрирует взрывной рост. Эта система контроля версий используется различными проектами с открытым исходным кодом.

Новичков часто пугает большое количество замысловатых команд и сложных аргументов. Но для начала все они и не нужны. Можно начать с изучения наиболее часто используемых команд, и после этого постепенно расширять свои знания. Именно так мы и поступим в этой статье. Поехали!

Git — это набор консольных утилит, которые отслеживают и фиксируют изменения в файлах (чаще всего речь идет об исходном коде программ, но вы можете использовать его для любых файлов на ваш вкус). С его помощью вы можете откатиться на более старую версию вашего проекта, сравнивать, анализировать, сливать изменения и многое другое. Этот процесс называется контролем версий. Существуют различные системы для контроля версий. Вы, возможно, о них слышали: SVN, Mercurial, Perforce, CVS, Bitkeeper и другие.

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

Установить git на свою машину очень просто:

Linux — нужно просто открыть терминал и установить приложение при помощи пакетного менеджера вашего дистрибутива. Для Ubuntu команда будет выглядеть следующим образом:
Windows — мы рекомендуем git for windows, так как он содержит и клиент с графическим интерфейсом, и эмулятор bash.
OS X — проще всего воспользоваться homebrew. После его установки запустите в терминале:

Если вы новичок, клиент с графическим интерфейсом(например GitHub Desktop и Sourcetree) будет полезен, но, тем не менее, знать команды очень важно.

Итак, мы установили git, теперь нужно добавить немного настроек. Есть довольно много опций, с которыми можно играть, но мы настроим самые важные: наше имя пользователя и адрес электронной почты. Откройте терминал и запустите команды:

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

Как мы отметили ранее, git хранит свои файлы и историю прямо в папке проекта. Чтобы создать новый репозиторий, нам нужно открыть терминал, зайти в папку нашего проекта и выполнить команду init. Это включит приложение в этой конкретной папке и создаст скрытую директорию .git, где будет храниться история репозитория и настройки.
Создайте на рабочем столе папку под названием git_exercise. Для этого в окне терминала введите:

Командная строка должна вернуть что-то вроде:

Это значит, что наш репозиторий был успешно создан, но пока что пуст. Теперь создайте текстовый файл под названием hello.txt и сохраните его в директории git_exercise.

status — это еще одна важнейшая команда, которая показывает информацию о текущем состоянии репозитория: актуальна ли информация на нём, нет ли чего-то нового, что поменялось, и так далее. Запуск git status на нашем свежесозданном репозитории должен выдать:

В git есть концепция области подготовленных файлов. Можно представить ее как холст, на который наносят изменения, которые нужны в коммите. Сперва он пустой, но затем мы добавляем на него файлы (или части файлов, или даже одиночные строчки) командой add и, наконец, коммитим все нужное в репозиторий (создаем слепок нужного нам состояния) командой commit.
В нашем случае у нас только один файл, так что добавим его:

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

Проверим статус снова, на этот раз мы должны получить другой ответ:

Коммит представляет собой состояние репозитория в определенный момент времени. Это похоже на снапшот, к которому мы можем вернуться и увидеть состояние объектов на определенный момент времени.
Чтобы зафиксировать изменения, нам нужно хотя бы одно изменение в области подготовки (мы только что создали его при помощи git add), после которого мы может коммитить:

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

1. Подключение к удаленному репозиторию

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

Сейчас самое время переслать наш локальный коммит на сервер. Этот процесс происходит каждый раз, когда мы хотим обновить данные в удаленном репозитории.
Команда, предназначенная для этого - push. Она принимает два параметра: имя удаленного репозитория (мы назвали наш origin) и ветку, в которую необходимо внести изменения (master — это ветка по умолчанию для всех репозиториев).

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

3. Клонирование репозитория

Сейчас другие пользователи GitHub могут просматривать ваш репозиторий. Они могут скачать из него данные и получить полностью работоспособную копию вашего проекта при помощи команды clone.

Новый локальный репозиторий создается автоматически с GitHub в качестве удаленного репозитория.

4. Запрос изменений с сервера

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

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

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

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

1. Создание новой ветки

Основная ветка в каждом репозитории называется master. Чтобы создать еще одну ветку, используем команду branch

Это создаст новую ветку, пока что точную копию ветки master.

2. Переключение между ветками

Сейчас, если мы запустим branch, мы увидим две доступные опции:

master — это активная ветка, она помечена звездочкой. Но мы хотим работать с нашей “новой потрясающей фичей”, так что нам понадобится переключиться на другую ветку. Для этого воспользуемся командой checkout, она принимает один параметр — имя ветки, на которую необходимо переключиться.

3. Слияние веток

Наша “потрясающая новая фича” будет еще одним текстовым файлом под названием feature.txt. Мы создадим его, добавим и закоммитим:

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

Теперь, если мы откроем наш проект в файловом менеджере, мы не увидим файла feature.txt, потому что мы переключились обратно на ветку master, в которой такого файла не существует. Чтобы он появился, нужно воспользоваться merge для объединения веток (применения изменений из ветки amazing_new_feature к основной версии проекта).

Теперь ветка master актуальна. Ветка amazing_new_feature больше не нужна, и ее можно удалить.

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

1. Отслеживание изменений, сделанных в коммитах

У каждого коммита есть свой уникальный идентификатор в виде строки цифр и букв. Чтобы просмотреть список всех коммитов и их идентификаторов, можно использовать команду log:
[spoiler title='Вывод git log']

[/spoiler]
Как вы можете заметить, идентификаторы довольно длинные, но для работы с ними не обязательно копировать их целиком — первых нескольких символов будет вполне достаточно. Чтобы посмотреть, что нового появилось в коммите, мы можем воспользоваться командой show [commit]
[spoiler title='Вывод git show']

[/spoiler]
Чтобы увидеть разницу между двумя коммитами, используется команда diff (с указанием промежутка между коммитами):
[spoiler title='Вывод git diff']

[/spoiler]
Мы сравнили первый коммит с последним, чтобы увидеть все изменения, которые были когда-либо сделаны. Обычно проще использовать git difftool, так как эта команда запускает графический клиент, в котором наглядно сопоставляет все изменения.

2. Возвращение файла к предыдущему состоянию

Гит позволяет вернуть выбранный файл к состоянию на момент определенного коммита. Это делается уже знакомой нам командой checkout, которую мы ранее использовали для переключения между ветками. Но она также может быть использована для переключения между коммитами (это довольно распространенная ситуация для Гита - использование одной команды для различных, на первый взгляд, слабо связанных задач).
В следующем примере мы возьмем файл hello.txt и откатим все изменения, совершенные над ним к первому коммиту. Чтобы сделать это, мы подставим в команду идентификатор нужного коммита, а также путь до файла:

3. Исправление коммита

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

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

4. Разрешение конфликтов при слиянии

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

Тим предпочитает forEach:

Система не смогла разрешить конфликт автоматически, значит, это придется сделать разработчикам. Приложение отметило строки, содержащие конфликт:
[spoiler title='Вывод']

[/spoiler]
Над разделителем ======= мы видим последний (HEAD) коммит, а под ним - конфликтующий. Таким образом, мы можем увидеть, чем они отличаются и решать, какая версия лучше. Или вовсе написать новую. В этой ситуации мы так и поступим, перепишем все, удалив разделители, и дадим git понять, что закончили.

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

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

5. Настройка .gitignore

В большинстве проектов есть файлы или целые директории, в которые мы не хотим (и, скорее всего, не захотим) коммитить. Мы можем удостовериться, что они случайно не попадут в git add -A при помощи файла .gitignore

Создайте вручную файл под названием .gitignore и сохраните его в директорию проекта.
Внутри файла перечислите названия файлов/папок, которые нужно игнорировать, каждый с новой строки.
Файл .gitignore должен быть добавлен, закоммичен и отправлен на сервер, как любой другой файл в проекте.

Вот хорошие примеры файлов, которые нужно игнорировать:

Логи
Артефакты систем сборки
Папки node_modules в проектах node.js
Папки, созданные IDE, например, Netbeans или IntelliJ
Разнообразные заметки разработчика.

Файл .gitignore, исключающий все перечисленное выше, будет выглядеть так:

Символ слэша в конце некоторых линий означает директорию (и тот факт, что мы рекурсивно игнорируем все ее содержимое). Звездочка, как обычно, означает шаблон.

Вот и все! Наше руководство окончено. Мы очень старались собрать всю самую важную информацию и изложить ее как можно более сжато и кратко.
Git довольно сложен, и в нем есть еще много функций и трюков. Если вы хотите с ними познакомиться, вот некоторые ресурсы, которые мы рекомендуем:

У меня есть локальный репозиторий Git. Я хотел бы сделать его доступным на удаленном сервере с поддержкой ssh. Как мне это сделать?

Я думаю, вы делаете голый репозиторий на удаленной стороне, git init --bare , добавьте удаленную сторону в качестве push / pull tracker для вашего локального репозитория ( git remote add origin URL ), а затем локально вы просто сказать git push origin master . Теперь любой другой репозиторий pull из удаленного репозитория.

чтобы изначально настроить любой сервер Git, необходимо экспортировать существующий репозиторий в новый пустой репозиторий - репозиторий, который не содержит рабочего каталога. Это, как правило, просто сделать. Чтобы клонировать репозиторий для создания нового голого репозитория, выполните команду clone с помощью . По соглашению, голые каталоги репозитория заканчиваются на .git , например:

эта команда берет репозиторий Git сама по себе, без рабочий каталог, и создает каталог специально для него одного.

на данный момент, другие пользователи, которые иметь SSH доступ к тому же серверу, который имеет доступ для чтения к /opt/git каталог может клонировать ваш репозиторий, запустив

если пользователь SSHs в сервер и имеет доступ на запись к , он автоматически получает доступ. Git автоматически добавит группе права на запись в репозиторий, если вы запустите команду git init с .

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

примечание для людей, которые создали локальную копию в Windows и хотят создать соответствующий удаленный репозиторий в системе Unix-line, где текстовые файлы получают LF-окончания на дальнейших клонах разработчиками в Unix-подобных системах, но crlf-окончания в Windows.

Если вы создали свой репозиторий Windows до настройка перевода конца строки затем у вас есть проблема. По умолчанию Git не переводит, поэтому ваш рабочий набор использует CRLF, но ваш репозиторий (т. е. данные, хранящиеся под .git) также сохранил файлы как CRLF.

когда вы нажимаете на пульт, сохраненные файлы копируются как есть, перевод конца строки не происходит. (Перевод конца строки происходит, когда файлы передаются в репозиторий, а не когда репозитории выталкиваются). Вы заканчиваете CRLF в своем Unix-подобном репозитории, что не то, что вы хотите.

чтобы получить LF в удаленном репозитории, вы должны сначала убедиться, что LF находится в локальном репозитории, по ре-нормализации репозитории для Windows. Это не будет иметь видимого влияния на ваш рабочий набор Windows, который по-прежнему имеет окончания CRLF, однако при нажатии на remote пульт получит LF правильно.

Я не уверен, что есть простой способ сказать, какие окончания строк у вас есть в вашем репозитории Windows-я думаю, вы можете проверить его, установив core.autocrlf=false, а затем клонирование (если РЕПО имеет LF-окончания, клон также будет иметь LF).

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

предполагая, что вы уже настроили и использовали git с помощью ssh-ключей, я написал небольшой скрипт Python, который при выполнении из рабочего каталога настроит удаленный и инициализирует каталог как репозиторий git. Конечно, вам придется отредактировать скрипт (только один раз), чтобы сообщить ему сервер и корневой путь для всех хранилища.

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

вы можете сделать голый репозиторий git со следующим код:

один из вариантов удаленного репозитория git использует протокол SSH:

для получения дополнительной информации, проверьте ссылку: Git на сервере - протоколы

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

в вашем случае, уже есть РЕПО на удаленном доступен. В зависимости от того, как вы получаете доступ к удаленному РЕПО ( с именем пользователя внутри url или ключом ssh, который обрабатывает проверку), используйте только :

есть и другие способы клонирования РЕПО. Таким образом, вы вызываете его, если у вас есть настройка ssh-ключа на вашем компьютере, которая проверяет при вытягивании вашего репозитория. Существуют и другие комбинации url-адреса, если вы хотите включить свой пароль и имя пользователя для входа в удаленный репозиторий.

В папке с проектом создаю локальный репозиторий ( git init ), выполняю весь необходимый минимум ( git add . , git commit -m "Описание коммита" ), и пробую выложить его в свой аккаунт на GitHub:

А возвращается ошибка:

Помогите решить проблему, как выложить свой проект на GitHub.

3 ответа 3

Linux / OS X

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

Вводим пароль от учетной записи:

Enter host password for user 'USER_NAME':

Репозиторий demo создан.

Теперь выгружаем проект.

Windows

Вариант 1:

Устанавливаем утилиту cURL и перезагружаемся. Дальше последовательность идентична Linux.

Вариант 2 (Спасибо @PinkTux):

Cкачиваем архив wget, разархивируем в любое место на диске и прописываем путь в переменной PATH . Открываем командную строку и пишем следующее:

Обратите внимание на экранирование кавычек (обратный слэш перед кавычкой) в --post-data . Не смотря на отсутствие необходимости перезагрузки, все же способ имеет и недостаток - необходимо явно в строке указывать пароль.

Таким способом можно создавать репозитории с различными параметрами.Вот туд приведен полный перечень параметров. Например для создания приватного репозитория (если у вас есть конечно такая привилегия) нужно подставить в первую строку после -d :

А почему . /demo.git в git remote . , если в curl . дали имя <"name":"demo">(т.е. без .git)? По моему (пока еще начальному) опыту на github создается репозиторий в точности с указанным именем. Вообще, надежней перед git remote . зайти на github в только что созданный проект и скопировать URL

@avp, вы совершенно правы и именно так я и поступил – взял код, предлагаемый GitHub'ом. Ваш вопрос меня заинтересовал, и я нашел на него ответ на EngSO. Если я правильно понял .git в url используется для обращения к чистым репозиториям. Попробовал обратится без .git – коммит улетел на удаленный репозиторий . Спасибо за Ваш комментарий.

1. Создание удалённого репозитория при помощи hub

hub — консольное приложение, упрощающее введение команд git и позволяющее производить некоторые недоступные для git действия в удалённых репозиториях из терминала. Так, при помощи hub возможно создание нового GitHub репозитория без обращений к веб-интерфейсу, для этого используется команда

Необязательные параметры команды:

-d — описание репозитория, на сайте GitHub располагается под именами пользователя и репозитория;
-h — ссылка на сайт, соответствующий репозиторию, в веб-интерфейсе GitHub находится рядом с описанием;
-p — сделать репозиторий приватным; параметр доступен только если у Вас платный GitHub аккаунт.

2. Демонстрация

Создаём, используя Git Bash, репозиторий с именем KristinitaTest.github.io в Windows.

Новый репозиторий успешно создан.

3. Примечания

В ответе подразумевается, что Вы уже связаны с аккаунтом на GitHub, и Вам не придётся при каждом push вводить логин/пароль.
Лично протестировано только на Windows 10, но так как hub — кроссплатформенная утилита, решение должно работать и в других операционных системах.

4. Дополнительные ссылки

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

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

(Впрочем, конфликты тут не страшны - можно же и push -f сделать)

PS когда вы копируете ваши файлы на флешку (много файлов), вы перед этим обычно создаете пустую папку, куда будете копировать. Репозиторий - это контейнер для коммитов, точно так же как папка - контейнер для файлов. Пуш репозитория на гитхаб - это просто копирование ваших коммитов. Так почему же вы решили, что можно обойтись без создания пустого репозитория на гитхабе?

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

Статья обновлена и дополнена ?
?? Этот материал подойдёт тем, кто уже знает, зачем нужны Git и GitHub, но ещё не пользовался ими.

Всего за 15–20 минут (время прочтения и повторения описанных действий) вы научитесь:

? работать с Git в Терминале на macOS
? создавать удалённые репозитории на GitHub
? и главное — связывать локальные репозитории с удалёнными

Я собрал этот материал из нескольких курсов и гайдов для разных git-сервисов. Выбрал лучшее, убрал лишнее и адаптировал его для GitHub и mac. Так что вы получите максимум пользы, за минимум времени.

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

Для работы потребуются:

аккаунт на GitHub (предустановлен на macOS)
Git — можно установить отсюда

?? Для систем Git есть различные графические клиенты. У GitHub есть свой. Позже, вы сможете выбрать и использовать один из них, но в этой инструкции, для лучшего погружения и практики, используется Терминал.

Настройка Git

Если вы ещё не пользовались Git, то для начала необходимо зарегистрироваться как пользователь системы — добавить в систему Имя пользователя и e-mail. Запустите Терминал, и выполните поочерёдно две команды (имя и имейл вписываются без скобок):

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

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

Удалённый репозиторий на GitHub — это облако, в котором хранятся файлы проекта и история их изменений. Локально же — это просто папка проекта на компе.

Репозитории на GitHub используются для самых разных целей:

расшаривания кода и другой информации (например, список интересного в телеграм)
совместной разработки, обсуждения и ведения проектов (не только связанных с кодом, например, карта навыков и развития тим-лида)
и даже для ведения тасок (во встроенном таск-треккере)

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

Порядок действий такой:

?? Можно делать и наоборот, но приведённая последовательность больше подходит для новичков.

Для каждого проекта лучше создавать отдельный репозиторий на Github. Ниже описано создание удалённого репозитория и локальной папки для тестового проекта hello-world, и их синхронизация.

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

Новый репозиторий на GitHub можно создать, нажав в правом верхнем углу на + и выбрав New repository в выпадающем меню:

Откроется страница настройки нового репозитория (скрин ниже), на которой:

вводится имя репозитория
добавляется краткое описание проекта (не обязательно)
выбирается тип репозитория

?? На GitHub есть два типа репозиториев — Public (будет виден всем, на странице вашего аккаунта, и все смогут писать коммиты), Private (будет виден только вам и тем, кому вы предоставите доступ в настройках репозитория).

добавляется файл README (чекбокс Initialize this repository with a README)

?? Для Public репозиториев принято добавлять файл README с описанием проекта. В файл добавится описание из поля Description. А вся информация из этого файла будет отображаться на странице проекта.

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

После такой элементарной настройки, уже можно создать репозиторий ? зелёная кнопка Create repository.

На открывшейся странице созданного репозитория, всё что нам нужно по проекту, находится на вкладке Code. Тут же выводится содержание файла README.

На момент создания, у проекта есть один файл README.md, один commit (запись о факте создания репозитория) и одна ветка (главная ветка master).

?? Для работы продакта, или аналитика, зачастую, достаточно основной ветки master. Дополнительные ветки создаются для сложных проектов, или для совместной работы. Использование дополнительных веток будет рассмотрено в отдельном материале. Не забудьте нажать Follow.

Рабочая папка для проектов

Скорее всего, у вас уже есть папка для проектов. Если ещё нет, то создайте. Далее, необходимо будет перейти в неё в Терминале (описано ниже).

?? Папку самого проекта создавать не нужно, она клонируется из GitHub.

На начальном этапе, работать с файлами и папками привычнее в Finder. Быстро перейти сразу в папку для проектов (после её создания) в Терминале, можно прямо из Finder, правым кликом по папке для проектов ? Службы ? Новая вкладка Терминала по адресу папки.

Откроется вкладка Терминала с нужным нам адресом.

Чтобы работать с проектом локально, и при этом, все изменения синхронизировать с удалённым репозиторием, необходимо клонировать GitHub-проект.

Для этого на странице проекта на GitHub необходимо нажать кнопку Clone or download и скопировать адрес репозитория.

Далее, в Терминале (в той вкладке, которая открылась из Finder) выполняется команда (используя скопированный URL без скобок):

По завершению отработки команды, Терминал выдаст done — папка проекта, которую мы клонировали с GitHub появилась в папке для проектов на компе. Теперь можно работать с проектом локально — создавать файлы, редактировать их и все изменения синхронизировать с удалённым репозиторием.

Чтобы связать новый проект на GitHub с папкой проекта на компе, надо:

создать проект на GitHub (новый репозиторий) и скопировать его УРЛ
перейти в Терминале в общую папку для проектов (папку самого проекта создавать не надо)
клонировать проект с GitHub — git clone (URL без скобок)

?? Таким способом можно скопировать любой проект с Гитхаба себе на комп

Изменения в проекте

Для демонстрации синхронизации я сделаю два изменения:

скорректирую файл README
добавлю картинку в папку проекта

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

В файл README.md добавлена строка “My furst commit”. Сделана опечатка, которая будет исправлена позже, когда будет рассматриваться изменение файлов в репозитории GitHub.

В папку проекта добавлена картинка project-page.jpg (один из скриншотов из этого поста).

Git flow

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

Основные действия — это коммит и пуш. А git add — всего лишь служебная команда для регистрации/добавления изменений.

?? Commit — это точка сохранения проекта, в которую можно будет вернуться, если что-то пойдёт не так (как сохранение в игре). Эти сохранения и синхронизируются между локальным и удалённым репозиториями.
Push — это внесение закоммиченых локальных изменений в проект на удалённом репозитории.

Подробно о каждом действии — далее.

Информационная команда git status

Все манипуляции с проектом делаются в папке проекта. Для этого, необходимо открыть её в Терминале. Можно использовать приведённый выше способ (правый клик по папке в Finder). Или, если в Терминале уже открыта папка для проектов, можно переместиться в папку проекта командой (имя папки проекта вписывается без скобок):

Команды git add и git commit

В Терминале перейдём в папку проекта (все изменения с проектом делаются в папке проекта). Для отслеживания изменений используется команда:

? Все используемые git и github команды с их описанием будут приведены в отдельном блоке в конце материала.

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

?? git status можно не использовать, но хорошо знать, что такая возможность есть, и можно в любой момент посмотреть информацию о состоянии проекта.

?? Это будет полезно при работе с несколькими ветками.

Тут же, в круглых скобках git сам даёт подсказки, что можно делать дальше: use git add …

git add (добавить)

Командой git add регистрируются (добавляются) изменения в папке проекта. В больших проектах, при изменении одного файла, обычно добавляют только его (имя файла с расширением, без скобок):

Следующая команда регистрирует (добавляет) сразу все изменения. В небольших проектах можно всегда использовать её, т.к. это проще и быстрее:

Чтобы убедиться, что все изменения добавлены, можно снова выполнить git status (это не обязательно).

git commit (закоммитить)

Для создания коммита, и добавления к нему комментария используется расширенная команда (комментарий пишется как в примере — в кавычках):

?? Коммиты, обычно, делаются после какого то блока изменений — добавлен/переписан блок кода, или новый блок информации. Коммиты хорошо сопровождать описанием о проделанных изменениях.

Теперь git status показывает, что изменений больше нет. И что есть один коммит, не добавленный в ветку.

git push (запушить)

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

?? При первом использовании git push , Git запросит логин и пароль от аккаунта на GitHub. При вводе пароля, никакие символы не появляются и курсор не сдвигается — это нормально, просто введите полностью и нажмите энтер. Если пароль введён без ошибок — всё сработает.

В git status , теперь будет информация, что никаких новых изменений нет (nothing to commit), и коммитить нечего.

Теперь проект на Гитхабе актуальный — тут отобразились все изменения, которые были сделаны локально: добавился один commit, добавился файл, изменился README.

перейти в Терминале в папку самого проекта
зарегистрировать изменения — git add .
создать коммит — git commit -m "Комментарий"
запушить коммит на GitHub — git push origin master

?? Для отслеживания статуса изменений в проекте используется команда git status

Бывает так, что файлы проекта правятся прямо на сайте GitHub. Или кто-то из участников проекта запушил новые изменения. В обоих случаях, необходимо получить эти изменения и обновить локальный репозиторий.

Редактирование файлов проекта на сайте удалённого репозитория

?? Все изменения в удалённом репозитории являются коммитами. Т.е. при сохранении изменений файла, сразу добавляется коммит в проекте на GitHub.

Для редактирования файлов на сайте GitHub используется встроенный редактор. Порядок действий такой:

Вносятся изменения в файле;
Добавляется описание коммита;
Сохраняется коммит.

После сохранения, коммит добавляется в проект и сразу примеряются все изменения.

На Гитхабе хранится история всех коммитов и подробная информация по ним. Если зайти в любой коммит, можно посмотреть какие правки были сделаны. Удалённые строки подсвечиваются красным, добавленные — зелёным.

Обновление локального репозитория

Для обновления локального репозитория, после любых изменений проекта на Гитхабе, в Терминале (надо находится в папке проекта) используется команда:

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

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

Сам по себе Git – это эффективная технология с открытым исходным кодом, позволяющая отслеживать локальные изменения при разработке кода, особенно при создании сложного программного обеспечения.

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

Три файла и два коммита

Прежде чем следовать этому учебнику по git remote add origin, настройте локальную установку Git, локально инициализированный репозиторий по крайней мере с одним коммитом Git и учетную запись в GitHub или GitLab.

Для этого урока мы будем использовать GitHub, но процесс с GitLab практически идентичен.

Начните с локального репозитория, хранящегося в папке с именем my-local-repo, в которой находятся три файлов:

Сам репозиторий имеет только две коммита, которые вы можете увидеть, выполнив команду git reflog, как показано на рисунке ниже.

Создайте удаленный репозиторий на GitHub

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

Создать удаленный репозиторий легко.

В этом примере я назвал репозиторий GitHub my-github-repo, чтобы четко отличить его от репозитория Git, который хранится локально в папке с именем my-local-repo.

Поскольку вы будете передавать информацию в репозиторий GitHub, не инициализируйте ее с помощью README, настройте файл gitignore или добавьте лицензию.

Все эти вещи будут существовать в локальном репозитории и будут впоследствии перенесены в удаленный GitHub.

Если эти ресурсы существуют в обоих репозиториях до запуска команды git remote add origin, это создаст дополнительные шаги слияния и разрешения конфликтов, которых легко избежать.

Скопируйте и измените URL удаленного добавления GitHub

При условии, что URL-адрес уникально идентифицирует созданный мной репозиторий GitHub:

Скопируйте и вставьте этот URL-адрес в текстовый редактор, а затем добавьте свое имя пользователя и пароль в начало URL-адреса:

Эта настройка URL позволяет аутентифицировать файл без использования диспетчера учетных данных или другого инструмента управления паролями.

Запустите команду git remote add origin

С URL-адресом GitHub, сохраненным в буфере обмена в папке, содержащей локальный репозиторий Git, откройте окно терминала и выполните следующую команду git remote add origin:

Чтобы убедиться, что удаленное хранилище было добавлено в вашу конфигурацию, используйте команду git remote –v.

Выполните git push

Наконец, с настроенной службой GitHub отправьте все свои локальные изменения кода, историю изменений на удаленный сервер с помощью команды git push.

Убедитесь, что вы указали опцию –set-upstream, иначе удаленный сервер отклонит операцию.

Также включите название ветки, которую нужно нажать, которая в этом случае является master.

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

Убедитесь, что прошел git push на GitHub

После завершения команд git remote add и push вернитесь к экземпляру GitHub и посмотрите на содержимое недавно созданного репозитория.

Результат локальной команды git remote add и push отражается в удаленном репозитории GitHub.

Удаленный репозиторий GitHub должен содержать все файлы, которые составляют ваш локальный репозиторий, и в то же время хранить копию вашей истории коммитов.

Если вы посмотрите на мой репозиторий GitHub, вы увидите файлы HelloWorld.java, index.html и style.css, а также указание на то, что репозиторий содержит две фиксации.

Эти файлы и коммиты соответствуют выводу команды git reflog с самого начала этого урока.

Добавить комментарий Отменить ответ

Ищете во что поиграть в январе 2022 года? Устали лепить снежки на улице или заворачивать рождественские подарки для своих близких? В данной статье Вы найдете игры на любой вкус! Ах, белая зима началась внезапно! В такой мороз совсем не хочется выходить из дома и на этот случай разработчики мобильных игр выпустили много интересных релизов! В.

Вопрос: Как отладить/найти изменения или неудачные команды во время процесса загрузки? 1. В процессе загрузки, при появлении загрузочного меню grub нажмите “e” для редактирования grub, затем прокрутите вниз, пока не увидите запись boot: echo "Loading Linux. linux16 /vmlinuz-XXX root=XXXro crashkernel=auto rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet LANG=en_US.UTF-8 2. В строке с “linux” удалите следующие записи, если они.

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

Когда вы посещаете официальный сайт LXLE, его мантра – “Оживите старый ПК” – смело бросается в глаза. И это именно то, что LXLE стремится сделать. Основанный на релизе Ubuntu/Lubuntu LTS, LXLE – это легкий дистрибутив Linux, дружественный к ресурсам и идеально подходящий для старых ПК или систем с низкими системными характеристиками. Фактически, LXLE занимает видное.

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