GUI для Git: подборка популярных решений

Поддерживаю про Git Extensions. Как 15 лет назад начал пользоваться, так и продолжаю. Пробовал другие клиенты, но по функциональности с ним может сравниться только Kraken. Но он платный, а Extensions нет :)
Из серьезных минусов:

• windows only. Так что на маке приходится крутиться с Soutcetree

• нет темной темы оформления :) они в какой-то версии её выкатили, но она была кривая-косая и они ее откатили

логичный вопрос - нужны ли автосгенерированные файлы в репозитории?

обычно такие директории сразу уходят в gitignore

Мне казалось ровно наоборот – цепочки удобнее в консоли (автоматизация), а в гуе отдельные действия, где нет команды на кончиках пальцев и надо повтыкать в экран.

Или я неправильно понял смысл слова "цепочка"?

Ой, а знаете чё скажу? Нет лучшего инструмента. Мне приходится пользоваться разными GUI и консольным гитом (в том числе и fugitive для vim). Звучит фигово, но деваться не куда(. А тут споры о том, кто каким одним функционалом одной проги пользуется, которого нет в другой проге.

В обычной ситуации я буду делать либо `git diff` без аргументов (показывает все изменения, кроме новых файлов), либо `git add -p` (смотреть изменения по кускам и сразу решать, что добавлять в индекс, а что нет).

В сложной ситуации я тоже вызову гуй (обычно это gitk, который есть везде) и попытаюсь разобраться в картине в целом.

Ваш вопрос очень хорош тем, что он подсказывает, где именно могут лежать источники расхождений между любителями cli и любителями gui. Возможно, что дело в частоте, объёме и сложности просматриваемых изменений. Я давно привык уже делать собственные коммиты максимально часто (даже после самых простых изменений). Подавляющую часть времени я сижу с "чистым статусом", а когда ситуация меняется, то новые изменения либо добавляются в коммит, либо целиком отбрасываются. Последствия этой тактики такие:

1. Вызывать какой-либо gui на такое частое действие (временами вплоть до нескольких раз в минуту) начинает быстро надоедать. Пока программа запустится, пока отрисует ситуацию, пока голова разбертёся в этой картине, пройдёт заметно много времени.

2. С другой стороны, команды в cli можно набивать молниеносно быстро (привычки пальцев + алиасы по вкусу), а отсмотреть и отрешать сравнительно небольшой объём достаточно однородных изменений нетрудно.

3. Частые повторы позволяют закрепить привычку работать через cli. Формируется мышечная память и укрепляются маршруты в голове ("в такой-то ситуации используем такую команду").

4. Со временем это приводит к тому, что даже большие коммиты (например, чужие) становится удобнее изучать через cli (на деле, часто через cli и редактор одновременно). Гуёвые программы почти перестают использоваться.

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

Я в вскоде пробовал ребейз через гуй сделать, всё сломалось) Пришлось в консоли.

при работе по ssh лично мне нужно 3 команды hg pull -u hg checkout branch_nme hg update. работать с репой на сервере плохая идея. обычно там токены только для чтения реп а не записи. но при необходимости нужные команды гуглятся. с гуи вход легче. новичку проще понять что надо делать когда перед глазами есть вся история. с командами это гораздо тружнее. Когда уже есть понимание работы то загуглить как в гите смерджить ветки например уже горахдо легче. особенно если догадатся предварительно поэксперементировать на копии репы и результат контролировать через тот же гуи.

Я юзаю второй вариант, а места где он не сработал подсвечивают запахи на исправление.

Да, я неправильно понял задачу, наверное из-за того, что мне ни разу в жизни не приходилось объединять два последних коммита и даже сложно представить, зачем это может понадобиться. А вот amend – регулярно =D.

хеш_коммита_который_ещё_надо_найти

Вроде речь идёт о двух последних коммитах и искать ничего не надо, не?
git log -2 – или я опять что-то неправильно понял?

Я давно так не смеялся.

RTFM

