Comments 43
Хмм… На Хабре не любят git-flow?
На хабре не любят бессмысленные, да ещё и не относящиеся к статье комментарии. Вот написал бы inook, какое отношение git‐flow имеет к статье и почему он «забыл о боли» — минусов было бы меньше.
А вы изучите лучше все возможности гита — даже для ведения репозитория одним человеком ветки крайне полезны. Для чего:
чтобы вносить изменения в код на какую-то другую тему в то время как имеются незаконченные изменения, для фиксации в общей истории только значащих изменений, в то время как в рабочей ветке могут быть зафиксированы незавершенные состояния кода, для более простого ревью фич, для откладывания изменений в коде и применении их, когда основа для изменения уже другая.
показать ветки в которые вошел данный коммит:
git branch -a --contains $SHA(можно добавить в sourceTree customAction и дергать мышкой из гуи)
показать разницу в коммитах между двумя бранчами
git log --oneline release/release_1.23 ^release/release_1.22
А можно как-то проверить коммиты, которые были перенесены в другую ветку с помощью cherry-pick? sha у них отличаются, конечно. Можно попробовать patch-id, но это несколько затратно перебирать много коммитов.
В общем случае видимо только скриптить перебор.
Зря. Я начал использовать 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 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))'"
Выводит список локальных веток, отсортированный по времени, с последними коммитами и их датами.
format:" и " в конце на '
Поэтому: коммит, дата, название ветки, название коммита.
Тогда вывод читается намного лучше.
Малоизвестные Git-команды