Что происходит при удалении удаленного репозитория?
Удаление репозитория на GitHub похоже на полное удаление файла с вашего ПК. Однако при удалении удаленного репозитория следует учитывать следующее:
- Вы не можете получить удаленный репозиторий.
- Удаление удаленного репозитория не влияет на файлы проекта локально.
- Это также не влияет на ваш локальный репозиторий.
- Все комментарии, пакеты, рабочий процесс и администраторы удаляются вместе с ним.
- Удаленный репозиторий не может быть разветвлен.
Учитывая последствия удаления репозитория GitHub, вы можете передумать. Однако GitHub также позволяет вам архивировать репозитории вместо их удаления.
Вы можете получить доступ к этой опции, щелкнув Архивировать этот репозиторий в зоне опасности .
Инструмент 2: Pull Requests
Pull Requests — отличный способ внести свой вклад в репозиторий, сделав его форк. В конце дня, если мы хотим, мы можем отправить pull request владельцу репозитория, чтобы объединить наши изменения кода. Сам pull request может включать обсуждение качества кода, функций или даже общей стратегии.
Давайте теперь рассмотрим основные шаги для pull request.
Инициирование pull request
В Github есть две модели для pull request:
- Модель Fork & Pull — используется в общедоступном репозитории, на который у вас нет push-доступа
- Share Repository Model — используется в частном репозитории, на который у нас есть push-доступ. В этом случае форк не требуется.
Здесь мы видим рабочий процесс между двумя пользователями ( и ) для модели Fork and Pull:
- Определите репозиторий Github, в который вы хотите внести свой вклад, и нажмите кнопку «Fork», чтобы создать клон репозитория в вашей собственной учетной записи Github:
- Это создаст точную копию репозитория в вашем собственном аккаунте
- Выберите URL-адрес SSH, чтобы он запрашивал вашу парольную кодовую фразу SSH вместо имени пользователя и пароля каждый раз, когда вы делаете или . Затем мы будем клонировать этот репозиторий на наш локальный компьютер:
- Как правило, мы создадим новую ветку git для каждой новой задачи. Это хорошая практика, потому что в будущем, если мы продолжим обновление ветки после некоторых обсуждений, запрос на перенос будет автоматически обновляться. Давайте создадим новую ветку, чтобы внести очень простое изменение в файл :
- После внесения соответствующих дополнений для создания новых функций мы просто передадим новые изменения и проверку в ветку git master:
- На этом этапе мы запушим ветку в удаленный репозиторий. Для этого мы сначала перейдем на ветку с новой задачей, а так же на псевдоним для удаленного репозитория. Затем мы будем пушить изменения с помощью :
- На нашей развязанной странице Github репозитория мы перейдем к ветке с новой функцией, а затем нажмите кнопку «Pull Request».
- После отправки пул реквеста он напрямую приведет нас к странице запроса в исходном репозитории. Мы увидим наш запрос на pull.
- После обсуждения возможно, что владелец форкнутого репозитория может захотеть добавить изменения в новую функцию. В этом случае мы выберем одну и ту же ветку на нашей локальной машине, зафиксируем ее и запушим ее обратно на Github. Когда мы заходим на страницу запроса в оригинальном репозитории, он будет автоматически обновляться!
Слияние пул реквеста
Если вы являетесь владельцем оригинального репозитория, существует два способа слияния входящего пул реквеста:
- Слияние непосредственно на Github: если мы делаем слияние непосредственно на Github, то убедитесь, что нет конфликтов, и реквест готов к объединению в ведущую ветку. Владелец оригинального хранилища может просто щелкнуть зеленую кнопку «Слить запрос», чтобы сделать это:
- Слияние на наших локальных машинах: в других случаях могут возникнуть конфликты слияния, и после нажатия кнопки «Информация» у Github будут четкие инструкции о том, как мы можем объединить ветвь на нашей локальной машине, потянув за изменения из ветви контрибьютера:
Существуют различные модели создания веток, используемые для управления версиями в командах разработки программного обеспечения. Вот две популярные модели рабочего процесса git: (1) рабочий процесс Github, который имеет простую ветвящуюся модель и использует запросы на pull, и (2) Gitflow, который имеет более обширное разветвление. Модель, которая в конечном итоге будет выбрана, определенно будет меняться в зависимости от команды, проекта и ситуации.
Зачем нужно удалять плохие репозитории GitHub
Вы же не хотите представлять грязный GitHub потенциальным работодателям во время поиска работы. Плохие репозитории, полные практического кода, или расплывчатые незавершенные проекты не дают хорошего представления о ваших способностях.
Кроме того, это может заставить потенциальных клиентов усомниться в вашей компетентности.
Эти проблемы могут не относиться к вам, если вы не используете GitHub профессионально. Но если вы планируете серьезно подойти к своим рабочим процессам и представить более профессиональный GitHub, вам следует очистить свои репозитории. Вы можете начать с удаления тех, которые не добавляют ценности вашим учетным данным GitHub.
Глобальный .gitignore
Git также позволяет вам создать глобальный файл , в котором вы можете определить правила игнорирования для каждого Git-репозитория вашей локальной системы.
Файл может называться по вашему усмотрению и храниться в любом месте. Наиболее распространенным местом хранения этого файла является домашний каталог. Вам придется вручную создать файл и настроить Git для его использования.
Например, чтобы установить в качестве глобального файла игнорирования Git, выполните следующие действия:
1. Создайте файл:
2. Добавьте этот файл в Git-конфигурацию:
3. Откройте файл в текстовом редакторе и добавьте в него свои правила.
Глобальные правила особенно полезны при игнорировании определенных файлов, которые вы никогда не захотите фиксировать, таких как файлы с конфиденциальной информацией или скомпилированные исполняемые файлы.
Создание Git-репозитория
Сначала рассмотрим создание репозитория. Представим, что у вас уже есть папка для хранения файлов, но она еще не находится под контролем Git.
Откройте «Командную строку» (Windows) или Терминал (Linux/macOS) и перейдите по пути данной папки.
В Linux выполните команду:
cd /home/user/directory
В macOS
cd /Users/user/directory
В Windows:
cd C:/Users/user/directory
Остается только ввести нижеуказанную команду, чтобы завершить первый этап.
git init
Благодаря этой команде создается структура подкаталога со всеми необходимыми файлами. Кстати, все они расположены в подпапке с названием .git. Пока что проект не находится под контролем учета версий, поскольку в него добавлены только нужные элементы для работы Git. Для добавления файлов в репозиторий будем использовать git add. Команда git commit является заключительной:
git add git commit -m 'initial project version'
Теперь у вас есть Git-репозиторий со всеми необходимыми составляющими и отслеживаемыми файлами.
