how-to-one-branch-git.md

При начале работы обязательно выполняем:

git pull

А в конце работы обязательно выполняем:

git push

Это вообще хорошая практика, оставлять репозиторий в консистентном состоянии после окончания работы и обновлять состояние непосредственно перед тем как приступить к работе.

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

• Работаем с кодом как обычно. Пилим свою функциональность, коммитим какие-то законченные по смыслу этапы. В общем, тут все как обычно.
• Когда функциональность закончена, спокойно выполняем команду:

git push

• Если удалось запушить, значит никаких изменений никто до тебя внести не успел. Твоя работа тут закончена, можно пилить следующую фичу.
• Если в ответ на команду ты видишь такое:

git push

To [email protected]:USER_NAME/REPOCITORY_NAME.git
 ! [rejected]        BRANCH_NAME -> BRANCH_NAME (fetch first)
error: failed to push some refs to '[email protected]:USER_NAME/REPOCITORY_NAME.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

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

git pull --rebase

или тоже самое, но короче:

git pull -r

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

git add CONFLICT_FILE_NAME

Затем выполняем:

git rebase --continue

Если снова появились конфликты, продолжаем решать их до бавлять и продолжать ребейс. В конечном итоге, при очередном выполнении команды продолжения ребейс, накатится вся история. И можно выполнить:

git push

• Вот и все.

История чистая. Никаких git push --force. По возможности стоит чаще делать этот push. Чтобы по максимому пользоваться приемуществом быстрого досутпа к коду написанному товаризами по воркфлоу.