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

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

git up при надобности ныкает все ещё незакоммиченные изменения в stash
«Спасибо, всё очень понятно.»
В смысле, тем, кто глубоко в теме — понятно, но даже и им приятнее было бы читать более опрятный русский текст. А код — кто в курсе, тому понятно, остальные просто остерегутся применять.
Да вроде все понятно, и очень полезно. Спасибо автору.
А разве обязательно делать add перед stash?
По идее, можно заюзать -u.
Ага, но -u появился только с версии 1.7.7, так что на всякий случай не использую.
Это скорее не в туториал, в tips&tricks;)
Нет, делаем по своему в силу специфики софта и его распространения.
Ещё зачем делать rebase когда у нас чистенько всё и будет, по идее fastforward?
А если локальные коммиты были?
НЛО прилетело и опубликовало эту надпись здесь
Merge будет делать лишние merge коммиты и историю нелинейной. Это неудобно если нужно просто получить новые коммиты (не пушать свои еще). Ну и неприятно видеть лишние коммиты в истории (неудобно в случае поиска плохого коммита).
НЛО прилетело и опубликовало эту надпись здесь
Объективный аргумент, если вы не сделаете push, а через некоторое время запустите опять git up. И в истории образуется несколько merge commit, что сложно для отката, переноса и review
В большинстве команд в которых я работал, тоже всегда делают merge с локальными изменениями, история выглядит ужасающе, особенно когда работают более 3 человек.
Вообще в конфиге есть опции для того чтобы rebase делался по дефолту.
За то что я бью линейкой по рукам за таки merge commits меня прозвали gitлером =/
image
Зато понятно, что из какой ветки прилетело.
НЛО прилетело и опубликовало эту надпись здесь
Такую историю и правда неудобно читать. Более того, информация о таких мержах — сплошной шум, ничего полезного.
Когда каждая фича в своей ветке, очень даже полезно.
Ни что вам не мешает делать отдельную ветку для каждой фичи и держать историю изменений «чистой».

Так на самом деле и должно быть:
1. новая фича — новая ветка.
2. фича готова, делаем pull ветки куда будем мержить, пусть будет master
3. делаем rebase фича_ветки относительно master
4. делает мерж фича_ветки в master.
Причем здесь фича-ветки?
У обоих подходов есть свои объективные плюсы и минусы. Выбрав один, не обязательно категорично считать другой полным ужасом.
Да, верно.
Вот мне интересно, если fastforward + merge + еще один дополнительный комит для вас это «чистенько», что же для вас тогда НЕ чистенько?
Думаю, да. Спасибо :)
Я ещё некоторое количество алиасов в баше для гита делаю:
#### file ~/.profile

alias gpull="git pull origin" # usage: gpull master
alias gpush="git push origin" # usage: gpush master

function gitcb() # getting git current branch
{
	git status 2>/dev/null | head -1 | cut -d ' ' -f 4
}

alias gpullcb="gpull $(gitcb)"
alias gpushcb="gpush $(gitcb)"


Для быстрого пулла и пуша.
git branch -u origin/foo foo

После этого git push/pull из локальной ветки foo будет эквивалентен git push/pull origin foo.

Аналогичный эффект будет если один раз сделать пуш таким образом:

git push -u origin foo
Для частого переключения веток это не пойдёт, придётся каждый раз при переключении это вызывать.
Или я недокурил мануалы?
Для каждой ветки достатчно вызвать это по одному разу.
Т.е. если мы сделали

git branch -u origin/foo foo
git branch -u origin/bar bar


То как бы мы не переключались между ветками в последствии pull/push из локальной ветки foo будет работать c origin/foo, а из ветки bar — c origin/bar
Это да, но ветки ведь и создаются часто.
И, кроме того, это надо проделывать для всех проектов, что тоже не очень удобно.

А так — запомнил «gpushcb» — и всё! Ещё функция gitcb иногда может в скриптах пригодиться.
НЛО прилетело и опубликовало эту надпись здесь
Раз уж пошла такая пьянка, то грех не поделиться своими шоткатами (+ несколькими взятыми из oh-my-zsh): gist.github.com/3430432
Небольшой хинт к вашей функции gitcb, если позволите:

$ git symbolic-ref -q HEAD | sed s:refs/heads/::
Спасибо, работает как надо! =)
Может не в тему. а в чем проблема с неленейностью истории?
Да вообще проблемы с ней нет, да и rebase штука потенциально опасная при мёрже в обе стороны. Но идея со stash-pull занятная.
НЛО прилетело и опубликовало эту надпись здесь
Ничего особенного, но сложно понять кто после кого что сделал (когда git log --graph показывает мешанину), сложно оттрекать кто когда добавил проблему (надоест делать git blame HEAD~1^2~4), неудобно ревьювить код (кроме того кто-то может поменять что-то лишнее в merge коммите). Да и просто некрасиво, мусорно.

Rebase же штука опасная, но когда: 1) если меняешь уже пушнутые коммиты (табу, и здесь такое не делается), и 2) при конфликтном ребэйсе не создастся мердж коммит, а изменятся оригинальные. Согласен — перемерджить изменения уже не выйдет. Но это проблема если ребэйс делается очень редко, если делать часто — много не поломаешь (в том числе и вероятность конфликта маленькая).
А если вдруг еще по каким либо причинам понадобится перенести все патчи, один за одним на новое дерево. То то будет веселья, если история с кучами мержей…

