Ivan Bogachev

@keyframes custom-fade-in {
    0% {
        stroke-dasharray: 0 300;
        fill: transparent;
        animation-timing-function: ease-in;
    }
    50% {
        stroke-dasharray: 150 150;
        fill: transparent;
        animation-timing-function: ease-out;
    }
    100% {
        stroke-dasharray: 300 0;
        fill: #000;
    }
}

path {
    stroke: #000;
    fill: none;
    stroke-dasharray: 0 300;
    animation: custom-fade-in 2s ease-in-out infinite;
    animation-fill-mode: forwards;
}

• Исходники с вашим кодом - однозначно да. Это самое главное.
  
• Все конфиги для сборки - да. Иначе без них проект не собрать. Исключение - какие-то ситуативно-локальные конфиги с ключами, паролями, и всем тем, что не должно попасть к другим людям. Но тогда это нужно описать в доках, что и где должно быть.
  
• Картинки - зависит от. SVG - скорее да, т.к. это текст. Растровые, особенно большие, может быть стоит хранить отдельно. Но это зависит от проекта и соглашений, главное избегать крайностей, чтобы репозиторий с лендингом не весил по пол гигабайта из-за исходников картинок или макетов. И это к любым бинарникам имеет отношение.
  
• node_modules - нет. Зависимости и зависимости зависимостей - это обычно тысячи файлов, которые вы никогда (ну почти никогда) не будете править своими руками. Они могут скачиваться при сборке проекта, в репозитории им делать нечего.
  
• Собранный и минифицированный проект - может быть. Зависит от применения. Обычно это не нужно хранить в системе контроля версий в том смысле, что минифицированные файлы мы все равно получаем при сборке и руками их не правим. Но иногда могут возникать ситуации вроде "хочу использовать репозиторий на GitHub как зеркало для моего NPM пакета" или "хочу захостить что-то на GitHub Pages", или "хочу, чтобы любая домохозяйка могла скопировать мой скрипт в свой бложик на wordpress и не парилась со сборкой", или еще что-то в этом духе. Иными словами, минифицированные файлы могут туда попасть, если вы понимаете, зачем это вам, какую задачу это решит. В общем случае пользы от этого никакой.
  

Крайне любопытен с точки зрения визуальной составляющей.
Мне бы хотелось понимать, посредством каких технологий он был сделан.

1. Волны абстрактные и на фотографиях, шум на фоне - WebGL, шейдеры. Вода на первом экране - скорее всего моделируется как идеальная жидкость, волны на фотографиях - чисто геометрические.
   
2. Обведение текста в овал, трилистник с пунктиром, стрелки на карте - SVG, рисование линии по такому принципу.
   
3. Плавные переходы между экранами можно делать по-разному, даже забытый модными фронтендерами pjax будет к месту. Можно познакомиться с barba.js - это если не самый популярный, то один из популярных инструментов для работы с плавными переходами. Можно использовать роутеры из SPA-фреймворков, не принципиально. Самое сложное здесь - все синхронизировать.
   
4. Карта с персонажами - это может быть обычная верстка, подложенная под канвас с шумом. Самый простой вариант.
   
5. Есть небольшое покачивание элементов вслед за мышкой, логично предположить, что это банальная CSS-трансформация на mousemove.
   
6. Рисование дуг из точек - это может быть либо SVG, как в п.2, только эта линия будет маской, либо можно это строить как графики.
   
7. Ну и немного стандартных CSS-анимаций там тоже есть.
   

@keyframes load {
    0% {
        width: 0%;
        background: #f00;
    }
    50% {
        width: 70%;
        background: #00f;
    }
    100% {
        width: 100%;
        background: #0f0;
    }
}

• Есть устоявшиеся английские названия для всех стандартных элементов интерфейса и вспомогательных оберток. Использование других названий (в том числе на другом языке) приведет к потере скорости чтения кода, придется привыкать к новым именованиям.
  
• Придется постоянно переключаться между раскладками при написании кода. Минус к удобству.
  
• В любимой IDE вашего коллеги может быть шрифт, не поддерживающий ваши альтернативные non-ascii символы. Ему будет плохо.
  

• Отобразить картинку на плоскости в WebGL контексте, оставив по краям немного прозрачности (чтобы был простор для искажений).
  
• Волны - это смещения пикселей. Характер может быть разным, но скорее всего будет что-то в духе "смещение пикселя = синус(положение пикселя + время)". Похожий пример есть вот в этой статье.
  
• Покраснение - при задании цвета пикселя во фрагментном шейдере увеличиваем значение R в рамках RGBA (в зависимости от времени).
  
• Дальше заменяем время на нужный нам параметр (скролл с верха страницы например, ну или что там вам нужно).
  

const a = '"#512534"';   // <-- Другие кавычки
const b = "\"#512534\""; // <-- Экранизация
const c = `"#512534"`;   // <-- Шаблонные строки

.btn1 {
	// z-index: 1;
}