git commit -a

еретик!

why?

modified: article/views.pyc
pyc

man gitignore

Мне надо опять делать git add /path/filename ?

Ага.

А чего делать с deleted файлами?

Тоже git add.

А чего делать с deleted файлами?

Тоже git add.

git rm

git commit -a провоцирует на заведомо ущербный workflow. В реальности, почти никогда текущее состояние рабочего дерева не является желаемым коммитом. Всегда присутствуют какие-то левые мусорные изменения, которые коммитить крайне нежелательно.

В своём workflow я использую git add <filename> для добавления новых файлов и git add -p чтобы выбрать изменения в существующих файлов, которые я хочу закоммитить. Обратные операции для git add будут git reset и git reset -p. Ещё полезен git checkout -p, он позволяет откатывать изменения в файлах.

В своём workflow я использую git add <filename> для добавления новых файлов и git add -p чтобы выбрать изменения в существующих файлов, которые я хочу закоммитить. Обратные операции для git add будут git reset и git reset -p. Ещё полезен git checkout -p, он позволяет откатывать изменения в файлах.

И как ты тестишь свои изменения перед тем, как закоммитить?

git add -i удобная штука

git commit -a

если что-то коммитить не нужно, прописать в .gitignore.

И как ты тестишь свои изменения перед тем, как закоммитить?

Никак. Я коммичу, вычищаю мусор при помощи git checkout -p. Если, вдруг, остаётся какое-то другое неортогональное изменение, то я его прячу при помощи git stash. Дальше собираю «чистое» рабочее дерево и тестирую. При наличии CI бота, можно просто запушить ветку как есть.На выходе получаются аккуратные, логически завершённые коммиты с минимальными усилиями.

На практике я вижу как люди при помощи commit -a коммитят простыни из сиюминутных исправлений и случайных изменений файлов (пробелов, переносов). Читать такие исправления сложно, разрешать конфликты ещё сложнее. Зачем так делать, непонятно. Получается люди решают при помощи git проблему, которая на самом деле лучше решается при помощи Dropbox.

git commit -a провоцирует на заведомо ущербный workflow. В реальности, почти никогда текущее состояние рабочего дерева не является желаемым коммитом. Всегда присутствуют какие-то левые мусорные изменения, которые коммитить крайне нежелательно.

Это git add провоцирует на мусорку в рабочем каталоге. Не бывает «левых» изменений - все изменения должны быть либо закоммичены, либо отменены. Либо стать частью локального конфига. Если незакоммиченные изменения постоянно болтаются - значит, ты делаешь что-то не так. А когда коммитишь изменения выборочно, содержимое коммита не соответствует текущему состоянию рабочего каталога. Возможно, это состояние вообще никогда в реальности не существовало. Постоянно люди таким образом коммитят сломанный код, а потом удивляются.

Никак. Я коммичу, вычищаю мусор при помощи git checkout -p. Если, вдруг, остаётся какое-то другое неортогональное изменение, то я его прячу при помощи git stash. Дальше собираю «чистое» рабочее дерево и тестирую. При наличии CI бота, можно просто запушить ветку как есть.На выходе получаются аккуратные, логически завершённые коммиты с минимальными усилиями.

А я предпочитаю перед пушем проверить, что все мои коммиты как минимум компилируются по отдельности. При этом если не сразу оформлять минимальные изменения коммитами, а резать одно большое изменение на коммиты, то может получиться так, что всё вместе - собирается, а по отдельности - нет. При этом CI пошлёт эти коммиты в лес^W^Wна доработку =). Можно конечно их после нарезки зачекаутить по отдельности, проверить и подправить при необходимости, но это лишняя работа.

На практике я вижу как люди при помощи commit -a коммитят простыни из сиюминутных исправлений и случайных изменений файлов (пробелов, переносов). Читать такие исправления сложно, разрешать конфликты ещё сложнее. Зачем так делать, непонятно.

Но это ведь не проблема git commit -a.

В общем это дело вкуса, ИМХО.

Х3 х3, я вот например стараюсь держать working tree в состоянии, «я готовое к коммиту», а вся левота должна быть в gitignore. Что бы git clean -fxd ничего и никогда не портил.

Держать несколько изменений в один момент, это скорее путь адептов subversion. У людей git'a для этого есть ветки, в частности stash.

Не бывает «левых» изменений - все изменения должны быть либо закоммичены, либо отменены. Либо стать частью локального конфига

Всё верно.

А когда коммитишь изменения выборочно, содержимое коммита не соответствует текущему состоянию рабочего каталога.

