Как переписать на свой гитлаб
Перейти к содержимому

Как переписать на свой гитлаб

  • автор:

Git, как правильно скопировать чужой проект в свой?

Есть мой проект с какими-то моими наработками. Есть проект слайдера на github.com. Хочу скопировать его правильно к себе в проект. Я мог бы просто взять и скачать его с сайта и мне бы этого было вполне достаточно. Но все же мне хочется узнать, что я потеряю в данном случаи, какие у меня будут преимущества? Еще хочу, если это возможно и не долго, сделать так, чтобы у этого скопированного слайдера был только один последний коммит.

Отслеживать
33.9k 25 25 золотых знаков 130 130 серебряных знаков 222 222 бронзовых знака
задан 30 янв 2017 в 13:46
25 2 2 серебряных знака 8 8 бронзовых знаков
git-scm.com/book/ru/v1/… git submodule add https://github.com/kopipejst/coin-slider.git coin-slider
30 янв 2017 в 13:52

Все сработало, спасибо за полезную инфу. Жаль, что я раньше не нашел этот учебник. Изучал вот этот, а там я не чего подобного не припоминаю.

30 янв 2017 в 17:39

3 ответа 3

Сортировка: Сброс на вариант по умолчанию

Можно добавить этот проект как субмодуль в ваш проект. Синаксис такой:

git submodule add

В данном случае:

git submodule add [email protected]:kopipejst/coin-slider.git coin-slider 

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

cd coin-slider git pull 

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

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

Отслеживать
ответ дан 30 янв 2017 в 14:08
Nick Volynkin ♦ Nick Volynkin
33.9k 25 25 золотых знаков 130 130 серебряных знаков 222 222 бронзовых знака

Спасибо, за информацию!))) Единственное, ваш варит не сработал: «fatal: не удалось клонировать «[email protected]:kopipejst/coin-slider.git» в подмодуль по пути «/srv/http/test»». Побывал по проще, так сработало!) git submodule add github.com/kopipejst/coin-slider.git Поправите меня, если так делать нельзя.

30 янв 2017 в 15:59

@taiiku наверное, нужно чтобы папка /srv/http/ существовала и у вас были права на запись в неё. Она точно не руту принадлежит?

30 янв 2017 в 16:37

http — принадлежит мне, но почему-то переименовать не могу, (заметил случайно, хотел скопировать имя), а вот svr — это root. Попробовал создать тестовый репозиторий в домашней папке, та же ошибка.

30 янв 2017 в 17:08

Надо смотреть на лицензию проекта. Судя по всему лицензия проекта MIT License — одна из самых либеральных, следовательно вам нет необходимости отдельно публиковать модификации, которые вы возможно будете вносить. Следовательно нет необходимости заморачиваться с fork’ом проекта.

В таком случае достаточно будет дернуть zip архив и вставить его в свой проект (лучше всего в отдельный каталог).

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

Отслеживать
ответ дан 30 янв 2017 в 14:08
81.1k 7 7 золотых знаков 72 72 серебряных знака 153 153 бронзовых знака
Спасибо, за хорошее объяснения ситуации и про лицензии.
30 янв 2017 в 16:06

git clone 

И создастся папка с именем репозитория

DmitriyRF / Скопировать на github

This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters

Для того что бы скопировать/клониолвать/переместить с компьютера на github свой репозиторий нужно:
1. Создать репозиторий на github и смотришь его url по https или ssh
2. В папке с проектов запустить gitBash и прописать:
git init // Инициализация
git add . // Индексируешь
git commit -m «first commit» // Коммитишь или git commit -am «first commit»
git status // Проверяешь, что все нужные файлы проиндексированы, если попали ненужные изменения, сбрасываешь: git reset HEAD имя файла
git remote add // Добавляешь удаленный(дальний) репозиторий, где — это какое-нибудь имя, например origin — это https/ssh ссылка на репозиторий
// По умолчанию репозиторий называется origin, просмотреть их можно git remote -v.
——> git push -u origin master Потом можно это вставить
git pull —rebase master // Стягиваешь изменения из удаленной ветки:
git push master // Отправляешь свои изменения на github // git push [remote-name] [branch-name].
При конфликте можно просмотреть все существующие ветки(для создания ветки используется git branch [branch-name])
git branch (* — указывает на ту ветку на которой сейчас находимся)
Для смены ветки: $ git checkout [branch-name]
Чтобы включить изменения в ветке [branch-name] в master, выполните $ git merge [branch-name] находясь при этом в master
Если изменения не конфликтуют, то вы закончили.
Если же существуют какие либо конфликты, то в проблемных файлах останутся заметки которые можно увидеть выполнив;
$ git diff
Как только вы отредактировали файлы вызывающие конфликты выполните,
$ git commit -a
git push -f origin master
! Делаем принудительный коммит в основной репозиторий -f значит force
! Эта команда силой перезаписывает внешний репозиторий на локальный!
Например, если вы фиксируете изменения, и понимаете,
что забыли проиндексировать изменения в файле,
который хотели включить в коммит,
можно сделать примерно так:
$ git commit -m ‘initial commit’
$ git add forgotten_file
$ git commit —amend
В итоге получится единый коммит — второй коммит заменит результаты первого.
Отмена локальных изменений (до индексации)
Измените file.html
Иногда случается, что вы изменили файл в рабочем каталоге,
и хотите отменить последние коммиты.
С этим справится команда checkout
$ git status
# On branch master
# Changes not staged for commit:
# (use «git add . » to update what will be committed)
# (use «git checkout — . » to discard changes in working directory)
#
# modified: file.html
#
no changes added to commit (use «git add» and/or «git commit -a»)
$ git checkout file.html
$ git status
# On branch master
nothing to commit (working directory clean)
$ cat file.html
$ git reset —hard HEAD^ удаляет коммит и все изменения в файла и новый файлы с диска навсегда.
…or create a new repository on the command line
echo «# ___________» >> README.md
git init
git add README.md
git commit -m «first commit»
git remote add origin git@github.com:DmitriyRF/__________.git
git push -u origin master
…or push an existing repository from the command line
git remote add origin git@github.com:DmitriyRF/__________.git
git push -u origin master

