refactor: border to changelog example

refactor: article intro to another

refactor: article some additional addition

refactor: add git log example

refactor: article to be Git Conventional Commits named

refactor: article further in grammar

refactor: article wording a bit

refactor: article add link to getting started

refactor: fixing a bit wording for getting started

refactor: article to fix some mistakes

refactor: a bit wording

refactor: clarify a bit point in recap

refactor: article grammar sweeping

refactor: article wording furtther

refactor: clarify standard which in article header

refactor: clarify that it is generated changelog

refactor: fix unordered list indent

README.md

@@ -41,16 +41,14 @@ as a result of the tool work, you have decreased toll on release documentation w
   - `echo 123 >> README.md && git add -A && git commit -m "feat: init repo with first code"`
   - `echo 123 >> README.md && git add -A && git commit -m "fix: memory leak in sql connection opener"`
   - `echo 123 >> README.md && git add -A && git commit -m "feat: new super feature"`
-  - `echo 123 >> README.md && git add -A && git commit -m 'feat!: new super feature`
+  - `echo 123 >> README.md && git add -A && git commit -m 'feat!: new super feature'`
 
 `BREAKING CHANGE: api for endpoint status changed to users-status'`
     - due to bash using `!` as a keyword syntax, we need to use `''` single quotes
   - `echo 123 >> README.md && git add -A && git commit -m "fix(api): example of scoped bug fix"`
   - generate changelog with `autogit changelog`
 
-<p align="center" class="custom_borser">
-  <img src="assets/changelog_example.png" style="border: 5px solid #FFF;"/>
-</p>
+![changelog example](assets/changelog_example.png)
 
 ## video version:
 

docs/git-conventional-commits.md

@@ -1,29 +1,31 @@
 # Git Conventional Commits
 
+**Communicating with other devs through git**
+
 <p align="center">
   <img src="../assets/logo.png" style="width: 200px; height: 200px;"/>
 </p>
 
 ## Intro
 
-Software development is often seen as a place for geeks without social skills, controversary software development requires often communication skills to gather requirements and explain what we did and why. We write code not just for machines, but for other humans to read (including by ourselves a year later)
+We write code not just for machines, but for other humans to read (including future us, who forgot the written code in a year). Software development is a team effort, and therefore it requires communicating what we change and why we change it. 
 
