What Lab2 Submission should've been. Have not been redacted since the due date

file.txt

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

history.txt

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

lab1/submission1.md

@@ -0,0 +1,88 @@
+# Task 1
+
+## Commit Signing
+
+Commit signing is a way to cryptographically verify the identity of the author of a commit. Git supports multiple signing methods, including GPG and SSH keys. The signature is embedded in the commit and verified by platforms like GitHub and Bitbucket, which display a verification status (such as "Verified").
+
+## Benefits of SSH Signing
+
+### 1. Simple Setup
+
+- SSH keys are already widely used for authentication with remote repositories.
+- Does not require installing or configuring GPG, which can be complex, especially on Windows.
+- Creating and adding SSH keys is quick and straightforward.
+
+### 2. Enhanced Trust and Security
+
+- Signed commits prove that the commit was created by a specific person (the SSH key owner).
+- Helps prevent history tampering or malicious impersonation.
+
+### 3. Platform Integration
+
+- GitHub displays the signature status directly in pull requests and commit history.
+- Commit signing can be enforced via branch protection rules.
+- Bitbucket Server and Data Center (starting with version 8.8) also support SSH commit verification.
+
+### 4. Reuse of Existing Keys
+
+- The same SSH keys that are already used for repository access can be used again.
+- No need to manage a separate GPG key.
+
+### 5. Compliance and Audit Support
+
+- Signed commits create a cryptographically verifiable trail of changes.
+- Facilitates auditability and helps meet security and compliance requirements.
+
+## Conclusion
+
+Using SSH commit signatures is a  convenient way to prove authorship of code changes. It is especially valuable in collaborative development, open source projects, and environments with strong security requirements.
+
+
+---
+
+# Task 2
+
+## Standard Merge
+
+Creates a merge-commit and saves the change log of all branches
+
+### Pros:
+
+- Stores the full log of changes
+- Is convenient for collaborative environments
+
+### Cons:
+
+- A large volume of merge-commits can clutter the commit history
+
+## Squash and Merge
+
+Combines all the commits in a branch before merging
+
+### Pros:
+
+- Increased history readability
+
+### Cons:
+
+- Information about intermediate commits is lost
+
+## Rebase and Merge
+
+Applies all commits over the base branch
+
+### Pros:
+
+- Linear history with no merge commits
+
+### Cons:
+
+- Can be dangerous in collaborative environments
+
+## Why Standard Merge is Prefered
+
+Because it:
+
+- Saves the full commit history
+- Allows for an easy management of who and when applied what changes
+- Does not rewrite history, making it safe for collaborative projects

lab2/submission2.md

@@ -0,0 +1,85 @@
+# Task 1
+
+### Commit object
+
+![](commit_hash.png)
+
+Commit object contains:
+
+- tree link
+- parent commit
+- author and committer information
+- SSH signature
+- commit message
+
+### Tree object
+
+![](tree_hash.png)
+
+Tree object contains:
+
+- access rights
+- object types (blob is a file, tree is a directory)
+- object hash
+- file or directory name
+
+### Blob object
+
+![](blob_hash.png)
+
+Blob object contains the raw representation of the file's contents.
+
+# Task 2
+
+Using `git checkout -b git-reset-practice` a new branch was created
+
+Then a `file.txt` was created and modified through three commits
+
+### git reset --soft HEAD~1
+
+This command put the HEAD one commit behind while keeping the changes in the staging area, so that they can be commited again with or without change.
+
+![](soft_reset.png)
+
+### git reset --hard HEAD~1
+
+This command put the head one commit behind and also removed all the changes from the staging area and the working directory.
+
+![](hard_reset.png)
+
+### git reset --hard <reflog_hash>
+
+After finding a commit hash in a reflog, the state of the branch was reset to the second commit:
+
+![](hard_reset_hash.png)
+
+# Task 3
+
+![](branch_graph_1.png)
+
+![](branch_graph_2.png)
+
+`git log --graph`'s visualization of the commit and branching history helps one understand how repository branches and how these branches later merge together, which can be helpful for a collaborative project. It helps seeing repository's structure and to understand the commit history more clearly.
+
+# Task 4
+
+## Git tag name(s) created:
+
+v0.9.0 — commit with the third task
+v1.0.0 — current commit
+
+## Commands used:
+
+- git tag v0.9.0
+- git push origin v0.9.0
+- git log # to get the hash for the commit
+
+- <git add and git commit>
+- git tag v1.0.0
+- git push origin v1.0.0
+- git log # to get the hash for the commit
+
+## Commit hashes
+
+- 9f42659cb042e495fd39c241a63c2d77cddf930b
+- 186c485f837ccc1d5d15da9b56fe0f771494b3a0