(c) тот, кто этот самый FM даже не открывал.

Annotated tags are meant for release while lightweight tags are meant for private or temporary object labels. For this reason, some git commands for naming objects (like git describe) will ignore lightweight tags by default.

Hidden text

Это результат следующего:

$ git tag lightweight_tag
$ git tag annotated_tag -a -m "Added annotated tag"

Теперь фокус: что в этой единственной отсылке к annotated tag рассказывает о том, в чём именно состоит эта разница? Ах да:

git describe:
    --tags                use any tag, even unannotated

$ git describe --tags
annotated_tag

Верни собаку, и едем дальше. Черри-пик.

--ff

If the current HEAD is the same as the parent of the cherry-pick’ed commit, then a fast forward to this commit will be performed.

--strategy=

Use the given merge strategy. Should only be used once. See the MERGE STRATEGIES section in git-merge[1] for details.

-X

--strategy-option=

Pass the merge strategy-specific option through to the merge strategy. See git-merge[1] for details.

Ничего не наводит на мысль, что что-то здесь прям слишком сильно торчат уши мержа? Что эта документация нам дала, кроме путаницы?

@KvanTTT

В любом случае, это запоминается за пару раз и больше такой вопрос не возникает.

Если работа в том и состоит, что откусывать, то да, запоминается. А когда это раз в 5 лет надо -- не запоминается. Более того, а английском языке reset, rollback и revert имеют очень разную смысловую нагрузку. Это в русском "откатить" (новояз) или там "сбросить", "отменить". Reset -- крайне неинтуитивный термин для операции записи истории коммитов (а вот с текущим деревом очень даже подходит). Одна и та же команда reset в гите может:

• изменить историю

• сбросить дерево каталогов проекта до состояния, указанного по номеру коммита и/или имени ветки/тега, но не меняя историю

Это очень логично, да. Запоминается сходу.

Вас никто не заставляет их использовать

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

@zloddey

Судя по тому, что Вы постоянно сравниваете "неправильный" git с "правильным" hg, мы имеем место именно с неподходящей моделью

Не надо пытаться подменить обсуждаемую тему тем, чем она не является. По крайней мере, для всех DVCS домен один и тот же. И модель одна и та же: история изменений в дереве каталогов. Просто Торвальдс прикрутил к этой модели интерфейс, пользователь которого в его картине мира является разработчиком git, а потому может по имени git-команды сразу сообразить, какие файлы и каким образом будут изменены в .git. Тогда как разработчики, например, SVN и Mercurial интерфейс пользователя предоставляют такой, который предполагает, что пользователь в том же самом домене и в той же самой модели командует "что я хочу сделать", а что, как и чем поменять в бинарных файлах самой DVCS пользователя не грузят, для этого есть Developer Guide. Как бы это понятнее объяснить...

# Healthy DVCS way
class User:
  def publish_article(self, article):
    article_obj = Article.create(**article)
    ArticleUser.link(article_obj.id, self.id)


# Smoker GIT way
class ArticleUser:
  def create_article_user_link(article, user):
    db.insert(ArticleUser, article.id, user.id)


class Article:
  def create(**kwargs): ...

Вот в первом случае DVCS здорового человека предоставляет простой и понятный интерфейс для пользователя. Который просто хочет опубликовать статью. Вся внутренняя кухня оборачивается предоставленным методом интерфейса, пользователю не надо беспокоиться, что там на самом деле получается.

Во втором случае у нас GIT, где пользователь должен точно знать: тут мы создадим объект статьи, там мы должны не забыть дёрнуть метод связывания (иначе статья останется висеть "ничья"). Ну, вы же тут все с кучей кармы, имеете публикации. Вот представьте, что на Хабре надо вместо нажатия кнопки "Опубликовать статью", надо угадать правильно одну из кнопок "Записать в таблицу связей published_objects", "Записать в таблицу objects", "Записать в таблицу posts" (помним же, да, что есть на самом деле "Posts" на Хабре?)