|
| 1 | +# Task 1 |
| 2 | + |
| 3 | +## Commit Signing |
| 4 | + |
| 5 | +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"). |
| 6 | + |
| 7 | +## Benefits of SSH Signing |
| 8 | + |
| 9 | +### 1. Simple Setup |
| 10 | + |
| 11 | +- SSH keys are already widely used for authentication with remote repositories. |
| 12 | +- Does not require installing or configuring GPG, which can be complex, especially on Windows. |
| 13 | +- Creating and adding SSH keys is quick and straightforward. |
| 14 | + |
| 15 | +### 2. Enhanced Trust and Security |
| 16 | + |
| 17 | +- Signed commits prove that the commit was created by a specific person (the SSH key owner). |
| 18 | +- Helps prevent history tampering or malicious impersonation. |
| 19 | + |
| 20 | +### 3. Platform Integration |
| 21 | + |
| 22 | +- GitHub displays the signature status directly in pull requests and commit history. |
| 23 | +- Commit signing can be enforced via branch protection rules. |
| 24 | +- Bitbucket Server and Data Center (starting with version 8.8) also support SSH commit verification. |
| 25 | + |
| 26 | +### 4. Reuse of Existing Keys |
| 27 | + |
| 28 | +- The same SSH keys that are already used for repository access can be used again. |
| 29 | +- No need to manage a separate GPG key. |
| 30 | + |
| 31 | +### 5. Compliance and Audit Support |
| 32 | + |
| 33 | +- Signed commits create a cryptographically verifiable trail of changes. |
| 34 | +- Facilitates auditability and helps meet security and compliance requirements. |
| 35 | + |
| 36 | +## Conclusion |
| 37 | + |
| 38 | +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. |
| 39 | + |
| 40 | + |
| 41 | +--- |
| 42 | + |
| 43 | +# Task 2 |
| 44 | + |
| 45 | +## Standard Merge |
| 46 | + |
| 47 | +Creates a merge-commit and saves the change log of all branches |
| 48 | + |
| 49 | +### Pros: |
| 50 | + |
| 51 | +- Stores the full log of changes |
| 52 | +- Is convenient for collaborative environments |
| 53 | + |
| 54 | +### Cons: |
| 55 | + |
| 56 | +- A large volume of merge-commits can clutter the commit history |
| 57 | + |
| 58 | +## Squash and Merge |
| 59 | + |
| 60 | +Combines all the commits in a branch before merging |
| 61 | + |
| 62 | +### Pros: |
| 63 | + |
| 64 | +- Increased history readability |
| 65 | + |
| 66 | +### Cons: |
| 67 | + |
| 68 | +- Information about intermediate commits is lost |
| 69 | + |
| 70 | +## Rebase and Merge |
| 71 | + |
| 72 | +Applies all commits over the base branch |
| 73 | + |
| 74 | +### Pros: |
| 75 | + |
| 76 | +- Linear history with no merge commits |
| 77 | + |
| 78 | +### Cons: |
| 79 | + |
| 80 | +- Can be dangerous in collaborative environments |
| 81 | + |
| 82 | +## Why Standard Merge is Prefered |
| 83 | + |
| 84 | +Because it: |
| 85 | + |
| 86 | +- Saves the full commit history |
| 87 | +- Allows for an easy management of who and when applied what changes |
| 88 | +- Does not rewrite history, making it safe for collaborative projects |
0 commit comments