Открыть список
Как стать автором
Обновить

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

очередная кучка алиасов
нет бы в апстрим протащить хотя бы какой-нибудь (хотя бы git it в качестве поведения по умолчанию)


inb4: я понимаю, что это сложно

Прошу прощения, но я не вижу никакого смысла протаскивать это в апстрим, если все это можно реализовать в виде алиасов. Не стоит плодить сущности без особой нужды на то.
все это можно реализовать в виде алиасов

своих собственных алиасов у каждого второго пользователя

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

Действительно, ожидал увидеть мясо про rev-parse, for-each-ref, cat-file, rebase --onto, fetch +, update-ref, show-ref… А тут просто пачка алиасов.

Можете порекомендовать статьи, в которых более-менее доступно разжевано это самое «мясо»?

К сожалению нет. Небольшая часть этого есть в pro git. Оставшаяся же часть осваивается посредством долгого и вдумчивого ковыряния в git на практике.

Это еще не самое страшное. Хуже, когда такой любитель алиасов начинает их втыкать в продуктовые и CI скрипты, потому что «так удобнее».

К слову, я в скриптах пользуюсь исключительно длинными ключами команд (git commit --message="$ABYRVALG" вместо git commit -m "$ABYRVALG")

Разумеется. Скрипт пишется один раз, а читается несколько, да еще и через пол года-год.
Самый нужный алиас это «кто первым добавил эту строку», пока что-то всё что попадалось как-то криво работало или не работало
Использую git-flow и уже давно забыл о боли.

Хмм… На Хабре не любят git-flow?

На хабре не любят бессмысленные, да ещё и не относящиеся к статье комментарии. Вот написал бы inook, какое отношение git‐flow имеет к статье и почему он «забыл о боли» — минусов было бы меньше.

Думаю, потому что мерж там по умолчанию --no-ff и не нужно вспоминать, с какой опцией -d или -D нужно удалять слитые ветки. Ну и в принципе, стандартизированный flow и инструменты для него освобождают мозг для более важных задач.

staaash, grog, commend, shorty, please? Насколько мне известно, git‐flow заменяет только merc и it. Кроме того, совет «используйте git‐flow» подходит только для новых проектов или проектов, где он уже используется.

А я использую пока лишь TortoiseGit в самом примитивном виде, просто для себя лично, локально. Без веток, только фиксацию изменений, чтобы не потерять историю изменений и чтобы было куда откатиться если чего поломаю. На предыдущей работе был svn, на новой ничего — а без контроля версий как-то уже некомфортно :)

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

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
добавлю от себя еще две полезных команды

показать ветки в которые вошел данный коммит:
git branch -a --contains $SHA
(можно добавить в sourceTree customAction и дергать мышкой из гуи)

показать разницу в коммитах между двумя бранчами
git log --oneline release/release_1.23 ^release/release_1.22

А можно как-то проверить коммиты, которые были перенесены в другую ветку с помощью cherry-pick? sha у них отличаются, конечно. Можно попробовать patch-id, но это несколько затратно перебирать много коммитов.

Если в коммитах проставляется герритовский ChangeId, то поиском по коммитам с тем же ChangeId. Это можно сделать например с помощью git grep. Но это если вы знаете копии чего вы хотите искать.

В общем случае видимо только скриптить перебор.
Есть команда cherry, который делает обратное — показывает коммиты, которых еще нет в другой ветке, может быть она подойдет? Правда, для определения коммитов используется тот же patch-id, подозреваю, который вы сочли дорогим.

Эта команда, как минимум, уже готова. Спасибо, попробую.

эх, а я так и не добрался до Git :(

Зря. Я начал использовать vcs ещё когда работал на заводе, где никому ничего не надо было и всякий работал как хотел. Тогда это была cvs. Я даже ветки не использовал, но уже забыл про "ё-моё, что ж я наделал-то", "откуда это здесь" и "что я имел в виду". Теперь однозначно git, ветки, упрощённый git flow — даже при том, что владею кодом единолично. Зато нет проблем разрабатывать несколько функциональных едиц, радикально переделывать код, но при этом не терять возможности выпустить хотфикс менее, чем за полчаса. Это реально стоит времени на обучение.

Да, спасибо за информацию, думаю в скором будущем начну обучение.
Начните прямо сейчас! А то в ближайшем будущем пожалеете, что тянули время. Буквально пяток команд достаточно изучить для начала работы.

Я очень старался, но так и не понял отрывок про git shorty. В полном выводе git status есть информация про package.json и index.js, а в выводе git shorty только какой-то test и .gitignore. Может кто-нибудь пояснить, что имел в виду автор?

Автор опечатался, скорее всего, и сделал копипасту с разных репозиториев.


% git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    deleted:    a

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   b

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    c

% git status --short --branch
## master
D  a
 M b
?? c
НЛО прилетело и опубликовало эту надпись здесь
Первому коммиту в репозитории нельзя сделать ребейз, как обычному.

git rebase -i --root

soft reset последнего коммита с выводом статуса


git config --global alias.rs1 '!git reset --soft HEAD~1 && git status --short --branch'
git status --short --branch

=
git status -sb


можно спокойно обойтись и без алиаса
git status — это длинно.
git st — наше всё! (тяжкое наследие svn, я понимаю).
Я еще больше ленив видимо. У меня git status -sb реализовано в виде алиаса gs
git log -> gl
gd -> git diff
gp -> git push ну и так далее, что умещается в две буквы

Как же приятно узнавать что-то новое о старом добром, казалось бы, вдоль и поперёк известном инструменте!

С алиасов гита перешел на алиасы из oh-my-zsh https://github.com/robbyrussell/oh-my-zsh/blob/master/plugins/git/git.plugin.zsh — очень рекомендую, хорошо продуманы. Заменили мне все комманды гита, которые я постоянно использую в работе, избавив меня от головной боли с продумыванием имен и подбором параметров для команд, когда я пытался сам сделать хорошую систему под себя.
Сегодня добавил себе ещё алиас git branches:

git config --global alias.branches "for-each-ref --sort=committerdate refs/heads/ --format='%(HEAD) %(color:yellow)%(refname:short)%(color:reset) - %(color:red)%(objectname:short)%(color:reset) - %(contents:subject) - %(authorname) (%(color:green)%(committerdate:relative)%(color:reset))'"


Выводит список локальных веток, отсортированный по времени, с последними коммитами и их датами.
grog из статьи больше не работает, нужно заменить format:" и " в конце на '
О ужас. Я бы те поля, которые более менее похожы по размеру, выводил в самом начале строки, да и сортировку лучше делать в обратном порядке: наиболее свежие выводить первыми.

Поэтому: коммит, дата, название ветки, название коммита.

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