Split readme to en and ru languages

README.md

@@ -1,64 +1,62 @@
 ## Foreword
 
-Many of us using git in our day-to-day work. I'm noticed that some of you (or may be many of you) just use few features of it.
-Like: `add`, `commit`, `push` and `pull`.
-There is might be different reasons for that.
-You don't know another stuff and/or afraid to use them.
-Commands `amend` and `rebase` is nightmare for you.
+Many of us are using git in our day-to-day work. I've noticed that some of you (or may be many of you) are using only a few few features of it e.g. `add`, `commit`, `push`, `pull`.
+There might be different reasons for that; you might not know anything better or are overwhelmed by their complexity.
+Commands `amend` and `rebase` might seem a nightmare for you.
 Now I will try to fix that.
 
 ## Why history is important
 
-Git history it's like contents of the book.
-It helps other people to understand the purpose of each commit.
-What's why your logs should be well named and followed by clear description.
+Git history is like the table of contents of a book.
+It helps other people understand the purpose of each commit.
+What's why your logs should be well named and follow a clear description.
 
 ## Some Commits best practices
 
   * Commit should contain related changes. Fixing two different bugs should produce two separate commits.
     Small commits make it easier to understand for other team members.
 
-  * Commit often. It will allows you to commit only related changes.
+  * Commit often. It will allow you to commit only related changes.
 
-  * Don't commit half-done work. This means you should not commit unfinished feature at the end of working day.
-    This also does not means you should commit whole huge feature in one commit. Just split it into small chuncks.
+  * Don't commit work half-done. This means you should not commit an unfinished feature at the end of working day.
+    This also does not mean you should commit a huge complex feature in one commit. Just split it into small chuncks.
 
-  * Use branch per feature. That allow you group commits in history.
+  * Use branch per feature. That allows you to group the commits in history.
 
 ## Read before commit
 
-There is a good practice to read your emails and messages before send them.
-That's works and with `git diff` too. So check your diffs before commit.
+There is a good practice to read your emails and messages before you send them.
+That works and with `git diff` as well. So check your diffs before commit.
 
-Just use `git diff` command for unstaged files and `git diff --cached` for staged.
-(staged files are those files what just have added using `git add` command)
+Simply use `git diff` command for unstaged files and `git diff --cached` for the staged ones.
+(staged files are the files what just have added using `git add` command)
 
-I'm usually find some stuff to fix like extra empty line, todo comment or typos.
+I usually find some stuff to fix like extra empty line, todo comment or typos.
 
 ## How to write good commit message
 
 Never use -m (--message) flag to git commit.
-It invites you set short unreadable commit messages.
-`git commit` will opens your default editor where you could write more useful commit message.
+It invites you to set short unreadable commit messages.
+`git commit` will open your default editor where you could write a more useful commit message.
 
-There is terrific note from Tim Pope about writing commit messages.
+There is a terrific note from Tim Pope about writing commit messages.
 
 Long story short.
 
-Your commit title should be short, capitalized title with 50 or less characters followed by blank line.
-Then goes more detailed description of changes wrapped in about to 72 characters.
+Your commit title should be a short, capitalized sentence with 50 or less characters followed by a blank line.
+Then a more detailed description of changes goes wrapped in about to 72 characters.
 
-Write your commit messages in imperative way: Use "fix", "change", "add" instead of "fixed", "changed", "added".
-That convention matches up with commit messages generated by `git merge` and `git revert`.
+Write your commit messages in an imperative fashion: Use "fix", "change", "add" instead of "fixed", "changed", "added".
+This convention matches up with commit messages generated by `git merge` and `git revert`.
 
 ## Add changes interactively
 
-You're probably familiar with adding files into staging area using `add` command.
-Sometimes you might make changes whose should belong to different commits.
-As we have talk before we don't want to our commits to looks like 'Fixed A and B'.
+You're probably familiar with adding files into staging area using the `add` command.
+Sometimes you might make changes that should belong to different commits.
+As we said, we don't want our commits to looks like 'Fix A and B'.
 
 So here `add -p <filename>` (`add --patch`) comes to help.
-Interactive adding will asks to perform some action for each hunk.
+Interactive adding will ask to perform some action for each hunk.
 These actions are:
 
     y - stage this hunk
@@ -84,7 +82,7 @@ We could avoid using fast forward for merge and even set is as default behavior
 
 ## Merge with --no-ff
 
-The --no-ff flash ensures there will be a merge commit, even if git could do a fast forward merge.
+The --no-ff flag ensures there will be a merge commit, even if git could do a fast forward merge.
 That picture shows the difference between merges with and without fast forward.
 
 http://i.stack.imgur.com/FMD5h.png
