Еще одна инструкция по пользованию git

[Shtucer]

Заголовок предполагает инструкцию по лечению git'а, а в статье инструкция по использованию оного.

[Dreyk]

занудливый конечно комментарий, но (как часто и бывает с занудствованием) — верный

[domix32]

А чем он у вас болен?

[Shtucer]

С чего вы решили, что он у меня болен?

[domix32]

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

[Shtucer]

Не я предлагаю, а автор поста. Будьте внимательны.

[KoMePcAHT]

Я по какой-то непонятной причине почти не пользуюсь IDE

Лично я комичу из IDE

т.е. вы почти не комитите?

[BerkutEagle]

Вы просто перечислим некоторые команды git. git help > habr

[iberezhnyk]

Как по мне, мне более подходит другой подход:
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. Правило:
Одной фичей занимается один человек. Один человек занимается одной фичей.

[pinoquinho]

Пожалуй что не соглашусь с правилом 1 фича — 1 выстрелчеловек. В идеальном мире — да, возможно.
Допустим мы решили на сайте сделать новую кнопочку. У нас есть верстальщик и программист. Дизайнер нам все нарисовал, верстальщик сверстал, программист сделал, а оно не работает. Например верстальщик что-то не учел и в общей верстке это не работает. Или пришел продукт, посмотрел, не понравилось, решили переделать. Надо править. Это норма.
Или разработчик бэкенд, разработчик фронтенд. Да, набросали АПИ, но что это за работа в которой не требуется изменений.
Или 10 лет назад вообще все комитили в мастер и никого это не смущало.

[ashumkin]

Смотрим какие файлы конфликтуют (both modified)

# git status

, правим их, добавляем

# git add «conflict_file_name»

правим? неужто руками? может лучше

git mergetool

?

[KeyJoo]

Шпоргалки, мануалы, обзоры, книги по теме — все полезны. Хорошо, когда это уже прочно входит в память, т.к. регулярное использование оставляет свой отпечаток.
Спасибо за статью. +1 в закладки.