-Messaging apps change, and the history of messages is rarely preserved. [Git]([https://www.oreilly.com/library/view/head-first-git/9781492092506/](https://www.oreilly.com/library/view/head-first-git/9781492092506/)) always remains to save another commit of code change and the message attached to it. A Git repository is the ultimate source of truth regarding a project. Every cloned git repository is a full decentralized backup of it.
+Messaging apps change, and the history of messages is rarely getting preserved. [Git]([https://www.oreilly.com/library/view/head-first-git/9781492092506/](https://www.oreilly.com/library/view/head-first-git/9781492092506/)) always remains to save another commit of code change and the message attached to it. A Git repository is the ultimate source of truth regarding a project. Every cloned git repository is a full decentralized backup of it.
 
-We can traverse for [example](https://github.com/torvalds/linux/commit/2099306c4e1d5d772b150aeac68fdd1d0331b09d) Linux repository to see... git commits used as equivalent to emailing.
+As an [example](https://github.com/torvalds/linux/commit/2099306c4e1d5d772b150aeac68fdd1d0331b09d) of using Git to its full potential we can traverse for Linux repository to see git commits used as equivalent to emailing.
 
-It is hard writing good atomic commit messages though. It takes some getting used to operating [git with best practices](https://deepsource.com/blog/git-best-practices)
+It is hard writing good atomic commit messages though. It takes some getting used to operating [git with best practices](https://deepsource.com/blog/git-best-practices).
 
-But how we can ensure that every member will be adhering to such practices? Or even how to remember to do it yourself?
+But how can we ensure that every member will be adhering to such practices? Or even how to remember to do it yourself?
 The answer is, we can enforce it with [linter](../) 😄
 
-## Standard
+## Standard v1.0.0
 
-[This linter - autogit](../) will help enforcing [Git conventional commits v1.0.0](https://www.conventionalcommits.org/en/v1.0.0/) standard
+[The tool - autogit](../) helps enforcing [git conventional commits v1.0.0](https://www.conventionalcommits.org/en/v1.0.0/) standard.
 
 It operates through [git hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) of your repository. Once linked, it will enforce itself on git commit at any your Git GUI tool.
 
-you will be encouraged writing commits like that (the tool will prevent commit being submitted unless it adheres to the set rules)
+you will be encouraged writing commits like that (the tool will prevent commit submitted unless it adheres to the set rules)
 
 ```
 <type>(<optional scope>)(optional breaking change '!' char): <subject>
@@ -62,11 +64,11 @@ https://github.com/darklab8/darklab_autogit/assets/20555918/44a05f9b-393f-4f6c-a
 
 ## How it benefits you?
 
-- it is easier to review your and others Pull requests of submitted code.
-  - each code line is easier understood why was added
-- u can utilize `git blame` onto your git files like that
-  for each code line u will see author of the line and exact commit why it was added
-  - that will help you investigating curious bugs and problems later
+- it is easier to review your and others' Pull requests of submitted code.
+  - each code line is easier to understand why was added
+- u can utilize `git blame` on your git files like that
+  for each code line, u will see the author of the line and exact message why it was added
+  - through linked git commit you will be able to access hopefully descriptive git commit why this change was made
 
 ```
 $ git blame main.go
@@ -82,13 +84,20 @@ d4745237 (dd84ai 2023-12-10 00:09:35 +0100  8) )
 ^3e43b5c (dd84ai 2022-12-10 19:54:42 +0100 10) func main() {
 def7cc5c (dd84ai 2023-10-21 23:30:37 +0200 11)  interface_cli.Execute()
 ^3e43b5c (dd84ai 2022-12-10 19:54:42 +0100 12) }
+
+$ git log 3e43b5c
+commit 3e43b5c006406b75afc8ca083262a71c462fd9d0
+Author: dd84ai <[email protected]>
+Date:   Sat Dec 10 19:54:42 2022 +0100
+
+    chore: init project with GPL license
 ```
 
 - u can use tools made for git conventional commits standard parsing,
   that will generate changelogs of changes for product releases!
   - This feature is available in [autogit](../)
 
-example of changelog:
+example of generated changelog:
 ![changelog example](../assets/changelog_example.png)
 
 - Your repository will look professionally with neat git commits, git tags, releases and changelogs! 😎
@@ -97,14 +106,13 @@ How can we enforce it for all developers of the repository though?
 
 - By using [CI run with autogit](../.github/workflows/validate.yml) for every commit push or pull request!
 
-## Tools
+## What makes autogit different?
 
 There are many [tools for conventional commits](https://www.conventionalcommits.org/en/about/)
 
-What makes this tool different?
-
+Autogit is different by having next things:
 - It was written with [CI usage in mind](../.github/workflows/validate.yml)
-  - it is easy to insert it into any other CI instrument with such an example.
+  - it is easy to insert it into any other CI instrument with the example.
   - just ensure you clone a repository with the history of your tags and commits 😉
 - as a Golang compiled binary it does not require you to install node.js of a specific version or any other heavy interpreter for its running in CI or at the local dev machine.
   - even having `git` installed is not required for this tool to operate.
@@ -116,6 +124,10 @@ What makes this tool different?
 ## Recap
 
 - We learned that communicating our work to other developers (and yourself in a year) is important.
-- Git serves ultimate source of truth for that.
+- Git serves the ultimate source of truth that will remain with us through years
 - For Git commits to be a more readable history, we can utilize `git conventional commits` enforced by linters.
-- We can use the history of `git conventional commits` to generate automatically changelogs of changes for releases.
+- We can use the history of `git conventional commits` to generate automatically changelogs for releases.
+
+## Where next?
+
+- [Getting started with autogit](../README.md)