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

Question

[Akmat]

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

В общем я раньше не использовал git, поэтому не знаю как, где, когда.
На каком шаге зафиксировать и коммитить и т.д. ?
Можете поделиться своим опытом?

Comments

[Толстый Лорри]

Коммитить есть смысл некоторые единицы работы в рамках проекта, атомарные и не ломающие билд (чтобы их можно было откатить). Дробить их можно так, как удобно (если это будет повторять undo/redo редактора, то едва ли это будет удобно), а потом, при желании, перед тем, как они попадут в общедоступный репозиторий (git-push), можно будет сделать git-rebase, слепив кучу мелких коммитов в один большой.

Answer 1

[Назар Мокринский]

Я почти всегда при работе с Git пользуюсь IDE, соответственно все действия с git (почти все, иногда лезу в консоль) делаю через неё.
Обычно коммиты делаются после завершения некоторого логического куска работы (новая фича, исправление бага, добавленный тест или группа тестов, некоторые достаточно существенные промежуточные состояния и так далее), смотрите на GitHub примеры как это делают другие.

То есть кратко:
1) нет
2) нет
3) да

Comments

[zooks]

Тоже пришел к тому, что через IDE работать с гитом удобнее.

[Александр Моргунов]

Я использую SourceTree для работы с гитом. Тоже полезная вещь. Хотя в IDE у JetBrains довольно удобно последнее время работать с git.

[Alexander D.]

Tower. Дорого, но того стоит

Answer 2

[d'Ivan]

git add, git commit следует выполнять лишь тогда, когда наращивается значимый функционал или полноценное исправление ошибки, при этом каждая фиксация (commit) должна означать, что программа будет работать исправно как до, так и после фиксации. То есть полурешения, приводящие к неисправной работе программы, фиксировать не следует.
Просто "написал функцию" - это не функционал, а мёртвый код. До тех пор пока эта функция не будет вызываться где-то из кода. Желательно ещё дописать модульный тест для проверки работоспособности данной функции. Вот тогда имеет смысл фиксировать изменения.
Или любое исправление, при котором с новым решением программа работает исправно (сбой не вызыван логическими ошибками и т.д.).

Comments

[Roman Mindlin]

"написал функцию" - тоже иногда имеет смысл, если есть четкий план работы. Сделал N объектов, в конце дня зафиксировал. Как минимум, чтобы другие видели.

[zooks]

Roman Mindlin: именно так - он же коммитит, а не пушит.

[Roman Mindlin]

zooks:

Answer 3

[Astrohas]

1- нет. Коммиты должны что то значить.
2-если что -то то значить то да. если эти пару строк сами по себе ничего не значат то нет
3 - хм тут точно нужно комитить

Answer 4

[aol-nnov]

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

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

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

В этом прелесть децентрализованных систем контроля версий в противоположность централизованным (например, svn)

Comments

[Stalker_RED]

Пушить раз в месяц - плохая практика, т.к. при откатывании такого коммита откатится все что сделано за месяц. уезжая на остров можно же отдельную ветку завести, и в ней уже коммитить каждый значимый кусок кода. Весь смысл гита в том, чтобы можно было откатывать именно частями - отдельными коммитами, а делая огромные коммиты "работа васи за октябрь" вы всё идею убиваете.

[aol-nnov]

Stalker_RED: коммитить раз в месяц - плохо. пущить? личное дело каждого.
разберитесь в предмете, сударь!

[Saboteur]

Какое отношение это имеет "в противоположность централизованным" системам?

Кто мешает поднять вам SVN на локальной машине и уехать с ней в отпуск, спокойно там работая?
А потом приехать и влить изменения в тот же гитхаб с такой же "легкостью" (это если никто ничего не трогал тут)

Прелесть децентрализированных систем несколько в другом.

[Василий Назаров]

Кто мешает поднять вам SVN на локальной машине

Как минимум, осознание факта, что SVN - каменный век

Answer 5

[Егор Казанцев]

Коммиты надо делать когда можешь написать комментарий к коммиту

Comments

[Astrohas]

очень тонко

Answer 6

[Василий Назаров]

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

Answer 7

[Adamos]

Контроль версий - это ведь не отчет о проделанной работе, это просто удобный способ вспомнить, как что-то менялось, и сравнить то, что было до, с тем, что стало после.
Коммитить на уровне "написал новую функцию", "добавил новый класс" и, тем более, "создал десять объектов" - по большому счету, бессмысленно.
Вам нужно будет откатываться или хотя бы сравнивать только тогда, когда вы что-то меняете. И когда понадобится сравнить, вам нужно будет знать, что вы поменяли и зачем. Первое вам скажет git, второе - только ваш комментарий к коммиту. И именно в этом его важность, да и важность раздельных коммитов вообще.

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

В общем, на git нужно смотреть не снизу (от кода), а сверху - с точки зрения собственных интересов через год-два, когда к этому коммиту придется вернуться. И все станет проще.

Answer 8

[devalone]

Я пишу код, конкретный функционал, допустим, какую-то функцию, вот я закончил эту функцию, она работает прекрастно, протестил - все ок, и теперь мне коммитить, зафиксировать?

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

Answer 9

[ngreduce]

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

Пушить в свой форк, или отдельную feature ветку как минимум в конце рабочего дня. Страхуетесь на случай проблем с железом или ваших ошибок при перезаписи истории.
А вообще есть определенные методологии. Главное что важно понять - история в вашей локальной ветке очень легко переписывается, надо просто привыкнуть к набору действий чтобы код не потерять.

Answer 10

[dummyman]

Отвечу коротко. Делайте коммит когда все тесты проходят со статусом success.

Answer 11

[Владислав Яндимиркин]

В своих проектах зачастую использую Contribution Guide, https://seesparkbox.com/foundry/semantic_commit_me...
очень помогает, когда ты не можешь распределить свои изменения по коммитам.