
Первый раз в жизни сознательно сделал rebase
Вот делаю я git checkout branch1 --force. Тут же делаю git status и вижу, что поменялось 5 файлов. При этом, если открыть одниз них 1.cpp, видно что у него переносы строк CRLF, а в гит-диффе написано что CRLF заменился на LF.
В gitattributes есть такое:
text=auto
.cpp text
Ну раз уж тут такая киллер-фича на пойнтах
То и ох#еть теперь самое время закрасить это днищенское УГ обновить стильцы!
https://gitlab.com/flashwalker/userstyles
Скажите, это нормально feature/bugfix-бранчи называть по номерам задач в issue-трекере?
Помогите с гитом, я абсолютно не могу понять его логики.
Задача такая:
На гитхабе есть проект, не мой, я захотел сделать там несколько изменений, для этого склонировал репозиторий к себе, изменил, отправил автору пулл-реквест. Автор посмотрел, сказал, что нормально, но добавит изменения не сейчас, а потом, в новую версию проекта. А пока развивается старая. Как мне теперь опять синхронизировать мой локальный репозиторий с моими изменениями со всеми новыми изменениями оригинального репозитория?
Я раньше патчи делал и накладывал, наверное в гите как-то проще должно быть?
Взбугуртнулось. Только теперь пришла в голову мысль: нафиг git по умолчанию лезет исправлять переносы строк? Например, все работают в винде, нафиг им сдалась эта перегонка туда-сюда? Понятно что это для кроссплатформенности. Но почему-то до меня это долго доходило.
Вот есть ветка release, есть хотфикс ветки и есть метки. А есть версии продукта типа 1.0 alpha, 1.0 beta1, 1.0 beta2, 1.0 rc1, 1.0 release, 1.1 alpha, 1.0.1 (в хронологическом порядке). Как они соотносятся друг с другом?
Котаны, а как вы решаете проблему с правами при git push в собственный репозиторий у себя в локалке? Каждый раз при ошибке запускать скрипт - не вариант.
http://habrahabr.ru/post/28268/
Не забывайте, что вы всегда можете подлить какую-нибудь ветку в текущую с помощью git merge other-branch.
выходим в мастер (gco master), подливаем ветку (git merge my-branch),
мне нужно было подлить мастер в локальную ветку.
А вот это наверное дельный совет:
2) На первых порах не морочьте себе голову с rebase и «чистотой» линии коммитов. Это беспокоит только последних эстетов или Линуса (который мерджит десяток веток в день). Читать git-log и игнорировать банальные merge commits нет никакой проблемы.
Год 2008, да.
Странные доводы в комментах http://habrahabr.ru/post/255443/
Скажите как у вас внутри команды предаётся инфа о том, какие нужно сделать изменения в ДБ, чтобы вот этот коммит правильно заработал?
Внезапно на bitbucket.org можно сделать вот так http://rabotyahoff.bitbucket.org/
Инструкция http://pages.bitbucket.org/
запустил git rebase -i с патченной версии линукс ядра от 2008 на текущую. зря да? чет уже долго жду ))
Из progit: "Так как ветка, которую мы слили, указывала на коммит, являющийся прямым родителем коммита, на котором мы сейчас находимся, Git просто сдвинул её указатель вперёд."
Читаю и не верю своим глазам. Главу назад была схема, где показано отношение коммит-родитель_коммита, и вот не соответствует оно новой схеме.
http://git-scm.com/book/ru/...-ветвления-и-слияния
git svn только что выдал "fatal: malformed index info". откуда-то в том же каталоге взялся коредамп перла.. ну да пофиг. git svn fetch; git svn rebase и вроде всё как обычно, всё работает. хмм...