Как вы работате с гитом?

Учу Git на этом сайте Основы Git
Недавно начинал работать с гитом, сейчас во всех проектах пытаюсь использовать именно его.
У меня куча вопросов на эту тему, один из них - когда с
делать коммит и push в github?
Пример:
1) Я пишу код, написал первую строку и я должен зафиксировать изменения и коммитить (git add и git commit )?
2) Пишу код, написал несколько строчек и я должен зафиксировать изменения и коммитить?
3) Я пишу код, конкретный функционал, допустим, какую-то функцию, вот я закончил эту функцию, она работает прекрастно, протестил - все ок, и теперь мне коммитить, зафиксировать?

В общем я раньше не использовал git, поэтому не знаю как, где, когда.
На каком шаге зафиксировать и коммитить и т.д. ?
Можете поделиться своим опытом?
  • Вопрос задан
  • 3588 просмотров
Решения вопроса 4
nazarpc
@nazarpc
Open Source enthusiast
Я почти всегда при работе с Git пользуюсь IDE, соответственно все действия с git (почти все, иногда лезу в консоль) делаю через неё.
Обычно коммиты делаются после завершения некоторого логического куска работы (новая фича, исправление бага, добавленный тест или группа тестов, некоторые достаточно существенные промежуточные состояния и так далее), смотрите на GitHub примеры как это делают другие.

То есть кратко:
1) нет
2) нет
3) да
Ответ написан
2ord
@2ord
продвинутый чайник
git add, git commit следует выполнять лишь тогда, когда наращивается значимый функционал или полноценное исправление ошибки, при этом каждая фиксация (commit) должна означать, что программа будет работать исправно как до, так и после фиксации. То есть полурешения, приводящие к неисправной работе программы, фиксировать не следует.
Просто "написал функцию" - это не функционал, а мёртвый код. До тех пор пока эта функция не будет вызываться где-то из кода. Желательно ещё дописать модульный тест для проверки работоспособности данной функции. Вот тогда имеет смысл фиксировать изменения.
Или любое исправление, при котором с новым решением программа работает исправно (сбой не вызыван логическими ошибками и т.д.).
Ответ написан
Astrohas
@Astrohas
Python/Django Developer
1- нет. Коммиты должны что то значить.
2-если что -то то значить то да. если эти пару строк сами по себе ничего не значат то нет
3 - хм тут точно нужно комитить
Ответ написан
@aol-nnov
коммиты ты делаешь тогда, когда считаешь нужным что-то зафиксировать, чтобы потом можно было эти изменения обратить, например.
push-ишь ты тогда, когда хочется поделиться своими наработками с внешним миром.

то есть, ты можешь вообще создать локальный репозиторий и никогда не пущить (муахаха) или пущить раз в неделю/месяц/год.

Можешь уехать на необитаемый остров и там работать спокойно, потом приехать в цивилизацию и всё влить в гитхаб.

В этом прелесть децентрализованных систем контроля версий в противоположность централизованным (например, svn)
Ответ написан
Пригласить эксперта
Ответы на вопрос 8
saintbyte
@saintbyte
Django developer
Коммиты надо делать когда можешь написать комментарий к коммиту
Ответ написан
На самом деле, вы задали достаточно религиозный вопрос.
Я для себя (и команды)
1. Делаю коммит, когда хочу зафиксировать какое-то состояние кода, причём, иногда, это даже состояние типа "WTF".
2. Намного более важно не когда вы делаете коммит, а как вы ветвитесть.
В частности, рекомендуемая практика:
2.0. Коммиты в процессе разработки никогда не делаются в master (хотя бы в develop, чаще нужно больше веток)
2.1. в master-е каждый коммит = релиз (условно стабильный), появляется merge-м из веток разработки.
2.2. На каждую "большую" (это субъективно) фичу делаете новую ветку.
2.3. Таки интенсивная разработка первой (или 0-й) версии и дальнейшей разработки, после первого релиза, скорее всего, будет очень сильно отличаться.
Тут некий шаблон (к сожалению, не "однозначно верно")
https://habrahabr.ru/post/106912/
Ответ написан
Adamos
@Adamos
Контроль версий - это ведь не отчет о проделанной работе, это просто удобный способ вспомнить, как что-то менялось, и сравнить то, что было до, с тем, что стало после.
Коммитить на уровне "написал новую функцию", "добавил новый класс" и, тем более, "создал десять объектов" - по большому счету, бессмысленно.
Вам нужно будет откатываться или хотя бы сравнивать только тогда, когда вы что-то меняете. И когда понадобится сравнить, вам нужно будет знать, что вы поменяли и зачем. Первое вам скажет git, второе - только ваш комментарий к коммиту. И именно в этом его важность, да и важность раздельных коммитов вообще.

В частности, это означает, что если вы занимаетесь каким-то новым классом и поэтому решили исправить API старого - вам желательно вынести исправление старого класса в один коммит (с уточнением, ради чего было исправление), а создание нового класса - в другой. Который вам понадобится когда-нибудь только как отправная точка в списке правок этого класса.

В общем, на git нужно смотреть не снизу (от кода), а сверху - с точки зрения собственных интересов через год-два, когда к этому коммиту придется вернуться. И все станет проще.
Ответ написан
devalone
@devalone
̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻
Я пишу код, конкретный функционал, допустим, какую-то функцию, вот я закончил эту функцию, она работает прекрастно, протестил - все ок, и теперь мне коммитить, зафиксировать?

Вот этот вариант ближе всего, можно даже коммитить, когда реализовал определённый модуль, т.е. слишком часто ни к чему.
Ответ написан
ngreduce
@ngreduce
На feature ветке коммиты на каждый чих (особенно если нет LocalHistory в IDE).
В мастер идет squash - одна feature один коммит. Возможны вариации на тему, если есть staging.

Пушить в свой форк, или отдельную feature ветку как минимум в конце рабочего дня. Страхуетесь на случай проблем с железом или ваших ошибок при перезаписи истории.
А вообще есть определенные методологии. Главное что важно понять - история в вашей локальной ветке очень легко переписывается, надо просто привыкнуть к набору действий чтобы код не потерять.
Ответ написан
dummyman
@dummyman
диссидент-схизматик
Отвечу коротко. Делайте коммит когда все тесты проходят со статусом success.
Ответ написан
В своих проектах зачастую использую Contribution Guide, https://seesparkbox.com/foundry/semantic_commit_me...
очень помогает, когда ты не можешь распределить свои изменения по коммитам.
Ответ написан
guar
@guar
https://t.me/another_way_out
Имхо это на подсознательном уровне, могу попробовать провести аналогию с компьютерными играми, авто-сейв это ваша IDE, она сейвит постоянно код.
Но все таки есть ручные сохранения, во первых они не стакаются в один сейв и вы всегда можете откатится на конкретный момент, во вторых они могут иметь какое то логическое значение так же (прошел босса).
Так и тут, делайте коммит на логических точках, а так же желательно когда заканчивайте работу вечером, мало ли что произойдет с IDE, и всегда делайте push (если вы не в мастере разрабатывайте конечно, что не рекомендуется).
Так же советую пользоваться git через консоль, а не через приложения, так вы сможете воспользоваться любой фичей git и не будете ограничены в интерфейсах приложений. Это относится к любой консольной утилите в принципе.
Да согласен diff не всегда удобен, для этого использую Github Desktop
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы