В плане слияния веток `git merge` отличается от `git rebase` только тем, как выглядит история коммитов, насколько она красива и понятна.
Если несколько разработчиков коммитят в одну и ту же ветку, тогда мы не запускаем пул, что загрузить master ветку
```
git pull origin master
```
Мы делаем это с параметром
```
git pull --rebase origin master
```
И после пушим ветку на сервер.
```
git push origin master
```
У нас не будет коммитов слияния 'merge branch'.
План работы:
1. Создаем новую ветку от master
```
git checkout -b new-feature
```
2. Но за это время разработчики закоммитили в мастер правки, нам нужно подтянуть в свою ветку свежий мастер, чтобы убедиться, что его работа не ломает работу. Переключаемся на мастер, стягивает свежие коммиты
```
git checkout master
git pull --rebase origin master
```
и переходит обратно в свою ветку
```
git checkout new-feature
```
3. Запускаем мерже с master
```
git rebase master
```
4. Cливаем ветку new-feature в master и удаляем её
```
git checkout master
git merge --no-ff new-feature
git branch -d new-feature
```
Флаг --no-ff предотвращает выполнение git merge "fast-forward", если он обнаруживает, что ваш текущий HEAD является предком фиксации(коммита), которую вы пытаетесь выполнить merge. Быстрая перемотка вперед-это когда вместо построения merge фиксации(коммита) git просто перемещает указатель ветви, чтобы указать на входящую фиксацию(коммит). Это обычно происходит при выполнении git pull без каких-либо локальных изменений.
P.S. Негласное правило. Без опаски пользуйтесь git rebase смело до тех пор, пока Вы работаете в своей ветке один. Как только к ветке присоединяется ваш коллега, подтягивайте изменения из основной ветки через merge. Это связано с тем, что rebase перезаписывает историю коммитов, и пушить на сервер вам придется с опцией --force.