svfat
@svfat
☺Нужен VPS? Два месяца бесплатно. Смотри профиль☺

Как вы используете git при разработке в одиночку?

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

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

Как вы с этим справляетесь? И вообще нужен ли здесь Git Flow или забить на все и работать как работается?
  • Вопрос задан
  • 7180 просмотров
Решения вопроса 9
Adamos
@Adamos
Для себя одного git, как мне кажется, нужен только как "машина времени" и "обратный роадмап".
То есть, чтобы иметь возможность посмотреть более ранний вариант кода и чтобы в потоке коммитов найти, когда были какие-то конкретные изменения.
По большому счету, ничего, кроме коммитов в мастер, тут и не требуется. Разве что желательны мелкие коммиты с осмысленным написанием изменений, а не куски того, о чем сам не вспомнишь через неделю.
Ответ написан
@kirill-93
Ну я думаю, что не стоит рассказывать о прелестях и возможностях гита. Если вы работаете в одиночку, то не обязательно использовать ветки. Можно и в мастер коммитить, и использовать для того, чтоб всегда можно было откатиться к любой версии. Я тоже, когда работаю над небольшими проектами в одиночку не пользуюсь ветками. Но если проект "живой", и весит в вебе, то всегда есть риск, что что-нибудь сломается, и тогда, чтоб в попыхах не ломать голову, пытаясь найти ошибку, и не наломать дров, как обычно и бывает, когда срочно нужно что то поправить, можно спокойно откатиться до рабочей версии и искать неспеша ошибку. Хотя бы ради этого стоит использовать гит.
Ответ написан
@carbon88
.NET developer/ORM developer
Конечно сложно себя дисциплинировать. Но когда вырабатывается привычка, то стараешься писать осмысленные комментарии к комитам. Особенно когда нужно что-то найти в десятке тысяч комитов, тытаешься делать так чтобы было понятно по описанию комита. Иначе придется постоянно копаться в самих изменениях комитов, чтобы найти то, что нужно. По сути, в пределах отдельной ветки которая названа более-менее нормально (а мы стараемся делать именно так, ветка на каждый task или issue и по завершению закрывать и сливать с основной) можно и писать менее осмысленные комментарии.

Нужно себя пересиливать, выдавать себе люлей раз начальника нет хотябы полгодика, типа "какого х.. тут ты понаписал этот бред!? ни..я ведь не понятно что да как в этом комите!". Потом втянитесь и скилл наработаете. Мне было лениво писать хорошие комменты комитов, когда английский был не очень (все только на нем, даже в коде описания и комментарии только на нем), сложно было попросту. А сейчас подтянул, словарный запас поднатаскал, скилл наработал и проще сформировать мысли при комите.

В общем будьте самокритичнее и требовательнее к себе. Или вы, извиняюсь, настолько тряпка что не можете дать себе "бодрящего пенделя" когда это надо?
Ответ написан
IonDen
@IonDen
JavaScript developer. IonDen.com
Пока вы ведете проекты в гит только для себя, никогда вы не сможете внедрить гит флоу нормально.

Это пойдет в тот момент, когда вы будете разрабатывать какие-нибудь большие продукты, например Open Source, где важно соблюдать версии, писать четкие описание изменений и т.д. Ну или поработать в команде, так чтобы это засело в подкорку.
Ответ написан
@Akellacom
CTO
Постоянно использую, комичу все изменения по разным задачам по проекту, пишу осмысленный комментарий, не испытываю проблем. Это уже как привычка.
Ответ написан
AlexZaharow
@AlexZaharow
Программист. Javascript, Java!
Работаю хоть и в большой фирме, но сказал бы, что почти в одиночку, но если бы не ветки с мерджами, было бы труднее. В какой-то момент перестало хватать только git и я вокруг git построил небольшую инфраструктуру:

- Поставил на работе gitlab, загрузил с github несколько значимых, проектов, потому что некоторые были с ошибками, исправил те ошибки, теперь можно скачивать с github новые версии и применять свои исправления
- незаметно количество проектов выросло почти до 70 штук и похоже, что будет расти дальше. Часть из них - эксперименты с подробной документацией. На работе иногда перекидывают на разные работы, документация позволяет контекст вспомнить
- веду лайфлог в zim wiki desktop и на свой gitlab периодически выкладываю.
- стараюсь популяризовать git среди своих коллег.

Вывод - пренебрегать flow не стоит. Неизвестно, когда потребуется вернуться назад и к этому надо быть готовому (немного популистски, но близко к реальности).
Ответ написан
Vityarik
@Vityarik
1) Коммитить чаще, тогда проще придумать что написать в комментарии, а чтобы проще разобраться в этих мелких коммитах объединять их в ветках.

2) Не забывать для чего вы используете git:
- знать когда что и зачем исправил в коде
- иметь возможность переключится на состояние кода на момент релиз и сделать hotfix
- ... ?
Если будете помнить зачем вам git автоматически будете делать коммиты и организовывать ветки правильно.
Ответ написан
@abcd0x00
Использую git по принципу master/devel. В master идут только крупные изменения вроде новых версий, которые помечаются тегами. В devel идут только принимаемые изменения (никаких ошибок). Для каждого нового процесса создаётся ветвь, которая вливается в devel, когда полностью завершена. А вот ветвь процесса может быть одна или ветвиться дальше.

Зачем это нужно? Проектов много, каждому по несколько лет уже. Когда через год открываешь что-то, то не очень помнишь, какие там были нюансы, задумки. У меня бывало уже такое, что я открывал собственный код и никак не мог даже вспомнить, когда это я его писал.
Ответ написан
Хороший вопрос! В нашей веб-студии все сайты делаются одним разработчиком. И почти всегда на продакшене. Потому что сайт - это сайт. Клиент тыкает пальчиком и хочет фичу - сделал, показал, уточнил, переделал. И пусть меня закидают камнями, но в большинстве проектов система контроля версий не нужна. Нужны обычные резервные копии.

Однако:

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

Есть проекты, когда нельзя вести разработку на продакшене. Например, тестируем выгрузку каталога товаров из 1С. Тогда удобно делать две копии продукта: дев и продакшен. Делать разработку на деве и отправлять изменения на продакшен.

У себя мы используем mercurial. Но в гит логика аналогичная.
Ответ написан
Пригласить эксперта
Ответы на вопрос 5
opium
@opium
Просто люблю качественно работать
Просто коммичу любые значимые изменения с вменяемым небольшим комментом
Ответ написан
Antonoff
@Antonoff
Разработчик
Стараюсь использовать гит, без gitflow, иногда хорошо самому себе спасает жопу, когда наговнокодил и нужно ресторнуть предыдущую версию.
Ответ написан
@zjoin
Я для разработки использую ветку dev. И к конце каждого дня делаю коммиты в ветку master.
Ответ написан
tvolf
@tvolf
Нашел одну веселую картинку на тему умения правильно давать названия коммитам ) В свое время очень она меня порадовала )
hhGnpOF.jpg
Ответ написан
trevoga_su
@trevoga_su
использую svn чисто как удаленное хранилище, что бы из любой точки можно взять код и начать его дописывать.
версионность вообще не нужна, когда один работаешь. даже ни разу не было потребности смотреть в историю.
Ответ написан
Ваш ответ на вопрос

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

Войти через центр авторизации
Похожие вопросы
Antilatency Воронеж
от 50 000 до 200 000 руб.
Acme Crypto Corp Нижний Новгород
от 150 000 до 250 000 руб.
CORE Москва
от 100 000 до 150 000 руб.
22 февр. 2019, в 20:42
400 руб./в час
22 февр. 2019, в 20:23
2000 руб./за проект
22 февр. 2019, в 19:31
20000 руб./за проект