Евгений

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

Файлы, которые генерируются или относятся к другим проектам, никогда не должны включаться в git. Это увеличивает размер репозитория, затрудняет обновление. Фактически, вы с самого начала создаете большую свалку, в которой с самого начала будет не разобраться, а спустя месяцы — тем более, ради мнимого «удобства».

В репозиторий добавляйте только те файлы, которые пишете/изменяете вы сами.

А фреймворк, например, устанавливается в каждой копии разработчика или на сервере командами npm или yarn.

На вопрос сложно ответить, не зная на чем вы разрабатываете. Когда я разрабатываю на Django, то у меня в каждом проекте есть пакет settings с тремя модулями: production, development и local. Если для разработки требуются миграции, изменяющие схему, я делаю копию базы (pg_dump | psql) с соответствующим названиям, и в local_settings прописываю название копии.

В одном проекте, где у меня очень много веток и заказчику важно, чтобы все они были независимы (он делает скрупулезный code review по каждой и мержит каждую по отдельности), я немного автоматизировал этот процесс:

database = 'frobnicator'
branch = subprocess.check_output(['git', 'rev-parse', '--abbrev-ref', 'HEAD']).decode('ascii').strip()
if branch.startswith('python-3'):
    database = 'frobnicator-python3-port'
elif branch == 'master' or branch.startswith('FB-472'):
    database = 'frobnicator-filestack-integration'
else:
    raise RuntimeError('Please, update configuration file to use correct database')

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': database,
        'USER': '',
        'PASSWORD': '',
        'HOST': 'localhost',
        'PORT': '5432',
    }
}

Мне кажется, что здесь сложно дать однозначный ответ. Для начала, каждый разработчик должен изучить основные принципы и команды Git. Я много раз сталкивался (и продолжаю сталкиваться) с тем, что разработчики заучивают 2-3 команды (git commit/git pull/git push) и просто долбят их вообще не понимая, что эти команды делают. IDE делают этот процесс еще хуже, потому что там даже не надо задумываться над тем, что вбиваешь, разработчик просто нажимает кнопочку и получает грязь в репозитории. А потом в Slack-чате кричит: «Я все сделал по бумажке! Как мне сказали, сделал git commit и git push, это ваш долбаный git напортачил!» (на самом деле слышал такое и не раз).

Затем можно сделать репозиторий например, с ветками master и ветками, в которые разработчики добавляют новые фичи (или исправляют баги). Например, add-new-image-upload. Так называемые feature-branch'и. При заканчивании работы в feature-бранче, сливать их с master. Высший пилотаж — делать rebase перед слиянием, чтобы не загромождать историю бесполезными merge commits. Еще боле высший пилотаж — перейти на git-flow, который автоматизирует работу с бранчами master, development, feature branches, hotfixes, release branches. Но забегать вперед не стоит.

Сначала git pull, затем git merge. Или можно попытаться сделать rebase, но судя по вопросу, вам этого вопроса касаться еще рано.