Pull to refresh

Comments 33

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

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


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

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

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

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

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

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

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

При открытии гитхаба в браузере и переходе на ваш 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}
Only those users with full accounts are able to leave comments. Log in, please.