Saved searches

Use saved searches to filter your results more quickly

Cancel Create saved search

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

Как перенести свой репозиторий в организацию

AMM2017/Instruction

This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Switch branches/tags
Branches Tags
Could not load branches
Nothing to show
Could not load tags
Nothing to show

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Cancel Create

  • Local
  • Codespaces

HTTPS GitHub CLI
Use Git or checkout with SVN using the web URL.
Work fast with our official CLI. Learn more about the CLI.

Sign In Required

Please sign in to use Codespaces.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Git stats

Files

Failed to load latest commit information.

Latest commit message
Commit time

README.md

Перенос своего репозитория в эту организацию

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

git status # Показывает текущую ветку и изменённые\подготовленные(staged) файлы git branch # Выводит список всех веток git log --pretty=format:"%h - %an, %ar : %s" # Показывает комиты текущей ветки

Удаляем существующий remote

git remote remove origin

Создаём пустой(!) репозиторий в организации и копируем ssh url Создаём новый remote

git remote add origin %url%

Пушим нужные ветки (master, dev, . ) не забывая привязывать up-stream ветки

git checkout master git push -u origin master git checkout dev git push -u origin dev .

About

Как перенести свой репозиторий в организацию

Git для начинающих. Урок 2.
Создание и клонирование репозитория

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

Что такое репозиторий

Это каталог в файловой системе, где хранится информация о проекте:

  • файлы и папки проекта
  • история проекта
  • настройки проекта
  • служебная информация

Информация о репозитории хранится в скрытой папке .git в корне проекта.

Можно ли работать с git локально

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

Локальный репозиторий

Это репозиторий, который хранится на нашей машине, в рабочей папке проекта. Это та самая скрытая папка .git

Удаленный репозиторий, зачем он нужен

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

Плюсы удаленного репозитория

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

Что такое клонирование

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

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

В первую очередь, нужно получить ссылку на проект. Мы можем найти ее сами или получим готовую, например, на новой работе. Возьмем для примера репозиторий vuejs — https://github.com/vuejs/vue.git

Наберем в командной строке

 $ git clone https://github.com/vuejs/vue.git 

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

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

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

 $ git clone https://github.com/vuejs/vue.git vue-new 

Где vue-new — нужное название папки.

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

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

Где держать репозиторий

Есть множество вариантов, самые известные — это github и bitbucket. Нужно выбирать.

github или bitbucket

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

Чтобы продолжить уроки, нужно зарегистрироваться на github. Если у вас нет там аккаунта, то форму регистрации увидите сразу на главной странице — https://github.com/

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

После регистрации создание репозитория доступно с главной страницы github. При создании нужно указать название проекта и тип (публичный или приватный). На остальное пока не обращаем внимания.

Права на репозиторий, публичные и приватные

Есть 2 типа репозиториев:

  • публичный (public), открыт всем
  • приватный (private), доступен только определенному кругу лиц — в первую очередь, нам самим

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

Для себя будем создавать приватные репозитории. Для этого нам понадобятся ssh-ключи.

нельзя просто так клонировать приватный репозиторий

Что такое ssh-ключи

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

ssh-ключ не имеет прямого отношения к git, но так репозитории находятся на удаленных серверах, то ssh-ключи используются для разграничения доступа к приватным репозиториям.

ssh-ключ состоит из пары ключей: публичного и приватного ключа. Это просто 2 текстовых файла:

  • /домашний-каталог/.ssh/id_rsa.pub — публичный
  • /домашний-каталог/.ssh/id_rsa — приватный

Публичный ключ передается сторонним серверам, например, github, для открытия доступа на эти сервера. Приватный ключ хранится только на нашей машине и никому не передается. То есть когда у нас просят ssh-ключ, чтобы дать доступ на какой-нибудь сервер, мы отдаем именно публичный ключ, id_rsa.pub

Как сгенерировать ssh-ключ

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

 $ cd ~/.ssh $ ls -l 

