Mithgol

Предпочитаю второй подход, потому что считаю полезною подробную историю и ясно видные места слияний.

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

К числу таких проектов относится, например, Node.

Короче вопрос в том — что делать с чужим кодом типо jQuery например или другими подобными контроллами и библиотеками? где их выкладывать? к себе в проект?? как добиться чтобы была именно та версия что мне нужна, а не какая то иная, ведь авторы дописывают библиотеки постоянно?

Возможны следующие варианты:

• Целиком класть чужой код к себе в проект.  Тогда в проекте будет именно та версия, что нужна.
   
• Не класть код к себе в проект.  Тогда следует составить в README-файле подробную и понятную инструкцию для пользователей проекта: где раздобыть чужой код, необходимый для работы проекта, и как установить, чтобы всё работало.
   
• Подключить чужой код в своей проект в виде git-подмодуля.  Пользователь сможет подать простую команду Git, после чего чужой код скачается откуда следует и установится куда надо. Работает только в тех случаях, когда чужой код лежит в общедоступном git-хранилище.

А я встречал при ходе вот так же версии у людей и кучу архивов со старыми версиями их программ. Как такое делается?

Следовало бы дать адрес для примера — тогда станет проще объяснить, что Вы там встретили и как это достигается.

Идеология DVCS предполагает, что у каждого разработчика есть свой репозиторий, в котором он создаёт ветки, проверяет их эффект, а затем заливает готовый код наверх (в upstream).

Логично поэтому либо дать каждому разработчику заодно и возможность поднять собственную тестовую копию сайта.

Если это не возможно, то уместно устроить дело так, чтобы у каждого разработчика на основной тестовой копии сайта была своя ветка и возможность там тестировать код. Эта-то ветка тогда и станет для него upstreamом, то есть тем местом, куда разработчик будет код заливать из своего личного репозитория. Там проверив свой код, разработчик станет делать merge оттуда в master.