A
При этом если в коммите ты нафигачил всего подряд, определить какой код относился к фиче, а какой нет становится решительно сложнее
Size: a a a
2021 January 13
A
От этого и возникает рекомендация делать атомарные коммиты. То есть одно логическое изменение — один коммит.
VB
хм, ну да. Тут это было бы полезно, согласен.
Не возникало просто такой конкретной ситуации
Не возникало просто такой конкретной ситуации
Это просто один из простых примеров
A
хм, ну да. Тут это было бы полезно, согласен.
Не возникало просто такой конкретной ситуации
Не возникало просто такой конкретной ситуации
Ну не возникало — не используй. Возможно со временем сам к этому прийдешь.
VB
Точно так же, если разработка ведётся быстро, и без тестирования на каждом этапе - Гит позволяет тебе легко найти - на каком этапе ты внёс ошибку в код и он перестал работать
A
Правда я не представляю как в современном мире можно вообще хоть что-то разрабатывать без контроля версий
A
Разве что какие-то одноразовые скрипты
RT
Хорошо, спасибо за ответы)
АК
By @Rostislaved
Rostislav Teryaev:
@ponomarevv @trueflywood
Спасибо за ответы, но все же это больше про то, КАК делать коммиты. А не про то, КОГДА их делать.
Я не могу понять, какие части работы надо объединять в коммиты. Я могу весь проект 1м коммитом сделать, но это не здорово, а как его разбить на мелкие коммиты не понимаю. Может это из-за специфики. Я пишу микросервисы и они правда маленькие.
Небольшой пример.
Если в сервисе идет работа даже с двумя базами, я не пишу сперва весь код для одной базы, чтобы можно было сделать коммит вроде: "Реализовать работу с первой бд", а потом для второй базы, чтобы был коммит "Реализовать работу со второй бд". Я их пишу параллельно, например, потому, что подключение к ним - практически один и тот же код, поэтому легко его сразу скопировать. В таком случае можно было бы сделать коммит: "Реализовал работу с двумя базами", но это как-то не здорово, т.к. в одном комите уже не одно изменение, а несколько.
Более того, я первую версию микросервиса всю пишу вот так вот параллельно, базы, контроллеры, мейн и т.д. Когда-то просто напишу вызов функции, а реализацию оставлю на потом, чтобы оставаться на том же уровне абстракции и вроде того.
После того, как я напишу первый финальный вариант и сервис пойдет в прод, то спустя какое-то время в нем может надо что-то изменить или добавить. И вот только в этом случае получается делать маленькие коммиты, которые будут например:
Исправить опечатку в readme
Обновить хост бд
Собственно, что я хочу понять - это только у меня вот так и проблема во мне?) Или может все в основе своей работают уже с существующим кодом, куда только вносятся исправления и добавляются фичи, поэтому этапа "до 1й версии в проде" у них нет?
Rostislav Teryaev:
@ponomarevv @trueflywood
Спасибо за ответы, но все же это больше про то, КАК делать коммиты. А не про то, КОГДА их делать.
Я не могу понять, какие части работы надо объединять в коммиты. Я могу весь проект 1м коммитом сделать, но это не здорово, а как его разбить на мелкие коммиты не понимаю. Может это из-за специфики. Я пишу микросервисы и они правда маленькие.
Небольшой пример.
Если в сервисе идет работа даже с двумя базами, я не пишу сперва весь код для одной базы, чтобы можно было сделать коммит вроде: "Реализовать работу с первой бд", а потом для второй базы, чтобы был коммит "Реализовать работу со второй бд". Я их пишу параллельно, например, потому, что подключение к ним - практически один и тот же код, поэтому легко его сразу скопировать. В таком случае можно было бы сделать коммит: "Реализовал работу с двумя базами", но это как-то не здорово, т.к. в одном комите уже не одно изменение, а несколько.
Более того, я первую версию микросервиса всю пишу вот так вот параллельно, базы, контроллеры, мейн и т.д. Когда-то просто напишу вызов функции, а реализацию оставлю на потом, чтобы оставаться на том же уровне абстракции и вроде того.
После того, как я напишу первый финальный вариант и сервис пойдет в прод, то спустя какое-то время в нем может надо что-то изменить или добавить. И вот только в этом случае получается делать маленькие коммиты, которые будут например:
Исправить опечатку в readme
Обновить хост бд
Собственно, что я хочу понять - это только у меня вот так и проблема во мне?) Или может все в основе своей работают уже с существующим кодом, куда только вносятся исправления и добавляются фичи, поэтому этапа "до 1й версии в проде" у них нет?
Не заморачивайся размером комита. У меня кормит это состояние изменения между двумя состояниями "работает" кода.
Примерно так:
пишу код -> проверяю что он делает то что надо -> комичу
И так по кругу.
Примерно так:
пишу код -> проверяю что он делает то что надо -> комичу
И так по кругу.
АК
By @Rostislaved
Rostislav Teryaev:
@ponomarevv @trueflywood
Спасибо за ответы, но все же это больше про то, КАК делать коммиты. А не про то, КОГДА их делать.
Я не могу понять, какие части работы надо объединять в коммиты. Я могу весь проект 1м коммитом сделать, но это не здорово, а как его разбить на мелкие коммиты не понимаю. Может это из-за специфики. Я пишу микросервисы и они правда маленькие.
Небольшой пример.
Если в сервисе идет работа даже с двумя базами, я не пишу сперва весь код для одной базы, чтобы можно было сделать коммит вроде: "Реализовать работу с первой бд", а потом для второй базы, чтобы был коммит "Реализовать работу со второй бд". Я их пишу параллельно, например, потому, что подключение к ним - практически один и тот же код, поэтому легко его сразу скопировать. В таком случае можно было бы сделать коммит: "Реализовал работу с двумя базами", но это как-то не здорово, т.к. в одном комите уже не одно изменение, а несколько.
Более того, я первую версию микросервиса всю пишу вот так вот параллельно, базы, контроллеры, мейн и т.д. Когда-то просто напишу вызов функции, а реализацию оставлю на потом, чтобы оставаться на том же уровне абстракции и вроде того.
После того, как я напишу первый финальный вариант и сервис пойдет в прод, то спустя какое-то время в нем может надо что-то изменить или добавить. И вот только в этом случае получается делать маленькие коммиты, которые будут например:
Исправить опечатку в readme
Обновить хост бд
Собственно, что я хочу понять - это только у меня вот так и проблема во мне?) Или может все в основе своей работают уже с существующим кодом, куда только вносятся исправления и добавляются фичи, поэтому этапа "до 1й версии в проде" у них нет?
Rostislav Teryaev:
@ponomarevv @trueflywood
Спасибо за ответы, но все же это больше про то, КАК делать коммиты. А не про то, КОГДА их делать.
Я не могу понять, какие части работы надо объединять в коммиты. Я могу весь проект 1м коммитом сделать, но это не здорово, а как его разбить на мелкие коммиты не понимаю. Может это из-за специфики. Я пишу микросервисы и они правда маленькие.
Небольшой пример.
Если в сервисе идет работа даже с двумя базами, я не пишу сперва весь код для одной базы, чтобы можно было сделать коммит вроде: "Реализовать работу с первой бд", а потом для второй базы, чтобы был коммит "Реализовать работу со второй бд". Я их пишу параллельно, например, потому, что подключение к ним - практически один и тот же код, поэтому легко его сразу скопировать. В таком случае можно было бы сделать коммит: "Реализовал работу с двумя базами", но это как-то не здорово, т.к. в одном комите уже не одно изменение, а несколько.
Более того, я первую версию микросервиса всю пишу вот так вот параллельно, базы, контроллеры, мейн и т.д. Когда-то просто напишу вызов функции, а реализацию оставлю на потом, чтобы оставаться на том же уровне абстракции и вроде того.
После того, как я напишу первый финальный вариант и сервис пойдет в прод, то спустя какое-то время в нем может надо что-то изменить или добавить. И вот только в этом случае получается делать маленькие коммиты, которые будут например:
Исправить опечатку в readme
Обновить хост бд
Собственно, что я хочу понять - это только у меня вот так и проблема во мне?) Или может все в основе своей работают уже с существующим кодом, куда только вносятся исправления и добавляются фичи, поэтому этапа "до 1й версии в проде" у них нет?
Чаще всего это несколько методов в разных классах которые вызывают друг друга.
АК
Обычно, в идеале, один коммит = одна задача. Разбить можно как угодно: пофиксил баг - коммит, добавил комментари - коммит. Если у тебя каждый микросервис в отдельной репе - ну да, сего там коммитить. Но и тут бывает - что-то попоавить, переменную добавить и т.д. Каждое твое действие - коммит. Ты можешь коммитить хоть каждый новый символ - но голова ж у тебя не только чтоб в неё есть. Разбей свою работу на логические этапы.
Я бы сказал, одна задача = одна feature-ветка. Я сторонник git-flow
RT
Спасибо за комментарии, буду иметь в виду)
AK
Ребят, всем привет!
Закоммитил изменения, проморгал один файлик, нужно его убрать из измененных, те из коммита убрать, как можно это сделать?
Закоммитил изменения, проморгал один файлик, нужно его убрать из измененных, те из коммита убрать, как можно это сделать?
CN
git push -u для чего нужен флаг -u и чем отличие если без него запускать?
A
Calle Nord
git push -u для чего нужен флаг -u и чем отличие если без него запускать?
А что документация на этот счет говорит?
A
Ребят, всем привет!
Закоммитил изменения, проморгал один файлик, нужно его убрать из измененных, те из коммита убрать, как можно это сделать?
Закоммитил изменения, проморгал один файлик, нужно его убрать из измененных, те из коммита убрать, как можно это сделать?
Закоммитил или запушил?
AK
Закоммитил или запушил?
Закоммитил, но уже просто покрыл другим коммитом
AK
Хз правильно ли так делать, но сказали что можно revert сделать софтовый
CN
А что документация на этот счет говорит?
git push я знаю, это отправить изменения ветки на сервер, —set-upstream добавить ветку, но про -u ни инфы
CN
Сервер в данном случае это удаленный репозиторий