p.s. почему то когда такое случается, любители «мержей», куда то пропадают…
НЛО прилетело и опубликовало эту надпись здесь
Часто использую сокращение dc для «diff --cached», чтобы убедиться, что сейчас буду коммитить именно то, что планировал.

И ещё сотрудник как-то поделился длинной строчкой, которую я теперь таскаю между всеми компами, где требуется работать с гитом (привожу не командой, а строкой из файла gitconfig):
gr = "log --all --graph --pretty=format:'%Cred%h%Creset%x09%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative"

Позволяет просматривать дерево коммитов в очень удобном виде.
У меня подобная строчка, только цветовая схема помягче и элементы расположены иначе:

alias gha='git log --graph --date=relative --all --topo-order --pretty=format:'\''%C(cyan)[%an]%Creset %C(green bold)%d%Creset %C(yellow)%h%Creset : %s %C(cyan)[%ad]%Creset'\'''


Алиас легко добавить на любом сервере

Не очень понятно зачем такой алиас нужен на сервере. Вы прямо на серверах разрабатываете что ли?
Хм… ну да. С гитом часто работаю в консоли на серверах — общий dev-сервер (среда близко к продакшн), свой локальный (побыстрее), CI сервер, домашний. Да, на продакшне именно git up не пригодится :)
Могу предположить, что это git branch --set-upstream.
А данная ошибка(описка) могла возникнуть из-за того, что в git push [-u | --set-upstream].
Сначала переходим на гит, потом делаем, чтобы все было как в старом-добром svn ^___^
На мой взгляд эта статья еще раз подтверждает тезис о быстрорастущей популярности IT и необходимости адаптации инфраструктуры к требованиям новичков. ИТ уже не торт.
НЛО прилетело и опубликовало эту надпись здесь
В каком смысле не торт? Вы имеете ввиду, что слишком много людей вертится во всём это хозяйстве, а не избранные, многим это всё уже не кажется магией? И поэтому уже не торт? :)
есть такая штука: ZSH и к ней есть такая: oh-my-zsh github.com/robbyrussell/oh-my-zsh
и там есть плагин для git. Посмотрите, очень удобно!

gl = git pull
gp = git push
ga=git add
gm=git merge

но это я просто детский пример привёл, лучше посмотрите сами!
github.com/robbyrussell/oh-my-zsh/blob/master/plugins/git/git.plugin.zsh
Вброшу свои 5 копеек (файл ~/.gitconfig)
[alias]
        co = checkout
        ci = commit
        st = status
        br = branch
        di = diff --color
        hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short
        llog = log --all --graph --decorate=full --date-order --color
        
Моё:

st = status
ci = commit
ca = commit --amend
co = checkout
chp = cherry-pick

ri = rebase -i
ri2 = rebase -i HEAD~2
ri3 = rebase -i HEAD~3
ri4 = rebase -i HEAD~4

sc = svn dcommit
sf = show --pretty=«format:» --name-only
sr = svn rebase

Уже не помню моё или собрано где-то:

d = diff -C
ds = diff -C --stat
dsp = diff -C --stat -p
dw = diff -C --color-words
dp = diff --patch -U --no-prefix

l = log -C --decorate
ls = log -C --stat --decorate
lsp = log -C --stat -p --decorate
lg = log --graph '--pretty=tformat:%Cblue%h%Creset %Cgreen%ar%Creset %Cblue%d%Creset %s'
lga = log --graph '--pretty=tformat:%Cblue%h%Creset %Cgreen%ar%Creset %Cblue%d%Creset %s' --all
l19 = log --graph '--pretty=tformat:%Cblue%h%Creset %Cgreen%ar%Creset %Cblue%d%Creset %s' --all -19
# для сложных ветвлений
lsd = log --graph '--pretty=tformat:%Cblue%h%Creset %Cgreen%ar%Creset %Cblue%d%Creset %s' --all --simplify-by-decoration
ru = remote update
sb = show-branch --sha1-name
ls-del = ls-files -d
ls-mod = ls-files -m # включая удалённые файлы
ls-new = ls-files --exclude-standard -o
ls-ign = ls-files --exclude-standard -o -i
ka = !gitk --all
kdo = !gitk --date-order
kado = !gitk --all --date-order
kasd = !gitk --all --simplify-by-decoration
# для сложных ветвлений
lsd =…

Ну, название говорит само за себя ;)
Забавы ради:

fix = "!am() { curl -s http://whatthecommit.com/ | grep '<p>' | cut -c4-; }; git commit -em \"# $(am)\" \"$@\""
Кстати, IntelliJ и другие IDE от JetBrains уже давно это умеют делать: Update Project (pull from tracked branch), Checkout и Merge.
id = log -1 --format='commit %C(green)%h%C(white) by %C(yellow)%an%C(white), %ar (%ad)%n%n%B'
НЛО прилетело и опубликовало эту надпись здесь
В какой версии git?
Похожий алиас (вернее скрипт) входит в состав git-friendly.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Изменить настройки темы

Истории