Комментарии 12
Заголовок предполагает инструкцию по лечению git'а, а в статье инструкция по использованию оного.
Я по какой-то непонятной причине почти не пользуюсь IDE
Лично я комичу из IDE
т.е. вы почти не комитите?
Вы просто перечислим некоторые команды git. git help > habr
Как по мне, мне более подходит другой подход:
1) Создаём (или используем сущуствующую) ветку develop с master-a;
2) Создаем ветку, как говорил автор, для фичи с названием (или ID) в Gira или др.;
3) Пишем код, делая время от времени коммиты;
4) Делаем Rebase;
5) Выполняем push в свою ветку;
6) После review, если с кодом всё нормально, делаем слиение нашей ветки в develop (Можно сначало develop в нашу ветку, дабы узнать какие нас ждут конфликты);
7) Если нужно доделывать, то доделываем);
8) Удаляем origin/[наша ветка];
9) Делаем нужные правки и делаем коммит;
10) Снова Rebase и идём к пункту 5;
11) Переходим в develop с нашими изменениями;
12) Переходим к пункту 1.
P.S. Правило:
Одной фичей занимается один человек. Один человек занимается одной фичей.
1) Создаём (или используем сущуствующую) ветку develop с master-a;
2) Создаем ветку, как говорил автор, для фичи с названием (или ID) в Gira или др.;
3) Пишем код, делая время от времени коммиты;
4) Делаем Rebase;
5) Выполняем push в свою ветку;
6) После review, если с кодом всё нормально, делаем слиение нашей ветки в develop (Можно сначало develop в нашу ветку, дабы узнать какие нас ждут конфликты);
7) Если нужно доделывать, то доделываем);
8) Удаляем origin/[наша ветка];
9) Делаем нужные правки и делаем коммит;
10) Снова Rebase и идём к пункту 5;
11) Переходим в develop с нашими изменениями;
12) Переходим к пункту 1.
P.S. Правило:
Одной фичей занимается один человек. Один человек занимается одной фичей.
Пожалуй что не соглашусь с правилом 1 фича — 1 выстрелчеловек. В идеальном мире — да, возможно.
Допустим мы решили на сайте сделать новую кнопочку. У нас есть верстальщик и программист. Дизайнер нам все нарисовал, верстальщик сверстал, программист сделал, а оно не работает. Например верстальщик что-то не учел и в общей верстке это не работает. Или пришел продукт, посмотрел, не понравилось, решили переделать. Надо править. Это норма.
Или разработчик бэкенд, разработчик фронтенд. Да, набросали АПИ, но что это за работа в которой не требуется изменений.
Или 10 лет назад вообще все комитили в мастер и никого это не смущало.
Допустим мы решили на сайте сделать новую кнопочку. У нас есть верстальщик и программист. Дизайнер нам все нарисовал, верстальщик сверстал, программист сделал, а оно не работает. Например верстальщик что-то не учел и в общей верстке это не работает. Или пришел продукт, посмотрел, не понравилось, решили переделать. Надо править. Это норма.
Или разработчик бэкенд, разработчик фронтенд. Да, набросали АПИ, но что это за работа в которой не требуется изменений.
Или 10 лет назад вообще все комитили в мастер и никого это не смущало.
Смотрим какие файлы конфликтуют (both modified)
# git status
, правим их, добавляем
# git add «conflict_file_name»
правим? неужто руками? может лучше
git mergetool
Шпоргалки, мануалы, обзоры, книги по теме — все полезны. Хорошо, когда это уже прочно входит в память, т.к. регулярное использование оставляет свой отпечаток.
Спасибо за статью. +1 в закладки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Еще одна инструкция по пользованию git