Если видим файлы id_rsa и id_rsa.pub — отлично, ключи уже есть.

Если этих файлов нет, то нужно сгенерировать ключи утилитой ssh-keygen. В Windows она устанавливается вместе с git, в Linux и MacOS при необходимости установите. В Linux, например, вот так

 $ sudo apt install ssh-keygen 

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

 $ ssh-keygen -t rsa -b 4096 -C "your_email@example.com" 
 $ ls -l total 24 -rw------- 1 sn8 sn8 1675 Feb 11 2017 id_rsa -rw-r--r-- 1 sn8 sn8 392 Feb 11 2017 id_rsa.pub -rw-r--r-- 1 sn8 sn8 5746 Oct 28 21:52 known_hosts 

Появились файлы id_rsa и id_rsa.pub — значит, ключи успешно сгенерированы.

known_hosts — это файл, в котором ssh прописывает сервера, на которые мы заходим. При первом подключении к github нужно будет разрешить доступ к github.com (напечатать yes в терминале)

Как добавить ssh-ключ в настройках github

Открываем публичный ключ id_rsa.pub и копируем его содержимое. В настройках github ищем раздел «SSH и GPG keys» — https://github.com/settings/keys. Жмем «New SSH key», задаем название ключа, например, имя, и вставляем форму публичный ключ, прямо текстом. Все, теперь у нас есть доступ к нашим приватным репозиториям.

Два способа создания проекта

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

Второй, когда у нас уже есть проект. Нужно зайти в папку проекта и связать его с уже существующим репозиторием на github. Это называется инициализация.

Рассмотрим оба способа.

Пустой проект

Создаем приватный репозиторий на github, назовем его first-site. Я зарегистрировался под именем Webdevkin, моя ссылка для клонирования будет такая — git@github.com:Webdevkin/first-site.git. Ваша зависит от имени пользователя.

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

 $ git clone git@github.com:Webdevkin/first-site.git 

В текущей папке получим новую папку с названием first-site — это и есть наш проект.

P.S. У вас склонировать этот репозиторий не получится — он закрытый. Создайте свой 🙂

Непустой проект

Допустим, у нас на локальной машине уже есть проект second-site. Создаем в github репозиторий second-site. Заходим в папку проекта и выполняем команды

 $ git init $ git add . $ git commit -m "Initial commit" $ git remote add origin git@github.com:Webdevkin/second-site.git $ git push -u origin master 

Все, можно приступать к работе над проектом. Команды add, commit и push мы разберем в следующих уроках.

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

Что могу посоветовать

  • github или bitbucket? Для личных проектов неважно, оба сервиса разрешают бесплатно создавать приватные репозитории. Для open source или резюме — github
  • не увлекайтесь клонированием в папку со своим названием. Есть шанс запутаться, самому или коллегам
  • не путайте публичный и приватный ключи. Отдаем вовне только публичный ключ id_rsa.pub
  • при смене рабочей машины можно не генерировать ssh-ключи заново, а скопировать их со старой машины. Тогда не придется заново прописывать новые ключи на серверах

Немного подробнее о копировании ssh-ключей

Как скопировать ssh-ключи с одной машины на другую

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

  • Скопировать id_rsa и id_rsa.pub со старой машины на новую
  • Посмотреть права на файлы, возможно, ключи окажутся слишком «открытыми» для записи и потребуется сменить им права доступа — sudo chmod 700 ~/.ssh/*
  • Выполнить команду ssh-add

Ссылки, которые могут пригодиться

  • github — https://github.com/
  • bitbucket — https://bitbucket.org/
  • подробнее об ssh-ключах (en) — connecting-to-github-with-ssh

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

Спасибо за внимание и до встречи!

Все уроки курса

  • Вводный урок
  • 1. Установка и базовая настройка git
  • 2. Создание и клонирование репозитория git
  • 3. Делаем первые изменения, git status и git diff
  • 4. Коммиты и история коммитов, git commit, git log и git show
  • 5. Подробнее об истории коммитов. Путешествие по истории
  • 6. Работа с сервером, git push и git pull
  • 7. Ветки — главная фишка git, git branch и git checkout
  • 8. Работа с ветками на сервере, git fetch
  • 9. Слияния или мерджи веток, git merge
  • 10. Конфликты и их разрешение
  • Платная часть курса. Презентация
  • * 11. Работа с gitignore и git exclude
  • * 12. Буфер обмена git, git stash
  • * 13. Копирование коммитов, git cherry-pick
  • * 14. Отмена и редактирование последнего коммита
  • * 15. Отмена произвольного коммита, git revert
  • 16. Склеивание коммитов, git rebase —interactive и git reflog
  • * 17. Зачем склеивать коммиты. Плюсы и минусы сквоша
  • * 18. Работа с git rebase. Отличия от merge
  • * 19. Что такое git push —force и как с ним работать
  • * 20. Ищем баги с помощью git, git bisect
  • * 21. Как и зачем работать с тегами git
  • * 22. Процессы: github flow и git flow
  • * 23. Псевдонимы в git
  • 24. Мердж-реквесты
  • * 25. Форки

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *