Как применять Git начинающему?

Question

[Гаджи]

Прошёл несколько курсов по Git, но всё равно нет четкого понимания как с ним работать. Пока только понял, как добавить изменения, закомитить, отправить на гитхаб, скачать оттуда, может ещё с ветками разберусь по ходу дела. И я не знаю как использовать Git на практике в вёрстке. Когда и как часто нужно комитить?

Comments

[Сергей delphinpro]

Закончил таск - закоммитил.

пример

Существует понятие атомарного коммита.
Вот здесь более или менее подробно написано https://qna.habr.com/answer?answer_id=903450#answe...

[4iloveg]

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

Answer 1

[Aleksandr Yurchenko]

Значит курсы были не очень. Git не предназначен ни для верстки, ни для frontend, ни для backend.

Системой контроля версий вы можете отслеживать изменения в чем угодно. И главным преимуществом (на мой взгляд) является ведение своего рода истории работы над проектом и возможность откатиться на определенный его участок.

Плюс при командной разработке отпадают "вопросы: "кто это сделал?", плюс возможность ограничить внесения изменения в определенные ветки (например на продакшен).

Я уверен, что плюсов у Git гораздо больше, назвал известные мне. Не знаю какие вы курсы проходили, но мне хватило githowto, начил ещё читать книгу "Git для профессионального программиста", но меня хватило страниц на 200 :)

Comments

[Гаджи]

Это почему же не нужен для веба? Я во многих вакансиях видел. Даже на известных картах его ставят как обязательные знания.
https://tgraph.io/Dorozhnaya-karta-dlya-veb-razrab...
https://habr.com/ru/post/346010/
У меня немного всё запущенно с усвоением информации. Начал с githowto, потом переключился на видео курсы, но выбрал слишком обёмный курс и в конце уже не помнил, что было в начале. Для себя понял на будущее, что лучше начинать коротких курсов, с самых основ, когда они закрепятся, тогда можно углубится. С изучение CSS тоже самое было. Когда закончил Новую Большую Книгу CSS, забыл что было в начале.

[Aleksandr Yurchenko]

Гаджи, вы меня не правильно поняли.

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

Знание контроля версией сейчас мастхев не только в верстке, я сам сейчас в поисках оффера по бекенду и там он тоже есть, но это не значит, что условно специалист из другой области не сможет использовать Git.

[Гаджи]

Aleksandr Yurchenko, Да понял теперь. Я думал может в вебе подход какой то другой к нему, советы какие нибудь

[Aleksandr Yurchenko]

Гаджи, да в целом все зависит от команды и из правил. Кто-то работает с git flow, правда я с ней ни разу не работал :).
Там где я выполнял проекты была похожая но несколько упрощенная схема.
Есть продакшен, в него заливать может только тим-лид, есть ветка девелом и у каждого отдела свои ветки (фронт, бэк). Внутри этих веток есть ветки конкретных разрабов. Но это касается командной разработки.

Когда я ковыряюсь в одно лицо, обычно 3 ветки: мастер(продакшен), девелоп и далее ветки с конкретными задачами(сделать отправку формы, сделать валидацию и т.д). В Продакшен комичу исключительно из ветки девелом.

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

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

И последнее, советую использовать алиасы, до последнего почему то они вызывали у меня отторжение и я использовал полные команды. Но сейчас без них вообще не могу :)

Answer 2

[Robur]

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

В общем - применяйте так как можете, со временем поймете больше на практике. А то вам сейчас тут насоветуют git-flow, пул-реквесты самому себе, автоверсионирование, деплой через хуки и прочее вам не нужное.

Answer 3

[Владимир Коротенко]

Основные правила такие:

1. Перед началом работы делаете новую ветку, на этап работ, допустим на спринт в 2 недели
2. В спринте есть задачи, каждая выполненная задача это коммит, автоматическое закрытие задачи решается добавлением идентификатора в коммит https://help.github.com/en/github/managing-your-wo...
3. изучите команды amend, blame, status
4. В гите создаете задачи на доске проекта, при коммите они меняют статус в соответствии с п. 2
5. Все документировано и не вызывает вопросов.

Пс данная методика работает не только в github, но и в других системах.

Comments

[GavriKos]

По первому пункту - совершенно необязательно.
По второму пункту - задача может содержать >1 коммита, а если она объемная и содержит не один модуль - то ДОЛЖНА.
По третьему - зачем blame одиночному разработчику
По четвертому - в гите нет задач, доски и проекта. Путаете гит и гитхаб

[Владимир Коротенко]

GavriKos, Да это функционал github, впрочем это есть и в gitlab и в джире и во многих других.

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

Answer 4

[Андрей]

Начинающему верстальщику это ненужно.