@@ -100,13 +98,13 @@ Clear enough?
 NO!
 
 Simply put: Rebase is the command to rewrite history in some ways.
-Whese ways could be: Moving your commits on top of another branch, squash, split, amend.
+These ways could are: moving your commits on top of another branch, squash, split, amend.
 
 Simpliest use:
 
 From your branch `git rebase master`.
 Saves all commits made in current branch to temporary area.
-Resets your branch to master state then apply commits one by one from temporary area.
+Resets your branch to master state then applies commits one by one from temporary area.
 Complete result would looks like: [rebase picture]
 
 
@@ -134,23 +132,23 @@ It will opens default editor with following result:
     # If you remove a line here THAT COMMIT WILL BE LOST.
     # However, if you remove everything, the rebase will be aborted.
 
-But. Do not rebase published commits. Rebase changes commits and these commits will differs from previous ones.
+But. Do not rebase published commits. Rebase changes commits and these commits will differ from previous ones.
 People who've got these commits before will face some issues after pulling your changes.
-As exception I accept rebasing for feature branches. Because I will throw it out after merge into development branch.
+As exception I accept rebasing for feature branches because I will throw it out after merge into the development branch.
 
 ## git pull --rebase
 
 Pulling changes from remote location by default tries to merge changes into you current branch.
-It's use fast forward if it's possible but creates merge commit when faces conflicts in changes.
-Avoid extra merge commit we can use git pull with --rebase params.
-That will move our non published commits on top of history tree.
+It uses fast forward if it's possible but creates merge commit when facing conflicts in changes.
+In order to avoid extra merge commit we can use git pull with --rebase params.
+That will move our non published commits on top of the history tree.
 
 ## My Git workflow
 
   * Create new branch for every main feature using git checkout -b <feature-branch>
   * Commit your code in small indepent pieces.
   * If you forgot something for last commit use `git --amend`
-  * If you forgot something for recent commits then commit is as fix and use `rebase -i` to change commits order and squashing them.
+  * If you forgot something for recent commits then commit is as fix and use `rebase -i` to change commits order and squash them.
   * Use git rebase <main-branch> (it might be master or develop) from your <feature-branch> to move all your commits on top.
   * Use git merge --no-ff <feature-branch> from <main-branch>
 
@@ -171,10 +169,10 @@ To avoid wasting time you could describe aliases to most used git commands. Ther
   rc = rebase --continue
 ```
 
-The most attentive of you might notice what I'm using file name as `l` alias.
-It's how you could get result of external file as your command.
+As you could notice I'm using file name as `l` alias.
+This is how you can get the result of an external file as your command.
 
-This is my script (To be honest it's stolen from another guy) to format logs
+This is my script (To be honest it's 'borrowed' from another guy) that formats logs:
 
 https://github.com/ck3g/dotfiles/blob/master/githelpers
 
@@ -185,11 +183,11 @@ Here is how it looks like in terminal window.
 # Bonus feature
 ## Git Bisect
 
-One of my favorite feature. It helped me many times. I'm also like to ask about it on job inverviews.
+One of my favorite features that helped me many times. I also enjoy asking about it on job inverviews.
 
-Lets imagine a situation when you realized what something was broken and you don't know when.
-But you're know what 15 commits ago it's used to work. How to find broken commit?
-What when git bisect helps.
+Lets imagine a situation where you have realized that something had broken and you don't know when.
+But you know that 15 commits ago it used to work. How to find the guilty commit?
+That's when git bisect helps.
 
 git bisect uses binary search to find broken commit.
 
@@ -201,17 +199,16 @@ git bisect good v1.2.3    # Mark good commit
 ```
 
 git will checkout you between these commits where you will be able to check your current state.
-Then mark commit as good/bad. You should keep going until you're find broken commit.
-Check the difference using git show. Understand the problem. And use git reset to finish.
+Then mark commit as good/bad. You should keep going until you have found the bad commit.
+Check the differences using git show. Understand the problem. Use git reset to finish.
 
 Note:
-When your commits isn't atomic, like failing specs and its fixes are in different commits.
-You will probably be confused then bisect provide you commit with failing specs.
+When your commits aren't atomic e.g. failing specs and its fixes are in different commits, you will probably be confused that bisect provides the commit with the failing specs.
 
 ## Afterword
 
-Git is a powerful tool. We all using it on every day basis. Thus it's a good reason to master it.
-Try to use these advices in your everyday work. I hope you will like it.
+Git is a powerful tool. We are all using it on every day basis. Thus it's a good idea to master it.
+Try to use these pieces of advice in your everyday work. I hope you will like it.
 
 
 ## Links