Git reset practice

file.txt

@@ -0,0 +1,3 @@
+First commit
+Second commit
+Third commit

history.txt

@@ -0,0 +1,3 @@
+Commit A
+Commit B
+Commit C

submission1.md

@@ -0,0 +1,6 @@
+Подписанные коммиты (signed commits) в Git представляют собой коммиты, снабженные цифровой подписью, созданной с использованием криптографических ключей, таких как GPG или SSH. Их основное назначение — обеспечение безопасности и подтверждение подлинности кода. В отличие от обычных коммитов, которые содержат лишь имя и email автора (данные, которые можно легко подделать, изменив настройки Git), цифровая подпись гарантирует, что коммит был создан именно владельцем ключа, а не злоумышленником. Кроме того, подписанные коммиты защищают историю от несанкционированных изменений. Поскольку Git позволяет редактировать историю (например, через rebase или amend), злоумышленник, получивший доступ к репозиторию, может незаметно изменить старые коммиты. Однако если коммит подписан, любая попытка его модификации приведет к недействительности подписи, что сразу будет обнаружено.
+В open-source проектах, таких как ядро Linux, подписанные коммиты играют важную роль, так как позволяют сообществу убедиться, что изменения внесены доверенными участниками, а не скомпрометированными аккаунтами. На платформах вроде GitHub и GitLab такие коммиты помечаются как Verified. Кроме того, в организациях, работающих с критически важным кодом (например, банки или государственные структуры), подписанные коммиты часто являются обязательным требованием в соответствии с внутренними стандартами безопасности, поскольку позволяют точно отслеживать, кто и когда вносил изменения.
+Что касается стратегий слияния в Git, каждая из них имеет свои преимущества и недостатки. Обычное слияние (Standard Merge) создает новый коммит слияния, сохраняя оригинальные коммиты из обеих веток. Этот подход обеспечивает полную историю изменений, что упрощает отладку, а также четко показывает момент объединения веток, что особенно важно при командной работе. Однако он может приводить к усложнению графа коммитов, делая историю менее читаемой.
+Слияние со сжатием (Squash and Merge) объединяет все коммиты из feature-ветки в один, что делает историю более чистой и удобной для просмотра, но при этом теряется детальная информация о промежуточных изменениях, что может затруднить отладку. Этот метод хорошо подходит для короткоживущих веток, где отдельные коммиты не имеют особой ценности.
+Перебазирование с последующим слиянием (Rebase and Merge) перемещает коммиты из feature-ветки на верхушку основной, создавая линейную историю без коммитов слияния. Это делает историю более понятной, но при этом перезаписывает её, что может вызвать проблемы при совместной работе, особенно если ветки уже опубликованы.
+Несмотря на то, что обычное слияние иногда приводит к менее линейной истории, оно остается предпочтительным выбором для командной разработки, так как сохраняет всю историю изменений, не перезаписывает коммиты и четко фиксирует моменты интеграции. Эти преимущества делают его наиболее подходящим вариантом для большинства проектов с участием нескольких разработчиков.

text1.txt

@@ -0,0 +1 @@
+1