Комментарии 64
git up при надобности ныкает все ещё незакоммиченные изменения в stash«Спасибо, всё очень понятно.»
В смысле, тем, кто глубоко в теме — понятно, но даже и им приятнее было бы читать более опрятный русский текст. А код — кто в курсе, тому понятно, остальные просто остерегутся применять.
-10
А разве обязательно делать add перед stash?
+2
Это скорее не в туториал, в tips&tricks;)
+2
Еще хотел узнать как вы делаете deployment, по help.github.com/articles/deploying-with-capistrano принципу?
0
Ещё зачем делать rebase когда у нас чистенько всё и будет, по идее fastforward?
+2
А если локальные коммиты были?
+2
НЛО прилетело и опубликовало эту надпись здесь
Merge будет делать лишние merge коммиты и историю нелинейной. Это неудобно если нужно просто получить новые коммиты (не пушать свои еще). Ну и неприятно видеть лишние коммиты в истории (неудобно в случае поиска плохого коммита).
+2
НЛО прилетело и опубликовало эту надпись здесь
Объективный аргумент, если вы не сделаете push, а через некоторое время запустите опять git up. И в истории образуется несколько merge commit, что сложно для отката, переноса и review
+3
В большинстве команд в которых я работал, тоже всегда делают merge с локальными изменениями, история выглядит ужасающе, особенно когда работают более 3 человек.
Вообще в конфиге есть опции для того чтобы rebase делался по дефолту.
За то что я бью линейкой по рукам за таки merge commits меня прозвали gitлером =/
Вообще в конфиге есть опции для того чтобы rebase делался по дефолту.
За то что я бью линейкой по рукам за таки merge commits меня прозвали gitлером =/
+11
Зато понятно, что из какой ветки прилетело.
0
НЛО прилетело и опубликовало эту надпись здесь
Такую историю и правда неудобно читать. Более того, информация о таких мержах — сплошной шум, ничего полезного.
+3
Когда каждая фича в своей ветке, очень даже полезно.
0
Ни что вам не мешает делать отдельную ветку для каждой фичи и держать историю изменений «чистой».
Так на самом деле и должно быть:
1. новая фича — новая ветка.
2. фича готова, делаем pull ветки куда будем мержить, пусть будет master
3. делаем rebase фича_ветки относительно master
4. делает мерж фича_ветки в master.
Так на самом деле и должно быть:
1. новая фича — новая ветка.
2. фича готова, делаем pull ветки куда будем мержить, пусть будет master
3. делаем rebase фича_ветки относительно master
4. делает мерж фича_ветки в master.
+6
Причем здесь фича-ветки?
+3
У обоих подходов есть свои объективные плюсы и минусы. Выбрав один, не обязательно категорично считать другой полным ужасом.
+4
Да, верно.
0
Вот мне интересно, если fastforward + merge + еще один дополнительный комит для вас это «чистенько», что же для вас тогда НЕ чистенько?
0
addremove — это случем не то же самое, что «git add -A»?
0
Я ещё некоторое количество алиасов в баше для гита делаю:
Для быстрого пулла и пуша.
#### 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)"
Для быстрого пулла и пуша.
0
git branch -u origin/foo foo
После этого git push/pull из локальной ветки foo будет эквивалентен git push/pull origin foo.
Аналогичный эффект будет если один раз сделать пуш таким образом:
git push -u origin foo
После этого git push/pull из локальной ветки foo будет эквивалентен git push/pull origin foo.
Аналогичный эффект будет если один раз сделать пуш таким образом:
git push -u origin foo
+1
Для частого переключения веток это не пойдёт, придётся каждый раз при переключении это вызывать.
Или я недокурил мануалы?
Или я недокурил мануалы?
0
Для каждой ветки достатчно вызвать это по одному разу.
Т.е. если мы сделали
То как бы мы не переключались между ветками в последствии pull/push из локальной ветки foo будет работать c origin/foo, а из ветки bar — c origin/bar
Т.е. если мы сделали
git branch -u origin/foo foo
git branch -u origin/bar bar
То как бы мы не переключались между ветками в последствии pull/push из локальной ветки foo будет работать c origin/foo, а из ветки bar — c origin/bar
0
Тоже решил поделиться :)
https://github.com/Microfed/Git-bash-alisases
https://github.com/Microfed/Git-bash-alisases
+1
Я свои конфиги и алиасы тоже в гите храню =)
github.com/silvansky/macscripts
github.com/silvansky/macscripts
0
НЛО прилетело и опубликовало эту надпись здесь
Раз уж пошла такая пьянка, то грех не поделиться своими шоткатами (+ несколькими взятыми из oh-my-zsh): gist.github.com/3430432
+1
Небольшой хинт к вашей функции gitcb, если позволите:
$ git symbolic-ref -q HEAD | sed s:refs/heads/::
$ git symbolic-ref -q HEAD | sed s:refs/heads/::
+1
Может не в тему. а в чем проблема с неленейностью истории?
+5
Да вообще проблемы с ней нет, да и rebase штука потенциально опасная при мёрже в обе стороны. Но идея со stash-pull занятная.
+3
Ничего особенного, но сложно понять кто после кого что сделал (когда git log --graph показывает мешанину), сложно оттрекать кто когда добавил проблему (надоест делать git blame HEAD~1^2~4), неудобно ревьювить код (кроме того кто-то может поменять что-то лишнее в merge коммите). Да и просто некрасиво, мусорно.
Rebase же штука опасная, но когда: 1) если меняешь уже пушнутые коммиты (табу, и здесь такое не делается), и 2) при конфликтном ребэйсе не создастся мердж коммит, а изменятся оригинальные. Согласен — перемерджить изменения уже не выйдет. Но это проблема если ребэйс делается очень редко, если делать часто — много не поломаешь (в том числе и вероятность конфликта маленькая).
Rebase же штука опасная, но когда: 1) если меняешь уже пушнутые коммиты (табу, и здесь такое не делается), и 2) при конфликтном ребэйсе не создастся мердж коммит, а изменятся оригинальные. Согласен — перемерджить изменения уже не выйдет. Но это проблема если ребэйс делается очень редко, если делать часто — много не поломаешь (в том числе и вероятность конфликта маленькая).
+4
НЛО прилетело и опубликовало эту надпись здесь
Часто использую сокращение dc для «diff --cached», чтобы убедиться, что сейчас буду коммитить именно то, что планировал.
И ещё сотрудник как-то поделился длинной строчкой, которую я теперь таскаю между всеми компами, где требуется работать с гитом (привожу не командой, а строкой из файла gitconfig):
Позволяет просматривать дерево коммитов в очень удобном виде.
И ещё сотрудник как-то поделился длинной строчкой, которую я теперь таскаю между всеми компами, где требуется работать с гитом (привожу не командой, а строкой из файла 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"
Позволяет просматривать дерево коммитов в очень удобном виде.
+4
Алиас легко добавить на любом сервере
Не очень понятно зачем такой алиас нужен на сервере. Вы прямо на серверах разрабатываете что ли?
0
+3
Сначала переходим на гит, потом делаем, чтобы все было как в старом-добром svn ^___^
На мой взгляд эта статья еще раз подтверждает тезис о быстрорастущей популярности IT и необходимости адаптации инфраструктуры к требованиям новичков. ИТ уже не торт.
На мой взгляд эта статья еще раз подтверждает тезис о быстрорастущей популярности IT и необходимости адаптации инфраструктуры к требованиям новичков. ИТ уже не торт.
+4
есть такая штука: 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
и там есть плагин для 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
0
Вброшу свои 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
0
Моё:
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
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
+2
Забавы ради:
fix = "!am() { curl -s http://whatthecommit.com/ | grep '<p>' | cut -c4-; }; git commit -em \"# $(am)\" \"$@\""
+2
Кстати, IntelliJ и другие IDE от JetBrains уже давно это умеют делать: Update Project (pull from tracked branch), Checkout и Merge.
+1
id = log -1 --format='commit %C(green)%h%C(white) by %C(yellow)%an%C(white), %ar (%ad)%n%n%B'
0
НЛО прилетело и опубликовало эту надпись здесь
Похожий алиас (вернее скрипт) входит в состав git-friendly.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Git up и все все все