Я отбираю изменения при помощи git add -p даже если у меня в каталоге идеальное изменение без мусора и с единственным логическим смыслом. Это позволяет мне ещё раз внимательно рассмотреть свои изменения.

Если у меня в рабочей директории есть несколько изменений, то git add -p позволяет мне закоммитить их отдельно. Я коммичу первое изменение, делаю git stash, тестирую. Если изменения ортогональные (например, изменение документации никак не может сломать код), то такие коммиты я делаю без дополнительного тестирования. Иногда у меня бывают приступы излишней самоуверенности, и я пропускаю неортогональные изменения, приводящие к битым состояниям, но такое бывает очень редко.

В таком подходе git для меня также выступает в роли умного текстового редактора. При помощи git commit -a, конечно, можно производить нормальные коммиты, но для этого мне лично понадобится больше усилий.

При этом если не сразу оформлять минимальные изменения коммитами, а резать одно большое изменение на коммиты, то может получиться так, что всё вместе - собирается, а по отдельности - нет.

Я понимаю эту проблему. Но реальность такова, что я не могу писать только одно изменение за раз. Сначала пишется какой-то прототип, тестируется на работоспособность и только потом он оформляется в изменения. Сам процесс этого оформления является ценной возможностью пересмотреть свои изменения. git add -p позволяет удобно это делать.

При этом мне даже не столь важно, будут ли все состояния превосходно оттестированными. Если это зачем-то необходимо, напишите тесты, пусть CI прогоняет их на каждый коммит. Ведь, git commit -a тоже не решает проблему человеческого фактора.

Но это ведь не проблема git commit -a.

Да. Но, с ваших слов, не ясно пользуетесь ли вы чем-то кроме commit -a. Я рассказываю о проблемах людей. которые пользуются только commit -a. и утверждаю, что в их подходе сделать нормальный коммит безумно сложно.

Трудно мануал прочитать?

Х3 х3, я вот например стараюсь держать working tree в состоянии, «я готовое к коммиту», а вся левота должна быть в gitignore. Что бы git clean -fxd ничего и никогда не портил.

Левота бывает разной.

Действительно, просто так валяющихся файлов в репозитории в принципе быть не должно, для этого, конечно, надо использовать .gitignore.

Ещё бывает так, что случайное нажатие клавиши оставило лишний пробел или перенос строки или даже серьёзную поломку. Нужно следить, чтобы commit -a не захватил такие изменения. Тоесть, как минимум, нужно смотреть git diff/git show, что люди забывают/ленятся делать. После обнаружения проблемы, нужно как-то ещё избавится от неё. Те, кто не слышал про git checkout -p, будут запускать редактор и править руками?

Кстати, бывает ещё полезная левота. Например я держу в working tree отладочный вывод для текущей фичи. После тестирования фича идёт в продакшен, а отладочный вывод быстро летит в топку. То есть, эффективно, stage выступает как альтернативный буфер для текстового редактора.

Лично я делаю так. Начал работать над фичей 1, обнаружил, что сначала нужна фича 2. Отложил фичу 1 с помощью hg shelve/git stash, стал работать над фичей 2. Нужна фича 3 для фичи 2? Отложил фичу 2, начал фичу 3. Думаешь, просто так этот stash сделан в виде стека? А разводить срач и думать «та потом разберусь» - типичные повадки говнокодера, следующая стадия развития после commit -m 'This week's changes. Added features, fixed bugs'.

Переходи на hg пока не поздно...

Присоединяюсь к словам этого достойного джентльмена.

А чего делать с deleted файлами? По факту я создал еще одну папку в проекте и переместил их туда, и отредактировал.

Надо было сделать git mv

Нужна фича 3 для фичи 2? Отложил фичу 2, начал фичу 3.

Хорошо. Пусть фича 3 это некий интерфейс в API, а фича 2 реализует через этот API какой-то функционал. Тогда, чтобы протестировать фичу 3, мне нужно иметь в рабочей директории также фичу 2. А ты мне её откладывать предлагаешь.

А разводить срач и думать «та потом разберусь» - типичные повадки говнокодера, следующая стадия развития после commit -m 'This week's changes. Added features, fixed bugs'.

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

git commit -a провоцирует на заведомо ущербный workflow. В реальности, почти никогда текущее состояние рабочего дерева не является желаемым коммитом. Всегда присутствуют какие-то левые мусорные изменения, которые коммитить крайне нежелательно.

