Как бороться с предупреждением об отсутствии файла Xcode в репозитории Git?
Я использую GIT для управления исходным кодом в моем проекте Xcode. После обновления библиотеки Cocopod я начал получать предупреждения, подобные следующим:
File:///Users/NinjaDev/Development/Xcode/NinjaApp/Pods/Alamofire/Source/Download.swift: предупреждение: Отсутствует файл: /Users/NinjaDev/Development/Xcode/NinjaApp/Pods/Alamofire/Source/Download.swift отсутствует в рабочей копии
Библиотека изменилась, так что файла Download.swift больше нет. Я зафиксировал проект и сделал чистку и перестройку, но все еще получаю сообщение об ошибке. Я предполагаю, что репозиторий не знает, что он был удален, но я не очень хорошо знаком с внутренней работой Git. как правильно это исправить и предотвратить повторение этого?
Изменить: по предложению Aspirin2D, вот статус git. В журнале git не было ничего необычного.
Статус Git
РЕДАКТИРОВАТЬ 2: Я понял, что произошло. Когда я зафиксировал в Xcode, файлы, которые я удалил, по умолчанию должны были быть сняты с проверки. Пока я возился с проблемой, я снова открыл меню фиксации, и, конечно же, это была просто куча непроверенных файлов. Проверьте их и снова зафиксируйте предупреждения. Почему Xcode по умолчанию не проверяет некоторые файлы?
Git happens! 6 типичных ошибок Git и как их исправить
Прим. перев.: На днях в блоге для инженеров любимого нами проекта GitLab появилась небольшая, но весьма полезная заметка с инструкциями, которые помогают сохранить время и нервы в случае различных проблем, случающихся по мере работы с Git. Вряд ли они будут новы для опытных пользователей, но обязательно найдутся и те, кому они пригодятся. А в конец этого материала мы добавили небольшой бонус от себя. Хорошей всем пятницы!
Все мы делаем ошибки, особенно при работе с такими сложными системами, как Git. Но помните: Git happens!
Если вы только начинаете путь с Git, обучитесь основам работы с ним в командной строке. А здесь я расскажу о том, как можно исправить шесть наиболее распространённых ошибок в Git.
1. Упс… Я ошибся в сообщении к последнему коммиту
После нескольких часов кодинга легко допустить ошибку в сообщении коммита. К счастью, это легко исправить:
С этой командой откроется текстовый редактор и позволит внести изменения в сообщение к последнему коммиту. И никто не узнает, что вы написали «addded» с тремя «d».
2. Упс… Я забыл добавить файл к последнему коммиту
Другая популярная ошибка в Git — слишком поспешный коммит. Вы забыли добавить файл, забыли его сохранить или должны внести небольшое изменение, чтобы коммит стал осмысленным? Вашим другом снова будет —amend .
Добавьте недостающий файл и выполните эту верную команду:
Теперь вы можете либо откорректировать сообщение, либо просто сохранить его в прежнем виде (с добавленным файлом).
3. Упс… Я добавил файл, который не должен быть в этом репозитории
Но что, если у вас обратная ситуация? Что, если вы добавили файл, который не хотите коммитить? Обманчивый ENV-файл, директорию сборки или фото с котом, что было случайно сохранено в неправильном каталоге… Всё решаемо.
Если вы сделали только stage для файла и ещё не коммитнули его, всё делается через простой reset нужного файла (находящегося в stage):
Если же вы всё-таки коммитнули изменение, потребуется дополнительный предварительный шаг:
Коммит будет откачен, картинка удалена, а затем сделан новый коммит.
Прим. перев.: Как замечено в комментариях к оригинальной статье, эту проблему тоже можно решить с помощью уже упомянутого —amend . По всей видимости, данным пунктом автор хотел показать, какие ещё есть способы изменения истории коммитов для исправления ошибки.
4. Упс… Я коммитнул изменения в master
Итак, вы работаете над новой фичей и поспешили, забыв создать новую ветку для неё. Вы уже коммитнули кучу файлов и все эти коммиты оказались в master’е. К счастью, GitLab может предотвращать push’ы прямо в master. Поэтому мы можем откатить все нужные изменения в новую ветку следующими тремя командами:
Примечание: Убедитесь, что сначала коммитнули или stash‘нули свои изменения — иначе все они будут утеряны!
Будет создана новая ветка, в master’е — произведён откат до состояния, в котором он был до ваших изменений, а затем сделан checkout новой ветки со всеми вашими изменениями.
5. Упс… Я сделал ошибку в названии ветки
Самые внимательные могли заметить в предыдущем примере ошибку в названии ветки. Уже почти 15:00, а я всё ещё не обедал, поэтому мой голод назвал новую ветку (branch) как future-brunch. Вкуснотища!
Переименуем эту ветку аналогичным способом, что используется при переименовании файла с помощью команды mv, то есть поместив её в новое место с правильным названием:
Если вы уже push’нули эту ветку, понадобится пара дополнительных шагов. Мы удалим старую ветку из remote и push’нем новую:
Прим. перев.: Удалить ветку из remote ещё можно с помощью:
6. Oops… I did it again!
Последняя команда на тот случай, когда всё пошло не так. Когда вы накопировали и навставляли кучу решений со Stack Overflow, после чего в репозитории всё стало ещё хуже, чем было в начале. Все мы однажды сталкивались с подобным…
git reflog показывает список всех выполненных вами операций. Затем он позволяет использовать магические возможности Git’а по путешествию во времени, т.е. вернуться к любому моменту из прошлого. Должен отметить, что это ваша последняя надежда — не стоит прибегать к ней в простых случаях. Итак, чтобы получить список, выполните:
Каждый наш шаг находится под чутким наблюдением Git’а. Запуск команды на проекте выше выдал следующее:
Обратите внимание на самый левый столбец — это индекс. Если вы хотите вернуться к любому моменту в истории, выполните следующую команду, заменив
Итак, теперь у вас есть шесть способов выбраться из самых частых Gitfalls (игра слов: pitfall переводится как «ловушка, ошибка» — прим. перев.).
Бонус от переводчика
Во-первых, ценное замечание ко всему написанному выше (кроме пункта 5). Нужно учитывать, что эти действия меняют историю коммитов, поэтому их следует проводить, только если изменения не были отправлены в remote (push’нуты). В противном случае старый плохой коммит уже будет на remote-ветке и придётся либо выполнять git pull (который сделает merge, и тогда попытка «почистить» историю приведёт к худшим последствиям), либо git push —force , что чревато потерей данных при работе с веткой нескольких человек…
Работа с Git через консоль
Задача: форкнуть репозиторий в GitHub, создать ветку и работать с кодом.
Сразу появляется много вопросов — что такое GitHub, какие для этого нужны команды, зачем, а главное, как всем этим пользоваться? Давайте разберёмся.
Когда мы пишем код, мы постоянно туда что-то добавляем, удаляем, и иногда всё может ломаться. Поэтому перед любыми изменениями стоит сделать копию проекта. Если собирать проекты в папки с именами проект1 , проект1_финал и проект2_доделка , вы быстро запутаетесь и точно что-нибудь потеряете. Поэтому для работы с кодом используют системы контроля версий.
Система контроля версий — программа, которая хранит разные версии одного документа, позволяет переключаться между ними, вносить и отслеживать изменения. Таких систем много и все они работают по принципу компьютерной игры, где вы можете вернуться к месту сохранения, если что-то пошло не так.
Git — самая популярная система контроля версий. С Git можно работать через командную строку (или терминал). В каждой системе своя встроенная программа для работы с командной строкой. В Windows это PowerShell или cmd, а в Linux или macOS — Terminal.
Вместо встроенных программ можно использовать любую другую — например, Git Bash в Windows или iTerm2 для macOS.
Как работает терминал: мы вводим команду и получаем ответ компьютера — или всё получилось, или где-то ошибка, или нужно ввести что-то ещё — например, пароль. Поэтому большая часть этой инструкции состоит из команд для терминала. Сначала будет непривычно, но вам понравится.
Но давайте по порядку — установим Git на компьютер.
Устанавливаем и настраиваем Git
Windows. Скачайте Git для Windows, запустите exe-файл, следуйте инструкциям.
macOS. Скачайте Git для macOS и запустите dmg-файл. Если он не запускается, зайдите в Системные настройки — Безопасность и нажмите кнопку Open anyway (Всё равно открыть).
Linux. Установите Git через встроенный менеджер пакетов. Если у вас Ubuntu, используйте команду sudo apt-get install git . Команды для других дистрибутивов можно посмотреть здесь.
Как проверить, что Git установился
Откройте терминал и введите команду
Если Git установлен, то вы увидите номер версии, например, 2.35.1 .
Настраиваем Git
Теперь нужно ввести имя и адрес электронной почты, чтобы ваши действия в Git были подписаны, а ещё для привязки к GitHub.
Добавить имя (введите его внутри кавычек):
Добавить электронную почту (замените email@example.com на вашу почту):
Опция —global значит, что имя и почта будут использоваться для всех ваших действий в Git. Если вы хотите менять эту информацию для разных проектов, то вводите эти же команды, только без опции —global .
Регистрируемся на GitHub
GitHub (или Гитхаб) — веб-сервис на основе Git, который помогает совместно разрабатывать IT-проекты. На Гитхабе разработчики публикуют свой и редактируют чужой код, комментируют проекты и следят за новостями других пользователей.
Профиль на Гитхабе и все проекты в нём — ваше публичное портфолио разработчика, поэтому нужно завести профиль, если у вас его ещё нет.
- Зайдите на сайт https://github.com и нажмите кнопку Sign up.
- Введите имя пользователя (понадобится в дальнейшей работе), адрес электронной почты (такой же, как при настройке Git) и пароль.
- На почту придёт код активации — введите на сайте.
- Появится окно с выбором тарифного плана. Если вы пользуетесь Гитхабом для учёбы, то укажите, что профиль нужен только для вас и вы студент.
- Опросы и выбор интересов можно пропустить.
На этом всё — вы зарегистрировались и у вас есть собственный профиль.
Устанавливаем SSH-ключи
Чтобы получить доступ к проектам на GitHub со своего компьютера и выполнять команды без постоянного ввода пароля, нужно, чтобы сервер вас узнавал. Для этого используются SSH-ключи.
SSH — протокол для безопасного соединения между компьютерами.
SSH-ключ состоит из двух частей — открытого и закрытого ключа. Открытый ключ мы отправляем на сервер. Его можно не прятать от всех и не переживать, что кто-то его украдёт, потому что без закрытого ключа он бесполезен. А вот закрытый ключ — секретная часть, доступ к нему должен быть только у вас. Это важно.
Мы будем подключаться к GitHub по SSH. Это работает так:
- Вы отправляете какую-то информацию на GitHub, который знает ваш открытый ключ.
- GitHub по открытому ключу понимает, что вы это вы, и отправляет что-то в ответ.
- Только вы можете расшифровать этот ответ, потому что только у вас есть подходящий закрытый ключ.
А чтобы подключиться к GitHub с помощью SSH-ключа, сначала нужно его создать.
Проверяем SSH-ключи
Перед созданием нового SSH-ключа проверим, есть ли на компьютере другие ключи. Обычно они лежат в папке с названием .ssh — поэтому посмотрим, есть ли в ней что-то, с помощью команды в терминале:
Если у вас уже есть SSH-ключ, то в списке будут файлы с именами вроде id_rsa.pub , id_ecdsa.pub или id_ed25519.pub . А если терминал ругается, что директории
/.ssh не существует, значит, у вас нет SSH-ключей. Давайте это исправим.
Создаём новый SSH-ключ
Откройте терминал и скопируйте туда эту команду. Не забудьте подставить в кавычки почту, на которую вы регистрировались на Гитхабе.
ed25519 — это алгоритм для генерации ключей. Если ваша система не поддерживает алгоритм ed25519 (и вы увидели ошибку), используйте немного другую команду с алгоритмом rsa :
Терминал спросит, куда сохранить ключ. Если не хотите менять имя файла, которое предлагает терминал, просто нажмите Enter.
Теперь нужно добавить пароль, которым будет зашифрован ваш ключ. Это стоит сделать, иначе в дальнейшем могут быть проблемы с настройкой, да и так просто безопаснее.
В результате создаётся новый SSH-ключ, привязанный к вашей электронной почте.
Создание ключа по шагам:
Добавляем SSH-ключ в ssh-agent
ssh-agent — программа для хранения и управления SSH-ключами. Давайте запустим её и добавим туда наш SSH-ключ. Запускаем командой eval «$(ssh-agent -s)» :
Если в ответ терминал покажет надпись «Agent pid» и число — значит, всё ок, агент запущен.
Теперь добавим наш ключ командой.
Если у вашего ключа другое имя, замените название id_ed25519 именем файла с ключом (это правило применяется и дальше в инструкции). Если вы устанавливали пароль на ключ, введите его два раза после ввода команды ssh-add (терминал подскажет, когда это сделать).
Теперь, если всё хорошо, появится надпись Identity added — значит, можно переходить к добавлению ключа на GitHub.
Копируем SSH-ключ
Чтобы добавить ключ на GitHub, нужно сначала его скопировать из вашего файла командой clip . Вы не увидите ключ на экране, но он появится в буфере обмена, и его можно будет вставить на Гитхаб.
Команда clip может не сработать на вашем компьютере, тогда есть два способа узнать ключ — простой и сложный.
Сложный способ. Найдите скрытую папку .ssh , откройте файл id_ed25519.pub в текстовом редакторе и скопируйте его содержимое.
Простой способ. Введите команду ниже и ключ появится прямо в терминале — его нужно вручную скопировать в буфер обмена. Ключ начинается с ssh-ed22519 или ssh-rsa (или похожей строки) — поэтому копируйте строку прямо с самого начала.
Не копируйте этот ключ из статьи — он уже не работает.
Добавляем SSH-ключ на GitHub
Это нужно сделать, чтобы GitHub вас узнавал.
Перейдите на страницу для работы с ключами в вашем профиле на GitHub и нажмите кнопку New SSH key.
В поле Title нужно добавить название нового ключа. Например, если вы используете Mac, вы можете назвать ключ MacBook Air, или, если ключ для курсов Академии, то Academy. А ключ, который вы скопировали на прошлом шаге, вставьте в поле Key.
Не копируйте ключ со скриншота — он уже не работает.
Теперь нажмите кнопку Add SSH key и, если потребуется, введите свой пароль от GitHub, чтобы подтвердить сохранение. Если всё сделано верно, новый ключ появится в списке на странице https://github.com/settings/keys.
Теперь мы можем поработать с проектом в репозитории.
Что такое репозиторий
Репозиторий — папка с файлами вашего проекта на сервере GitHub. Так вы можете работать с проектом откуда угодно, не переживая, что какие-то файлы потеряются — все данные останутся в репозитории.
Если над проектом работает несколько программистов, сначала создаётся мастер-репозиторий — это общий репозиторий с рабочей версией проекта. А каждый программист работает с форком — то есть полной копией мастер-репозитория. В форке вы можете безнаказанно менять код и не бояться что-то сломать в основной версии проекта.
Делаем форк мастер-репозитория
Заходим в нужный репозиторий и нажимаем на «вилку» с надписью fork.
Появится окно Create a new fork — проверьте, что он называется так, как вам нужно, и жмите кнопку Create fork. Через пару секунд всё готово.
Клонируем форк на компьютер — git clone
Клонировать форк — значит скачать его, чтобы работать с кодом на своём компьютере. Тут нам и пригодится SSH.
Открываем терминал и переходим в папку с будущим проектом — для этого используем команду cd your-project . Если вы хотите, чтобы проект лежал в папке device , введите
Если такой папки на компьютере нет, то сначала введите md your-project , чтобы создать эту папку, а затем cd your-project . Подробнее о командах.
Когда перейдёте в папку, введите команду git clone для клонирования репозитория:
Замените your-nickname на ваше имя пользователя на GitHub, а your-project — на название проекта. Проще всего их найти прямо наверху страницы репозитория.
Если вы правильно настроили SSH-ключи, Git скопирует репозиторий на ваш компьютер.
Если вы видите ошибку Error: Permission denied (publickey) , скорее всего, вы ошиблись в настройке SSH-ключа. Вернитесь в этот раздел инструкции и повторите процесс настройки.
Кстати, если вы хотите, чтобы название папки с проектом у вас на компьютере отличалось от имени репозитория, можете дополнить команду клонирования, добавив в конце другое название:
Теперь на вашем компьютере в папке your_project или в той, название которой вы указали, находится полная копия репозитория c GitHub.
В каждом репозитории есть как минимум одна основная ветка, которую создаёт сам Git — она называется master . Обычно в ней хранят проверенную версию программы без ошибок.
А если вы хотите исправить ошибку в коде или добавить что-то в проект, но не хотите сломать код в основной ветке, нужно создать новую ветку из master и работать из неё. Каждая ветка — что-то вроде второстепенной дороги, которая затем снова соединится с основной.
Создаём новую ветку
git branch
Откройте терминал и введите команду
Она показывает список веток, с которыми мы работаем в проекте, и выделяет текущую. Если мы находимся в master , то создаём новую ветку командой
Если текущая ветка не master , переключитесь на неё с помощью команды checkout . После git checkout надо указать название нужной ветки.
Мы делаем это, чтобы новая ветка содержала свежую рабочую версию проекта. Если вы ошиблись в названии, например, допустили опечатку, вы можете изменить название ветки с помощью команды:
Сохраняем изменения — git add
После того, как вы создали ветку и поработали в ней у себя на компьютере, нужно сохранить результат, чтобы появился в репозитории и не пропал.
Если вы хотите сохранить изменения не во всех файлах, для начала введите команду git status . Она покажет текущее состояние в вашей ветке, а именно список с названиями изменённых файлов, если они есть, и укажет на те, которые ожидают записи и сохранения (обычно они выделены красным цветом).
Чтобы сохранить все изменения разом, используйте команду
Чтобы сохранить изменения только отдельных файлов, укажите их имена вручную. Например, если вы изменили файл index.html , введите
Если название очень длинное, вы начните его писать, нажмите Tab и терминал сам предложит продолжение пути к файлу.
Делаем коммит — git commit
Сделать коммит — значит зафиксировать все сохранённые изменения и дать им название. Это делается с помощью команды commit
Текст сообщения должен быть лаконичным и вместе с этим сообщать о том, что делает коммит (внесённые изменения). Например,
- Добавляет имя наставника в Readme
- Вводит функцию сортировки изображений
- Правит ошибку в поиске городов на карте
Отправляем изменения на GitHub — git push
Сохранённые изменения пока не видны коллегам, потому что находятся в нашем локальном репозитории. Нужно отправить коммиты на GitHub. Для этого введите команду
Где origin означает репозиторий на компьютере, то есть ваш форк. Слово origin — часть команды, не меняйте это название на своё.
Создаём пулреквест
Пулреквест (или PR) — это предложение изменить код в репозитории. PR должен проверить администратор мастер-репозитория — это может быть коллега-разработчик, техлид или наставник на курсе.
Если к коду нет вопросов, пулреквест принимается. Если нужно что-то исправить — отклоняется, и придётся исправить код и снова пройти цепочку git add — git commit — git push . Если вы и дальше работаете в той же ветке, а пулреквест ещё не принят, все ваши изменения автоматически добавятся в пулреквест, созданный из этой ветки после команды git push origin название-текущей-ветки .
Чтобы создать пулреквест, зайдите на страницу вашего форка на GitHub. Вверху появилась плашка Compare & pull request, а ещё можно зайти на вкладку Pull Requests.
Нажмите на неё и окажетесь на странице открытия пулреквеста. Проверьте описание и нажмите Create pull request.
Готово, теперь ждём остаётся ждать одобрения пулреквеста или комментариев к нему.
Синхронизируем репозитории
Предположим, вы исправили код, руководитель или наставник одобрил ваши правки и принял пулреквест.
Теперь код в мастер-репозитории обновился, а в вашем форке нет, вы ведь не обновляли свою версию репозитория с тех пор, как клонировали её себе на компьютер. Приведём форк в актуальное состояние.
В локальном репозитории переключаемся на ветку master .
Забираем изменения из ветки master мастер-репозитория
Отправляем изменения уже из своей ветки master в ваш форк на GitHub с помощью команды
Готово, теперь форк и оригинальный репозиторий находятся в актуальном состоянии.
Словарик
Система контроля версий — программа, которая хранит разные версии одного документа, позволяет переключаться между ними, вносить и отслеживать изменения.
Git — самая популярная система контроля версий. С Git можно работать через терминал.
Как работает терминал: мы вводим команду и получаем ответ компьютера — или всё получилось, или где-то ошибка, или нужно ввести что-то ещё.
GitHub (или Гитхаб) — веб-сервис, основанный на Git, который помогает совместно разрабатывать IT-проекты. На Гитхабе разработчики публикуют свой и редактируют чужой код, комментируют проекты и следят за новостями других пользователей.
SSH-ключ нужен, чтобы получить доступ к проектам на GitHub со своего компьютера и выполнять команды без постоянного ввода пароля, нужно, чтобы сервер нас узнавал.
ssh-agent — программа для хранения и управления SSH-ключами.
Репозиторий — папка с файлами вашего проекта на сервере GitHub или у вас на компьютере.
Мастер-репозиторий— это общий для всей команды репозиторий с рабочей версией проекта.
Форк — полная копия мастер-репозитория, в которой вы можете безопасно работать.
Клонировать форк — скачать его командой git clone , чтобы работать с кодом на своём компьютере.
Пулреквест (или PR) — предложение изменить код в репозитории. PR должен проверить администратор мастер-репозитория — это может быть коллега-разработчик, техлид или наставник на курсе.