Git up и все все все

[@spmbt]

git up при надобности ныкает все ещё незакоммиченные изменения в stash

«Спасибо, всё очень понятно.»
В смысле, тем, кто глубоко в теме — понятно, но даже и им приятнее было бы читать более опрятный русский текст. А код — кто в курсе, тому понятно, остальные просто остерегутся применять.

[@Wolong]

Да вроде все понятно, и очень полезно. Спасибо автору.

[@SamDark]

А разве обязательно делать add перед stash?

[@SamDark]

По идее, можно заюзать -u.

[@denver]

Ага, но -u появился только с версии 1.7.7, так что на всякий случай не использую.

[@coocheenin]

Это скорее не в туториал, в tips&tricks;)

[@skorney]

Еще хотел узнать как вы делаете deployment, по help.github.com/articles/deploying-with-capistrano принципу?

[@SamDark]

Блин, не туда :(

[@denver]

Нет, делаем по своему в силу специфики софта и его распространения.

[@SamDark]

Ещё зачем делать rebase когда у нас чистенько всё и будет, по идее fastforward?

[@Xeor]

А если локальные коммиты были?

[@denver]

Merge будет делать лишние merge коммиты и историю нелинейной. Это неудобно если нужно просто получить новые коммиты (не пушать свои еще). Ну и неприятно видеть лишние коммиты в истории (неудобно в случае поиска плохого коммита).

[@vics001]

Объективный аргумент, если вы не сделаете push, а через некоторое время запустите опять git up. И в истории образуется несколько merge commit, что сложно для отката, переноса и review

[@omfg]

В большинстве команд в которых я работал, тоже всегда делают merge с локальными изменениями, история выглядит ужасающе, особенно когда работают более 3 человек.
Вообще в конфиге есть опции для того чтобы rebase делался по дефолту.
За то что я бью линейкой по рукам за таки merge commits меня прозвали gitлером =/

[@SamDark]

Зато понятно, что из какой ветки прилетело.

[@Goder]

Такую историю и правда неудобно читать. Более того, информация о таких мержах — сплошной шум, ничего полезного.

[@SamDark]

Когда каждая фича в своей ветке, очень даже полезно.

[@vovkab]

Ни что вам не мешает делать отдельную ветку для каждой фичи и держать историю изменений «чистой».

Так на самом деле и должно быть:
1. новая фича — новая ветка.
2. фича готова, делаем pull ветки куда будем мержить, пусть будет master
3. делаем rebase фича_ветки относительно master
4. делает мерж фича_ветки в master.

[@Goder]

Причем здесь фича-ветки?

[@Yan169]

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

[@SamDark]

Да, верно.

[@vovkab]

Вот мне интересно, если fastforward + merge + еще один дополнительный комит для вас это «чистенько», что же для вас тогда НЕ чистенько?

[@Xeor]

addremove — это случем не то же самое, что «git add -A»?

[@denver]

Думаю, да. Спасибо :)

[@silvansky]

Я ещё некоторое количество алиасов в баше для гита делаю:

#### 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)"

Для быстрого пулла и пуша.

[@Infernal]

git branch -u origin/foo foo

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

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

git push -u origin foo

[@silvansky]

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

[@Infernal]

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

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

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

[@silvansky]

Это да, но ветки ведь и создаются часто.
И, кроме того, это надо проделывать для всех проектов, что тоже не очень удобно.

А так — запомнил «gpushcb» — и всё! Ещё функция gitcb иногда может в скриптах пригодиться.

[@Goder]

Тоже решил поделиться :)
https://github.com/Microfed/Git-bash-alisases

[@silvansky]

Я свои конфиги и алиасы тоже в гите храню =)
github.com/silvansky/macscripts

[@Progrik]

Раз уж пошла такая пьянка, то грех не поделиться своими шоткатами (+ несколькими взятыми из oh-my-zsh): gist.github.com/3430432

[@malkolm]

Небольшой хинт к вашей функции gitcb, если позволите:

$ git symbolic-ref -q HEAD | sed s:refs/heads/::

[@silvansky]

Спасибо, работает как надо! =)

[@Xobb]

Может не в тему. а в чем проблема с неленейностью истории?

[@SamDark]

Да вообще проблемы с ней нет, да и rebase штука потенциально опасная при мёрже в обе стороны. Но идея со stash-pull занятная.

[@denver]

Ничего особенного, но сложно понять кто после кого что сделал (когда git log --graph показывает мешанину), сложно оттрекать кто когда добавил проблему (надоест делать git blame HEAD~1^2~4), неудобно ревьювить код (кроме того кто-то может поменять что-то лишнее в merge коммите). Да и просто некрасиво, мусорно.

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

[@vovkab]

А если вдруг еще по каким либо причинам понадобится перенести все патчи, один за одним на новое дерево. То то будет веселья, если история с кучами мержей…

p.s. почему то когда такое случается, любители «мержей», куда то пропадают…

[@CaptainFlint]

Часто использую сокращение 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"

Позволяет просматривать дерево коммитов в очень удобном виде.

[@TheOld]

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

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'\'''

[@romik]

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

Не очень понятно зачем такой алиас нужен на сервере. Вы прямо на серверах разрабатываете что ли?

[@denver]

Хм… ну да. С гитом часто работаю в консоли на серверах — общий dev-сервер (среда близко к продакшн), свой локальный (побыстрее), CI сервер, домашний. Да, на продакшне именно git up не пригодится :)

[@Santacruz]

git branch -u? Что это?

git-scm.com/docs/git-branch — тут нету

[@andreich3]

Могу предположить, что это git branch --set-upstream.
А данная ошибка(описка) могла возникнуть из-за того, что в git push [-u | --set-upstream].

[@nekt]

Сначала переходим на гит, потом делаем, чтобы все было как в старом-добром svn ^___^
На мой взгляд эта статья еще раз подтверждает тезис о быстрорастущей популярности IT и необходимости адаптации инфраструктуры к требованиям новичков. ИТ уже не торт.

[@G0ran]

В каком смысле не торт? Вы имеете ввиду, что слишком много людей вертится во всём это хозяйстве, а не избранные, многим это всё уже не кажется магией? И поэтому уже не торт? :)

[@SamDark]

Ну да. Раньше избранных на руках носили, а сейчас приходится работать :)

[@scorched]

есть такая штука: 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

[@Mirraz]

Вброшу свои 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
        

[@dimas]

Моё:

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

[@cubuanic]

# для сложных ветвлений
lsd =…

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

[@funca]

Забавы ради:

fix = "!am() { curl -s http://whatthecommit.com/ | grep '<p>' | cut -c4-; }; git commit -em \"# $(am)\" \"$@\""

[@edelweard]

Кстати, IntelliJ и другие IDE от JetBrains уже давно это умеют делать: Update Project (pull from tracked branch), Checkout и Merge.

[@shodan]

id = log -1 --format='commit %C(green)%h%C(white) by %C(yellow)%an%C(white), %ar (%ad)%n%n%B'

[@denver]

В какой версии git?