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

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

Судя по приведённой в комментариях ссылке, там используется bearer-аутентификация.

Получив token после авторизации, передавайте его в заголовках запроса в виде:
Authorization: Bearer awesome-token-12345

Именно так сервер поймёт, от кого именно идет запрос
https://swagger.io/docs/specification/authenticati...

Создайте переменную count и в каждой итерации цикла прибавляйте к ней 1 :)

Оба разработчика, когда работают в своих ветках, должны поддерживать актуальное состояние, т.е. периодически вливать (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.

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

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