Это ты mercurial-у расскажи. Его подход тоже жизнеспособен: код должен быть рабочим, а где гарантия, что по кускам он работает так же, как целиком?

А тесты у вас не пишут?

Да не, там выше товарисч про стэш, как раз мою мысль изложил. А перечисленное тобой решается нормальной практикой ревью. rebase и ammend, как раз для решения таких задач.

Да и лично я не бьюсь обычно в конвульсиях, что бы прямо каких то изменений левых наоставлять. Когда с svn работаю, да бывает, покоммитаю что то левое, тот же кусок новой фичи, но в гите, до мержа/пула, ты можешь столько раз этот код посмотреть и поправить, сколько нужно.

Например я держу в working tree отладочный вывод для текущей фичи.

я обычно ничего не конпеляю и не пускаю в рабочей директории, соответственно и не парюсь такими вещами, а перенаправить вывод ещё куда нибудь, имхо вообще не проблемма.

Вообщем имхо, проще почаще делать git commit -a, чем готовить один большой и красивый коммит, это всегда можно зарибейзить. Но на то оно и гит, что бы всем было удобно.

hg

А для сабжа есть что то типа гитхаба?

Опять гитосрач? =)

Ну что, чтооо в этом <...>ом гитхабе вы все нашли??? Звучит как «а в линуксе есть микрософт ворд чтобы документы редактировать?»... :)

А есть ли для него что-то вроде геррита?

Удобно, и всякие необандлы оттуда плагины тягют. Хотя мэй би и с битбакета умеют без указания урла.

Вообще, мну чисто религиозные чувства мешают пользоваться продуктами Altassian :)

Есть. От того же alatassian. Тормозная хрень, на больших кодебейзах тупит и лагает. Но по фичам рвет геррит. Енто связка fish eye + cruicible.

А есчё, она стоит как самолёт. И грузит тонны адового js, который заставляет мой браузер жрать в разы больше ресурсов, чем виртуал боксе в 4 ядра и 6гб оперативы гоняющий венду.

О5 же вопрос, а чего вы все в этом гите нашли?

Я про меркуриал много чего хорошего слышал, только вот в проде его нигде не видел.

Либо это последствия трендов, либо оно чем то обломно выходит.

Хорошо, пусть не гитхаб, но гитлаб то есть чем заменить? Или это тоже «под линухом майкрософт запускать»?

Я понимаю, что есть добрый altassian, но выше я уже изложил своё мнение - у манагера на тачке, где все 8 ядер работают, что бы это непотребство в браузере проиграть, оно норм, но когда у тебя ещё пра тройка тяжелых штук открыта, эту хрень лагает и колбасит, хочется искать и наносить увечья (извините не могу остановиться ... :))

А перечисленное тобой решается нормальной практикой ревью. rebase и ammend, как раз для решения таких задач.

Ревью git diff для меня слишком напряжен. Мне приятнее смотреть отдельные чанки и жать y. А ненужное затем выкинуть при помощи git checkout -p даже не запуская текстовый редактор.

rebase и amend это хорошо, но лучше до этого не доводить.

а перенаправить вывод ещё куда нибудь, имхо вообще не проблемма.

Да, я про временные отладочные выражения.

Вообщем имхо, проще почаще делать git commit -a, чем готовить один большой и красивый коммит, это всегда можно зарибейзить. Но на то оно и гит, что бы всем было удобно.

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

посоны вот вы развели димагогию) Лучше скажите, а куда засандалить gitignore? Создаем файлик c именем gitignore рядом с .git? А в нем чего пишем? *.pyc ?

git difftool, или на том же gitlab'e | github'e | ... посмотреть когда мерж реквест делаешь.

А ненужное потом просто выкинуть с помощью git clean -fxd :)

Ну на вкус и цвет...

Yes sir.

$ man gitignore

TDD не панацея. В любых реальных задачах бывают неизвестные такие, что тестов, взятых из астрала, будет недостаточно. Приходится разводить «рабочий беспорядок».

root
master

забористая у тебя трава
нафиг тебе git вообще?

чтобы commit -a не захватил такие изменения

У меня запускается vim со сплитом, в одном окне diff, в другом комментарии и список файлов.

Лови «секретные» команды

git update-index --assume-unchanged <список staged файлов>
git update-index --no-assume-unchanged <список staged файлов>
git ls-files -v | grep «^[a-z]»

Первая команда включает режим игнорирования изменений перечисленных staged файлов. Вторая команда отменяет этот режим. Посмотреть какие файлы уже помечены можно третьей командой.

hg не осилил. мануалы не осилил. понятненько.