-
Notifications
You must be signed in to change notification settings - Fork 116
Работа с Git для нетехнарей с помощью GitHub Desktop
Перед началом работы, обязательно зарегистрируйтесь на GitHub
В данном руководстве я буду называть GitHub Desktop "программа" или "клиент".
Качаем программу с официального сайта https://desktop.github.com/
Возможно, потребуется VPN.
Устанавливаем.
Клиент сразу запустится и вы увидите что-то такое:
Форк - отдельная копия репозитория, которая будет привязана к вашему аккаунту. Она необходима, так как у вас нет прав вносить изменения в основной репозиотрий. Для того, чтобы внести изменения, вы будете их "предлагать" - создавать "pull request", в котором будет видно, какие изменения вы внесли. Стоит уточнить, что fork'и и Pull request'ы - фишка GitHub, а не git.
Для создания форка, перейдите на главну страницу этого репозитория и нажмите кнопку Fork, следуйте инструкции.
На вашем аккаунте должна появиться копия данного репозитория, выглядит это примерно так:
Обратите внимание, что тут же указано, из какого репозитория сделан форк.
Аналог команды git clone
Теперь нам надо скачать содержимоей репозитория. Для этого заходим в GitHub Desktop и нажимаем Clone Repository from the Internet...
Тут же нам предложат подключить аккаунт
Выбираем подключение через браузер
У меня открылся Google Chrome и сразу предлагает отратно открыть приложение. Соглашаемся
Откроется окно со списком репозиториев на вашем аккаунте. Будут перечисленны как публичные, так и приватные репозитории. Находим форк перевода и нажимаем Clone
После непродолжительного процесса скачивания программа поймёт, что вы склонировали не просто репозитория, а форк от другого репозитория, и спросит вас, как вы планируете работать с этим репозиторием: вносить изменения в главный репозиторий или работать только со своей копией. Выбираем первый пункт и программа будет нам помогать выполнять некоторые шаги без необходимости заходить на GitHub.
Теперь ваш клиент выглядит вот так:
Под надписью No local changes
есть 3 панельки:
- Открыть папку с репозиторием в Visual Studio Code
- Открыть папку с репозиторием в Проводнике
- Открыть репозиторий на GitHub (откроется ссылка на главный репозиторий, а не на ваш форк)
Возможно, у вас на интерфейсе будет ещё такая панелька:
Игнорируйте её, она со временем пропадёт, когда программа поймёт, что вы ещё не вносили никаких изменений в главный репозиторий.
СОВЕТ: если хотите поменять на первой панельке редактор, с помощью которого будет открываться репозиторий, можете нажать на ссылку в надписи
Select your editor in Options
или зайти в настройки File -> Options -> Integrations -> External Editor, и выбрать, например, Notepad++, для которого в этой вики описаны полезные плагины (но с Notepad++ интеграция работает плохо: вместо того, чтобы открыть папку "как проект", от откроет все файлы репозитория в отдельных вкладках).
Тут я создал искусственный пример, на котором опишу, как выглядят основные элементы интерфейса после внесения изменений, но ДО создания коммита.
- Текущий репозиторий. Тут можно переключаться между другими вашими существущими репозиториями, скачать или создать новый.
- Вкладка Changes, которая переключает в режим просмотра внесённых изменений. Это основная вкладка, в которой вы будете работать.
- Вкладка History, в которой можно посмотреть историю коммитов или сравнить 2 ветки. Сюда вряд ли когда-либо понадобится заходить.
- Список изменённых файлов. Обращаем внимание на значок, который стоит после имени файла:
- красный - удалённый файл
- зелёный - добавленный файл
- жёлтый - изменённый файл
Тут же можно снять галочки с файлов, которые вы не хотите сохранять в коммит.
СОВЕТ: если хотите отменить все изменения в файле, нажмите на нём правой кнопкой мыши и выберите
Discard changes...
- Текст коммита, краткое описание, которое будет отображаться в истории.
- Описание коммита. Тут можно вводить большое описание, но обычно мы этим не пользуется, так что оставляем пустым.
- Кнопка создания коммита. После её нажатия все изменения буду сохранены и список изменённых файло станет пустым.
- Текущая ветка. Тут можно увидеть, в какую ветку будет создан коммит, а при нажатии можно создать новую или выбрать существующую ветку. Здесь вы будете в основном создавать новые ветки и возвращаться в master ветку.
- Эта кнопка позволяет отправить все внесённые изменения на GitHub (но только после создания коммита)
- Интерфейс сравнения между тем, что было и что добавлось в выбранный на панели 4 файл. Видно, какие строки удалены, а какие добавлены.
Обратите внимание, что строка 75 как-будто была удалена и добавлена та же самая, но на самом деле из-за добаления символа переноса строки считается, что это совсем другая строка. Для более удобного просмотра изменений, совутую использовать более продвинутые инструменты, например Meld.
Аналог команды git branch
ВНИМАНИЕ: Перед созданием ветки, убедитесь, что ваша текущая ветка - master
и вы подтянули все изменения из основного репозитория (см. раздел Подгрузка изменений).
После того, как вы решили, что будете переводить (обычно это организовано так, что вам дадут каонтерную задачу из этого списка ), вам нужно создать отдельную ветку, в которой вы будете работать. Ветка - это последовательность коммитов (изменений), которые вы будете вносить в репозиоторий. Ветки существуют, чтобы работа нескольких человек не мешала друг другу.
Для создания новой ветки, нажмите на кнопку 8 (см. скриншот в разделе Элементы интерфейса), а затем кнопку New Branch
.
Вводим в поле имя новой ветки и жмём кнопку Create Branch
.
В центральной панели появится такая панелька
Пока что игнорируйте её. Она говорит о том, что ветка создана локально на компьютере, а на GitHub вы её ещё не отправляли. А так как вы ещё не вносили никаких изменений в перевод, то нет необходимости ничего отправлять.
Теперь можете свободно менять любые файлы.
Аналог команды git commit
После того, как вы внесли изменения, вам нужно их сохранить и отправить на GitHub. Для этого создаются "коммиты". Можете воспринимать коммит как "точку сохранения" в играх: у него также есть состояние, время создания и имя. рекомендуется создавать несколько коммитов в рамках одной ветки, чтобы в каждом коммите было немного изменений. Обычно в рамках одного коммита меняется один файл или вносится один тип исправлений в нескольких файлах. Ну или, если изменение очень глобальное, просто делайте один коммите каждый раз, когда на сегодняшний день прекращаете работу.
Для создания коммита введите краткое описание изменений в поле 5 и нажмите кнопку 7 (см. скриншот в разделе Элементы интерфейса).
После первого коммита в ветке теперь имеет смысл нажать на кнопку Publish branch
на центральной панели. Это отправит на GitHub информацию о создании новой ветки и о коммите, сделанном в нём.
После этого на центральной панели появится кнопка Preview Pull Request
, но пока игнорируйте её, мы вернёмся к ней в разделе Создание Pull Request.
Теперь у вас 2 возможных пути дальнейших действий:
- продолжить вносить новые изменения и новые коммиты в текущей ветке
- предложить изменения на проверку (Pull request)
Если вы сделаете ещё коммит, то он не сразу попададёт на GitHub, его ещё нужно отправить на GitHub (аналог команды git push
).
Об этом вас предупредит кнопка Push origin
на центральной панели
Просто нажмите эту кнопку и изменения появятся в вашем форке на GitHub.
Если настала пора отправлять ваши изменения на проврку, то нужно на центральной панели нажать на кнопку Preview Pull Request
.
Откроется окно пре просмотра предлагаемых изменений.
После того, как убедились, что во вносимых изменениях всё нормально, нажмите на кнопку Create Pull Request
. В браузрере отероется страница создания Pull requets'а.
Тут вы можете изменить его название и описание. Обратите внимание, что в название Pull Request'а можно ввести вначале номер issue (со страницы задач), над которой вы работаете в формате #<НОМЕР>
. Это поможет тем, что потом на странице реквеста будет ссылка на issue, а на сранице issue будет информация о созданном реквесте.
Нажимаете на кнопку Create Pull Request
и получаете страницу с вашими изменениями. Скидывайте ссылку на эту страницу с просьбой проверить в чат в телеграмме и ждите комментариев.
На этой странице есть следующие разедлы:
- Conversation - обсуждение изменений. Тут будут отображаться все комментарии
- Commits - просто список ваших коммитов. Этот раздел редко нужен.
- Checks - тут проверки, делаемые GitHub, и у нас их нет.
- Files changed - самый интересный раздел, где каждый участник может на любую строку оставить коментарий и даже предложить свои изменения.
После получения комментарием вам может понадобится внести новые исправления. Для этого выполняйте все обычные действия как раньше:
- вносите локально нужные изменения
- создавайте в этой ветке новый коммит
- жмите
Push origin
и все изменения сразу появятся в этои же Pull request'е. То есть, пока Pull Resuest не закрыли, он будет в себя включать все новые коммиты из ветки, из которой создан.
Если в комментариях вам предложили внести конкретные изменения, то вы увидите в разеделе Conversation комментарий вот с таким интерфейсом.
Если согластны с предлагаемыми изменениями, то нажмите кнопку Commit Suggestion
, введите текст коммита и эти изменения попадут в вашу ветку.
Или напишите, почему эти изменения не подходят, ответив в обсуждении (поле Reply...
).
Если вы согласились с изменениями и создали на их основе коммит, то вам нужно, чтобы эти изменения попали к вам на локально. Для этого в приложении в заголовке нажмите кнопку Fetch origin
(чтобы клиент узнал о наличии изменений на сервере) и вы увидите вот такую панельку
в которой говорится, что существует 1 коммит, которого у вас нет локально. Теперь просто нажмите кнопку Pull origin
, и все изменения попадут к вам.
Постарайтесь избегать ситуаций, когда локально сделали коммит, но не нажали Push origin
, и при этом параллельно на GitHub применили изменения. Тогда, при попытке сделать Push origin
локальных изменений у вас сможет случиться "конфликт изменений".
Сначала вас предупредят, что есть изменения, которых нет локально:
Просто жмите Fetch
. Потом появится панелька с кнопкой Pull origin
, жмите её.
Если изменения делались в разных файлах или строках, то приложение само предложит способ объединения всех изменений и в большинстве случаев оно нормальное. Просто жмите в появившемся окне Continue merge
, а затем на центральное пенели Push origin
.
Но в случае, когда изменения были сделаны в одной и той же строке, придётся заниматься ручным решением конфликтов, и вы получите такое сообщение:
Нажмите на кнопку открытия вашего редактора и найлите конфликтное место. Оно выглидт примерно так:
Вам покажут изменения из обоих коммитов:
- между
<<<<<<< HEAD
и=======
- между
=======
и>>>>>>> <COMMIT HASH>
Вам нужно будет решить, что должно быть на месте этой строки (например, оставить только версию из одного коммита, либо объединить оба изменения). Отредактируйте её, удалив все строки с <<<<<<<
, =======
и >>>>>>>
, то есть файл должен быть в таком состоянии, какое вы хотите получить по итогу без всяких лишних строк.
После того, как вы отредактируете и сохраните файл, в приложении сообщение с описанием конфликта заменится на такое:
Нажмите Continue merge
, а затем Push origin
.
Когда ваши изменения внесут в главный репозиторий (или там появятся изменения от другого человека), то ваш форк станет отличаться.
Если на главной странице вашего репозитория в заголовке над списком файлов появилсь надпись This branch is N commits behind...
, то это значит ваш репозиторий отстаёт на несколько коммитов от основного.
Нажмите на кнопку Sync fork
, затем на Update branch
, чтобы подтянуть изменения в ваш репозиорий. В клиенте нужно будет нажать кнопку Fetch origin
и на панельке в середине Pull origin
, и тогда все изменения появятся локально.