iMaximus

Не работает, видимо потому, что файлу нужно было дать нормальное имя.
Правда, не совсем понятно зачем создавать файлы руками если все необходимые данных можно задать командами через терминал или вообще в Git клиенте если используете Sourcetree например.

1. Файл [path]/etc/gitconfig содержит значения, общие для всех пользователей системы и для всех их репозиториев. Если при запуске git config указать параметр --system, то параметры будут читаться и сохраняться именно в этот файл. Так как этот файл является системным, то вам потребуются права суперпользователя для внесения изменений в него.
   
   
2. Файл ~/.gitconfig или ~/.config/git/config хранит настройки конкретного пользователя. Этот файл используется при указании параметра --global и применяется ко всем репозиториям, с которыми вы работаете в текущей системе.
   
   
3. Файл config в каталоге Git (т. е. .git/config) репозитория, который вы используете в данный момент, хранит настройки конкретного репозитория. Вы можете заставить Git читать и писать в этот файл с помощью параметра --local, но на самом деле это значение по умолчанию. Неудивительно, что вам нужно находиться где-то в репозитории Git, чтобы эта опция работала правильно.
   

Можно делать аmend если сделали commit потом внесли какие то изменения и хотите чтобы они попали в последний commit. Если commits несколько можно сделать squash commits т.e. из 5 сделать один.

Лично я обычно поступаю следующим образом. Отвожу ветку от dev например dev_new_1 творю там любую дичь хоть 20 commits с идиотскими названиями. Когда понимаю что задача готова отвожу из последней версии dev свежую ветку допустим dev_new_2 в данный момент она равна dev

Далее
git checkout dev_new_2
git merge --squash dev_new_1
Смотрите что там все ваши изменения и проверяете еще раз
git commit -m 'merged dev_new_1'

Получается ветка со всеми вашими изменениями и одним commit.
Эту ветку уже выставляю на pull request
А за портянку из мусорных commits в серьезной конторе действительно могут побить :)

Там же написано все. Кто то уже сделал изменения. Нужно их забрать сделать git pull а уже потом пушить свои.

Правильно создавать Pull Request на bitbucket. После того как его посмотрят и заапрувят один или несколько разработчиков, он мержится в мастер ветку. В результате, меньше гомна в коде и всегда можно посмотреть, кто что мержил в доступной форме. По крайней мере 146% работают именно так, отличия воосновном в правилах принятия PR.

Сохранить изменения в Stash, а потом загружать этот Stash в какую угодно ветку. Всегда так делаю если путаю ветки или по каким то причинам не хочу в данный момент делать коммит.

Когда вы сделали git pull у вас появились незакоммиченные изменения. Нужно решить конфликты и сделать коммит. После этого уже можно спокойно сделать push. Сам конфликт за вас никто не решит, нужно смотреть код и выбирать чьи изменения оставлять или оставлять все.

Когда вы сделали pull c мастер ветки все изменения оказались в старой, плюс вы добавили еще один свой коммит. Естественно на remote ветке ничего не изменилось. Вот он вам и показывает что вы запушите туда кучу изменений с мастера плюс еще один свой последний.

Способов полно, проще всего черепикнуть. Если из терминала то

Переходим на мастер ветку
git checkout master

делаем пул на всякий случай чтобы были последние изменения
git pull origin master

Далее делаем сам черепик
git cherry-pick eb042098a5

eb042098a5 код коммита который вы сделали не в той ветке. У вас, естественно он другой.

Все, пушим в мастер
git push origin master

Профит, наш коммит в мастере.

Мое мнение что нет, даже если вы попадете в организацию где используют другие системы контроля, (мне такие не встречались) без труда адаптируетесь.