Каков сценарий использования git для одного разработчика?

Привет.

Наконец-то хочу разобраться с git'ом и понять, как его правильно использовать для работы в одиночку.

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

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

Как делать по другому и правильно? Создать ветку "dev", и все недоделанное коммитить в нее? И только потом в master?
  • Вопрос задан
  • 10360 просмотров
Решения вопроса 1
gobananas
@gobananas
finishhim.ru
Делаете ветку master, ветку dev и отдельные ветки под отдельные фичи.
Делаете 2 сайта - один сам проект (основной) - на него выкатываете master, второй сайт тестовый - на него выкатываете ветку dev. Остальные ветки разрабатываете, сливаете с dev выкатываете на тест, если там всё нормально то dev сливаете с мастером. За ноут просто когда садитесь если мастер новый есть делаете git pull и стягиваете новую версию
Ответ написан
Пригласить эксперта
Ответы на вопрос 9
KazeZlat
@KazeZlat
Погромист-затейник
Работаете в ветке dev, периодически вливая ее в master. Для крупных задач (не входящих в один коммит) делаете отдельные ветви из dev.

Вливая dev в master, делаете это с ключом --squash как то так:
git checkout master
git merge --squash dev

Тут теоретически могут быть конфликты, если вы делали коммиты в masterпараллельно с dev, которые вам надо разрешить, а после уже добавляете и делаете один большой коммит:
git add -A
git commit -m "Merged dev: %кратко (или нет) основные изменения%"
git push


А чтобы не мозолили глаз висящие коммиты с логической незавершенностью, их можно сливать их перед merge с помощью интерактивного rebase:
git checkout dev
git rebase -i master

Откроется редактор, в котором будет список коммитов ветки dev. Здесь можете слепить ненавистные коммиты с помощью команды squash (и тогда вам предложат отредактировать сообщение) или fixup (тут не предложат) и потом сделать git push --force (для одного не критично, в толпе лучше использовать --force-with-lease.

Или есть еще вариант - лепить к предыдущему коммиту сразу с помощью git commit --amend

Ну и после merge уже можете на master лейбл версии повесить.
Ответ написан
Комментировать
Есть очень простое правило - правильно так, как проще.

Можете вовсе использовать master для синхронизации всех файлов, ничего страшного если идет активная стадия разработки, Вы единственный разработчик, а релиз еще очень нескоро. И если умеете не перескакивать от одной недоделанной задачи к другой.

Как только понадобится делать релизы, там уже можно заморочиться с master, staging, feature-бранчами и тп, но только по мере необходимости.

PS. Раз уж мы действуем по принципу KISS, вместо утилиты командной строки лучше использовать удобный GUI, например на Mac это Source Tree (по-моему самая классная программа на моем ноуте).
Это также поможет работать с гитом правильнее - вручную просматривать и стейджить каждый измененный файл, а не через git add -A.
Ответ написан
Комментировать
@InoMono
Если вы не фиксите баги в старой версии, одновременно делая и новую версию - то отдельные ветки вам не нужны.
Для начала освоение научитесь делать четкие коммиты. Чтобы изменения (файлы включенные в коммит) и цель этих изменений (комментарий коммита) совпадали
Ответ написан
Комментировать
@iMaximus
Все просто, работаете на компьютере. Перед тем как закончить, все коммитите и делаете push. Сели за ноут делаете pull.
Если пилите новую фичу, или что то глобальное, лучше создать отдельную ветку, и пока все не закончите делать на ней. На само деле это не обязательно, так как в любом случае все commits и history будут и так видны, а накосячить одному, мало реально, даже если делать все на мастере.
Главное, не забывать простое правило, сел за комп pull перед уходом от компа push.
Ответ написан
Комментировать
@Vasiliy_M
ничего не понял
Предположим, я что-то поделал на компе, недоделал, закоммитил в локальный репозиторий и запушил на сервер
зачем вам коммитить в локальный репозиторий?

Но при таком сценарии использования на сервере будет куча коммитов с недоделланым функционалом. Фактически удаленный репозиторий станет лишь местом синхронизации файлов.
Ору!! А тебе что нужно? Что бы каждый коммит был законченным изменением? Разбивай тогда задачу на мелкие подзадачи.

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

Написал метод, верстку сделал или рефакторинг - пушу. Даже комменты не пишу.
Ответ написан
Sly_tom_cat
@Sly_tom_cat
.
Для синхронизации между двумя компами использую syncthing.
git и github (как remote master) используется именно для осмысленных коммитов с законченными доработками.
Так у меня чистая история коммитов, ни ребейзов ни прочей сомнительной активности для приведения истории в порядок - не нужны.

Но это не отменяет использования веток. Отдельная фича - отдельная ветка. Почти рабочее - мержу в dev. После тестирования меджу dev в master. В мастер стараюсь напрямую не коммитить, разве что какие-то обновления readme и прочей атрибутики.

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

Когда вполне созрела версия - создаю релиз (прямо на github-е) ну попутно лью в PPA на launcpad (это уже собственно к разработке не имеет отношения - это автоматическая доставка обновлений пользователям).
Ответ написан
Комментировать
@motomac
Тоже использую develop ветку для подобного, но в последнее время все больше склоняюсь к мысли, что это не нужно.
  1. Пушить незаконченный код не хочется
  2. Придумывать этому незаконченному коду описание при каждодневной работе утомляет
  3. На историю коммитов потом смотреть больно

Возможно, стоит попробовать дополнительно к гиту юзать какой-нибудь Dropbox и пушить только законченные осмысленные вещи.
Ответ написан
@kapod
Коммитить всё как есть в отдельную ветку (dev или тематичную таске), по завершению таски — ребейз для красоты истории и мерж в мастер.
Ответ написан
Комментировать
Zordhauer
@Zordhauer
я использую master в качестве основной ветки разработки, куда стараюсь пушить преимущественно рабочий и законченный код. Для процесса разработки создаю отдельные тематические ветки, которые перед слиянием с мастером (ну и периодически для долгоживущих веток) привожу в порядок с помощью git rebase.
Продакшн код (релизы) подготавливаю в отдельной ветке и сливаю release ветку с master и production.
Нерабочий код и всякие недоделки коммичу только в тематические ветки и добавляю к описанию коммита префикс "WIP" (work-in-progress) и иногда дополняю инфой о том, что ещё хотел,но не успел сделать.

Как я понимаю, это преимущественно gitflow политика, с примесью Gilab flow (когда ветка разработки - это master).
Ответ написан
Комментировать
Ваш ответ на вопрос

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

Похожие вопросы
23 нояб. 2024, в 12:39
100000 руб./за проект
23 нояб. 2024, в 12:16
60000 руб./за проект
23 нояб. 2024, в 08:36
2000 руб./за проект