Github — без командной строки


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

    Многие опытные пользователи github-а знают, что отнюдь не для всего обязательно нужно использовать командную строку. Все это так.

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


    Думаю с созданием форка (копированием репозитория к себе) — все легко справятся, поэтому сразу идем дальше.

    Создание ветки


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

    Создать новую ветку (копированием из текущей) можно прямо в окошке смены ветки. Вводим имя — enter — готово.



    Добавление файлов


    Создание новых файлов здесь же — далеко ходить не нужно. Жмем "+"

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

    Здесь можно отредактировать как сам файл, так и его имя. В редактировании имени есть одна интересная особенность — используя '/' и '../' можно перемещаться по дереву каталогов. (в итоге, при создании файла, заодно будут созданы, не существовавшие до этого папки)


    Синхронизация форка с основным репозиторием


    Часто бывает так, мы делаем форк репозитория, правим там что-то, делаем pull-request. Автор принимает этот pull-request и мы успокаиваемся на некоторое время. Через пару месяцев, мы вновь хотим что-то улучшить, но наша копия уже безнадежно устарела. Здесь требуется синхронизация. Легко можно найти как это сделать, используя командную строку. Намного реже встречается объяснение того, как это сделать непосредственно на github.

    Итак:
    • открываем свой форк на github
    • заходим с список его pull-request-ов
    • жмем «New Pull Request», по умолчанию github берет за базу оригинальный репозиторий и сравнивает наш с ним, но нам нужно наоборот
    • жмем «switching the base», (если мы что-то редактировали в своей копии, нужно нажать Edit, и вручную поменять базу) — сразу же увидим все, что в оригинальном репозитории было добавлено в последнее время
    • жмем «Создать Pull-request», даем ему какое-нибудь понятное имя, типа «Update from original»
    • жмем «Send pull request»
    • жмем «Merge pull request» и подтверждаем это действие — все

    Столько пунктов, скажите вы — согласен, в виде списка выглядит громоздко, попробуйте видео — всего 53 секунды. Я сам, попробовав всего раз, сразу же запомнил и стал использовать.

    P.S.
    Я не стал здесь описывать очевидные вещи: как сделать форк, как сделать pull-request — так как они делаются в 1 клик.

    А что еще из неочевидного можно делать с репами без использовани командной строки?
    Поделиться публикацией

    Комментарии 33

      +41
      Серьезно, не понимаю, как разработчика может напугать командная строка. В ней же быстрее работать даже! Разработчик, разрабатывая, годами тренирует навык печати, как может так быть, что после этого искать кнопки, кликать мышкой и ждать, когда браузер соизволить открыть что бы то ни было получается быстрее?
        +7
        Если вы про браузер именно, то согласен, но вот про консоль в целом не совсем. Мне лично в SourceTree от Atlassian куда проще/быстрее работать с git'ом, чем в консоли возиться (хотя тут тоже только по кнопочкам жать надо, как правило).
          +1
          Консоль позволяет работать без смены контекста. Вот сижу я в Emacs и пишу код, надо посмотреть коммиты или закоммитить что-то — открыл shell прямо внутри редактора и получил все нужные сведения. Не нравится консоль и не хочется изучать многообразие команд и флагов — используешь какой-нибудь пакет к редактору, упрощающую работу с Git.
            +1
            есть проблема в source tree. это GUI ограничено и реализует только ~~~10% функциональности VCS. хотя, для большинства, этого достаточно.
              +7
              После того как я проникся SourceTree, необходимость в использовании гита из консоли практически пропала, иногда конечно бывают случаи, что что-то там сделать сложно или неудобно, но я никогда не пойму людей, которые утверждают что им из консоли смотреть диф и вмердживать отдельные правки удобнее (а такие есть)
                +1
                Sourcetree умеет git add --patch и git rebase --interactive?
                  0
                  Интерактивный ребейз вроде бы умеет. Но лично мне в IntelliJ IDEA он мне нравится гораздо больше.
                    0
                    Посмотрел в идее. На мой взгляд он ужасен. То же, что в консоли, но требует кучу кликов мышкой (в отличии от чуть меньшего количества нажатий клавиш при использовании EDITOR=vim).

                    Потом ещё раз гляну, как идея справляется с конфликтами при мерже, вдруг что-нибудь изменилось. До этого маркеры 3way merge воспринимались как синтаксическая ошибка, никакого assist'а по ним не было (приходилось смотреть диффы к конкретным маркерам в консоли, как обычно).
                      0
                      Мне в идее больше всего нравится как раз работа с конфликтами. В идее самый удобный three-way-merge с которым я когда-либо работал (плюс ещё интеграция с подсветкой/анализами для кода).
                        0
                        Он запускается только при rebase из самой идеи? Или при наличии конфликтов его можно запустить так?
                          +1
                          Нет, насколько я понимаю, он универсальный и появляется если в репозитории есть конфликты:
                          Скрытый текст


                          Ну и при мёржах он автоматически вызывается.
                            +1
                            Спасибо, поэкспериментирую. В принципе, меня пока спасают vim и git mergetool, вызывающий meld или kdiff3, но почему бы и не посмотреть на потенциально более удобную тулзу =)
              +2
              Ну не знаю. Всякое бывает, я вот часто не на рабочем месте просматриваю репы. Ничего не настроено, но почему бы не сделать что-нибудь полезное в несколько кликов.
                +6
                Не всегда в ней быстрее. Ну а использовать консоль ради консоли смысла не вижу. Некоторые задачи намного удобней выполнять в GUI, тоже самое и про консоль можно сказать.
                  +2
                  Git gui это хорошо, но постоянно делают его неправильно.

                  Вот есть какая-то кнопка. Uncommit к примеру. И вот что она сделает?
                  Если бы разработчики добавили к каждой «волшебной» кнопке список git команд которые эта кнопка применит то будет дело.
                  А так минное поле.
                  +7
                  Навык печати не при чем. Дело в знании команд и их многочисленных параметров.
                  Если знаешь их наизусть (=используешь постоянно), то комстрока действительно часто быстрее.
                  Если нужно лезть в документацию и долго там разбираться (не потому что дурак, а просто именно этот продукт я не использую в повседневности) — долго, муторно, да и неохота.
                    0
                    Консоль нужна. Хотя у нас есть люди, которые сразу подсаживаются на SourceTree (и это плохо) — его хватает в 95% случаев и многие штатные вещи в нем, действительно, быстрее чем в консоли делать (например, подготовить выкладку новой версии и массово слить изменения с веток фитч — перед глазами сразу и схема и дельта и оценка).
                    Когда надо слить одну ветку или отрастить — то тут такого приимущества нет — я консоль использую. Понимание консоли важно, в том числе и на сервере — там без нее уже никак.
                    GUI не тупиковая ветвь. ST — хорош, правда в последнем релизе под винду накосячили они много (
                    +4
                    К сожалению таким образом можно делать правки только в одном файле на коммит.
                    Ну и конечно стоит упомянуть о hub
                      +1
                      Консоль и возможности гитхаба в браузере — разные инструменты, для разных целей и ситуаций.
                        –9
                        Мои поздравления, господа, вы изобрели GUI.
                          +5
                          В основном опечатки так отсылаю в репозитории.
                            +3
                            Правки в документации (более-менее мелкие) тоже удобно делать =)
                            0
                            Картинки через веб-интерфейс можно залить?
                              0
                              Похоже что нет.
                              0
                              Синхронизировал форк описанным способом, через браузер. Теперь в моём форке красуется коммит «Merge pull request», в оригинале его нет. О fast-forward, видимо, github не слышал. Ну нафиг ваши интерфейсы, консоль наше всё.
                                0
                                Я так и думал, что есть подвох. Далеко не всё в Git можно сделать через графический интерфейс. Иногда что-то сделать можно, но результат будет странным.

                                В частности, поэтому некоторые люди и не принимают pull-request через Github и не делают коммитов через UI.
                                  0
                                  Ну принимать пулреквесты из других репозиториев через интерфейс можно, там всё-равно нельзя сделать fast-forward. В моём же случае форки были 2 недели назад синхронизированы, и изменений я не делал, а появился лишний коммит. Ну и гуй я использую в одном случае — индексация части изменений, если их много было сделано, то мышкой быстро натыкать мне удобнее.
                                    0
                                    Я не вам пытался донести мысль, а автору поста. Извиняюсь за двусмысленность.

                                    GUI в git бывает удобен, потому и существуют всяческие tig/gitk/Github. Непосредственно для commit/merge/pull использовать командную строку разумнее.
                                +1
                                Еще удобно нажимать «T» в корне GitHub репозитория, чтобы поискать файл по его имени.
                                  –1
                                  Для обыденных действий консольные команды уже в подкорке сидят и набираются автоматом. С учетом того, что я пользователь линукса (соглашусь, что пользователям windows консоль менее удобна — в плане, что ее открыть, по крайней мере, еще надо), мне проще нажать хоткей, чтобы вылез эмулятор терминала (тем более, что он и так открыт — сборка и тестирование проекта осуществляется из консоли же). Для оставшихся действий веб интерфейс едва ли чем нибудь поможет. Открывал как gitk, но у меня там глаза разбежались тут же =)

                                  Файлы редактировать через веб интерфейс тоже, как мне кажется, не очень удобно — потом нужно будет идти в локальный репозиторий и синхронизировать изменения.
                                    +1
                                    Я, наверное, какой-то неправильный программист.

                                    Когда помогаю коллеге на работе с Гитом на Windows, то всегда запускаю Git Shell и перепроверяю всё, что вижу в GH4Win командами, потому что есть много файлов, которые коммитить нельзя, а GUI как-то .gitignore еще плохо освоил (от слова «никак»)

                                    На j4f проектах (домашняя система – OSX) всё пытаюсь переехать с консоли на GUI (GH4Mac, SourceTree как-то не зашёл, еще посматриваю на Tower), ибо банально забодало: слишком много телодвижений при постоянных маленьких коммитах + некоторые вещи в GUI (просмотр диффов, например) намного проще и приятнее.
                                      0
                                      Я, по видимому, тоже неправильный программист.
                                      Я пишу код на виртуальной машине с Linux, где SourceTree и GitHub клиентов пока не ожидается. Так что большинство операций делаю через консоль, хотя перед этим на хостовой системе (Mac OS) в SourceTree смотрю что пойдёт в коммит.
                                      +2
                                      Хм. Использую один алиас для быстрого создания Пулл Реквестов (особенно если работаешь на форке). Может кому пригодиться:

                                      При открытии гитхаба в браузере и переходе на ваш feature-branch, URL гитхаба будет выглядеть примерно так:
                                      https://github.com/{orgname}/{reponame}/tree/{featurebranch}
                                      Если его немного видоизменить до ( tree/ на compare/{sourcebranch}...):
                                      https://github.com/{orgname}/{reponame}/compare/{sourcebranch}...{featurebranch}
                                      То вы сразу перейдёте на страницу создания нужного вам ПР (с правильными ветками!)

                                      Это дико удобно если ваш феатуре бранч нужно мерджить более чем на 1 ветку (у меня часто по 3 ПР на разные ветки в 5+ репозиториях. Экономит время очень заметно)

                                      Ещё круче сделать алиас для консольной команды. Например используя:
                                      xdg-open https://github.com/${org_name}/${repo_name}/compare/${arg_source_branch}...${current_feature_branch}

                                      UDP:
                                      ПР между форками выглядит примерно так:
                                      https://github.com/${org_name}/${repo_name}/compare/${arg_source_repo_name}:${arg_source_branch}...${current_repo_name}:${current_feature_branch}

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

                                      Самое читаемое