Александр Докин

Оба разработчика, когда работают в своих ветках, должны поддерживать актуальное состояние, т.е. периодически вливать (merge) dev в свою ветку.

Поэтому, прежде чем делать pull request, разработчик B должен вмержить dev в свою ветку. В случае, если при этом возникнут конфликты, он решает их внутри своей ветки. И только после того, как он удостоверится, что эта ветка содержит все коммиты из dev и все тесты проходят, можно делать pull request в dev.

Для начала: есть понятие локального (local) и удаленного (remote) репозитория.
origin - это синоним remote-репозитория, т.е. origin/name - это remote ветка, а просто name - соответствующая локальная ветка.

Remote-репозиторий используется как централизованное хранилище, с которым синхронизируются разработчики с помощью git pull origin/name. Это последовательное выполнение git fetch и git merge. Fetch берет изменения с remote-репозитория, а merge пытается применить их к соответствующим локальным веткам.

Если вы новичок, советую изучить хотя бы основы Git. Отличный способ это сделать - внимательно почитать https://git-scm.com/book.

Полезные главы:

• Работа с удалёнными репозиториями
  
• О ветвлении в двух словах
  

Нет, если редактировались разные файлы, то конфликтов не будет.

Когда вы работаете в ветке, обязательно поддерживайте ее в актуальном состоянии мастера. Т.е. в данном случае после пуша в master (167) переключайтесь на ветку staging (104) и делайте merge мастера в нее. Если даже будут конфликты - разруливаете их в этой отдельной ветке, не трогая master.