├── output ├── 32-01.txt ├── 33-01.txt ├── 11-05.txt ├── 13-02.txt ├── 31-01.txt ├── 30-01.txt ├── 03-01.txt ├── 07-02.txt ├── 35-02.txt ├── 02-01.txt ├── 40-01.txt ├── 30-02.txt ├── 27-02.txt ├── 07-01.txt ├── 36-02.txt ├── 13-03.txt ├── 25-03.txt ├── 08-04.txt ├── 25-04.txt ├── 33-02.txt ├── 18-01.txt ├── 36-01.txt ├── 09-02.txt ├── 13-01.txt ├── 14-01.txt ├── 08-03.txt ├── 02-02.txt ├── 05-01.txt ├── 20-04.txt ├── 21-01.txt ├── 17-02.txt ├── 25-01.txt ├── 38-01.txt ├── 10-03.txt ├── 11-03.txt ├── 12-02.txt ├── 19-02.txt ├── 11-04.txt ├── 20-05.txt ├── 10-01.txt ├── 11-01.txt ├── 04-01.txt ├── 11-06.txt ├── 12-01.txt ├── 09-03.txt ├── 29-01.txt ├── 19-03.txt ├── 20-02.txt ├── 25-02.txt ├── 16-01.txt ├── 08-01.txt ├── 15-03.txt ├── 17-03.txt ├── 25-02-1.txt ├── 28-01-1.txt ├── 32-02.txt ├── 14-02.txt ├── 15-01.txt ├── 20-03.txt ├── 08-02.txt ├── 15-02.txt ├── 15-04.txt ├── 37-01.txt ├── 41-01.txt ├── 17-01.txt ├── 19-01.txt ├── 20-01.txt ├── 20-06.txt ├── 27-03.txt ├── 22-01.txt ├── 10-02.txt ├── 09-01.txt ├── 29-02.txt ├── 31-02.txt ├── 11-02.txt ├── 24-01.txt ├── 27-01.txt ├── 35-01.txt ├── 23-01.txt ├── 25-05.txt ├── 28-02.txt └── 28-01.txt ├── .gitignore ├── pages ├── en │ ├── adding_a_remote_repository.mdx │ ├── rebasing_vs_merging.mdx │ ├── remove_the_oops_tag.mdx │ ├── pulling_shared_changes.mdx │ ├── adding_a_tracking_branch.mdx │ ├── setup.mdx │ ├── thank_you.mdx │ ├── staging_changes.mdx │ ├── merging.mdx │ ├── change_the_original_repository.mdx │ ├── viewing_diverging_branches.mdx │ ├── what_is_origin.mdx │ ├── making_changes.mdx │ ├── merging_back_to_master.mdx │ ├── remote_branches.mdx │ ├── pushing_a_change.mdx │ ├── cloning_repositories.mdx │ ├── navigating_branches.mdx │ ├── checking_status.mdx │ ├── more_setup.mdx │ ├── bare_repositories.mdx │ ├── review_the_cloned_repository.mdx │ ├── merging_pulled_changes.mdx │ ├── changes_in_master.mdx │ ├── create_a_project.mdx │ ├── staging_and_committing.mdx │ ├── fetching_changes.mdx │ ├── hosting_your_git_repositories.mdx │ ├── multiple_repositories.mdx │ ├── resetting_the_style_branch.mdx │ ├── undoing_local_changes.mdx │ ├── amending_commits.mdx │ ├── undoing_staged_changes.mdx │ ├── undoing_committed_changes.mdx │ ├── creating_a_conflict.mdx │ ├── committing_changes.mdx │ └── getting_old_versions.mdx ├── uk │ ├── adding_a_remote_repository.mdx │ ├── rebasing_vs_merging.mdx │ ├── remove_the_oops_tag.mdx │ ├── pulling_shared_changes.mdx │ ├── adding_a_tracking_branch.mdx │ ├── setup.mdx │ ├── staging_changes.mdx │ ├── merging.mdx │ ├── viewing_diverging_branches.mdx │ ├── thank_you.mdx │ ├── change_the_original_repository.mdx │ ├── making_changes.mdx │ ├── merging_back_to_master.mdx │ ├── remote_branches.mdx │ ├── what_is_origin.mdx │ ├── cloning_repositories.mdx │ ├── checking_status.mdx │ ├── pushing_a_change.mdx │ ├── review_the_cloned_repository.mdx │ ├── navigating_branches.mdx │ ├── merging_pulled_changes.mdx │ ├── staging_and_committing.mdx │ ├── changes_in_master.mdx │ ├── bare_repositories.mdx │ ├── create_a_project.mdx │ ├── more_setup.mdx │ ├── fetching_changes.mdx │ ├── multiple_repositories.mdx │ ├── resetting_the_style_branch.mdx │ ├── hosting_your_git_repositories.mdx │ ├── undoing_local_changes.mdx │ ├── undoing_staged_changes.mdx │ ├── amending_commits.mdx │ ├── undoing_committed_changes.mdx │ └── creating_a_conflict.mdx ├── pt-BR │ ├── adding_a_remote_repository.mdx │ ├── rebasing_vs_merging.mdx │ ├── remove_the_oops_tag.mdx │ ├── pulling_shared_changes.mdx │ ├── setup.mdx │ ├── adding_a_tracking_branch.mdx │ ├── thank_you.mdx │ ├── staging_changes.mdx │ ├── change_the_original_repository.mdx │ ├── merging.mdx │ ├── viewing_diverging_branches.mdx │ ├── what_is_origin.mdx │ ├── making_changes.mdx │ ├── remote_branches.mdx │ ├── staging_and_committing.mdx │ ├── merging_back_to_master.mdx │ ├── cloning_repositories.mdx │ ├── review_the_cloned_repository.mdx │ ├── pushing_a_change.mdx │ ├── checking_status.mdx │ ├── navigating_branches.mdx │ ├── merging_pulled_changes.mdx │ ├── bare_repositories.mdx │ ├── create_a_project.mdx │ ├── more_setup.mdx │ ├── changes_in_master.mdx │ ├── fetching_changes.mdx │ ├── hosting_your_git_repositories.mdx │ ├── multiple_repositories.mdx │ ├── resetting_the_style_branch.mdx │ ├── undoing_local_changes.mdx │ ├── amending_commits.mdx │ ├── undoing_staged_changes.mdx │ └── undoing_committed_changes.mdx └── ru │ ├── adding_a_remote_repository.mdx │ ├── rebasing_vs_merging.mdx │ ├── remove_the_oops_tag.mdx │ ├── pulling_shared_changes.mdx │ ├── setup.mdx │ ├── adding_a_tracking_branch.mdx │ ├── thank_you.mdx │ ├── staging_changes.mdx │ ├── merging.mdx │ ├── viewing_diverging_branches.mdx │ ├── change_the_original_repository.mdx │ ├── merging_back_to_master.mdx │ ├── making_changes.mdx │ ├── what_is_origin.mdx │ ├── remote_branches.mdx │ ├── cloning_repositories.mdx │ ├── review_the_cloned_repository.mdx │ ├── checking_status.mdx │ ├── navigating_branches.mdx │ ├── pushing_a_change.mdx │ ├── merging_pulled_changes.mdx │ ├── changes_in_master.mdx │ ├── create_a_project.mdx │ ├── staging_and_committing.mdx │ ├── bare_repositories.mdx │ ├── more_setup.mdx │ ├── fetching_changes.mdx │ ├── multiple_repositories.mdx │ ├── resetting_the_style_branch.mdx │ ├── hosting_your_git_repositories.mdx │ ├── undoing_local_changes.mdx │ ├── undoing_staged_changes.mdx │ ├── amending_commits.mdx │ ├── undoing_committed_changes.mdx │ └── creating_a_conflict.mdx ├── README.md └── outline.yml /output/32-01.txt: -------------------------------------------------------------------------------- 1 | $ git remote 2 | origin 3 | -------------------------------------------------------------------------------- /output/33-01.txt: -------------------------------------------------------------------------------- 1 | $ git branch 2 | * main 3 | -------------------------------------------------------------------------------- /output/11-05.txt: -------------------------------------------------------------------------------- 1 | $ git tag 2 | v1 3 | v1-beta 4 | -------------------------------------------------------------------------------- /output/13-02.txt: -------------------------------------------------------------------------------- 1 | $ git restore --staged hello.html 2 | -------------------------------------------------------------------------------- /output/31-01.txt: -------------------------------------------------------------------------------- 1 | $ cd home 2 | $ ls 3 | css 4 | index.html 5 | README 6 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | .idea 2 | .DS_Store 3 | *.sublime-project 4 | *.sublime-workspace 5 | 6 | -------------------------------------------------------------------------------- /output/30-01.txt: -------------------------------------------------------------------------------- 1 | $ cd .. 2 | $ pwd 3 | /home/alex/githowto/repositories 4 | $ ls 5 | work 6 | -------------------------------------------------------------------------------- /output/03-01.txt: -------------------------------------------------------------------------------- 1 | $ git status 2 | On branch main 3 | nothing to commit, working tree clean 4 | -------------------------------------------------------------------------------- /output/07-02.txt: -------------------------------------------------------------------------------- 1 | $ git status 2 | On branch main 3 | nothing to commit, working tree clean 4 | -------------------------------------------------------------------------------- /output/35-02.txt: -------------------------------------------------------------------------------- 1 | $ cat README 2 | This is the Hello World example from the GitHowTo tutorial. 3 | -------------------------------------------------------------------------------- /output/02-01.txt: -------------------------------------------------------------------------------- 1 | Initialized empty Git repository in /home/alex/githowto/repositories/work/.git/ 2 | -------------------------------------------------------------------------------- /output/40-01.txt: -------------------------------------------------------------------------------- 1 | $ git push shared main 2 | To ../work.git 3 | 71df43a..d9d2bea main -> main 4 | -------------------------------------------------------------------------------- /output/30-02.txt: -------------------------------------------------------------------------------- 1 | $ git clone work home 2 | Cloning into 'home'... 3 | done. 4 | $ ls 5 | home 6 | work 7 | -------------------------------------------------------------------------------- /output/27-02.txt: -------------------------------------------------------------------------------- 1 | $ git reset --hard HEAD~2 2 | HEAD is now at 0ee0113 Renamed hello.html; moved style.css 3 | -------------------------------------------------------------------------------- /output/07-01.txt: -------------------------------------------------------------------------------- 1 | $ git commit 2 | [main 78433de] Added h1 tag 3 | 1 file changed, 1 insertion(+), 1 deletion(-) 4 | -------------------------------------------------------------------------------- /output/36-02.txt: -------------------------------------------------------------------------------- 1 | $ cat README 2 | This is the Hello World example from the Git tutorial. 3 | (changed in origin) 4 | -------------------------------------------------------------------------------- /output/13-03.txt: -------------------------------------------------------------------------------- 1 | $ git restore hello.html 2 | $ git status 3 | On branch main 4 | nothing to commit, working tree clean 5 | -------------------------------------------------------------------------------- /output/25-03.txt: -------------------------------------------------------------------------------- 1 | $ git merge --abort 2 | $ git status 3 | On branch style 4 | nothing to commit, working tree clean 5 | -------------------------------------------------------------------------------- /output/08-04.txt: -------------------------------------------------------------------------------- 1 | $ git commit -m "Added HTML header" 2 | [main b7614c1] Added HTML header 3 | 1 file changed, 2 insertions(+) 4 | -------------------------------------------------------------------------------- /output/25-04.txt: -------------------------------------------------------------------------------- 1 | $ git add index.html 2 | $ git commit -m "Resolved merge conflict" 3 | [style 79ac6fa] Resolved merge conflict 4 | -------------------------------------------------------------------------------- /output/33-02.txt: -------------------------------------------------------------------------------- 1 | $ git branch -a 2 | * main 3 | remotes/origin/HEAD -> origin/main 4 | remotes/origin/main 5 | remotes/origin/style 6 | -------------------------------------------------------------------------------- /output/18-01.txt: -------------------------------------------------------------------------------- 1 | $ git switch -c style 2 | Switched to a new branch 'style' 3 | $ git status 4 | On branch style 5 | nothing to commit, working tree clean 6 | -------------------------------------------------------------------------------- /output/36-01.txt: -------------------------------------------------------------------------------- 1 | $ git merge origin/main 2 | Updating 39a1e0f..71df43a 3 | Fast-forward 4 | README | 3 ++- 5 | 1 file changed, 2 insertions(+), 1 deletion(-) 6 | -------------------------------------------------------------------------------- /output/09-02.txt: -------------------------------------------------------------------------------- 1 | $ git log --oneline 2 | b7614c1 Added HTML header 3 | 46afaff Added standard HTML page tags 4 | 78433de Added h1 tag 5 | 5836970 Initial commit 6 | -------------------------------------------------------------------------------- /output/13-01.txt: -------------------------------------------------------------------------------- 1 | $ git status 2 | On branch main 3 | Changes to be committed: 4 | (use "git restore --staged ..." to unstage) 5 | modified: hello.html 6 | 7 | -------------------------------------------------------------------------------- /output/14-01.txt: -------------------------------------------------------------------------------- 1 | $ git revert HEAD 2 | [main 86364a1] Revert "Oops, we didn't want this commit" 3 | Date: Tue Nov 28 05:51:38 2023 -0600 4 | 1 file changed, 1 deletion(-) 5 | -------------------------------------------------------------------------------- /output/08-03.txt: -------------------------------------------------------------------------------- 1 | $ git add . 2 | $ git status 3 | On branch main 4 | Changes to be committed: 5 | (use "git restore --staged ..." to unstage) 6 | modified: hello.html 7 | 8 | -------------------------------------------------------------------------------- /output/02-02.txt: -------------------------------------------------------------------------------- 1 | $ git add hello.html 2 | $ git commit -m "Initial commit" 3 | [main (root-commit) 5836970] Initial commit 4 | 1 file changed, 1 insertion(+) 5 | create mode 100644 hello.html 6 | -------------------------------------------------------------------------------- /output/05-01.txt: -------------------------------------------------------------------------------- 1 | $ git add hello.html 2 | $ git status 3 | On branch main 4 | Changes to be committed: 5 | (use "git restore --staged ..." to unstage) 6 | modified: hello.html 7 | 8 | -------------------------------------------------------------------------------- /output/20-04.txt: -------------------------------------------------------------------------------- 1 | $ git add . 2 | $ git status 3 | On branch style 4 | Changes to be committed: 5 | (use "git restore --staged ..." to unstage) 6 | renamed: hello.html -> index.html 7 | 8 | -------------------------------------------------------------------------------- /output/21-01.txt: -------------------------------------------------------------------------------- 1 | $ git switch main 2 | Switched to branch 'main' 3 | $ git add README 4 | $ git commit -m "Added README" 5 | [main ee16740] Added README 6 | 1 file changed, 1 insertion(+) 7 | create mode 100644 README 8 | -------------------------------------------------------------------------------- /output/17-02.txt: -------------------------------------------------------------------------------- 1 | $ git add hello.html 2 | $ git commit --amend -m "Added copyright statement with email" 3 | [main 9288a33] Added copyright statement with email 4 | Date: Tue Nov 28 05:51:38 2023 -0600 5 | 1 file changed, 1 insertion(+) 6 | -------------------------------------------------------------------------------- /output/25-01.txt: -------------------------------------------------------------------------------- 1 | $ git switch style 2 | Switched to branch 'style' 3 | $ git merge main 4 | Auto-merging index.html 5 | CONFLICT (content): Merge conflict in index.html 6 | Automatic merge failed; fix conflicts and then commit the result. 7 | -------------------------------------------------------------------------------- /output/38-01.txt: -------------------------------------------------------------------------------- 1 | $ git clone --bare work work.git 2 | Cloning into bare repository 'work.git'... 3 | done. 4 | $ ls work.git 5 | branches 6 | config 7 | description 8 | HEAD 9 | hooks 10 | info 11 | objects 12 | packed-refs 13 | refs 14 | -------------------------------------------------------------------------------- /output/10-03.txt: -------------------------------------------------------------------------------- 1 | $ git switch main 2 | Previous HEAD position was 5836970 Initial commit 3 | Switched to branch 'main' 4 | $ cat hello.html 5 | 6 | 7 | 8 | 9 |

Hello, World!

10 | 11 | 12 | -------------------------------------------------------------------------------- /output/11-03.txt: -------------------------------------------------------------------------------- 1 | $ git tag v1-beta 2 | $ git log 3 | 46afaff 2023-11-28 | Added standard HTML page tags (HEAD, tag: v1-beta) [Alexander Shvets] 4 | 78433de 2023-11-28 | Added h1 tag [Alexander Shvets] 5 | 5836970 2023-11-28 | Initial commit [Alexander Shvets] 6 | -------------------------------------------------------------------------------- /output/12-02.txt: -------------------------------------------------------------------------------- 1 | $ git restore hello.html 2 | $ git status 3 | On branch main 4 | nothing to commit, working tree clean 5 | $ cat hello.html 6 | 7 | 8 | 9 | 10 |

Hello, World!

11 | 12 | 13 | -------------------------------------------------------------------------------- /output/19-02.txt: -------------------------------------------------------------------------------- 1 | $ git switch main 2 | Switched to branch 'main' 3 | $ cat hello.html 4 | 5 | 6 | 7 | 8 | 9 |

Hello, World!

10 | 11 | 12 | -------------------------------------------------------------------------------- /output/11-04.txt: -------------------------------------------------------------------------------- 1 | $ git checkout v1 2 | Previous HEAD position was 46afaff Added standard HTML page tags 3 | HEAD is now at b7614c1 Added HTML header 4 | $ git checkout v1-beta 5 | Previous HEAD position was b7614c1 Added HTML header 6 | HEAD is now at 46afaff Added standard HTML page tags 7 | -------------------------------------------------------------------------------- /output/20-05.txt: -------------------------------------------------------------------------------- 1 | $ mkdir css 2 | $ git mv style.css css/style.css 3 | $ git status 4 | On branch style 5 | Changes to be committed: 6 | (use "git restore --staged ..." to unstage) 7 | renamed: style.css -> css/style.css 8 | renamed: hello.html -> index.html 9 | 10 | -------------------------------------------------------------------------------- /output/10-01.txt: -------------------------------------------------------------------------------- 1 | $ git log 2 | b7614c1 2023-11-28 | Added HTML header (HEAD -> main) [Alexander Shvets] 3 | 46afaff 2023-11-28 | Added standard HTML page tags [Alexander Shvets] 4 | 78433de 2023-11-28 | Added h1 tag [Alexander Shvets] 5 | 5836970 2023-11-28 | Initial commit [Alexander Shvets] 6 | -------------------------------------------------------------------------------- /output/11-01.txt: -------------------------------------------------------------------------------- 1 | $ git tag v1 2 | $ git log 3 | b7614c1 2023-11-28 | Added HTML header (HEAD -> main, tag: v1) [Alexander Shvets] 4 | 46afaff 2023-11-28 | Added standard HTML page tags [Alexander Shvets] 5 | 78433de 2023-11-28 | Added h1 tag [Alexander Shvets] 6 | 5836970 2023-11-28 | Initial commit [Alexander Shvets] 7 | -------------------------------------------------------------------------------- /output/04-01.txt: -------------------------------------------------------------------------------- 1 | $ git status 2 | On branch main 3 | Changes not staged for commit: 4 | (use "git add ..." to update what will be committed) 5 | (use "git restore ..." to discard changes in working directory) 6 | modified: hello.html 7 | 8 | no changes added to commit (use "git add" and/or "git commit -a") 9 | -------------------------------------------------------------------------------- /output/11-06.txt: -------------------------------------------------------------------------------- 1 | $ git log main --all 2 | b7614c1 2023-11-28 | Added HTML header (tag: v1, main) [Alexander Shvets] 3 | 46afaff 2023-11-28 | Added standard HTML page tags (HEAD, tag: v1-beta) [Alexander Shvets] 4 | 78433de 2023-11-28 | Added h1 tag [Alexander Shvets] 5 | 5836970 2023-11-28 | Initial commit [Alexander Shvets] 6 | -------------------------------------------------------------------------------- /output/12-01.txt: -------------------------------------------------------------------------------- 1 | $ git status 2 | On branch main 3 | Changes not staged for commit: 4 | (use "git add ..." to update what will be committed) 5 | (use "git restore ..." to discard changes in working directory) 6 | modified: hello.html 7 | 8 | no changes added to commit (use "git add" and/or "git commit -a") 9 | -------------------------------------------------------------------------------- /output/09-03.txt: -------------------------------------------------------------------------------- 1 | $ git log --pretty=format:"%h %ad | %s%d [%an]" --date=short 2 | b7614c1 2023-11-28 | Added HTML header (HEAD -> main) [Alexander Shvets] 3 | 46afaff 2023-11-28 | Added standard HTML page tags [Alexander Shvets] 4 | 78433de 2023-11-28 | Added h1 tag [Alexander Shvets] 5 | 5836970 2023-11-28 | Initial commit [Alexander Shvets] -------------------------------------------------------------------------------- /output/29-01.txt: -------------------------------------------------------------------------------- 1 | $ git switch main 2 | Switched to branch 'main' 3 | $ git merge style 4 | Updating 85c14e9..39a1e0f 5 | Fast-forward 6 | css/style.css | 3 +++ 7 | hello.html => index.html | 1 + 8 | 2 files changed, 4 insertions(+) 9 | create mode 100644 css/style.css 10 | rename hello.html => index.html (73%) 11 | -------------------------------------------------------------------------------- /output/19-03.txt: -------------------------------------------------------------------------------- 1 | $ git switch style 2 | Switched to branch 'style' 3 | $ cat hello.html 4 | 5 | 6 | 7 | 8 | 9 | 10 |

Hello, World!

11 | 12 | 13 | -------------------------------------------------------------------------------- /output/20-02.txt: -------------------------------------------------------------------------------- 1 | $ git show v1 2 | b7614c1 2023-11-28 | Added HTML header (tag: v1) [Alexander Shvets] 3 | 4 | diff --git a/hello.html b/hello.html 5 | index 6da0629..0d576c4 100644 6 | --- a/hello.html 7 | +++ b/hello.html 8 | @@ -1,4 +1,6 @@ 9 | 10 | + 11 | + 12 | 13 |

Hello, World!

14 | 15 | -------------------------------------------------------------------------------- /output/25-02.txt: -------------------------------------------------------------------------------- 1 | $ git status 2 | On branch style 3 | You have unmerged paths. 4 | (fix conflicts and run "git commit") 5 | (use "git merge --abort" to abort the merge) 6 | 7 | Unmerged paths: 8 | (use "git add ..." to mark resolution) 9 | both modified: index.html 10 | 11 | no changes added to commit (use "git add" and/or "git commit -a") 12 | -------------------------------------------------------------------------------- /output/16-01.txt: -------------------------------------------------------------------------------- 1 | $ git tag -d oops 2 | Deleted tag 'oops' (was 86364a1) 3 | $ git log --all 4 | b7614c1 2023-11-28 | Added HTML header (HEAD -> main, tag: v1) [Alexander Shvets] 5 | 46afaff 2023-11-28 | Added standard HTML page tags (tag: v1-beta) [Alexander Shvets] 6 | 78433de 2023-11-28 | Added h1 tag [Alexander Shvets] 7 | 5836970 2023-11-28 | Initial commit [Alexander Shvets] 8 | -------------------------------------------------------------------------------- /output/08-01.txt: -------------------------------------------------------------------------------- 1 | $ git status 2 | On branch main 3 | Changes to be committed: 4 | (use "git restore --staged ..." to unstage) 5 | modified: hello.html 6 | 7 | Changes not staged for commit: 8 | (use "git add ..." to update what will be committed) 9 | (use "git restore ..." to discard changes in working directory) 10 | modified: hello.html 11 | 12 | -------------------------------------------------------------------------------- /output/15-03.txt: -------------------------------------------------------------------------------- 1 | $ git reset --hard v1 2 | HEAD is now at b7614c1 Added HTML header 3 | $ git log 4 | b7614c1 2023-11-28 | Added HTML header (HEAD -> main, tag: v1) [Alexander Shvets] 5 | 46afaff 2023-11-28 | Added standard HTML page tags (tag: v1-beta) [Alexander Shvets] 6 | 78433de 2023-11-28 | Added h1 tag [Alexander Shvets] 7 | 5836970 2023-11-28 | Initial commit [Alexander Shvets] 8 | -------------------------------------------------------------------------------- /output/17-03.txt: -------------------------------------------------------------------------------- 1 | $ git log 2 | 9288a33 2023-11-28 | Added copyright statement with email (HEAD -> main) [Alexander Shvets] 3 | b7614c1 2023-11-28 | Added HTML header (tag: v1) [Alexander Shvets] 4 | 46afaff 2023-11-28 | Added standard HTML page tags (tag: v1-beta) [Alexander Shvets] 5 | 78433de 2023-11-28 | Added h1 tag [Alexander Shvets] 6 | 5836970 2023-11-28 | Initial commit [Alexander Shvets] 7 | -------------------------------------------------------------------------------- /output/25-02-1.txt: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | <<<<<<< HEAD:index.html 5 | 6 | ======= 7 | Hello World Page 8 | >>>>>>> main:hello.html 9 | 10 | 11 |

Hello, World!

12 |

Let's learn Git together.

13 | 14 | 15 | -------------------------------------------------------------------------------- /pages/en/adding_a_remote_repository.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "39. Adding a remote repository" 3 | --- 4 | 5 | ### Goals 6 | 7 | - To add a bare repo as a remote to our original repo. 8 | 9 | Let's add the `work.git` repository to our original repository. 10 | 11 | 12 | ``` 13 | cd work 14 | git remote add shared ../work.git 15 | ``` 16 | 17 | 18 |

We are now in the `work` repository.

-------------------------------------------------------------------------------- /output/28-01-1.txt: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | <<<<<<< HEAD 5 | Hello World Page 6 | ======= 7 | 8 | >>>>>>> 903eb1d (Included stylesheet into hello.html) 9 | 10 | 11 |

Hello, World!

12 |

Let's learn Git together.

13 | 14 | 15 | -------------------------------------------------------------------------------- /output/32-02.txt: -------------------------------------------------------------------------------- 1 | $ git remote show origin 2 | * remote origin 3 | Fetch URL: /home/alex/githowto/repositories/work 4 | Push URL: /home/alex/githowto/repositories/work 5 | HEAD branch: main 6 | Remote branches: 7 | main tracked 8 | style tracked 9 | Local branch configured for 'git pull': 10 | main merges with remote main 11 | Local ref configured for 'git push': 12 | main pushes to main (up to date) 13 | -------------------------------------------------------------------------------- /pages/uk/adding_a_remote_repository.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "39. Додавання віддаленого репозиторія" 3 | --- 4 | 5 | ### Цілі 6 | 7 | - Додати чистий репозиторій як віддалений до нашого оригінального репозиторія. 8 | 9 | Додаймо репозиторій `work.git` до нашого оригінального репозиторія. 10 | 11 | 12 | ``` 13 | cd work 14 | git remote add shared ../work.git 15 | ``` 16 | 17 | 18 |

Зараз ми знаходимося в репозиторії `work`.

-------------------------------------------------------------------------------- /output/14-02.txt: -------------------------------------------------------------------------------- 1 | $ git log 2 | 86364a1 2023-11-28 | Revert "Oops, we didn't want this commit" (HEAD -> main) [Alexander Shvets] 3 | 6a44bec 2023-11-28 | Oops, we didn't want this commit [Alexander Shvets] 4 | b7614c1 2023-11-28 | Added HTML header (tag: v1) [Alexander Shvets] 5 | 46afaff 2023-11-28 | Added standard HTML page tags (tag: v1-beta) [Alexander Shvets] 6 | 78433de 2023-11-28 | Added h1 tag [Alexander Shvets] 7 | 5836970 2023-11-28 | Initial commit [Alexander Shvets] 8 | -------------------------------------------------------------------------------- /output/15-01.txt: -------------------------------------------------------------------------------- 1 | $ git log 2 | 86364a1 2023-11-28 | Revert "Oops, we didn't want this commit" (HEAD -> main) [Alexander Shvets] 3 | 6a44bec 2023-11-28 | Oops, we didn't want this commit [Alexander Shvets] 4 | b7614c1 2023-11-28 | Added HTML header (tag: v1) [Alexander Shvets] 5 | 46afaff 2023-11-28 | Added standard HTML page tags (tag: v1-beta) [Alexander Shvets] 6 | 78433de 2023-11-28 | Added h1 tag [Alexander Shvets] 7 | 5836970 2023-11-28 | Initial commit [Alexander Shvets] 8 | -------------------------------------------------------------------------------- /output/20-03.txt: -------------------------------------------------------------------------------- 1 | $ mv hello.html index.html 2 | $ git status 3 | On branch style 4 | Changes not staged for commit: 5 | (use "git add/rm ..." to update what will be committed) 6 | (use "git restore ..." to discard changes in working directory) 7 | deleted: hello.html 8 | 9 | Untracked files: 10 | (use "git add ..." to include in what will be committed) 11 | index.html 12 | 13 | no changes added to commit (use "git add" and/or "git commit -a") 14 | -------------------------------------------------------------------------------- /pages/pt-BR/adding_a_remote_repository.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "39. Adicionando um repositório remoto" 3 | --- 4 | 5 | ### Metas 6 | 7 | - Adicionar um repositório bare como um remoto para o nosso repositório original. 8 | 9 | Vamos adicionar o repositório `work.git` ao nosso repositório original. 10 | 11 | 12 | ``` 13 | cd work 14 | git remote add shared ../work.git 15 | ``` 16 | 17 | 18 |

Agora nós estamos no repositório `work`.

19 | -------------------------------------------------------------------------------- /output/08-02.txt: -------------------------------------------------------------------------------- 1 | $ git commit -m "Added standard HTML page tags" 2 | [main 46afaff] Added standard HTML page tags 3 | 1 file changed, 5 insertions(+), 1 deletion(-) 4 | $ git status 5 | On branch main 6 | Changes not staged for commit: 7 | (use "git add ..." to update what will be committed) 8 | (use "git restore ..." to discard changes in working directory) 9 | modified: hello.html 10 | 11 | no changes added to commit (use "git add" and/or "git commit -a") 12 | -------------------------------------------------------------------------------- /output/15-02.txt: -------------------------------------------------------------------------------- 1 | $ git log 2 | 86364a1 2023-11-28 | Revert "Oops, we didn't want this commit" (HEAD -> main, tag: oops) [Alexander Shvets] 3 | 6a44bec 2023-11-28 | Oops, we didn't want this commit [Alexander Shvets] 4 | b7614c1 2023-11-28 | Added HTML header (tag: v1) [Alexander Shvets] 5 | 46afaff 2023-11-28 | Added standard HTML page tags (tag: v1-beta) [Alexander Shvets] 6 | 78433de 2023-11-28 | Added h1 tag [Alexander Shvets] 7 | 5836970 2023-11-28 | Initial commit [Alexander Shvets] 8 | -------------------------------------------------------------------------------- /output/15-04.txt: -------------------------------------------------------------------------------- 1 | $ git log --all 2 | b7614c1 2023-11-28 | Added HTML header (HEAD -> main, tag: v1) [Alexander Shvets] 3 | 86364a1 2023-11-28 | Revert "Oops, we didn't want this commit" (tag: oops) [Alexander Shvets] 4 | 46afaff 2023-11-28 | Added standard HTML page tags (tag: v1-beta) [Alexander Shvets] 5 | 6a44bec 2023-11-28 | Oops, we didn't want this commit [Alexander Shvets] 6 | 78433de 2023-11-28 | Added h1 tag [Alexander Shvets] 7 | 5836970 2023-11-28 | Initial commit [Alexander Shvets] 8 | -------------------------------------------------------------------------------- /pages/ru/adding_a_remote_repository.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "39. Добавление удаленного репозитория" 3 | --- 4 | 5 | ### Цели 6 | 7 | - Добавить чистый репозиторий в качестве удаленного репозитория к нашему оригинальному репозиторию. 8 | 9 | Давайте добавим репозиторий `work.git` к нашему оригинальному репозиторию. 10 | 11 | 12 | ``` 13 | cd work 14 | git remote add shared ../work.git 15 | ``` 16 | 17 | 18 |

Сейчас мы находимся в репозитории `work`.

-------------------------------------------------------------------------------- /pages/en/rebasing_vs_merging.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "26. rebase vs merge" 3 | --- 4 | 5 | ### Goals 6 | 7 | - Learn the difference between rebasing and merging. 8 | 9 | ### Discussion 10 | 11 | Let us look at the differences between rebasing and merging. To do this, we need to get back into the repository at the time prior to the first merge, and then repeat the same steps but using relocating instead of merging. 12 | 13 | We will use the `reset` command to return the branch to a previous state. -------------------------------------------------------------------------------- /output/37-01.txt: -------------------------------------------------------------------------------- 1 | $ git branch --track style origin/style 2 | Branch 'style' set up to track remote branch 'style' from 'origin'. 3 | $ git branch -a 4 | * main 5 | style 6 | remotes/origin/HEAD -> origin/main 7 | remotes/origin/main 8 | remotes/origin/style 9 | $ git log --all --graph --max-count=2 10 | * 71df43a 2023-11-28 | Changed README in original repo (HEAD -> main, origin/main, origin/HEAD) [Alexander Shvets] 11 | * 39a1e0f 2023-11-28 | Renamed hello.html; moved style.css (origin/style, style) [Alexander Shvets] 12 | -------------------------------------------------------------------------------- /pages/pt-BR/rebasing_vs_merging.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "26. rebase como uma alternativa à merge" 3 | --- 4 | 5 | ### Metas 6 | 7 | - Aprender a diferença entre rebase e fundir. 8 | 9 | ### Discussão 10 | 11 | Vamos olhar para as diferenças entre `rebase` e `merge`. Para fazer isso, precisamos voltar no repositório no momento antes do primeiro merge e então repetir os mesmos passos realocando ao invés de fundindo. 12 | 13 | Nós usaremos o comando `reset` para voltar o branch para um estado anterior. 14 | -------------------------------------------------------------------------------- /output/41-01.txt: -------------------------------------------------------------------------------- 1 | $ git remote add shared ../work.git 2 | $ git branch --track shared main 3 | Branch 'shared' set up to track local branch 'main'. 4 | $ git pull shared main 5 | From ../work 6 | * branch main -> FETCH_HEAD 7 | * [new branch] main -> shared/main 8 | Updating 71df43a..d9d2bea 9 | Fast-forward 10 | README | 2 +- 11 | 1 file changed, 1 insertion(+), 1 deletion(-) 12 | $ cat README 13 | This is the Hello World example from the Git tutorial. 14 | (changed in the origin and pushed to shared) 15 | -------------------------------------------------------------------------------- /pages/uk/rebasing_vs_merging.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "26. rebase проти merge" 3 | --- 4 | 5 | ### Цілі 6 | 7 | - Дізнатися відмінності між перебазуванням і злиттям. 8 | 9 | ### Обговорення 10 | 11 | Розгляньмо відмінності між злиттям і перебазуванням. Для того, щоб це зробити, нам потрібно повернутися в репозиторій в момент до першого злиття, а потім повторити ті ж дії, але з використанням перебазування замість злиття. 12 | 13 | Ми будемо використовувати команду `reset` для повернення гілок до попереднього стану. -------------------------------------------------------------------------------- /output/17-01.txt: -------------------------------------------------------------------------------- 1 | $ git add hello.html 2 | $ git commit -m "Added copyright statement" 3 | [main e641c0e] Added copyright statement 4 | 1 file changed, 1 insertion(+) 5 | $ git log 6 | e641c0e 2023-11-28 | Added copyright statement (HEAD -> main) [Alexander Shvets] 7 | b7614c1 2023-11-28 | Added HTML header (tag: v1) [Alexander Shvets] 8 | 46afaff 2023-11-28 | Added standard HTML page tags (tag: v1-beta) [Alexander Shvets] 9 | 78433de 2023-11-28 | Added h1 tag [Alexander Shvets] 10 | 5836970 2023-11-28 | Initial commit [Alexander Shvets] 11 | -------------------------------------------------------------------------------- /output/19-01.txt: -------------------------------------------------------------------------------- 1 | $ git log --all 2 | 9288a33 2023-11-28 | Added copyright statement with email (main) [Alexander Shvets] 3 | 903eb1d 2023-11-28 | Included stylesheet into hello.html (HEAD -> style) [Alexander Shvets] 4 | b7614c1 2023-11-28 | Added HTML header (tag: v1) [Alexander Shvets] 5 | 46afaff 2023-11-28 | Added standard HTML page tags (tag: v1-beta) [Alexander Shvets] 6 | 555372e 2023-11-28 | Added css stylesheet [Alexander Shvets] 7 | 78433de 2023-11-28 | Added h1 tag [Alexander Shvets] 8 | 5836970 2023-11-28 | Initial commit [Alexander Shvets] 9 | -------------------------------------------------------------------------------- /pages/ru/rebasing_vs_merging.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "26. rebase против merge" 3 | --- 4 | 5 | ### Цели 6 | 7 | - Узнать различия между перебазированием и слиянием. 8 | 9 | ### Обсуждение 10 | 11 | Давайте рассмотрим различия между слиянием и перебазированием. Для того чтобы это сделать, нам нужно вернуться в репозиторий в момент до первого слияния, а затем повторить те же действия, но с использованием перебазирования вместо слияния. 12 | 13 | Мы будем использовать команду `reset` для возврата веток к предыдущему состоянию. -------------------------------------------------------------------------------- /pages/en/remove_the_oops_tag.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "16. Removing the oops tag" 3 | --- 4 | 5 | ### Goals 6 | 7 | - Removing the `oops` tag. 8 | 9 | ## _01_ Removal of the `oops` tag 10 | 11 | The `oops` tag has performed its function. Let us remove that tag and permit the garbage collector to delete referenced commit. 12 | 13 | 14 | ``` 15 | git tag -d oops 16 | git log --all 17 | ``` 18 | 19 | 20 | 21 | ```git 22 | ==include[output/16-01.txt] 23 | ``` 24 | 25 | 26 | The `oops` tag will no longer appear in the repository. -------------------------------------------------------------------------------- /output/20-01.txt: -------------------------------------------------------------------------------- 1 | $ git log hello.html 2 | 903eb1d 2023-11-28 | Included stylesheet into hello.html (HEAD -> style) [Alexander Shvets] 3 | 9288a33 2023-11-28 | Added copyright statement with email (main) [Alexander Shvets] 4 | b7614c1 2023-11-28 | Added HTML header (tag: v1) [Alexander Shvets] 5 | 46afaff 2023-11-28 | Added standard HTML page tags (tag: v1-beta) [Alexander Shvets] 6 | 78433de 2023-11-28 | Added h1 tag [Alexander Shvets] 7 | 5836970 2023-11-28 | Initial commit [Alexander Shvets] 8 | $ git log style.css 9 | 555372e 2023-11-28 | Added css stylesheet [Alexander Shvets] 10 | -------------------------------------------------------------------------------- /output/20-06.txt: -------------------------------------------------------------------------------- 1 | $ git commit -m "Renamed hello.html; moved style.css" 2 | [style 0ee0113] Renamed hello.html; moved style.css 3 | 2 files changed, 0 insertions(+), 0 deletions(-) 4 | rename style.css => css/style.css (100%) 5 | rename hello.html => index.html (100%) 6 | $ git log css/style.css 7 | 0ee0113 2023-11-28 | Renamed hello.html; moved style.css (HEAD -> style) [Alexander Shvets] 8 | $ git log --follow css/style.css 9 | 0ee0113 2023-11-28 | Renamed hello.html; moved style.css (HEAD -> style) [Alexander Shvets] 10 | 555372e 2023-11-28 | Added css stylesheet [Alexander Shvets] 11 | -------------------------------------------------------------------------------- /pages/uk/remove_the_oops_tag.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "16. Видалення тегу oops" 3 | --- 4 | 5 | ### Цілі 6 | 7 | - Видалення тегу `oops`. 8 | 9 | ## _01_ Видалення тегу `oops` 10 | 11 | Тег `oops` свою функцію виконав, видалимо його. Це дасть змогу внутрішньому механізму Git прибрати залишкові коміти, на які тепер не посилаються жодні гілки або теги. 12 | 13 | 14 | ``` 15 | git tag -d oops 16 | git log --all 17 | ``` 18 | 19 | 20 | 21 | ```git 22 | ==include[output/16-01.txt] 23 | ``` 24 | 25 | 26 | Тег `oops` більше не буде відображатися у репозиторії. -------------------------------------------------------------------------------- /pages/ru/remove_the_oops_tag.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "16. Удаление тега oops" 3 | --- 4 | 5 | ### Цели 6 | 7 | - Удаление тега `oops`. 8 | 9 | ## _01_ Удаление тега `oops` 10 | 11 | Тег `oops` свою функцию выполнил, давайте удалим его. Это позволит внутреннему механизму Git убрать остаточные коммиты, на которые теперь не ссылаются никакие ветки или теги. 12 | 13 | 14 | ``` 15 | git tag -d oops 16 | git log --all 17 | ``` 18 | 19 | 20 | 21 | ```git 22 | ==include[output/16-01.txt] 23 | ``` 24 | 25 | 26 | Тег `oops` больше не будет отображаться в репозитории. -------------------------------------------------------------------------------- /pages/pt-BR/remove_the_oops_tag.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "16. Removendo a tag oops" 3 | --- 4 | 5 | ### Metas 6 | 7 | - Remover a tag `oops`. 8 | 9 | ## _01_ Remoção da tag `oops` 10 | 11 | A tag `oops` cumpriu sua função, vamos removê-la. Isso permitirá que o mecanismo interno do Git remova os commits residuais, que agora não são referenciados por nenhum branch ou tag. 12 | 13 | 14 | ``` 15 | git tag -d oops 16 | git log --all 17 | ``` 18 | 19 | 20 | 21 | ```git 22 | ==include[output/16-01.txt] 23 | ``` 24 | 25 | 26 | A tag `oops` não aparecerá mais no repositório. 27 | -------------------------------------------------------------------------------- /output/27-03.txt: -------------------------------------------------------------------------------- 1 | $ git log --graph 2 | * 0ee0113 2023-11-28 | Renamed hello.html; moved style.css (HEAD -> style) [Alexander Shvets] 3 | * 903eb1d 2023-11-28 | Included stylesheet into hello.html [Alexander Shvets] 4 | * 555372e 2023-11-28 | Added css stylesheet [Alexander Shvets] 5 | * 9288a33 2023-11-28 | Added copyright statement with email [Alexander Shvets] 6 | * b7614c1 2023-11-28 | Added HTML header (tag: v1) [Alexander Shvets] 7 | * 46afaff 2023-11-28 | Added standard HTML page tags (tag: v1-beta) [Alexander Shvets] 8 | * 78433de 2023-11-28 | Added h1 tag [Alexander Shvets] 9 | * 5836970 2023-11-28 | Initial commit [Alexander Shvets] 10 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Contributor guide 2 | 3 | I've opened this repository in order to give people ability to translate content of githowto.com to their languages. 4 | 5 | Steps to create your translation: 6 | 7 | 1. Fork this repository. 8 | 2. In your fork, copy directory "en" (or any other language version) with all of it's content and rename it to the language code you're going to translate to. 9 | 3. Translate each of the text files inside the directory. Do not change the file names. Note, that the content is in Markdown format, although it is heavily using HTML. 10 | 4. Submit a pull request. 11 | 5. Once pull request is accepted, the translation will appear on the website. 12 | -------------------------------------------------------------------------------- /pages/en/pulling_shared_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "41. Pulling shared changes" 3 | --- 4 | 5 | ### Goals 6 | 7 | - Learn how to pull changes from the shared repository. 8 | 9 | Quickly switch to the `home` repository and pull the changes we just sent to the shared repository. 10 | 11 | 12 | ``` 13 | cd ../home 14 | ``` 15 | 16 | 17 |

We are now in the `home` repository.

18 | 19 | Continue with... 20 | 21 | 22 | ``` 23 | git remote add shared ../work.git 24 | git branch --track shared main 25 | git pull shared main 26 | cat README 27 | ``` 28 | 29 | 30 | 31 | ```git 32 | ==include[output/41-01.txt] 33 | ``` 34 | -------------------------------------------------------------------------------- /pages/uk/pulling_shared_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "41. Підтягування спільних змін" 3 | --- 4 | 5 | ### Цілі 6 | 7 | - Навчитися підтягувати зміни зі спільного репозиторія. 8 | 9 | Швидко перемкніться в репозиторій `home` і підтягніть зміни, щойно відправлені в спільний репозиторій. 10 | 11 | 12 | ``` 13 | cd ../home 14 | ``` 15 | 16 | 17 |

Зараз ми знаходимося у репозиторії `home`.

18 | 19 | Продовжіть з... 20 | 21 | 22 | ``` 23 | git remote add shared ../work.git 24 | git branch --track shared main 25 | git pull shared main 26 | cat README 27 | ``` 28 | 29 | 30 | 31 | ```git 32 | ==include[output/41-01.txt] 33 | ``` 34 | -------------------------------------------------------------------------------- /pages/ru/pulling_shared_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "41. Подтягивание общих изменений" 3 | --- 4 | 5 | ### Цели 6 | 7 | - Научиться подтягивать изменения из общего репозитория. 8 | 9 | Быстро переключитесь в репозиторий `home` и подтяните изменения, только что отправленные в общий репозиторий. 10 | 11 | 12 | ``` 13 | cd ../home 14 | ``` 15 | 16 | 17 |

Сейчас мы находимся в репозитории `home`.

18 | 19 | Продолжите с... 20 | 21 | 22 | ``` 23 | git remote add shared ../work.git 24 | git branch --track shared main 25 | git pull shared main 26 | cat README 27 | ``` 28 | 29 | 30 | 31 | ```git 32 | ==include[output/41-01.txt] 33 | ``` 34 | -------------------------------------------------------------------------------- /pages/pt-BR/pulling_shared_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "41. Removendo modificações comuns" 3 | --- 4 | 5 | ### Metas 6 | 7 | - Aprender a extrair alterações do repositório compartilhado. 8 | 9 | Rapidamente mude para o repositório `home` e extraia as modificações recém enviadas ao repositório comum. 10 | 11 | 12 | ``` 13 | cd ../home 14 | ``` 15 | 16 | 17 |

Agora nós estamos no repositório _home_.

18 | 19 | Continue com ... 20 | 21 | 22 | ``` 23 | git remote add shared ../work.git 24 | git branch --track shared main 25 | git pull shared main 26 | cat README 27 | ``` 28 | 29 | 30 | 31 | ```git 32 | ==include[output/41-01.txt] 33 | ``` 34 | -------------------------------------------------------------------------------- /pages/en/adding_a_tracking_branch.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "37. Adding a tracking branch" 3 | --- 4 | 5 | ### Goals 6 | 7 | - Learn how to add a local branch that tracks a remote branch. 8 | 9 | Branches that start with `remotes/origin` belong to the original repository. Note that you don't have a `style` branch anymore, but Git knows that it was in the original repository. 10 | 11 | ## _01_ Add a local branch tracking the remote branch 12 | 13 | 14 | ``` 15 | git branch --track style origin/style 16 | git branch -a 17 | git log --max-count=2 18 | ``` 19 | 20 | 21 | 22 | ```git 23 | ==include[output/37-01.txt] 24 | ``` 25 | 26 | 27 | Now we can see the `style` branch in the branch list and log. -------------------------------------------------------------------------------- /pages/ru/setup.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "0. Подготовка" 3 | --- 4 | 5 | ### Цели 6 | 7 | - Установить материалы учебника и подготовить их к работе. 8 | 9 | ## _01_ Скачайте учебные материалы 10 | 11 | Скачайте учебные материалы здесь: 12 | 13 | - [https://githowto.com/githowto.zip](/githowto.zip) 14 | 15 | ## _02_ Распакуйте учебные материалы 16 | 17 | Пакет учебных материалов должен иметь главную директорию `githowto` с двумя поддиректориями: 18 | 19 | - `repositories`: пустая директория, в которой будут располагаться ваши репозитории. 20 | - `files`: заранее упакованные файлы для того, чтобы вы могли продолжить работать с учебными материалами на любом этапе. Если вы застрянете, просто скопируйте нужный урок в свой репозиторий. -------------------------------------------------------------------------------- /output/22-01.txt: -------------------------------------------------------------------------------- 1 | $ git log --all --graph 2 | * ee16740 2023-11-28 | Added README (HEAD -> main) [Alexander Shvets] 3 | | * 0ee0113 2023-11-28 | Renamed hello.html; moved style.css (style) [Alexander Shvets] 4 | | * 903eb1d 2023-11-28 | Included stylesheet into hello.html [Alexander Shvets] 5 | | * 555372e 2023-11-28 | Added css stylesheet [Alexander Shvets] 6 | |/ 7 | * 9288a33 2023-11-28 | Added copyright statement with email [Alexander Shvets] 8 | * b7614c1 2023-11-28 | Added HTML header (tag: v1) [Alexander Shvets] 9 | * 46afaff 2023-11-28 | Added standard HTML page tags (tag: v1-beta) [Alexander Shvets] 10 | * 78433de 2023-11-28 | Added h1 tag [Alexander Shvets] 11 | * 5836970 2023-11-28 | Initial commit [Alexander Shvets] 12 | -------------------------------------------------------------------------------- /output/10-02.txt: -------------------------------------------------------------------------------- 1 | $ git checkout 5836970 2 | Note: switching to '5836970'. 3 | 4 | You are in 'detached HEAD' state. You can look around, make experimental 5 | changes and commit them, and you can discard any commits you make in this 6 | state without impacting any branches by switching back to a branch. 7 | 8 | If you want to create a new branch to retain commits you create, you may 9 | do so (now or later) by using -c with the switch command. Example: 10 | 11 | git switch -c 12 | 13 | Or undo this operation with: 14 | 15 | git switch - 16 | 17 | Turn off this advice by setting config variable advice.detachedHead to false 18 | 19 | HEAD is now at 5836970 Initial commit 20 | $ cat hello.html 21 | Hello, World! 22 | -------------------------------------------------------------------------------- /pages/en/setup.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "0. Initial setup" 3 | --- 4 | 5 | ### Goals 6 | 7 | - Prepare the materials of the tutorial. 8 | 9 | ## _01_ Download the tutorial materials 10 | 11 | You can download the tutorial materials from the following link: 12 | 13 | - [https://githowto.com/githowto.zip](/githowto.zip) 14 | 15 | ## _02_ Extract the tutorial materials 16 | 17 | The tutorial package contains two directories: 18 | 19 | - `repositories`: an empty directory where you will create your repositories. 20 | - `files`: contains prepackaged files that allow you to pick up the tutorial at any stage. If you encounter any difficulties, simply replace your repositories with the files from a corresponding lesson inside this directory. 21 | -------------------------------------------------------------------------------- /pages/en/thank_you.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Thank you!" 3 | --- 4 | 5 | That's it! Thank you for using GitHowTo. 6 | 7 | ## Feedback 8 | 9 | Feel free to email me your questions and feedback: 10 | 11 |

Alexander Shvets
12 | alex@githowto.com

13 | 14 | ## License 15 | 16 | This work is released under a [Creative Commons, Attribution-NonCommercial-ShareAlike License](http://creativecommons.org/licenses/by-nc-sa/3.0/). 17 | 18 | This site's content is [hosted on GitHub](https://github.com/shvetsgroup/githowto-content). If you find a typo and want to fix it, just create a [Pull Request](https://github.com/shvetsgroup/githowto-content/pulls) with a change. Same way you can contribute a translation. -------------------------------------------------------------------------------- /output/09-01.txt: -------------------------------------------------------------------------------- 1 | $ git log 2 | commit b7614c1aea1ffbc46400fe1a163842d6ec620a43 3 | Author: Alexander Shvets 4 | Date: Tue Nov 28 05:51:38 2023 -0600 5 | 6 | Added HTML header 7 | 8 | commit 46afaff2232fc3d564c40f65cb82e7e94839a1bb 9 | Author: Alexander Shvets 10 | Date: Tue Nov 28 05:51:38 2023 -0600 11 | 12 | Added standard HTML page tags 13 | 14 | commit 78433de967102f2b59d0a8a60eb397b2663ed282 15 | Author: Alexander Shvets 16 | Date: Tue Nov 28 05:51:38 2023 -0600 17 | 18 | Added h1 tag 19 | 20 | commit 58369706affbc1c27fa03a65fc7a05847278045f 21 | Author: Alexander Shvets 22 | Date: Tue Nov 28 05:51:38 2023 -0600 23 | 24 | Initial commit 25 | -------------------------------------------------------------------------------- /pages/pt-BR/setup.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "0. Preparação" 3 | --- 4 | 5 | ### Metas 6 | 7 | - Instalar os materiais do tutorial e deixá-los prontos para o trabalho. 8 | 9 | ## _01_ Faça download dos materiais do tutorial 10 | 11 | Faça download dos materiais do tutorial aqui: 12 | 13 | - [https://githowto.com/githowto.zip](/githowto.zip) 14 | 15 | ## _02_ Extraia os materiais do tutorial 16 | 17 | O pacote do tutorial deve conter a pasta principal `githowto` com duas sub-pastas: 18 | 19 | - `repositories`: um diretório de trabalho vazio. Seus repositórios serão criados aqui. 20 | - `files`: arquivos pré-empacotados para você continuar trabalhando no tutorial em qualquer passo. Se você ficar preso, apenas copie a lição desejada para o seu diretório de trabalho. 21 | -------------------------------------------------------------------------------- /output/29-02.txt: -------------------------------------------------------------------------------- 1 | $ git log --all --graph 2 | * 39a1e0f 2023-11-28 | Renamed hello.html; moved style.css (HEAD -> main, style) [Alexander Shvets] 3 | * 23149b5 2023-11-28 | Included stylesheet into hello.html [Alexander Shvets] 4 | * b9e6de1 2023-11-28 | Added css stylesheet [Alexander Shvets] 5 | * 85c14e9 2023-11-28 | Added meta title [Alexander Shvets] 6 | * ee16740 2023-11-28 | Added README [Alexander Shvets] 7 | * 9288a33 2023-11-28 | Added copyright statement with email [Alexander Shvets] 8 | * b7614c1 2023-11-28 | Added HTML header (tag: v1) [Alexander Shvets] 9 | * 46afaff 2023-11-28 | Added standard HTML page tags (tag: v1-beta) [Alexander Shvets] 10 | * 78433de 2023-11-28 | Added h1 tag [Alexander Shvets] 11 | * 5836970 2023-11-28 | Initial commit [Alexander Shvets] 12 | -------------------------------------------------------------------------------- /pages/uk/adding_a_tracking_branch.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "37. Додавання гілки відстеження" 3 | --- 4 | 5 | ### Цілі 6 | 7 | - Навчитися додавати локальну гілку, котра відстежує зміни віддаленої гілки. 8 | 9 | Гілки, котрі починаються з `remotes/origin` є гілками оригінального репозиторія. Зверніть увагу, що у вас більш немає гілки з назвою `style`, але Git знає, що в оригінальному репозиторії гілка `style` була. 10 | 11 | ## _01_ Додайте локальну гілку, котра відстежує віддалену гілку 12 | 13 | 14 | ``` 15 | git branch --track style origin/style 16 | git branch -a 17 | git log --max-count=2 18 | ``` 19 | 20 | 21 | 22 | ```git 23 | ==include[output/37-01.txt] 24 | ``` 25 | 26 | 27 | Тепер ми можемо бачити гілку `style` у списку гілок і у лозі. 28 | -------------------------------------------------------------------------------- /pages/uk/setup.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "0. Підготовка" 3 | --- 4 | 5 | ### Цілі 6 | 7 | - Встановити матеріали курсу і підготувати їх до роботи. 8 | 9 | ## _01_ Завантажте навчальні матеріали 10 | 11 | Завантажте матеріали тут: 12 | 13 | - [https://githowto.com/githowto.zip](/githowto.zip) 14 | 15 | ## _02_ Розпакуйте навчальні матеріали 16 | 17 | Пакет навчальних матеріалів складається з двох директорій: 18 | 19 | - `repositories`: порожня директорія, в якій ви будете створювати свої репозиторії. 20 | - `files`: завчасно упаковані файли для того, щоб ви могли продовжити роботу з навчальними матеріалами на будь-якому етапі. Якщо ви десь застрягнете, просто знайдіть в тут номер уроку, на якому ви зараз перебуваєте, та скопіюйте звідти репозиторії замість тих, що у вас є в `repositories`. -------------------------------------------------------------------------------- /pages/pt-BR/adding_a_tracking_branch.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "37. Adicionando um branch de rastreamento" 3 | --- 4 | 5 | ### Metas 6 | 7 | - Aprender como adicionar um branch local que rastreia um repositório remoto. 8 | 9 | Branches que começam com `remotes/origin` pertencem ao repositório original. Perceba que, mesmo que você não tenha mais o branch `style`, ele sabe que o branch está no repositório original. 10 | 11 | ## _01_ Adicione um branch local que rastreia um branch remoto 12 | 13 | 14 | ``` 15 | git branch --track style origin/style 16 | git branch -a 17 | git log --max-count=2 18 | ``` 19 | 20 | 21 | 22 | ```git 23 | ==include[output/37-01.txt] 24 | ``` 25 | 26 | 27 | Agora nós conseguimos ver o branch `style` na lista de branches e no log. 28 | -------------------------------------------------------------------------------- /pages/en/staging_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "5. Staging the changes" 3 | --- 4 | 5 | ### Goals 6 | 7 | - Learn to stage changes for the upcoming commits. 8 | 9 | ## _01_ Adding changes 10 | 11 | Now command Git to stage changes. Check the status: 12 | 13 | 14 | ``` 15 | git add hello.html 16 | git status 17 | ``` 18 | 19 | 20 | You will see: 21 | 22 | 23 | ```git 24 | ==include[output/05-01.txt] 25 | ``` 26 | 27 | 28 | Changes to the hello.html have been staged. This means that Git knows about the change, but it is not permanent in the repository. The next commit will include the changes staged. 29 | 30 | Should you decide not to commit the change, the `status` command will remind you that you can run `git restore --staged` command to unstage these changes. -------------------------------------------------------------------------------- /output/31-02.txt: -------------------------------------------------------------------------------- 1 | $ git log --all --graph 2 | * 39a1e0f 2023-11-28 | Renamed hello.html; moved style.css (HEAD -> main, origin/style, origin/main, origin/HEAD) [Alexander Shvets] 3 | * 23149b5 2023-11-28 | Included stylesheet into hello.html [Alexander Shvets] 4 | * b9e6de1 2023-11-28 | Added css stylesheet [Alexander Shvets] 5 | * 85c14e9 2023-11-28 | Added meta title [Alexander Shvets] 6 | * ee16740 2023-11-28 | Added README [Alexander Shvets] 7 | * 9288a33 2023-11-28 | Added copyright statement with email [Alexander Shvets] 8 | * b7614c1 2023-11-28 | Added HTML header (tag: v1) [Alexander Shvets] 9 | * 46afaff 2023-11-28 | Added standard HTML page tags (tag: v1-beta) [Alexander Shvets] 10 | * 78433de 2023-11-28 | Added h1 tag [Alexander Shvets] 11 | * 5836970 2023-11-28 | Initial commit [Alexander Shvets] 12 | -------------------------------------------------------------------------------- /output/11-02.txt: -------------------------------------------------------------------------------- 1 | $ git checkout v1^ 2 | Note: switching to 'v1^'. 3 | 4 | You are in 'detached HEAD' state. You can look around, make experimental 5 | changes and commit them, and you can discard any commits you make in this 6 | state without impacting any branches by switching back to a branch. 7 | 8 | If you want to create a new branch to retain commits you create, you may 9 | do so (now or later) by using -c with the switch command. Example: 10 | 11 | git switch -c 12 | 13 | Or undo this operation with: 14 | 15 | git switch - 16 | 17 | Turn off this advice by setting config variable advice.detachedHead to false 18 | 19 | HEAD is now at 46afaff Added standard HTML page tags 20 | $ cat hello.html 21 | 22 | 23 |

Hello, World!

24 | 25 | 26 | -------------------------------------------------------------------------------- /pages/pt-BR/thank_you.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Obrigado!" 3 | --- 4 | 5 | Isso é tudo! Obrigado por usar o GitHowTo. 6 | 7 | ## Comentários 8 | 9 | Sinta-se à vontade para nos enviar um email com suas questões e comentários: 10 | 11 |

Alexander Shvets
12 | alex@githowto.com

13 | 14 | ## Licença 15 | 16 | This work is released under a [Creative Commons, Attribution-NonCommercial-ShareAlike License](http://creativecommons.org/licenses/by-nc-sa/3.0/). 17 | 18 | O conteúdo desse site está [hospedado no Github](https://github.com/shvetsgroup/githowto-content). Se você encontrou um erro de digitação e quer consertá-lo, crie um [Pull Request](https://github.com/shvetsgroup/githowto-content/pulls) com a modificação. Da mesma maneira, você pode contribuir com uma tradução. 19 | -------------------------------------------------------------------------------- /pages/ru/adding_a_tracking_branch.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "37. Добавление ветки наблюдения" 3 | --- 4 | 5 | ### Цели 6 | 7 | - Научиться добавлять локальную ветку, которая отслеживает изменения удаленной ветки. 8 | 9 | Ветки, которые начинаются с `remotes/origin` являются ветками оригинального репозитория. Обратите внимание, что у вас больше нет ветки под названием `style`, но система контроля версий знает, что в оригинальном репозитории ветка `style` была. 10 | 11 | ## _01_ Добавьте локальную ветку, которая отслеживает удаленную ветку 12 | 13 | 14 | ``` 15 | git branch --track style origin/style 16 | git branch -a 17 | git log --max-count=2 18 | ``` 19 | 20 | 21 | 22 | ```git 23 | ==include[output/37-01.txt] 24 | ``` 25 | 26 | 27 | Теперь мы можем видеть ветку `style` в списке веток и логе. 28 | -------------------------------------------------------------------------------- /pages/uk/staging_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "5. Індексація змін" 3 | --- 4 | 5 | ### Цілі 6 | 7 | - Навчитися індексувати зміни для наступних комітів. 8 | 9 | ## _01_ Додайте зміни 10 | 11 | Зараз, дайте команду Git проіндексувати зміни. Перевірте стан: 12 | 13 | 14 | ``` 15 | git add hello.html 16 | git status 17 | ``` 18 | 19 | 20 | Ви побачите: 21 | 22 | 23 | ```git 24 | ==include[output/05-01.txt] 25 | ``` 26 | 27 | 28 | Зміни файлу `hello.html` було проіндексовано. Це означає, що Git тепер знає про зміни, але вони поки що не _перманентно_ (читай, _назавжди_) записані до репозиторія. Наступний коміт буде містити проіндексовані зміни. 29 | 30 | Якщо ви вирішили, що _не_ хочете комітити зміни, команда стану нагадає вам про те, що за допомогою команди `git restore --staged` можна зняти індексацію цих змін. -------------------------------------------------------------------------------- /pages/ru/thank_you.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Спасибо!" 3 | --- 4 | 5 | Спасибо за использование GitHowTo! Надеюсь, вам было интересно. 6 | 7 | ## Отзывы и пожелания 8 | 9 | Если у вас есть вопросы, отзывы или пожелания, присылайте их мне на email: 10 | 11 |

Александр Швец
12 | alex@githowto.com

13 | 14 | ## Лицензия 15 | 16 | Содержимое этого сайта находится под лицензией [Creative Commons, Attribution-NonCommercial-ShareAlike](http://creativecommons.org/licenses/by-nc-sa/3.0/). 17 | 18 | Содержимое сайта [доступно на Github](https://github.com/shvetsgroup/githowto-content). Если вы нашли ошибку или хотите сделать правку, можете создать [Pull Request](https://github.com/shvetsgroup/githowto-content/pulls) с вашим исправлением, либо просто создать новую [Issue](https://github.com/shvetsgroup/githowto-content/issues). -------------------------------------------------------------------------------- /pages/pt-BR/staging_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "5. Adicionando modificações ao stage" 3 | --- 4 | 5 | ### Metas 6 | 7 | - Aprender a adicionar modificações ao stage para os próximos commits. 8 | 9 | ## _01_ Adicionando modificações 10 | 11 | Agora mande o Git adicionar as modificações ao stage. Confira o status. 12 | 13 | 14 | ``` 15 | git add hello.html 16 | git status 17 | ``` 18 | 19 | 20 | Você verá: 21 | 22 | 23 | ```git 24 | ==include[output/05-01.txt] 25 | ``` 26 | 27 | 28 | Modificações no hello.html foram adicionadas ao stage. Isso quer dizer que o Git sabe da modificação, mas não é permanente no repositório. O próximo commit incluirá as modificações que estão no stage. 29 | 30 | Se você decidir não fazer commit da modificação, o comando `status` vai te lembrar que você pode usar o comando `git restore --staged` para remover essas mudanças do stage. 31 | -------------------------------------------------------------------------------- /output/24-01.txt: -------------------------------------------------------------------------------- 1 | $ git log --all --graph 2 | * 85c14e9 2023-11-28 | Added meta title (HEAD -> main) [Alexander Shvets] 3 | | * a33deed 2023-11-28 | Merge branch 'main' into style (style) [Alexander Shvets] 4 | | |\ 5 | | |/ 6 | |/| 7 | * | ee16740 2023-11-28 | Added README [Alexander Shvets] 8 | | * 0ee0113 2023-11-28 | Renamed hello.html; moved style.css [Alexander Shvets] 9 | | * 903eb1d 2023-11-28 | Included stylesheet into hello.html [Alexander Shvets] 10 | | * 555372e 2023-11-28 | Added css stylesheet [Alexander Shvets] 11 | |/ 12 | * 9288a33 2023-11-28 | Added copyright statement with email [Alexander Shvets] 13 | * b7614c1 2023-11-28 | Added HTML header (tag: v1) [Alexander Shvets] 14 | * 46afaff 2023-11-28 | Added standard HTML page tags (tag: v1-beta) [Alexander Shvets] 15 | * 78433de 2023-11-28 | Added h1 tag [Alexander Shvets] 16 | * 5836970 2023-11-28 | Initial commit [Alexander Shvets] 17 | -------------------------------------------------------------------------------- /pages/uk/merging.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "23. Злиття" 3 | --- 4 | 5 | ### Цілі 6 | 7 | - Навчитися зливати дві відмінні гілки для перенесення змін в одну гілку. 8 | 9 | ## _01_ Злиття гілок 10 | 11 | Злиття переносить зміни з двох гілок в одну. Повернемося до гілки `style` і зіллємо `main` із `style`. 12 | 13 | 14 | ``` 15 | git switch style 16 | git merge main 17 | git log --all --graph 18 | ``` 19 | 20 | 21 | 22 | ```git 23 | ==include[output/23-01.txt] 24 | ``` 25 | 26 | 27 | Шляхом періодичного злиття гілки `main` з гілкою `style` ви можете переносити з `main` будь-які зміни та підтримувати сумісність змін `style` зі змінами в основній гілці. 28 | 29 | Однак, це робить графіки комітів дійсно потворними. Пізніше ми розглянемо можливість перебазування, як альтернативи злиттю. 30 | 31 | ## _02_ Далі 32 | 33 | Що робити, якщо зміни в гілці `main` конфліктують зі змінами у `style`? -------------------------------------------------------------------------------- /pages/ru/staging_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "5. Индексация изменений" 3 | --- 4 | 5 | ### Цели 6 | 7 | - Научиться индексировать изменения для последующих коммитов. 8 | 9 | ## _01_ Добавьте изменения 10 | 11 | Теперь дайте команду Git проиндексировать изменения. Проверьте состояние: 12 | 13 | 14 | ``` 15 | git add hello.html 16 | git status 17 | ``` 18 | 19 | 20 | Вы увидите: 21 | 22 | 23 | ```git 24 | ==include[output/05-01.txt] 25 | ``` 26 | 27 | 28 | Изменения файла `hello.html` были проиндексированы. Это означает, что Git теперь знает об изменении, но изменение пока не _перманентно_ (читай, _навсегда_) записано в репозиторий. Следующий коммит будет включать в себя проиндексированные изменения. 29 | 30 | Если вы решили, что _не_ хотите коммитить изменения, команда состояния напомнит вам о том, что с помощью команды `git restore --staged` можно снять индексацию этих изменений. -------------------------------------------------------------------------------- /pages/uk/viewing_diverging_branches.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "22. Перегляд розбіжних гілок" 3 | --- 4 | 5 | ### Цілі 6 | 7 | - Навчитися переглядати розбіжні гілки у репозиторії. 8 | 9 | ## _01_ Перегляньте поточні гілки 10 | 11 | Тепер у репозиторії є дві гілки, що розходяться. Скористайтеся наступною командою `log`, щоб переглянути гілки і те, як вони розходяться. 12 | 13 | 14 | ``` 15 | git log --all --graph 16 | ``` 17 | 18 | 19 | 20 | ```git 21 | ==include[output/22-01.txt] 22 | ``` 23 | 24 | 25 | Опція `--all` гарантує, що ми бачимо всі гілки, оскільки за замовчуванням у лозі показується тільки поточна гілка. 26 | 27 | Опція `--graph` додає просте дерево комітів, зображене текстовими лініями. Ми бачимо обидві гілки (`style` і `main`) і те, що гілка `main` відмічена як `HEAD`, тобто вона є поточною. Спільним предком для обох гілок є гілка, у якій було внесено коміт «Added copyright statement with email». -------------------------------------------------------------------------------- /pages/uk/thank_you.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Дякую!" 3 | --- 4 | 5 | Дякую за користування GitHowTo! Маю надію, вам було цікаво. 6 | 7 | ## Відгуки та пропозиції 8 | 9 | Якщо у вас є запитання, відгуки чи пропозиції, надсилайте їх мені на email: 10 | 11 |

Олександр Швець
12 | alex@githowto.com

13 | 14 | ## Ліцензія 15 | 16 | Вміст цього сайту знаходиться під ліцензією [Creative Commons, Attribution-NonCommercial-ShareAlike](http://creativecommons.org/licenses/by-nc-sa/3.0/). 17 | 18 | Вміст сайту [доступний на Github](https://github.com/shvetsgroup/githowto-content). Якщо ви знайшли помилку на сайті, можете створити [Pull Request](https://github.com/shvetsgroup/githowto-content/pulls) із виправленням, або просто додати нову [Issue](https://github.com/shvetsgroup/githowto-content/issues). 19 | 20 | ## Подяка за переклад 21 | 22 | Цей сайт люб'язно переклав на українську Олексій Дашевський. -------------------------------------------------------------------------------- /pages/en/merging.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "23. Merging" 3 | --- 4 | 5 | ### Goals 6 | 7 | - Learn how to merge two distinct branches to restore changes to a single branch. 8 | 9 | ## _01_ Merge the branches 10 | 11 | Merging brings changes from two branches into one. Let us go back to the `style` branch and merge it with `main`. 12 | 13 | 14 | ``` 15 | git switch style 16 | git merge main 17 | git log --all --graph 18 | ``` 19 | 20 | 21 | 22 | ```git 23 | ==include[output/23-01.txt] 24 | ``` 25 | 26 | 27 | Through periodic `main` branch merging with the `style` branch you can pick up any changes or modifications to the `main` to maintain compatibility with the `style` changes in the mainline. 28 | 29 | However, it does produce ugly commit graphs. Later we will look at the option of rebasing rather than merging. 30 | 31 | ## _02_ Next 32 | 33 | But what if changes to the `main` branch conflict with changes in `style`? -------------------------------------------------------------------------------- /pages/en/change_the_original_repository.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "34. Changing the original repository" 3 | --- 4 | 5 | ### Goals 6 | 7 | - To make changes to the original repository, so we can try to pull the changes. 8 | 9 | ## _01_ Make a change in the original `work` repository 10 | 11 | 12 | ``` 13 | cd ../work 14 | ``` 15 | 16 | 17 |

We are now in the `work` repository.

18 | 19 | Make the following changes to the `README` file: 20 | 21 | 22 | ``` 23 | This is the Hello World example from the Git tutorial. 24 | (changed in origin) 25 | ``` 26 | 27 | 28 | Now add and commit this change 29 | 30 | 31 | ``` 32 | git add README 33 | git commit -m "Changed README in original repo" 34 | ``` 35 | 36 | 37 | ## _02_ Next 38 | 39 | Now the original repo has more recent changes that are not included in the cloned version. Next we will pull those changes across to the cloned repo. -------------------------------------------------------------------------------- /pages/en/viewing_diverging_branches.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "22. Viewing diverging branches" 3 | --- 4 | 5 | ### Goals 6 | 7 | - Learn how to view diverging branches in a repository. 8 | 9 | ## _01_ View current branches 10 | 11 | We now have two diverging branches in the repository. Use the following `log` command to view the branches and how they diverge. 12 | 13 | 14 | ``` 15 | git log --all --graph 16 | ``` 17 | 18 | 19 | 20 | ```git 21 | ==include[output/22-01.txt] 22 | ``` 23 | 24 | 25 | The `--all` flag guarantees that we see all the branches. By default, only the current branch is displayed. 26 | 27 | The `--graph` option adds a simple commit tree represented with basic text lines. We see both branches (`style` and `main`) and that the branch `main` is marked as `HEAD`, meaning that it's current. The common ancestor to both branches is the branch where the "Added copyright statement with email" commit has been introduced. 28 | -------------------------------------------------------------------------------- /pages/ru/merging.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "23. Слияние" 3 | --- 4 | 5 | ### Цели 6 | 7 | - Научиться сливать две отличающиеся ветки для переноса изменений обратно в одну ветку. 8 | 9 | ## _01_ Слияние веток 10 | 11 | Слияние переносит изменения из двух веток в одну. Давайте вернемся к ветке `style` и сольем `main` со `style`. 12 | 13 | 14 | ``` 15 | git switch style 16 | git merge main 17 | git log --all --graph 18 | ``` 19 | 20 | 21 | 22 | ```git 23 | ==include[output/23-01.txt] 24 | ``` 25 | 26 | 27 | Путем периодического слияния ветки `main` с веткой `style` вы можете переносить из `main` любые изменения и поддерживать совместимость изменений `style` с изменениями в основной ветке. 28 | 29 | Однако, это делает графики коммитов действительно уродливыми. Позже мы рассмотрим возможность перебазирования, как альтернативы слиянию. 30 | 31 | ## _02_ Далее 32 | 33 | Но что если изменения в ветке `main` конфликтуют с изменениями в `style`? -------------------------------------------------------------------------------- /pages/en/what_is_origin.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "32. What is origin?" 3 | --- 4 | 5 | ### Goals 6 | 7 | - Learn about the naming of the remote repositories. 8 | 9 | 10 | ``` 11 | git remote 12 | ``` 13 | 14 | 15 | 16 | ```git 17 | ==include[output/32-01.txt] 18 | ``` 19 | 20 | 21 | We see that the cloned repository knows the default name of the remote repository. To get more information about origin: 22 | 23 | 24 | ``` 25 | git remote show origin 26 | ``` 27 | 28 | 29 | 30 | ```git 31 | ==include[output/32-02.txt] 32 | ``` 33 | 34 | 35 | We can see that the `origin` of the remote repository is the original `work` repo. Remote repos are typically stored on a separate machine or a centralized server. However, as we see, they can also point to a repository on the same machine. There is nothing so special about the name `origin`, but there is a convention to use it for the primary centralized repository (if any). -------------------------------------------------------------------------------- /pages/en/making_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "4. Making changes" 3 | --- 4 | 5 | ### Goals 6 | 7 | - Learn to monitor the working directory’s state. 8 | 9 | ## _01_ Changing the “Hello, World” page 10 | 11 | Let's add some HTML-tags to our greeting. Change the file contents to: 12 | 13 | 14 | ```html 15 | →

←Hello, World!→

← 16 | ``` 17 | 18 | 19 | ## _02_ Checking the status 20 | 21 | Check the working directory’s status. 22 | 23 | 24 | ``` 25 | git status 26 | ``` 27 | 28 | 29 | You will see: 30 | 31 | 32 | ```git 33 | ==include[output/04-01.txt] 34 | ``` 35 | 36 | 37 | The first important aspect here is that Git knows `hello.html` file has been changed, but these changes are not yet committed to the repository. 38 | 39 | Another aspect is that the status message hints about what to do next. If you want to add these changes to the repository, use `git add`. To undo the changes use `git restore`. 40 | -------------------------------------------------------------------------------- /pages/ru/viewing_diverging_branches.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "22. Просмотр отличающихся веток" 3 | --- 4 | 5 | ### Цели 6 | 7 | - Научиться просматривать отличающиеся ветки в репозитории. 8 | 9 | ## _01_ Просмотрите текущие ветки 10 | 11 | Теперь у нас есть две расходящиеся ветки в репозитории. Используйте следующую команду `log` для просмотра веток и их расхождения. 12 | 13 | 14 | ``` 15 | git log --all --graph 16 | ``` 17 | 18 | 19 | 20 | ```git 21 | ==include[output/22-01.txt] 22 | ``` 23 | 24 | 25 | Опция `--all` гарантирует, что мы видим все ветки, так как по умолчанию в логе показывается только текущая ветка. 26 | 27 | Опция `--graph` добавляет простое дерево коммитов, представленное в виде простых текстовых линий. Мы видим обе ветки (`style` и `main`) причём ветка `main` помечена как `HEAD`, что означает, что она является текущей. Общим предком для обеих веток является ветка, в которую был внесен коммит «Added copyright statement with email». 28 | -------------------------------------------------------------------------------- /pages/pt-BR/change_the_original_repository.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "34. Mudando o repositório original" 3 | --- 4 | 5 | ### Metas 6 | 7 | - Fazer mudanças no repositório original para que possamos tentar receber essas mudanças. 8 | 9 | ## _01_ Faça uma mudança no repositório original `work` 10 | 11 | 12 | ``` 13 | cd ../work 14 | ``` 15 | 16 | 17 |

Agora nós estamos no repositório `work`

18 | 19 | Faça as seguintes mudanças no arquivo `README`: 20 | 21 | 22 | ``` 23 | This is the Hello World example from the Git tutorial. 24 | (changed in origin) 25 | ``` 26 | 27 | 28 | Agora adicione e faça commit dessas mudanças 29 | 30 | 31 | ``` 32 | git add README 33 | git commit -m "Changed README in original repo" 34 | ``` 35 | 36 | 37 | ## _02_ Próximo 38 | 39 | Agora o repositório original tem mudanças mais recentes que não estão incluídas na versão clonada. Em seguida, vamos receber essas mudanças no repositório clonado. -------------------------------------------------------------------------------- /pages/uk/change_the_original_repository.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "34. Зміна оригінального репозиторія" 3 | --- 4 | 5 | ### Цілі 6 | 7 | - Внести деякі зміни в оригінальний репозиторій, щоб потім спробувати підтягнути та злити зміни з віддаленої гілки в поточну. 8 | 9 | ## _01_ Внесіть зміни в оригінальний репозиторій `work` 10 | 11 | 12 | ``` 13 | cd ../work 14 | ``` 15 | 16 | 17 |

Зараз ми знаходимося в репозиторії `work`.

18 | 19 | Внесіть наступні зміни у файл `README`: 20 | 21 | 22 | ``` 23 | This is the Hello World example from the Git tutorial. 24 | (changed in origin) 25 | ``` 26 | 27 | 28 | Тепер додайте цю зміну і зробіть коміт 29 | 30 | 31 | ``` 32 | git add README 33 | git commit -m "Changed README in original repo" 34 | ``` 35 | 36 | 37 | ## _02_ Далі 38 | 39 | Тепер в оригінальному репозиторії є більш пізні зміни, яких немає в клонованій версії. Далі ми винесемо і зіллємо ці зміни до клонованого репозиторія. -------------------------------------------------------------------------------- /output/27-01.txt: -------------------------------------------------------------------------------- 1 | $ git switch style 2 | Already on 'style' 3 | $ git log --graph 4 | * 79ac6fa 2023-11-28 | Resolved merge conflict (HEAD -> style) [Alexander Shvets] 5 | |\ 6 | | * 85c14e9 2023-11-28 | Added meta title (main) [Alexander Shvets] 7 | * | a33deed 2023-11-28 | Merge branch 'main' into style [Alexander Shvets] 8 | |\| 9 | | * ee16740 2023-11-28 | Added README [Alexander Shvets] 10 | * | 0ee0113 2023-11-28 | Renamed hello.html; moved style.css [Alexander Shvets] 11 | * | 903eb1d 2023-11-28 | Included stylesheet into hello.html [Alexander Shvets] 12 | * | 555372e 2023-11-28 | Added css stylesheet [Alexander Shvets] 13 | |/ 14 | * 9288a33 2023-11-28 | Added copyright statement with email [Alexander Shvets] 15 | * b7614c1 2023-11-28 | Added HTML header (tag: v1) [Alexander Shvets] 16 | * 46afaff 2023-11-28 | Added standard HTML page tags (tag: v1-beta) [Alexander Shvets] 17 | * 78433de 2023-11-28 | Added h1 tag [Alexander Shvets] 18 | * 5836970 2023-11-28 | Initial commit [Alexander Shvets] 19 | -------------------------------------------------------------------------------- /pages/uk/making_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "4. Внесення змін" 3 | --- 4 | 5 | ### Цілі 6 | 7 | - Навчитися відстежувати стан робочої директорії. 8 | 9 | ## _01_ Змініть сторінку «Hello, World» 10 | 11 | Додамо деякі HTML-теги до нашого вітання. Змініть вміст файлу на: 12 | 13 | 14 | ```html 15 | →

←Hello, World!→

← 16 | ``` 17 | 18 | 19 | ## _02_ Перевірте стан 20 | 21 | Перевірте стан робочої директорії. 22 | 23 | 24 | ``` 25 | git status 26 | ``` 27 | 28 | 29 | Ви побачите: 30 | 31 | 32 | ```git 33 | ==include[output/04-01.txt] 34 | ``` 35 | 36 | 37 | Перше, що потрібно зауважити — Git знає, що файл `hello.html` було змінено, але ці зміни ще не зафіксовано у репозиторії. 38 | 39 | Також, зверніть увагу, що повідомлення про стан репозитарію дає вам підказку про те, що необхідно зробити далі. Якщо ви хочете внести зміни у репозиторій, скористайтеся командою `git add`. Якщо ні - виконайте команду `git restore` для скасування змін. 40 | -------------------------------------------------------------------------------- /output/35-01.txt: -------------------------------------------------------------------------------- 1 | $ cd ../home 2 | $ git fetch 3 | From /home/alex/githowto/repositories/work 4 | 39a1e0f..71df43a main -> origin/main 5 | $ git log --all --graph 6 | * 71df43a 2023-11-28 | Changed README in original repo (origin/main, origin/HEAD) [Alexander Shvets] 7 | * 39a1e0f 2023-11-28 | Renamed hello.html; moved style.css (HEAD -> main, origin/style) [Alexander Shvets] 8 | * 23149b5 2023-11-28 | Included stylesheet into hello.html [Alexander Shvets] 9 | * b9e6de1 2023-11-28 | Added css stylesheet [Alexander Shvets] 10 | * 85c14e9 2023-11-28 | Added meta title [Alexander Shvets] 11 | * ee16740 2023-11-28 | Added README [Alexander Shvets] 12 | * 9288a33 2023-11-28 | Added copyright statement with email [Alexander Shvets] 13 | * b7614c1 2023-11-28 | Added HTML header (tag: v1) [Alexander Shvets] 14 | * 46afaff 2023-11-28 | Added standard HTML page tags (tag: v1-beta) [Alexander Shvets] 15 | * 78433de 2023-11-28 | Added h1 tag [Alexander Shvets] 16 | * 5836970 2023-11-28 | Initial commit [Alexander Shvets] 17 | -------------------------------------------------------------------------------- /pages/pt-BR/merging.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "23. Fusão" 3 | --- 4 | 5 | ### Metas 6 | 7 | - Aprender como fundir dois branches diferentes para restaurar as modificações para um único branch. 8 | 9 | ## _01_ Fundindo em um único branch 10 | 11 | Fundir junta as modificações de dois branches em um. Vamos voltar para o branch `style` e fundi-lo com o `main`. 12 | 13 | 14 | ``` 15 | git switch style 16 | git merge main 17 | git log --all --graph 18 | ``` 19 | 20 | 21 | 22 | ```git 23 | ==include[output/23-01.txt] 24 | ``` 25 | 26 | 27 | Pelo merge periodico entre os branches `main` e `style`, você pode acompanhar quaisquer mudanças ou modificações ocorridas para manter a compatibilidade das mudanças de estilo na linha principal. 28 | 29 | Porém, isso faz com que os gráficos de commits fiquem feios. Mais tarde vamos considerar a rebase como uma alternativa à fusão. 30 | 31 | ## _02_ Próximo 32 | 33 | Mas e se as modificações no branch `main` conflitarem com as modificações do `style`? 34 | -------------------------------------------------------------------------------- /pages/pt-BR/viewing_diverging_branches.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "22. Visualizando os diferentes branches" 3 | --- 4 | 5 | ### Metas 6 | 7 | - Aprender como visualizar os diferentes branches no repositório. 8 | 9 | ## _01_ Vendo o branch atual 10 | 11 | Agora temos duas ramificações divergentes no repositório. Use o seguinte comando `log` para visualizar as ramificações e como elas divergem. 12 | 13 | 14 | ``` 15 | git log --all --graph 16 | ``` 17 | 18 | 19 | 20 | ```git 21 | ==include[output/22-01.txt] 22 | ``` 23 | 24 | 25 | A flag `--all` garante que nós vejamos todos os branches. Por padrão, apenas o branch atual é mostrado. 26 | 27 | A flag `--graph` adiciona uma árvore de commit simples representada por linhas de texto básicas. Vemos as duas ramificações (`style` e `main`) e que a ramificação `main` está marcada como `HEAD`, o que significa que é a atual. O ancestral comum a ambas as ramificações é a ramificação em que o commit "Added copyright statement with email" foi introduzido. -------------------------------------------------------------------------------- /output/23-01.txt: -------------------------------------------------------------------------------- 1 | $ git switch style 2 | Switched to branch 'style' 3 | $ git merge main 4 | Merge made by the 'ort' strategy. 5 | README | 1 + 6 | 1 file changed, 1 insertion(+) 7 | create mode 100644 README 8 | $ git log --all --graph 9 | * a33deed 2023-11-28 | Merge branch 'main' into style (HEAD -> style) [Alexander Shvets] 10 | |\ 11 | | * ee16740 2023-11-28 | Added README (main) [Alexander Shvets] 12 | * | 0ee0113 2023-11-28 | Renamed hello.html; moved style.css [Alexander Shvets] 13 | * | 903eb1d 2023-11-28 | Included stylesheet into hello.html [Alexander Shvets] 14 | * | 555372e 2023-11-28 | Added css stylesheet [Alexander Shvets] 15 | |/ 16 | * 9288a33 2023-11-28 | Added copyright statement with email [Alexander Shvets] 17 | * b7614c1 2023-11-28 | Added HTML header (tag: v1) [Alexander Shvets] 18 | * 46afaff 2023-11-28 | Added standard HTML page tags (tag: v1-beta) [Alexander Shvets] 19 | * 78433de 2023-11-28 | Added h1 tag [Alexander Shvets] 20 | * 5836970 2023-11-28 | Initial commit [Alexander Shvets] 21 | -------------------------------------------------------------------------------- /pages/pt-BR/what_is_origin.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "32. O que é origin?" 3 | --- 4 | 5 | ### Metas 6 | 7 | - Aprender sobre os nomes dos repositórios remotos. 8 | 9 | 10 | ``` 11 | git remote 12 | ``` 13 | 14 | 15 | 16 | ```git 17 | ==include[output/32-01.txt] 18 | ``` 19 | 20 | 21 | Nós vemos que o repositório clonado sabe o nome do repositório remoto padrão. Para acessar mais informações sobre esse tal de origin: 22 | 23 | 24 | ``` 25 | git remote show origin 26 | ``` 27 | 28 | 29 | 30 | ```git 31 | ==include[output/32-02.txt] 32 | ``` 33 | 34 | 35 | Nós podemos ver que o `origin` do repositório remoto é o repositório `work` original. Repositórios remotos são tipicamente guardados em uma máquina separada ou em um servidor centralizado. Porém, como podemos ver, eles também podem apontar para um repositório na mesma máquina. Não tem nada especial sobre o nome `origin`, mas existe uma convenção de usá-lo para o repositório primário central (se houver algum). 36 | -------------------------------------------------------------------------------- /output/25-05.txt: -------------------------------------------------------------------------------- 1 | $ git status 2 | On branch style 3 | nothing to commit, working tree clean 4 | $ git log --all --graph 5 | * 79ac6fa 2023-11-28 | Resolved merge conflict (HEAD -> style) [Alexander Shvets] 6 | |\ 7 | | * 85c14e9 2023-11-28 | Added meta title (main) [Alexander Shvets] 8 | * | a33deed 2023-11-28 | Merge branch 'main' into style [Alexander Shvets] 9 | |\| 10 | | * ee16740 2023-11-28 | Added README [Alexander Shvets] 11 | * | 0ee0113 2023-11-28 | Renamed hello.html; moved style.css [Alexander Shvets] 12 | * | 903eb1d 2023-11-28 | Included stylesheet into hello.html [Alexander Shvets] 13 | * | 555372e 2023-11-28 | Added css stylesheet [Alexander Shvets] 14 | |/ 15 | * 9288a33 2023-11-28 | Added copyright statement with email [Alexander Shvets] 16 | * b7614c1 2023-11-28 | Added HTML header (tag: v1) [Alexander Shvets] 17 | * 46afaff 2023-11-28 | Added standard HTML page tags (tag: v1-beta) [Alexander Shvets] 18 | * 78433de 2023-11-28 | Added h1 tag [Alexander Shvets] 19 | * 5836970 2023-11-28 | Initial commit [Alexander Shvets] 20 | -------------------------------------------------------------------------------- /pages/ru/change_the_original_repository.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "34. Изменение оригинального репозитория" 3 | --- 4 | 5 | ### Цели 6 | 7 | - Внести некоторые изменения в оригинальный репозиторий, чтобы затем попытаться подтянуть и слить изменения из удаленной ветки в текущую. 8 | 9 | ## _01_ Внесите изменения в оригинальный репозиторий `work` 10 | 11 | 12 | ``` 13 | cd ../work 14 | ``` 15 | 16 | 17 |

Сейчас мы находимся в репозитории `work`.

18 | 19 | Внесите следующие изменения в файл `README`: 20 | 21 | 22 | ``` 23 | This is the Hello World example from the Git tutorial. 24 | (changed in origin) 25 | ``` 26 | 27 | 28 | Теперь добавьте это изменение и сделайте коммит 29 | 30 | 31 | ``` 32 | git add README 33 | git commit -m "Changed README in original repo" 34 | ``` 35 | 36 | 37 | ## _02_ Далее 38 | 39 | Теперь в оригинальном репозитории есть более поздние изменения, которых нет в клонированной версии. Далее мы подтянем и сольем эти изменения в клонированный репозиторий. -------------------------------------------------------------------------------- /pages/ru/merging_back_to_master.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "29. Слияние в ветку main" 3 | --- 4 | 5 | ### Цели 6 | 7 | - Мы поддерживали соответствие ветки `style` с веткой `main` (с помощью `rebase`), теперь давайте сольем изменения `style` в ветку `main`. 8 | 9 | ## _01_ Слейте `style` в `main` 10 | 11 | 12 | ``` 13 | git switch main 14 | git merge style 15 | ``` 16 | 17 | 18 | 19 | ```git 20 | ==include[output/29-01.txt] 21 | ``` 22 | 23 | 24 | Поскольку последний коммит в `main` предшествует последнему коммиту ветки `style`, Git может выполнить ускоренное слияние, просто переместив указатель ветки вперед, на тот же коммит, что и ветка `style`. 25 | 26 | При ускоренном слиянии конфликты не возникают. Кроме того, при ускоренном слиянии не создается фиксация слияния. 27 | 28 | ## _02_ Просмотрите логи 29 | 30 | 31 | ``` 32 | git log --all --graph 33 | ``` 34 | 35 | 36 | 37 | ```git 38 | ==include[output/29-02.txt] 39 | ``` 40 | 41 | 42 | Теперь ветки `style` и `main` идентичны. 43 | -------------------------------------------------------------------------------- /output/28-02.txt: -------------------------------------------------------------------------------- 1 | $ git add . 2 | $ git rebase --continue 3 | [detached HEAD 23149b5] Included stylesheet into hello.html 4 | 1 file changed, 1 insertion(+) 5 | Rebasing (3/3) Successfully rebased and updated refs/heads/style. 6 | $ git status 7 | On branch style 8 | nothing to commit, working tree clean 9 | $ git log --all --graph 10 | * 39a1e0f 2023-11-28 | Renamed hello.html; moved style.css (HEAD -> style) [Alexander Shvets] 11 | * 23149b5 2023-11-28 | Included stylesheet into hello.html [Alexander Shvets] 12 | * b9e6de1 2023-11-28 | Added css stylesheet [Alexander Shvets] 13 | * 85c14e9 2023-11-28 | Added meta title (main) [Alexander Shvets] 14 | * ee16740 2023-11-28 | Added README [Alexander Shvets] 15 | * 9288a33 2023-11-28 | Added copyright statement with email [Alexander Shvets] 16 | * b7614c1 2023-11-28 | Added HTML header (tag: v1) [Alexander Shvets] 17 | * 46afaff 2023-11-28 | Added standard HTML page tags (tag: v1-beta) [Alexander Shvets] 18 | * 78433de 2023-11-28 | Added h1 tag [Alexander Shvets] 19 | * 5836970 2023-11-28 | Initial commit [Alexander Shvets] 20 | -------------------------------------------------------------------------------- /pages/pt-BR/making_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "4. Fazendo modificações" 3 | --- 4 | 5 | ### Metas 6 | 7 | - Aprender a monitorar o estado do dirétorio de trabalho. 8 | 9 | ## _01_ Modificar a página de “Hello, World” 10 | 11 | Vamos adicionar algumas tags HTML para a nossa saudação. Modifique os conteúdos do arquivo para: 12 | 13 | 14 | ```html 15 | →

←Hello, World!→

← 16 | ``` 17 | 18 | 19 | ## _02_ Conferindo o status 20 | 21 | Confira o status do diretório de trabalho. 22 | 23 | 24 | ``` 25 | git status 26 | ``` 27 | 28 | 29 | Você verá: 30 | 31 | 32 | ```git 33 | ==include[output/04-01.txt] 34 | ``` 35 | 36 | 37 | O primeiro aspecto importante aqui é que o Git sabe que o arquivo `hello.html` foi modificado, mas essas modificações ainda não sofreram commit para o repositório. 38 | 39 | Outro aspecto é que a mensagem de status oferece dicas sobre o que fazer em seguida. Se você quiser adicionar essas modificações para o repositório, use `git add`. Para desfazer as modificações use `git restore`. 40 | -------------------------------------------------------------------------------- /pages/en/merging_back_to_master.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "29. Merging to the main branch" 3 | --- 4 | 5 | ### Goals 6 | 7 | - We have kept our `style` branch up to date with the `main` branch (using `rebase`), but now let's merge the `style` branch changes back into the `main`. 8 | 9 | ## _01_ Merge `style` into `main` 10 | 11 | 12 | ``` 13 | git switch main 14 | git merge style 15 | ``` 16 | 17 | 18 | 19 | ```git 20 | ==include[output/29-01.txt] 21 | ``` 22 | 23 | 24 | Since the last commit in `main` directly precedes the last commit of the `style` branch, Git can merge fast-forward by simply moving the branch pointer forward, pointing to the same commit as the `style` branch. 25 | 26 | Conflicts do not arise in the fast-forward merge. Also, fast-forward merges do not create a merge commit. 27 | 28 | ## _02_ Check the logs 29 | 30 | 31 | ``` 32 | git log --all --graph 33 | ``` 34 | 35 | 36 | 37 | ```git 38 | ==include[output/29-02.txt] 39 | ``` 40 | 41 | 42 | Now the `style` and `main` branches are identical. 43 | -------------------------------------------------------------------------------- /pages/en/remote_branches.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "33. Remote branches" 3 | --- 4 | 5 | ### Goals 6 | 7 | - Learn about local and remote branches. 8 | 9 | Let's take a look at the branches in our cloned repository. 10 | 11 | 12 | ``` 13 | git branch 14 | ``` 15 | 16 | 17 | 18 | ```git 19 | $ git branch 20 | * main 21 | ``` 22 | 23 | 24 | As we can see only the `main` branch is listed in it. Where is the `style` branch? `git branch` only lists the local branches by default. 25 | 26 | ## _01_ 01 List of the remote branches 27 | 28 | To see all the branches, try the following command: 29 | 30 | 31 | ``` 32 | git branch -a 33 | ``` 34 | 35 | 36 | 37 | ```git 38 | $ git branch -a 39 | * main 40 | remotes/origin/HEAD -> origin/main 41 | remotes/origin/style 42 | remotes/origin/main 43 | ``` 44 | 45 | 46 | Git lists all the branches from the original repo, but the remote repository branches are not treated as local ones. If we need our own **style** branch, we need to create it on our own. In a minute you will see how it is done. 47 | -------------------------------------------------------------------------------- /pages/ru/making_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "4. Внесение изменений" 3 | --- 4 | 5 | ### Цели 6 | 7 | - Научиться отслеживать состояние рабочей директории. 8 | 9 | ## _01_ Измените страницу «Hello, World» 10 | 11 | Добавим кое-какие HTML-теги к нашему приветствию. Измените содержимое файла на: 12 | 13 | 14 | ```html 15 | →

←Hello, World!→

← 16 | ``` 17 | 18 | 19 | ## _02_ Проверьте состояние 20 | 21 | Теперь проверьте состояние рабочей директории. 22 | 23 | 24 | ``` 25 | git status 26 | ``` 27 | 28 | 29 | Вы увидите... 30 | 31 | 32 | ```git 33 | ==include[output/04-01.txt] 34 | ``` 35 | 36 | 37 | Первое, что нужно заметить, это то, что Git знает, что файл `hello.html` был изменен, но при этом эти изменения еще не зафиксированы в репозитории. 38 | 39 | Также обратите внимание на то, что сообщение о состоянии дает вам подсказку о том, что нужно делать дальше. Если вы хотите добавить эти изменения в репозиторий, используйте команду `git add`. В противном случае используйте команду `git restore` для отмены изменений. 40 | -------------------------------------------------------------------------------- /pages/ru/what_is_origin.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "32. Что такое origin?" 3 | --- 4 | 5 | ### Цели 6 | 7 | - Узнать об именах удаленных репозиториев. 8 | 9 | 10 | ``` 11 | git remote 12 | ``` 13 | 14 | 15 | 16 | ```git 17 | ==include[output/32-01.txt] 18 | ``` 19 | 20 | 21 | Мы видим, что клонированный репозиторий знает об имени по умолчанию удаленного репозитория. Давайте посмотрим, можем ли мы получить более подробную информацию об имени по умолчанию: 22 | 23 | 24 | ``` 25 | git remote show origin 26 | ``` 27 | 28 | 29 | 30 | ```git 31 | ==include[output/32-02.txt] 32 | ``` 33 | 34 | 35 | Мы видим, что имя по умолчанию (`origin`) удаленного репозитория — изначальное `work`. Удаленные репозитории обычно размещаются на отдельной машине, возможно, централизованном сервере. Однако, как мы видим здесь, они могут с тем же успехом указывать на репозиторий на той же машине. Нет ничего особенного в имени `origin`, однако существует традиция использовать `origin` в качестве имени первичного централизованного репозитория (если таковой имеется). 36 | -------------------------------------------------------------------------------- /pages/uk/merging_back_to_master.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "29. Злиття в гілку main" 3 | --- 4 | 5 | ### Цілі 6 | 7 | - Ми підтримували відповідність гілки `style` гілці `main` (за допомогою `rebase`), тепер зіллємо зміни `style` в гілку `main`. 8 | 9 | ## _01_ Злиття `style` в `main` 10 | 11 | 12 | ``` 13 | git switch main 14 | git merge style 15 | ``` 16 | 17 | 18 | 19 | ```git 20 | ==include[output/29-01.txt] 21 | ``` 22 | 23 | 24 | Оскільки остання фіксація у гілці `main` безпосередньо передує останній фіксації у гілці `style`, Git може об'єднати швидке перемотування вперед, просто пересунувши вказівник гілки вперед, щоб він вказував на ту саму фіксацію, що й у гілці `style`. 25 | 26 | Конфлікти не виникають під час злиття з прискоренням. Крім того, під час злиття з прискоренням не створюється коміт злиття. 27 | 28 | ## _02_ Перегляньте логи 29 | 30 | 31 | ``` 32 | git log --all --graph 33 | ``` 34 | 35 | 36 | 37 | ```git 38 | ==include[output/29-02.txt] 39 | ``` 40 | 41 | 42 | Тепер гілки `style` і `main` ідентичні. 43 | -------------------------------------------------------------------------------- /pages/uk/remote_branches.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "33. Віддалені гілки" 3 | --- 4 | 5 | ### Цілі 6 | 7 | - Дізнатися про локальні та віддалені гілки. 8 | 9 | Подивімось на гілки, доступні в нашому клонованому репозиторії. 10 | 11 | 12 | ``` 13 | git branch 14 | ``` 15 | 16 | 17 | 18 | ```git 19 | $ git branch 20 | * main 21 | ``` 22 | 23 | 24 | Як ми бачимо, у списку лише гілка `main`. Де гілка `style`? Команда `git branch`, за замовчуванням, виводить лише список локальних гілок. 25 | 26 | ## _01_ Список віддалених гілок 27 | 28 | Для того, щоб побачити всі гілки, спробуйте наступну команду: 29 | 30 | 31 | ``` 32 | git branch -a 33 | ``` 34 | 35 | 36 | 37 | ```git 38 | $ git branch -a 39 | * main 40 | remotes/origin/HEAD -> origin/main 41 | remotes/origin/style 42 | remotes/origin/main 43 | ``` 44 | 45 | 46 | Git виводить всі коміти в оригінальний репозиторій, але гілки в віддаленому репозиторії не розглядаються як локальні. Якщо ми хочемо власну гілку `style`, ми повинні самі її створити. Через хвилину ви побачите, як це робиться. -------------------------------------------------------------------------------- /pages/uk/what_is_origin.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "32. Що таке origin?" 3 | --- 4 | 5 | ### Цілі 6 | 7 | - Дізнатися про імена віддалених репозиторіїв. 8 | 9 | 10 | ``` 11 | git remote 12 | ``` 13 | 14 | 15 | 16 | ```git 17 | ==include[output/32-01.txt] 18 | ``` 19 | 20 | 21 | Ми бачимо, що клонований репозиторій знає про ім'я за замовчуванням віддаленого репозиторія. Подивімось, чи можемо ми отримати більш детальну інформацію про ім'я за замовчуванням: 22 | 23 | 24 | ``` 25 | git remote show origin 26 | ``` 27 | 28 | 29 | 30 | ```git 31 | ==include[output/32-02.txt] 32 | ``` 33 | 34 | 35 | Ми бачимо, що «ім'я за замовчуванням» віддаленого репозиторія — початкове `work`. Віддалені репозиторії зазвичай розміщуються на окремій машині, можливо, централізованому сервері. Однак, як ми бачимо тут, вони можуть з тим самим успіхом вказувати на репозиторій на тій самій машині. Немає нічого особливого в «імені за замовчуванням», проте існує традиція використовувати «ім'я за замовчуванням» на первинному централізованому репозиторії (якщо такий є). 36 | -------------------------------------------------------------------------------- /pages/en/pushing_a_change.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "40. Pushing changes" 3 | --- 4 | 5 | ### Goals 6 | 7 | - Learn how to push changes to the remote repository. 8 | 9 | Since bare repositories are usually shared on some sort of network server, it is usually difficult to cd into the repo and pull changes. So we need to push our changes into other repositories. 10 | 11 | Let’s start by creating a change to be pushed. Edit the `README` and commit it: 12 | 13 | 14 | ``` 15 | This is the Hello World example from the Git tutorial. 16 | (changed in the origin and pushed to shared) 17 | ``` 18 | 19 | 20 | 21 | ``` 22 | git switch main 23 | git add README 24 | git commit -m "Added shared comment to readme" 25 | ``` 26 | 27 | 28 | Now send changes to the shared repository. 29 | 30 | 31 | ``` 32 | git push shared main 33 | ``` 34 | 35 | 36 | _The shared repository_ is the one receiving changes sent by us. Remember, we added it as a remote repository in the previous lesson? 37 | 38 | 39 | ```git 40 | ==include[output/40-01.txt] 41 | ``` 42 | 43 | -------------------------------------------------------------------------------- /pages/ru/remote_branches.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "33. Удаленные ветки" 3 | --- 4 | 5 | ### Цели 6 | 7 | - Узнать о локальных и удаленных ветках. 8 | 9 | Давайте посмотрим на ветки, доступные в нашем клонированном репозитории. 10 | 11 | 12 | ``` 13 | git branch 14 | ``` 15 | 16 | 17 | 18 | ```git 19 | $ git branch 20 | * main 21 | ``` 22 | 23 | 24 | Как мы видим, в списке только ветка `main`. Где ветка `style`? Команда `git branch` выводит только список локальных веток по умолчанию. 25 | 26 | ## _01_ Список удаленных веток 27 | 28 | Для того чтобы увидеть все ветки, попробуйте следующую команду: 29 | 30 | 31 | ``` 32 | git branch -a 33 | ``` 34 | 35 | 36 | 37 | ```git 38 | $ git branch -a 39 | * main 40 | remotes/origin/HEAD -> origin/main 41 | remotes/origin/style 42 | remotes/origin/main 43 | ``` 44 | 45 | 46 | Git выводит все коммиты в оригинальный репозиторий, но ветки в удаленном репозитории не рассматриваются как локальные. Если мы хотим иметь собственную ветку `style`, мы должны сами ее создать. Через минуту вы увидите, как это делается. -------------------------------------------------------------------------------- /pages/pt-BR/remote_branches.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "33. Branches remotos" 3 | --- 4 | 5 | ### Metas 6 | 7 | - Aprender sobre branches locais e remotos. 8 | 9 | Vamos dar uma olhada nos branches do nosso repositório clonado. 10 | 11 | 12 | ``` 13 | git branch 14 | ``` 15 | 16 | 17 | 18 | ```git 19 | $ git branch 20 | * main 21 | ``` 22 | 23 | 24 | Como podemos ver, apenas o branch `main` está listado. Onde está o branch `style`? `git branch` lista apenas os branches locais, por padrão. 25 | 26 | ## _01_ Lista dos branches remotos 27 | 28 | Para ver todos os branches, use o seguinte comando: 29 | 30 | 31 | ``` 32 | git branch -a 33 | ``` 34 | 35 | 36 | 37 | ```git 38 | $ git branch -a 39 | * main 40 | remotes/origin/HEAD -> origin/main 41 | remotes/origin/style 42 | remotes/origin/main 43 | ``` 44 | 45 | 46 | O Git lista todos os commits do repositório original, mas os branches do repositório remoto não são tratados como os locais. Se nós precisamos do nosso próprio branch `style`, teremos que criá-lo. Em um minuto você verá como isso é feito. 47 | -------------------------------------------------------------------------------- /pages/pt-BR/staging_and_committing.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "6. Colocando em stage e fazendo commits" 3 | --- 4 | 5 | Adicionar algo ao stage no Git permite que você continue fazendo modificações no seu diretório de trabalho e, quando decidir que quer interagir com o controle de versão, permite que guarde as mudanças em pequenos commits. 6 | 7 | Pense que você editou três arquivos (`a. html`, `b. html` e `c. html`). Depois disso você tem que fazer commit de todas as modificações para que as mudanças em `a. html` e `b. html` sejam um único commit, enquanto as mudanças em `c. html`, que não são lógicamente relacionadas com as duas outras mudanças nos outros dois arquivos, sejam enviadas em um commit diferente. 8 | 9 | Em teoria, você pode fazer o seguinte:: 10 | 11 | 12 | ``` 13 | git add a.html 14 | git add b.html 15 | git commit -m "Changes for a and b" 16 | ``` 17 | 18 | 19 | 20 | ``` 21 | git add c.html 22 | git commit -m "Unrelated change to c" 23 | ``` 24 | 25 | 26 | Separando a adição ao stage e o commit, você pode customizar o que vai em cada commit. 27 | -------------------------------------------------------------------------------- /pages/uk/cloning_repositories.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "30. Клонування репозиторіїв" 3 | --- 4 | 5 | ### Цілі 6 | 7 | - Навчитися робити копії репозиторіїв. 8 | 9 | Якщо ви працюєте в команді, наступні 8 уроків досить важливі в розумінні, тому що ви майже завжди будете працювати з клонованими репозиторіями. 10 | 11 | ## _01_ Перейдіть в директорію `repositories` 12 | 13 | 14 | ``` 15 | cd .. 16 | pwd 17 | ls 18 | ``` 19 | 20 | 21 |

Зараз ми знаходимося в директорії `repositories`.

22 | 23 | 24 | ```git 25 | ==include[output/30-01.txt] 26 | ``` 27 | 28 | 29 | У цей момент ви повинні знаходитися в директорії `repositories`. Тут має бути єдиний репозиторій під назвою `work`. 30 | 31 | ## _02_ Створіть клон репозиторія `work` 32 | 33 | Давайте створимо клон репозиторія. 34 | 35 | 36 | ``` 37 | git clone work home 38 | ls 39 | ``` 40 | 41 | 42 | 43 | ```git 44 | ==include[output/30-02.txt] 45 | ``` 46 | 47 | 48 | У вашому списку репозиторіїв тепер має бути два репозиторія: оригінальний репозиторій `work` і клонований репозиторій `home`. -------------------------------------------------------------------------------- /pages/pt-BR/merging_back_to_master.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "29. Fundindo com o branch main" 3 | --- 4 | 5 | ### Metas 6 | 7 | - Nós mantivemos nosso branch `style` atualizado em relação ao branch `main` (usando `rebase`), mas agora vamos fundir as modificações de volta no `main`. 8 | 9 | ## _01_ Fundindo `style` no `main` 10 | 11 | 12 | ``` 13 | git switch main 14 | git merge style 15 | ``` 16 | 17 | 18 | 19 | ```git 20 | ==include[output/29-01.txt] 21 | ``` 22 | 23 | 24 | Como o último commit em `main` precede diretamente o último commit do ramo `style`, o Git pode fazer a mesclagem rápida simplesmente movendo o ponteiro do ramo para frente, apontando para o mesmo commit do ramo `style`. 25 | 26 | Os conflitos não surgem na mesclagem de avanço rápido. Além disso, as mesclagens de avanço rápido não criam um commit de mesclagem. 27 | 28 | ## _02_ Confira os logs 29 | 30 | 31 | ``` 32 | git log --all --graph 33 | ``` 34 | 35 | 36 | 37 | ```git 38 | ==include[output/29-02.txt] 39 | ``` 40 | 41 | 42 | Agora, as ramificações `style` e `main` são idênticas. 43 | -------------------------------------------------------------------------------- /pages/pt-BR/cloning_repositories.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "30. Clonando repositórios" 3 | --- 4 | 5 | ### Metas 6 | 7 | - Aprender a fazer cópias dos repositórios. 8 | 9 | Se estiver trabalhando em uma equipe, é muito importante entender as 8 lições a seguir, pois quase sempre é necessário trabalhar com repositórios clonados. 10 | 11 | ## _01_ Vá para o seu diretório `repositories` 12 | 13 | 14 | ``` 15 | cd .. 16 | pwd 17 | ls 18 | ``` 19 | 20 | 21 |

Agora nós estamos no diretório `repositories`.

22 | 23 | 24 | ```git 25 | ==include[output/30-01.txt] 26 | ``` 27 | 28 | 29 | Neste ponto você deve estar no seu diretório `repositories`. Ele deve conter um único repositório chamado `work`. 30 | 31 | ## _02_ Crie um clone do repositório `work` 32 | 33 | Vamos criar um clone do repositório. 34 | 35 | 36 | ``` 37 | git clone work home 38 | ls 39 | ``` 40 | 41 | 42 | 43 | ```git 44 | ==include[output/30-02.txt] 45 | ``` 46 | 47 | 48 | Agora devem ter dois repositórios no seu diretório de trabalho: o `work` original e o repositório clonado, chamado `home`. 49 | -------------------------------------------------------------------------------- /pages/ru/cloning_repositories.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "30. Клонирование репозиториев" 3 | --- 4 | 5 | ### Цели 6 | 7 | - Научиться делать копии репозиториев. 8 | 9 | Если вы работаете в команде, последующие 8 уроков довольно важны в понимании, т.к. вы почти всегда будете работать с клонированными репозиториями. 10 | 11 | ## _01_ Перейдите в директорию `repositories` 12 | 13 | 14 | ``` 15 | cd .. 16 | pwd 17 | ls 18 | ``` 19 | 20 | 21 |

Сейчас мы находимся в директории `repositories`.

22 | 23 | 24 | ```git 25 | ==include[output/30-01.txt] 26 | ``` 27 | 28 | 29 | В этот момент вы должны находиться в директории `repositories`. Здесь должен быть единственный репозиторий под названием `work`. 30 | 31 | ## _02_ Создайте клон репозитория `work` 32 | 33 | Давайте создадим клон репозитория. 34 | 35 | 36 | ``` 37 | git clone work home 38 | ls 39 | ``` 40 | 41 | 42 | 43 | ```git 44 | ==include[output/30-02.txt] 45 | ``` 46 | 47 | 48 | В вашем списке репозиториев теперь должно быть два репозитория: оригинальный репозиторий `work` и клонированный репозиторий `home`. -------------------------------------------------------------------------------- /pages/uk/checking_status.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "3. Перевірка стану" 3 | --- 4 | 5 | ### Цілі 6 | 7 | - Навчитися перевіряти стан репозиторія. 8 | 9 | ## _01_ Перевірте стан репозиторія 10 | 11 | Використовуйте команду `git status`, щоб дізнатися поточний стан репозиторія. 12 | 13 | 14 | ``` 15 | git status 16 | ``` 17 | 18 | 19 | Ви побачите: 20 | 21 | 22 | ```git 23 | ==include[output/03-01.txt] 24 | ``` 25 | 26 | 27 | > Якщо після виконання попередньої команди ви побачили `On branch master` замість `On branch main`, це означає, що у вас трохи старіша версія Git, яка не зрозуміла нас, коли ми попросили встановити назву гілок за замовчуванням на `main`. У цьому випадку ви можете перейменувати гілку на `main` за допомогою наступної команди: 28 | > ``` 29 | > git branch -m master main 30 | > ``` 31 | 32 | Команда перевірки стану повідомила, що комітити нема чого. Це означає, що у репозиторії вже зберігається поточний стан робочих файлів, та нема жодних змін, які б могли очікувати на запис. 33 | 34 | Ми будемо використовувати команду `git status`, щоб продовжувати відстежувати стан репозиторія та робочої директорії. -------------------------------------------------------------------------------- /pages/uk/pushing_a_change.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "40. Відправка змін" 3 | --- 4 | 5 | - Дізнатися, як передавати зміни у віддалений репозиторій. 6 | 7 | Оскільки чисті репозиторії зазвичай розташовуються на якомусь віддаленому сервері, ви не зможете туди просто зайти, щоб підтягнути зміни. Тому нам необхідно якось передати наші зміни в репозиторій. 8 | 9 | Почнемо зі створення зміни, яку потрібно передати в репозиторій. Відредагуйте `README` і зробіть коміт змін: 10 | 11 | 12 | ``` 13 | This is the Hello World example from the Git tutorial. 14 | (changed in the origin and pushed to shared) 15 | ``` 16 | 17 | 18 | 19 | ``` 20 | git switch main 21 | git add README 22 | git commit -m "Added shared comment to readme" 23 | ``` 24 | 25 | 26 | Тепер надішліть зміни до спільного репозиторія. 27 | 28 | 29 | ``` 30 | git push shared main 31 | ``` 32 | 33 | 34 | _Спільним_ називається репозиторій, що одержує відправлені нами зміни. Пам'ятаєте, ми додали його в якості віддаленого репозиторія в попередньому уроці? 35 | 36 | 37 | ```git 38 | ==include[output/40-01.txt] 39 | ``` 40 | 41 | -------------------------------------------------------------------------------- /pages/en/cloning_repositories.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "30. Cloning repositories" 3 | --- 4 | 5 | ### Goals 6 | 7 | - Learn how to make copies of the repositories. 8 | 9 | If you are working in a team, the following 8 lessons are quite important to understand because you almost always have to work with cloned repositories. 10 | 11 | ## _01_ Go to your `repositories` directory 12 | 13 | 14 | ``` 15 | cd .. 16 | pwd 17 | ls 18 | ``` 19 | 20 | 21 |

Now we are in the `repositories` directory.

22 | 23 | 24 | ```git 25 | ==include[output/30-01.txt] 26 | ``` 27 | 28 | 29 | At this point you should be in your `repositories` directory. It should contain a single repository named `work`. 30 | 31 | ## _02_ Create a clone of the `work` repository 32 | 33 | Let's create a clone of the repository. 34 | 35 | 36 | ``` 37 | git clone work home 38 | ls 39 | ``` 40 | 41 | 42 | 43 | ```git 44 | ==include[output/30-02.txt] 45 | ``` 46 | 47 | 48 | Right now there should now be two repos in your working directory: the original `work` repo and the cloned repository named `home`. 49 | -------------------------------------------------------------------------------- /pages/ru/review_the_cloned_repository.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "31. Просмотр клонированного репозитория" 3 | --- 4 | 5 | ### Цели 6 | 7 | - Узнать о ветках в удаленных репозиториях. 8 | 9 | ## _01_ Посмотрите на клонированный репозиторий 10 | 11 | Давайте взглянем на клонированный репозиторий. 12 | 13 | 14 | ``` 15 | cd home 16 | ls 17 | ``` 18 | 19 | 20 | 21 | ```git 22 | ==include[output/31-01.txt] 23 | ``` 24 | 25 | 26 | Вы увидите список всех файлов на верхнем уровне оригинального репозитория `README`, `index.html` и `css`). 27 | 28 | ## _02_ Просмотрите историю репозитория 29 | 30 | 31 | ``` 32 | git log --all 33 | ``` 34 | 35 | 36 | 37 | ```git 38 | ==include[output/31-02.txt] 39 | ``` 40 | 41 | 42 | Вы увидите список всех коммитов в новый репозиторий, и он должен совпадать с историей коммитов в оригинальном репозитории. Единственная разница должна быть в названиях веток. 43 | 44 | ## _03_ Удаленные ветки 45 | 46 | Вы увидите ветку `main` (`HEAD`) в списке истории. Вы также увидите ветки со странными именами (`origin/main`, `origin/style` и `origin/HEAD`). Мы поговорим о них чуть позже. -------------------------------------------------------------------------------- /pages/uk/review_the_cloned_repository.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "31. Перегляд клонованого репозиторія" 3 | --- 4 | 5 | ### Цілі 6 | 7 | - Дізнатися про гілки у віддалених репозиторіях. 8 | 9 | ## _01_ Подивіться на клонований репозиторій 10 | 11 | Давайте поглянемо на клонований репозиторій. 12 | 13 | 14 | ``` 15 | cd home 16 | ls 17 | ``` 18 | 19 | 20 | 21 | ```git 22 | ==include[output/31-01.txt] 23 | ``` 24 | 25 | 26 | Ви побачите список всіх файлів на верхньому рівні оригінального репозиторія (`README`, `index.html` і `css`). 27 | 28 | ## _02_ Перегляньте історію репозиторія 29 | 30 | 31 | ``` 32 | git log --all 33 | ``` 34 | 35 | 36 | 37 | ```git 38 | ==include[output/31-02.txt] 39 | ``` 40 | 41 | 42 | Ви побачите список всіх комітів у новий репозиторій, і він повинен збігатися з історією комітів в оригінальному репозиторії. Єдина різниця повинна бути в назвах гілок. 43 | 44 | ## _03_ Віддалені гілки 45 | 46 | Ви побачите гілку `main` (`HEAD`) в списку історії. Ви також побачите гілки з дивними іменами (`origin/main`, `origin/style` і `origin/HEAD`). Ми поговоримо про них трохи пізніше. -------------------------------------------------------------------------------- /pages/en/navigating_branches.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "19. Switching branches" 3 | --- 4 | 5 | ### Goals 6 | 7 | - Learn how to switch between the repository branches. 8 | 9 | Now our project has two branches: 10 | 11 | 12 | ``` 13 | git log --all 14 | ``` 15 | 16 | 17 | 18 | ```git 19 | ==include[output/19-01.txt] 20 | ``` 21 | 22 | 23 | ## _01_ Switching to the `main` branch 24 | 25 | To switch between branches, use the `git switch` command. 26 | 27 | 28 | ``` 29 | git switch main 30 | cat hello.html 31 | ``` 32 | 33 | 34 | 35 | ```git 36 | ==include[output/19-02.txt] 37 | ``` 38 | 39 | 40 | Now we are on the `main` branch. As you see, the `hello.html` has no traces of `style.css`. Don't worry; it is still in the repository, but we can't see it from the `main` branch. 41 | 42 | ## _02_ Let us return to the `style` branch 43 | 44 | 45 | ``` 46 | git switch style 47 | cat hello.html 48 | ``` 49 | 50 | 51 | 52 | ```git 53 | ==include[output/19-03.txt] 54 | ``` 55 | 56 | 57 | We are back to the `style` branch. As you can see, our CSS-related changes are present. 58 | -------------------------------------------------------------------------------- /pages/ru/checking_status.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "3. Проверка состояния" 3 | --- 4 | 5 | ### Цели 6 | 7 | - Научиться проверять состояние репозитория. 8 | 9 | ## _01_ Проверьте состояние репозитория 10 | 11 | Используйте команду `git status`, чтобы проверить текущее состояние репозитория. 12 | 13 | 14 | ``` 15 | git status 16 | ``` 17 | 18 | 19 | Вы увидите: 20 | 21 | 22 | ```git 23 | ==include[output/03-01.txt] 24 | ``` 25 | 26 | 27 | > Если после выполнения предыдущей команды вы видите `On branch master` вместо `On branch main`, это означает, что у вас немного устаревшая версия Git'а, которая не поняла нас, когда мы попросили установить имя ветки по умолчанию на `main`. В этом случае вы можете переименовать ветку в `main` с помощью следующей команды: 28 | > ``` 29 | > git branch -m master main 30 | > ``` 31 | 32 | Команда проверки состояния сообщила, что коммитить нечего. Это означает, что в репозитории уже хранится текущее состояние рабочих файлов, и нет никаких изменений, которые могли бы ожидать записи. 33 | 34 | Мы будем использовать команду `git status`, чтобы продолжать отслеживать состояние репозитория и рабочей директории. -------------------------------------------------------------------------------- /pages/en/checking_status.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "3. Checking the status of the repository" 3 | --- 4 | 5 | ### Goals 6 | 7 | - Learn how to check the repository’s status. 8 | 9 | ## _01_ Check the status of the repository 10 | 11 | Use the `git status` command, to check the current state of the repository. 12 | 13 | 14 | ``` 15 | git status 16 | ``` 17 | 18 | 19 | You will see: 20 | 21 | 22 | ```git 23 | ==include[output/03-01.txt] 24 | ``` 25 | 26 | 27 | > If you see `On branch master` instead of `On branch main` after running the previous command, it means that you have a slightly older version of Git, which didn't understand us when we asked to set the default branch name to `main`. In this case, you can rename the branch name to `main` with the following command: 28 | > ``` 29 | > git branch -m master main 30 | > ``` 31 | 32 | The command checks the status and reports that there’s nothing to commit, meaning the repository stores the current state of the working directory, and there are no changes to record. 33 | 34 | We will use the `git status` command to keep monitoring the states of both the working directory and the repository. 35 | -------------------------------------------------------------------------------- /pages/en/more_setup.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "1. Git credentials" 3 | --- 4 | 5 | ### Goals 6 | 7 | - To be fully prepared to work with Git. 8 | 9 | ## _01_ Setting up name and email address 10 | 11 | If you've never used Git before, the first step is to set up your name and email address. Run the following commands to let Git know your name and email. If Git is already installed, you can skip this step. 12 | 13 | 14 | git config --global user.name "Your Name" 15 | git config --global user.email "your_email@whatever.com" 16 | 17 | 18 | 19 | ## _02_ Default branch name 20 | 21 | We will use `main` as the default branch name. To set this up, run the following command: 22 | 23 | 24 | ``` 25 | git config --global init.defaultBranch main 26 | ``` 27 | 28 | 29 | 30 | ## _03_ Line endings treatment 31 | 32 | Also, for users of Unix/Mac: 33 | 34 | 35 | ``` 36 | git config --global core.autocrlf input 37 | git config --global core.safecrlf warn 38 | ``` 39 | 40 | 41 | For Windows users: 42 | 43 | 44 | ``` 45 | git config --global core.autocrlf true 46 | git config --global core.safecrlf warn 47 | ``` 48 | 49 | -------------------------------------------------------------------------------- /pages/pt-BR/review_the_cloned_repository.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "31. Examine o repositório clonado" 3 | --- 4 | 5 | ### Metas 6 | 7 | - Descobrir sobre branches em repositórios remotos. 8 | 9 | ## _01_ Visualizando o repositório clonado 10 | 11 | Vamos dar uma olhada no nosso repositório clonado. 12 | 13 | 14 | ``` 15 | cd home 16 | ls 17 | ``` 18 | 19 | 20 | 21 | ```git 22 | ==include[output/31-01.txt] 23 | ``` 24 | 25 | 26 | Você verá uma lista de todos os arquivos no nível acima ao do repositório original (`README`, `index.html` e `css`). 27 | 28 | ## _02_ Visualizando o histórico do repositório 29 | 30 | 31 | ``` 32 | git log --all 33 | ``` 34 | 35 | 36 | 37 | ```git 38 | ==include[output/31-02.txt] 39 | ``` 40 | 41 | 42 | Você verá uma lista de todos os commits no novo repositório, que deveriam ser iguais aos do repositório original. A única diferença deveria ser o nome dos branches. 43 | 44 | ## _03_ Branches remotos 45 | 46 | Você verá um branch `main` (`HEAD`) no histórico. Você também verá branches com nomes estranhos (`origin/main`, `origin/style` e `origin/HEAD`). Nós falaremos deles depois. 47 | -------------------------------------------------------------------------------- /pages/ru/navigating_branches.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "19. Переключение веток" 3 | --- 4 | 5 | ### Цели 6 | 7 | - Научиться перемещаться между ветками репозитория. 8 | 9 | Теперь в вашем проекте есть две ветки: 10 | 11 | 12 | ``` 13 | git log --all 14 | ``` 15 | 16 | 17 | 18 | ```git 19 | ==include[output/19-01.txt] 20 | ``` 21 | 22 | 23 | ## _01_ Переключение на ветку `main` 24 | 25 | Просто используйте команду `git switch` для переключения между ветками. 26 | 27 | 28 | ``` 29 | git switch main 30 | cat hello.html 31 | ``` 32 | 33 | 34 | 35 | ```git 36 | ==include[output/19-02.txt] 37 | ``` 38 | 39 | 40 | Теперь мы находимся в ветке `main`. Как видите, в `hello.html` нет никаких следов `style.css`. Не волнуйтесь, эти изменения все еще есть в репозитории, но мы не можем увидеть их из ветки `main`. 41 | 42 | ## _02_ Вернемся к ветке `style` 43 | 44 | 45 | ``` 46 | git switch style 47 | cat hello.html 48 | ``` 49 | 50 | 51 | 52 | ```git 53 | ==include[output/19-03.txt] 54 | ``` 55 | 56 | 57 | Мы вернулись к ветке `style`. Как видите, наши изменения, связанные с CSS, присутствуют. -------------------------------------------------------------------------------- /pages/uk/navigating_branches.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "19. Перемикання гілок" 3 | --- 4 | 5 | ### Цілі 6 | 7 | - Навчитися переміщуватися між гілками репозиторія. 8 | 9 | Тепер у вашому проєкті є дві гілки: 10 | 11 | 12 | ``` 13 | git log --all 14 | ``` 15 | 16 | 17 | 18 | ```git 19 | ==include[output/19-01.txt] 20 | ``` 21 | 22 | 23 | ## _01_ Перемикання на гілку `main` 24 | 25 | Просто використовуйте команду `git switch` для перемикання між гілками. 26 | 27 | 28 | ``` 29 | git switch main 30 | cat hello.html 31 | ``` 32 | 33 | 34 | 35 | ```git 36 | ==include[output/19-02.txt] 37 | ``` 38 | 39 | 40 | Тепер ми знаходимося у гілці `main`. Як бачите, у файлі `hello.html` немає жодних слідів `style.css`. Не хвилюйтеся, ці зміни все ще знаходяться у репозиторії, просто ми не бачимо їх з гілки `main`. 41 | 42 | ## _02_ Повернемося до гілки `style` 43 | 44 | 45 | ``` 46 | git switch style 47 | cat hello.html 48 | ``` 49 | 50 | 51 | 52 | ```git 53 | ==include[output/19-03.txt] 54 | ``` 55 | 56 | 57 | Ми повернулися до гілки `style`. Як ви можете бачити, наші зміни, пов'язані з CSS, присутні. -------------------------------------------------------------------------------- /pages/en/bare_repositories.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "38. Bare repos" 3 | --- 4 | 5 | ### Goals 6 | 7 | - Learn to create bare repos. 8 | 9 | A bare repository is a repository that doesn't have a working directory. It only contains the `.git` directory, the directory in which Git stores all its internal data. The main purpose of these repositories is to be a central repository that developers can push to and pull from, so there's no need in having a working directory. Bare repositories are also used in Git hosting services like GitHub and GitLab. In the next several lessons we will learn how to create a bare repository and how to push to it. 10 | 11 | ## _01_ Creating a bare repository. 12 | 13 | 14 | ``` 15 | cd .. 16 | git clone --bare work work.git 17 | ls work.git 18 | ``` 19 | 20 | 21 |

Now we are in the `repositories` directory.

22 | 23 | 24 | ```git 25 | ==include[output/38-01.txt] 26 | ``` 27 | 28 | 29 | The convention is that repositories ending in `.git` are bare repositories. We can see that there is no working directory in the `work.git` repo. Essentially it is nothing but the `.git` directory of a regular repo. 30 | -------------------------------------------------------------------------------- /pages/pt-BR/pushing_a_change.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "40. Submetendo modificações" 3 | --- 4 | 5 | ### Metas 6 | 7 | - Aprender a enviar alterações para o repositório remoto. 8 | 9 | Como os repositórios bare geralmente são compartilhados em algum tipo de servidor de rede, geralmente é difícil entrar no repositório e fazer alterações. Portanto, precisamos enviar nossas alterações para outros repositórios. 10 | 11 | Vamos começar criando uma alteração a ser enviada. Edite o `README` e faça o commit: 12 | 13 | 14 | ``` 15 | This is the Hello World example from the Git tutorial. 16 | (changed in the origin and pushed to shared) 17 | ``` 18 | 19 | 20 | 21 | ``` 22 | git switch main 23 | git add README 24 | git commit -m "Added shared comment to readme" 25 | ``` 26 | 27 | 28 | Agora envie as modificações para o repositório compartilhado. 29 | 30 | 31 | ``` 32 | git push shared main 33 | ``` 34 | 35 | _O repositório comum_ está recebendo nossas modificações enviadas. (Lembre-se, nós adicionamos ele como um repositório remoto na lição anterior). 36 | 37 | 38 | ```git 39 | ==include[output/40-01.txt] 40 | ``` 41 | 42 | -------------------------------------------------------------------------------- /pages/uk/merging_pulled_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "36. Злиття підтягнутих змін" 3 | --- 4 | 5 | ### Цілі 6 | 7 | - Навчитися зливати підтягнуті зміни в поточну гілку. 8 | 9 | ## _01_ Злийте підтягнуті зміни в локальну гілку `main` 10 | 11 | 12 | ``` 13 | git merge origin/main 14 | ``` 15 | 16 | 17 | 18 | ```git 19 | ==include[output/36-01.txt] 20 | ``` 21 | 22 | 23 | ## _02_ Ще раз перевірте файл `README` 24 | 25 | Зараз ми повинні побачити зміни. 26 | 27 | 28 | ``` 29 | cat README 30 | ``` 31 | 32 | 33 | 34 | ```git 35 | ==include[output/36-02.txt] 36 | ``` 37 | 38 | 39 | Ось і зміни. Хоча команда `git fetch` не зливає зміни, ми можемо вручну злити зміни з віддаленого репозиторія. 40 | 41 | ## _03_ Команда `pull` (підтягнути) 42 | 43 | Команда `fetch` дає вам повний контроль над тим, що саме підтягується та зливається в локальні гілки, але для зручності існує також команда `pull`, яка підтягує та зливає зміни з віддаленої гілки у вашу поточну гілку одним викликом. 44 | 45 | ``` 46 | git pull 47 | ``` 48 | 49 | ...еквівалентна наступним двом діям: 50 | 51 | ``` 52 | git fetch 53 | git merge origin/main 54 | ``` -------------------------------------------------------------------------------- /pages/ru/pushing_a_change.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "40. Отправка изменений" 3 | --- 4 | 5 | ### Цели 6 | 7 | - Узнать, как передавать изменения в удаленный репозиторий. 8 | 9 | Поскольку чистые репозитории обычно располагаются на каком-либо удаленном сервере, вы не сможете туда просто зайти, дабы подтянуть изменения. Поэтому нам необходимо как-нибудь передать наши изменения в репозиторий. 10 | 11 | Начнем с создания изменения, которое нужно передать в репозиторий. Отредактируйте `README` и закоммитьте его: 12 | 13 | 14 | ``` 15 | This is the Hello World example from the Git tutorial. 16 | (changed in the origin and pushed to shared) 17 | ``` 18 | 19 | 20 | 21 | ``` 22 | git switch main 23 | git add README 24 | git commit -m "Added shared comment to readme" 25 | ``` 26 | 27 | 28 | Теперь отправьте изменения в общий репозиторий. 29 | 30 | 31 | ``` 32 | git push shared main 33 | ``` 34 | 35 | 36 | _Общим_ называется репозиторий, получающий отправленные нами изменения. Помните, мы добавили его в качестве удаленного репозитория в предыдущем уроке? 37 | 38 | 39 | ```git 40 | ==include[output/40-01.txt] 41 | ``` 42 | 43 | -------------------------------------------------------------------------------- /pages/en/review_the_cloned_repository.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "31. Examine the cloned repository" 3 | --- 4 | 5 | ### Goals 6 | 7 | - To find out about branches in the remote repositories. 8 | 9 | ## _01_ Viewing the cloned repository 10 | 11 | Let's have a look at our cloned repository. 12 | 13 | 14 | ``` 15 | cd home 16 | ls 17 | ``` 18 | 19 | 20 | 21 | ```git 22 | ==include[output/31-01.txt] 23 | ``` 24 | 25 | 26 | You will see a list of all files in the top level of the original repository (`README`, `index.html` and `css`). 27 | 28 | ## _02_ View the history of the cloned repository 29 | 30 | 31 | ``` 32 | git log --all 33 | ``` 34 | 35 | 36 | 37 | ```git 38 | ==include[output/31-02.txt] 39 | ``` 40 | 41 | 42 | You will see a list of all the commits in the new repository, and it should match the commit history of the original repository. The only difference should be in the names of the branches. 43 | 44 | ## _03_ Remote branches 45 | 46 | You will see a `main` branch (`HEAD`) in the history. You will also find branches with strange names (`origin/main`, `origin/style` and `origin/HEAD`). We'll discuss them a bit later. 47 | -------------------------------------------------------------------------------- /pages/uk/staging_and_committing.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "6. Індексація та коміт" 3 | --- 4 | 5 | Окремий крок індексації в Git дозволяє вам розділяти великі зміни на малі коміти. Аналогія: ви помили машину і заодно залили рідину для очищення скла — ці дві зміни по своїй суті незалежні, а тому краще закомітити їх окремо. В іншому разі, в історії змін бачка для рідини очищення скла буде запис "Помив машину", що не відповідає суті зміни та може заплутати того, хто потім буде розбиратись в цій історії. 6 | 7 | Припустимо, що ви відредагували три файли (`a.html`, `b.html`, `c.html`). Тепер ви хочете закомітити всі зміни, але так, щоб зміни у `a.html` та `b.html` йшли одним комітом, в той час, коли зміни у `c.html` логічно не пов'язані з першими двома файлами й повинні йти окремим комітом. 8 | 9 | Теоретично, ви можете зробити наступне: 10 | 11 | 12 | ``` 13 | git add a.html 14 | git add b.html 15 | git commit -m "Changes for a and b" 16 | ``` 17 | 18 | 19 | 20 | ``` 21 | git add c.html 22 | git commit -m "Unrelated change to c" 23 | ``` 24 | 25 | 26 | Поділяючи індексацію і коміт, ви маєте можливість з легкістю налаштувати, що піде в який коміт. 27 | -------------------------------------------------------------------------------- /pages/en/merging_pulled_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "36. Merging pulled changes" 3 | --- 4 | 5 | ### Goals 6 | 7 | - Learn to get the fetched changes into the current branch and working directory. 8 | 9 | ## _01_ Merge the pulled changes into the local `main` branch 10 | 11 | 12 | ``` 13 | git merge origin/main 14 | ``` 15 | 16 | 17 | 18 | ```git 19 | ==include[output/36-01.txt] 20 | ``` 21 | 22 | 23 | ## _02_ Check the `README` again 24 | 25 | Now we should see the changes. 26 | 27 | 28 | ``` 29 | cat README 30 | ``` 31 | 32 | 33 | 34 | ```git 35 | ==include[output/36-02.txt] 36 | ``` 37 | 38 | 39 | These are the changes. Although `git fetch` does not merge the changes, we can manually merge them from the remote repo. 40 | 41 | ## _03_ The `pull` command 42 | 43 | The `fetch` command gives you precise control over what is pulled and merged, but for convenience, there is also a command `pull` which fetches and merges changes from the remote branch into your current branch with one call. 44 | 45 | ``` 46 | git pull 47 | ``` 48 | 49 | ...is equivalent to the following two steps: 50 | 51 | ``` 52 | git fetch 53 | git merge origin/main 54 | ``` -------------------------------------------------------------------------------- /pages/pt-BR/checking_status.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "3. Conferindo o status do repositório" 3 | --- 4 | 5 | ### Metas 6 | 7 | - Aprender como conferir o status do repositório. 8 | 9 | ## _01_ Confira o status do repositório 10 | 11 | Use o comando `git status` para checar o estado atual do repositório. 12 | 13 | 14 | ``` 15 | git status 16 | ``` 17 | 18 | 19 | Você verá: 20 | 21 | 22 | ```git 23 | ==include[output/03-01.txt] 24 | ``` 25 | 26 | 27 | > Se, depois de executar o comando anterior, você vir `On branch master` em vez de `On branch main`, isso significa que você tem uma versão ligeiramente desatualizada do Git que não nos entendeu quando pedimos para definir o nome padrão do branch como `main`. Nesse caso, você pode renomear a ramificação para `main` usando o seguinte comando: 28 | > ``` 29 | > git branch -m master main 30 | > ``` 31 | 32 | O comando confere o status e reporta que não existe nada para fazer um commit, o que quer dizer que o repositório está com o atual estado do diretório de trabalho e não existem modificações a serem gravadas. 33 | 34 | Nós usaremos o Git status para continuar monitorando os estados de ambos o diretório de trabalho e o repositório. 35 | -------------------------------------------------------------------------------- /pages/pt-BR/navigating_branches.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "19. Mudança de Branches" 3 | --- 4 | 5 | ### Metas 6 | 7 | - Aprender como navegar entre branches de repositórios. 8 | 9 | Agora o seu projeto possui dois branches: 10 | 11 | 12 | ``` 13 | git log --all 14 | ``` 15 | 16 | 17 | 18 | ```git 19 | ==include[output/19-01.txt] 20 | ``` 21 | 22 | 23 | ## _01_ Trocando para o branch `main` 24 | 25 | Para trocar o branch atual simplesmente use o comando `git switch`. 26 | 27 | 28 | ``` 29 | git switch main 30 | cat hello.html 31 | ``` 32 | 33 | 34 | 35 | ```git 36 | ==include[output/19-02.txt] 37 | ``` 38 | 39 | 40 | Agora estamos no ramo `main`. Como você pode ver, o `hello.html` não tem vestígios do `style.css`. Não se preocupe; ele ainda está no repositório, mas não podemos vê-lo na ramificação `main`. 41 | 42 | ## _02_ Vamos retornar para o branch do `style` 43 | 44 | 45 | ``` 46 | git switch style 47 | cat hello.html 48 | ``` 49 | 50 | 51 | 52 | ```git 53 | ==include[output/19-03.txt] 54 | ``` 55 | 56 | 57 | Estamos de volta ao ramo `style`. Como você pode ver, nossas alterações relacionadas ao CSS estão presentes. 58 | -------------------------------------------------------------------------------- /pages/ru/merging_pulled_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "36. Слияние подтянутых изменений" 3 | --- 4 | 5 | ### Цели 6 | 7 | - Научиться сливать подтянутые изменения в текущую ветку. 8 | 9 | ## _01_ Слейте подтянутые изменения в локальную ветку `main` 10 | 11 | 12 | ``` 13 | git merge origin/main 14 | ``` 15 | 16 | 17 | 18 | ```git 19 | ==include[output/36-01.txt] 20 | ``` 21 | 22 | 23 | ## _02_ Еще раз проверьте файл `README` 24 | 25 | Сейчас мы должны увидеть изменения. 26 | 27 | 28 | ``` 29 | cat README 30 | ``` 31 | 32 | 33 | 34 | ```git 35 | ==include[output/36-02.txt] 36 | ``` 37 | 38 | 39 | Вот и изменения. Хотя команда `git fetch` не сливает изменения, мы можем вручную слить изменения из удаленного репозитория. 40 | 41 | ## _03_ Команда `pull` (подтянуть) 42 | 43 | Команда `fetch` позволяет контролировать то, что именно подтягивается и сливается в ваши локальные ветки, но для удобства существует также команда `pull`, которая подтягивает и сливает изменения из удаленной ветки в текущую одним вызовом. 44 | 45 | ``` 46 | git pull 47 | ``` 48 | 49 | ...эквивалентна следующим двум шагам: 50 | 51 | ``` 52 | git fetch 53 | git merge origin/main 54 | ``` -------------------------------------------------------------------------------- /pages/uk/changes_in_master.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "21. Зміни в гілці main" 3 | --- 4 | 5 | ### Цілі 6 | 7 | - Навчитися працювати з декількома гілками з різними (і, можливо, конфліктуючими) змінами. 8 | 9 | Як я вже згадував раніше, Git дозволяє працювати з декількома гілками одночасно. Це дуже корисно при роботі в команді, оскільки люди можуть працювати над різними функціями паралельно. Це також корисно, коли ви працюєте наодинці: розробляючи функції в окремих гілках, ви все одно можете виправляти помилки і випускати незначні оновлення, використовуючи стабільний код в гілці `main`. 10 | 11 | ## _01_ Створіть файл `README` 12 | 13 | Створимо файл `README`. Він буде пояснювати, про що наш проєкт. 14 | 15 | 16 | ``` 17 | This is the Hello World example from the GitHowTo tutorial. 18 | ``` 19 | 20 | 21 | ## _02_ Закомітьте файл `README` у гілку `main` 22 | 23 | Наразі ми перебуваємо у гілці `style`. Файл `README` не є частиною цієї гілки, тому перед комітом слід перейти до гілки `main`. 24 | 25 | 26 | ``` 27 | git switch main 28 | git add README 29 | git commit -m "Added README" 30 | ``` 31 | 32 | 33 | 34 | ```git 35 | ==include[output/21-01.txt] 36 | ``` 37 | -------------------------------------------------------------------------------- /pages/pt-BR/merging_pulled_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "36. Fundindo modificações baixadas" 3 | --- 4 | 5 | ### Metas 6 | 7 | - Aprender como colocar as modificações baixadas no branch atual e no diretório de trabalho. 8 | 9 | ## _01_ Funda as modificações baixadas no branch `main` local 10 | 11 | 12 | ``` 13 | git merge origin/main 14 | ``` 15 | 16 | 17 | 18 | ```git 19 | ==include[output/36-01.txt] 20 | ``` 21 | 22 | 23 | ## _02_ Confira o `README` novamente 24 | 25 | Agora você deve ver as modificações. 26 | 27 | 28 | ``` 29 | cat README 30 | ``` 31 | 32 | 33 | 34 | ```git 35 | ==include[output/36-02.txt] 36 | ``` 37 | 38 | 39 | Essas são as modificações. Apesar do comando `git fetch` não fundir as mudanças, nós podemos fundi-las manualmente pelo repositório remoto. 40 | 41 | ## _03_ O comando `pull 42 | 43 | O comando `fetch` oferece controle preciso sobre o que é extraído e mesclado, mas, por conveniência, há também um comando `pull` que extrai e mescla as alterações do ramo remoto no ramo atual com uma única chamada. 44 | 45 | ``` 46 | git pull 47 | ``` 48 | 49 | ...é equivalente às duas etapas a seguir: 50 | 51 | ``` 52 | git fetch 53 | git merge origin/main 54 | ``` -------------------------------------------------------------------------------- /pages/uk/bare_repositories.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "38. Чисті репозиторії" 3 | --- 4 | 5 | ### Цілі 6 | 7 | - Навчитися створювати чисті репозиторії. 8 | 9 | Чистий репозиторій — це репозиторій, що не має робочих файлів. Він містить лише директорію `.git`, в якій Git зберігає всі свої внутрішні дані. Основне призначення таких репозиторіїв — бути центральним репозиторієм, з якого розробники можуть підтягувати та куди надсилати зміни. Тому в них немає сенсу створювати робочі файли, вони будуть тільки даремно займати місце на диску. Чисті репозиторії також використовуються на Git-хостингах, таких як GitHub і GitLab. У наступних кількох уроках ми дізнаємося, як створити чистий репозиторій і як працювати з ним. 10 | 11 | ## _01_ Створіть чистий репозиторій 12 | 13 | 14 | ``` 15 | cd .. 16 | git clone --bare work work.git 17 | ls work.git 18 | ``` 19 | 20 | 21 |

Зараз ми знаходимося в директорії `repositories`.

22 | 23 | 24 | ```git 25 | ==include[output/38-01.txt] 26 | ``` 27 | 28 | 29 | Зазвичай вважається, що репозиторії, які закінчуються на `.git`, є чистими репозиторіями. Ми бачимо, що у репозиторії `work.git` немає робочих файлів. По суті, це просто директорія `.git` зі звичайного репозиторія. -------------------------------------------------------------------------------- /pages/en/changes_in_master.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "21. Changes in the main branch" 3 | --- 4 | 5 | ### Goals 6 | 7 | - Learn how to work with several branches with different (sometimes conflicting) changes. 8 | 9 | As I mentioned previously, Git lets you work with several branches at the same time. It is very useful when working in a team because people can work on different features in parallel. It is also useful when working solo: while developing features in separate branches, you can still fix bugs and release minor updates using stable code in the `main` branch. 10 | 11 | ## _01_ Create the `README` file 12 | 13 | Let's create a `README` file. It will explain what our project is about. 14 | 15 | 16 | ``` 17 | This is the Hello World example from the GitHowTo tutorial. 18 | ``` 19 | 20 | 21 | ## _02_ Commit the `README` file to the `main` branch 22 | 23 | We are currently in the `style` branch. The `README` file is not part of this branch, so we must switch to the `main` branch before committing the changes. 24 | 25 | 26 | ``` 27 | git switch main 28 | git add README 29 | git commit -m "Added README" 30 | ``` 31 | 32 | 33 | 34 | ```git 35 | ==include[output/21-01.txt] 36 | ``` 37 | 38 | -------------------------------------------------------------------------------- /pages/en/create_a_project.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "2. Creating a project" 3 | --- 4 | 5 | ### Goals 6 | 7 | - Learn how to create a Git repository from scratch. 8 | 9 | ## _01_ Create a “Hello, World!” page 10 | 11 | Get started in an empty directory (for example, `repositories`, if you downloaded the file from the previous step) and add an empty subdirectory named `work`, then create a `hello.html` file in it with the following contents. 12 | 13 | 14 | ``` 15 | mkdir work 16 | cd work 17 | touch hello.html 18 | ``` 19 | 20 | 21 | 22 | ```html 23 | Hello, World! 24 | ``` 25 | 26 | 27 | ## _02_ Create a repository 28 | 29 | So you have a directory that contains one file. Run `git init` in order to create a Git repo from that directory. 30 | 31 | 32 | ``` 33 | git init 34 | ``` 35 | 36 | 37 | 38 | ```git 39 | ==include[output/02-01.txt] 40 | ``` 41 | 42 | 43 | ## _03_ Add the page to the repository 44 | 45 | Now let's add the “Hello, World” page to the repository. 46 | 47 | 48 | ``` 49 | git add hello.html 50 | git commit -m "Initial Commit" 51 | ``` 52 | 53 | 54 | You will see: 55 | 56 | 57 | ```git 58 | ==include[output/02-02.txt] 59 | ``` 60 | 61 | -------------------------------------------------------------------------------- /pages/ru/changes_in_master.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "21. Изменения в ветке main" 3 | --- 4 | 5 | ### Цели 6 | 7 | - Научиться работать с несколькими ветками с различными (и, возможно, конфликтующими) изменениями. 8 | 9 | Как я уже говорил, Git позволяет работать с несколькими ветками одновременно. Это очень удобно при работе в команде, поскольку люди могут параллельно работать над разными функциями. Это также полезно при работе в одиночку: разрабатывая функции в отдельных ветках, вы можете исправлять ошибки и выпускать небольшие обновления, используя стабильный код в ветке `main`. 10 | 11 | ## _01_ Создайте файл `README` 12 | 13 | Создадим файл `README`. В нем будет рассказано о сути нашего проекта. 14 | 15 | 16 | ``` 17 | This is the Hello World example from the GitHowTo tutorial. 18 | ``` 19 | 20 | 21 | ## _02_ Сделайте коммит файла `README` в ветку `main` 22 | 23 | В настоящее время мы находимся в ветке `style`. Файл `README` не является частью этой ветки, поэтому перед коммитом мы должны переключиться на ветку `main`. 24 | 25 | 26 | ``` 27 | git switch main 28 | git add README 29 | git commit -m "Added README" 30 | ``` 31 | 32 | 33 | 34 | ```git 35 | ==include[output/21-01.txt] 36 | ``` 37 | -------------------------------------------------------------------------------- /pages/ru/create_a_project.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "2. Создание проекта" 3 | --- 4 | 5 | ### Цели 6 | 7 | - Научиться создавать Git-репозиторий с нуля. 8 | 9 | ## _01_ Создайте страницу «Hello, World» 10 | 11 | Начните работу в пустой директории (например, `respositories`, если вы скачали архив с предыдущего шага) с создания пустой поддиректории `work`, затем войдите в неё и создайте там файл `hello.html` с таким содержанием: 12 | 13 | 14 | ``` 15 | mkdir work 16 | cd work 17 | touch hello.html 18 | ``` 19 | 20 | 21 | 22 | ```html 23 | Hello, World 24 | ``` 25 | 26 | 27 | ## _02_ Создайте репозиторий 28 | 29 | Теперь у вас есть директория с одним файлом. Чтобы создать Git-репозиторий из этой директории, выполните команду `git init`. 30 | 31 | 32 | ``` 33 | git init 34 | ``` 35 | 36 | 37 | 38 | ```git 39 | ==include[output/02-01.txt] 40 | ``` 41 | 42 | 43 | ## _03_ Добавьте страницу в репозиторий 44 | 45 | Теперь давайте добавим в репозиторий страницу «Hello, World». 46 | 47 | 48 | ``` 49 | git add hello.html 50 | git commit -m "Initial Commit" 51 | ``` 52 | 53 | 54 | Вы увидите... 55 | 56 | 57 | ```git 58 | ==include[output/02-02.txt] 59 | ``` 60 | 61 | -------------------------------------------------------------------------------- /pages/ru/staging_and_committing.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "6. Индексация и коммит" 3 | --- 4 | 5 | Отдельный шаг индексации в Git позволяет вам разделять большие изменения на маленькие коммиты. Аналогия: вы помыли машину и заодно залили жидкость для очистки стекла — эти два изменения по своей сути независимы, а потому лучше пометить их отдельно. В противном случае, в истории изменений бачка для жидкости очистки стекла будет запись "Помыл машину", что не соответствует сути изменения и может запутать того, кто потом будет разбираться в этой истории. 6 | 7 | Предположим, что вы отредактировали три файла (`a.html`, `b.html`, и `c.html`). Теперь вы хотите закоммитить все изменения, при этом чтобы изменения в `a.html` и `b.html` были одним коммитом, в то время как изменения в `c.html` логически не связаны с первыми двумя файлами и должны идти отдельным коммитом. 8 | 9 | В теории, вы можете сделать следующее: 10 | 11 | 12 | ``` 13 | git add a.html 14 | git add b.html 15 | git commit -m "Changes for a and b" 16 | ``` 17 | 18 | 19 | 20 | ``` 21 | git add c.html 22 | git commit -m "Unrelated change to c" 23 | ``` 24 | 25 | 26 | Разделяя индексацию и коммит, вы имеете возможность с легкостью настроить, что идет в какой коммит. 27 | -------------------------------------------------------------------------------- /pages/uk/create_a_project.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "2. Створення проєкту" 3 | --- 4 | 5 | ### Цілі 6 | 7 | - Навчитися створювати Git-репозиторій з нуля. 8 | 9 | ## _01_ Створіть сторінку «Hello, World» 10 | 11 | Почніть роботу в порожній директорії (наприклад, `repositories`, якщо ви завантажили архів з попереднього кроку) зі створення порожньої піддиректорії `work`, потім перейдіть до неї та створіть файл `hello.html` з наступним змістом: 12 | 13 | 14 | ``` 15 | mkdir work 16 | cd work 17 | touch hello.html 18 | ``` 19 | 20 | 21 | 22 | ```html 23 | Hello, World 24 | ``` 25 | 26 | 27 | ## _02_ Створіть репозиторій 28 | 29 | Зараз у вас є директорія з одним файлом. Щоб створити Git-репозиторій з цієї директорії, виконайте команду `git init`. 30 | 31 | 32 | ``` 33 | git init 34 | ``` 35 | 36 | 37 | 38 | ```git 39 | ==include[output/02-01.txt] 40 | ``` 41 | 42 | 43 | ## _03_ Додайте сторінку у репозиторій 44 | 45 | Зараз давайте додамо в репозитарій сторінку «Hello, World». 46 | 47 | 48 | ``` 49 | git add hello.html 50 | git commit -m "Initial Commit" 51 | ``` 52 | 53 | 54 | Ви побачите: 55 | 56 | 57 | ```git 58 | ==include[output/02-02.txt] 59 | ``` 60 | 61 | -------------------------------------------------------------------------------- /pages/pt-BR/bare_repositories.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "38. Repositórios bare" 3 | --- 4 | 5 | ### Metas 6 | 7 | - Aprender como criar repositórios bare. 8 | 9 | Um repositório bare é um repositório que não tem um diretório de trabalho. Ele contém apenas o diretório `.git`, o diretório no qual o Git armazena todos os seus dados internos. O principal objetivo desses repositórios é ser um repositório central para o qual os desenvolvedores podem enviar e receber arquivos, portanto, não há necessidade de ter um diretório de trabalho. Os repositórios básicos também são usados nos serviços de hospedagem do Git, como o GitHub e o GitLab. Nas próximas lições, aprenderemos a criar um repositório bare e a fazer push para ele. 10 | 11 | ## _01_ Criando um repositório bare 12 | 13 | 14 | ``` 15 | cd .. 16 | git clone --bare work work.git 17 | ls work.git 18 | ``` 19 | 20 | 21 |

Agora nós estamos no diretório `repositories`.

22 | 23 | 24 | ```git 25 | ==include[output/38-01.txt] 26 | ``` 27 | 28 | 29 | A convenção é que os repositórios que terminam em `.git` são repositórios simples. Podemos ver que não há diretório de trabalho no repositório `work.git`. Essencialmente, ele nada mais é do que o diretório `.git` de um repositório normal. -------------------------------------------------------------------------------- /pages/ru/bare_repositories.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "38. Чистые репозитории" 3 | --- 4 | 5 | ### Цели 6 | 7 | - Научиться создавать чистые репозитории. 8 | 9 | Чистый репозиторий — это репозиторий, не имеющий рабочей директории. Он содержит только директорию `.git`, в которой Git хранит все свои внутренние данные. Основное предназначение таких репозиториев — быть центральным хранилищем, в которое разработчики могут отправлять и из которого могут получать данные. Поэтому в них нет смысла создавать рабочие файлы, они будут только впустую занимать место на диске. Чистые репозитории также используются в сервисах Git-хостинга таких, как GitHub и GitLab. В следующих уроках мы узнаем, как создать чистый репозиторий и как отправлять в него изменения. 10 | 11 | ## _01_ Создайте чистый репозиторий 12 | 13 | 14 | ``` 15 | cd .. 16 | git clone --bare work work.git 17 | ls work.git 18 | ``` 19 | 20 | 21 |

Сейчас мы находимся в директории `repositories`.

22 | 23 | 24 | ```git 25 | ==include[output/38-01.txt] 26 | ``` 27 | 28 | 29 | Принято считать, что репозитории, заканчивающиеся на `.git`, являются чистыми репозиториями. Мы видим, что в репозитории `work.git` нет рабочей директории. По сути, это просто директория `.git` из обычного репозитория. -------------------------------------------------------------------------------- /pages/pt-BR/create_a_project.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "2. Criando um projeto" 3 | --- 4 | 5 | ### Metas 6 | 7 | - Aprender a criar um repositório Git do início. 8 | 9 | ## _01_ Crie uma página de "Hello, World" 10 | 11 | Comece com um diretório de trabalho vazio (por exemplo, `repositories`, se você fez download do arquivo do último passo) e crie um subdiretório vazio chamado `work`. Então, crie um arquivo `hello.html` dentro dele com o conteúdo indicado abaixo. 12 | 13 | 14 | ``` 15 | mkdir work 16 | cd work 17 | touch hello.html 18 | ``` 19 | 20 | 21 | 22 | ```html 23 | Hello, World 24 | ``` 25 | 26 | 27 | ## _02_ Crie um repositório 28 | 29 | Então você tem um diretório que tem um arquivo. Execute o comando `git init` para criar um repositório do Git a partir desse diretório. 30 | 31 | 32 | ``` 33 | git init 34 | ``` 35 | 36 | 37 | 38 | ```git 39 | ==include[output/02-01.txt] 40 | ``` 41 | 42 | 43 | ## _03_ Adicione a página ao repositório 44 | 45 | Agora vamos adicionar a página “Hello, World” ao repositório. 46 | 47 | 48 | ``` 49 | git add hello.html 50 | git commit -m "Initial Commit" 51 | ``` 52 | 53 | 54 | Você verá: 55 | 56 | 57 | ```git 58 | ==include[output/02-02.txt] 59 | ``` 60 | 61 | -------------------------------------------------------------------------------- /pages/ru/more_setup.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "1. Финальные приготовления" 3 | --- 4 | 5 | ### Цели 6 | 7 | - Полная готовность к работе с Git. 8 | 9 | ## _01_ Установка имени и электронной почты 10 | 11 | Если вы никогда ранее не использовали Git, для начала вам необходимо осуществить установку. Выполните следующие команды, чтобы Git узнал ваше имя и электронную почту. Эти данные используются для подписи изменений сделанных вами, что позволит отслеживать, кто и когда сделал изменения в файле. 12 | 13 | 14 | ``` 15 | git config --global user.name "Your Name" 16 | git config --global user.email "your_email@whatever.com" 17 | ``` 18 | 19 | 20 | 21 | ## _02_ Имя ветки по умолчанию 22 | 23 | Мы будем использовать `main` в качестве имени ветки по умолчанию. Чтобы установить его, выполните следующую команду: 24 | 25 | 26 | ``` 27 | git config --global init.defaultBranch main 28 | ``` 29 | 30 | 31 | 32 | ## _03_ Корректная обработка окончаний строк 33 | 34 | Для пользователей Unix/Mac: 35 | 36 | 37 | ``` 38 | git config --global core.autocrlf input 39 | git config --global core.safecrlf warn 40 | ``` 41 | 42 | 43 | Для пользователей Windows: 44 | 45 | 46 | ``` 47 | git config --global core.autocrlf true 48 | git config --global core.safecrlf warn 49 | ``` 50 | 51 | -------------------------------------------------------------------------------- /pages/en/staging_and_committing.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "6. Staging and committing" 3 | --- 4 | 5 | A separate indexing step in Git allows you to split large changes into small commits. For example, say, you washed your car and while doing so, also refilled the windshield washer fluid. These two changes are essentially independent, so it's better to commit them separately. Otherwise, the change log of the windshield wiper fluid tank will contain the entry "Washed the car", which does not correspond to the essence of the change and may confuse the person might be looking into this history later. 6 | 7 | Suppose you have edited three files (`a.html`, `b.html`, and `c.html`). After that you need to commit all the changes so that the changes to `a.html` and `b.html` were a single commit, while the changes to `c.html` were not logically associated with the first two files and were done in a separate commit. 8 | 9 | In theory, you can do the following: 10 | 11 | 12 | ``` 13 | git add a.html 14 | git add b.html 15 | git commit -m "Changes for a and b" 16 | ``` 17 | 18 | 19 | 20 | ``` 21 | git add c.html 22 | git commit -m "Unrelated change to c" 23 | ``` 24 | 25 | 26 | Separating staging and committing, you get the chance to easily customize what goes into a commit. 27 | -------------------------------------------------------------------------------- /pages/uk/more_setup.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "1. Фінальні приготування" 3 | --- 4 | 5 | ### Цілі 6 | 7 | - Повна готовність до роботи з Git. 8 | 9 | ## _01_ Встановлюємо ім'я та адресу електронної пошти 10 | 11 | Якщо ви ніколи раніше не використовували Git, для початку вам необхідно здійснити установку. Виконайте наступні команди, щоб Git дізнався про ваше ім'я та електронну пошту. Ці дані використовуються для підпису змін зроблених вами, що дозволить відстежувати, хто і коли зробив зміни в файлі. 12 | 13 | 14 | ``` 15 | git config --global user.name "Your Name" 16 | git config --global user.email "your_email@whatever.com" 17 | ``` 18 | 19 | 20 | 21 | ## _02_ Назва гілки за замовчуванням 22 | 23 | Ми будемо використовувати `main` як назву гілки за замовчуванням. Щоб налаштувати це, виконайте наступну команду: 24 | 25 | 26 | ``` 27 | git config --global init.defaultBranch main 28 | ``` 29 | 30 | 31 | 32 | ## _03_ Коректна обробка закінчень рядків 33 | 34 | Також, для користувачів Unix/Mac: 35 | 36 | 37 | ``` 38 | git config --global core.autocrlf input 39 | git config --global core.safecrlf warn 40 | ``` 41 | 42 | 43 | Для користувачів Windows: 44 | 45 | 46 | ``` 47 | git config --global core.autocrlf true 48 | git config --global core.safecrlf warn 49 | ``` 50 | 51 | -------------------------------------------------------------------------------- /pages/pt-BR/more_setup.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "1. A preparação final" 3 | --- 4 | 5 | ### Metas 6 | 7 | - Estar completamente preparado para usar o Git. 8 | 9 | ## _01_ Configurando nome e endereço de email 10 | 11 | Se você nunca usou Git antes, o primeiro passo é configurar seu nome e endereço de email. Execute os seguintes comandos para fazer com que o Git saiba seu nome e endereço de email. Esses dados são usados para assinar as alterações que você faz, o que lhe permitirá rastrear quem fez as alterações no arquivo e quando. 12 | 13 | 14 | ``` 15 | git config --global user.name "Seu Nome" 16 | git config --global user.email "seu_email@qualquercoisa.com" 17 | ``` 18 | 19 | 20 | 21 | ## _02_ Nome padrão do branch 22 | 23 | Usaremos `main` como o nome padrão da ramificação. Para configurar isso, execute o seguinte comando: 24 | 25 | 26 | ``` 27 | git config --global init.defaultBranch main 28 | ``` 29 | 30 | 31 | 32 | ## _03_ Tratamento de términos de linhas 33 | 34 | Além disso, para usuários de Unix/Mac: 35 | 36 | 37 | ``` 38 | git config --global core.autocrlf input 39 | git config --global core.safecrlf warn 40 | ``` 41 | 42 | 43 | Para usuários do Windows: 44 | 45 | 46 | ``` 47 | git config --global core.autocrlf true 48 | git config --global core.safecrlf warn 49 | ``` 50 | 51 | -------------------------------------------------------------------------------- /pages/uk/fetching_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "35. Підтягування змін" 3 | --- 4 | 5 | ### Цілі 6 | 7 | - Навчитися підтягувати зміни з віддаленого репозиторія. 8 | 9 | 10 | ``` 11 | cd ../home 12 | git fetch 13 | git log --all 14 | ``` 15 | 16 | 17 |

Зараз ми знаходимося в репозиторії `home`.

18 | 19 | 20 | ```git 21 | ==include[output/35-01.txt] 22 | ``` 23 | 24 | 25 | Зараз в репозиторії є всі коміти з оригінального репозиторія, але вони не злиті в локальні гілки клонованого репозиторія. 26 | 27 | В історії вище знайдіть коміт «Changed README in original repo». Зверніть увагу, що коміт містить у собі коміти `origin/main` і `origin/HEAD`. 28 | 29 | Тепер подивімось на коміт «Renamed hello.html; moved style.css». Ви побачите, що локальна гілка `main` вказує на цей коміт, а не на новий коміт, котрий ми щойно підтягнули. 30 | 31 | Висновком є те, що команда `git fetch` буде підтягувати нові коміти з віддаленого репозиторія, але не буде зливати їх з вашими напрацюваннями в локальних гілках. 32 | 33 | ## _01_ Перевірте README 34 | 35 | Ми можемо продемонструвати, що клонований файл `README` не змінився. 36 | 37 | 38 | ``` 39 | cat README 40 | ``` 41 | 42 | 43 | 44 | ```git 45 | ==include[output/35-02.txt] 46 | ``` 47 | 48 | 49 | Як бачите, жодних змін. -------------------------------------------------------------------------------- /pages/pt-BR/changes_in_master.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "21. Mudanças no branch main" 3 | --- 4 | 5 | ### Metas 6 | 7 | - Aprender como trabalhar com vários branches com diferentes (e às vezes conflitantes) modificações. 8 | 9 | Como mencionei anteriormente, o Git permite que você trabalhe com várias ramificações ao mesmo tempo. Isso é muito útil quando se trabalha em uma equipe, pois as pessoas podem trabalhar em diferentes recursos em paralelo. Também é útil quando se trabalha sozinho: enquanto desenvolve recursos em ramificações separadas, você ainda pode corrigir bugs e lançar pequenas atualizações usando o código estável na ramificação `main`. 10 | 11 | ## _01_ Criar o arquivo `README` 12 | 13 | Vamos criar um arquivo `README`. Ele explicará do que se trata o nosso projeto. 14 | 15 | 16 | ``` 17 | This is the Hello World example from the GitHowTo tutorial. 18 | ``` 19 | 20 | 21 | ## _02_ Enviar o arquivo `README` para a ramificação `main` 22 | 23 | No momento, estamos na ramificação `style`. O arquivo `README` não faz parte desse ramo, portanto, devemos mudar para o ramo `main` antes de fazer o commit das alterações. 24 | 25 | 26 | ``` 27 | git switch main 28 | git add README 29 | git commit -m "Added README" 30 | ``` 31 | 32 | 33 | 34 | ```git 35 | ==include[output/21-01.txt] 36 | ``` 37 | -------------------------------------------------------------------------------- /pages/en/fetching_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "35. Fetching changes" 3 | --- 4 | 5 | ### Goals 6 | 7 | - Learn how to pull changes from a remote repository. 8 | 9 | 10 | ``` 11 | cd ../home 12 | git fetch 13 | git log --all 14 | ``` 15 | 16 | 17 |

We are now in the `home` repository.

18 | 19 | 20 | ```git 21 | ==include[output/35-01.txt] 22 | ``` 23 | 24 | 25 | At the moment, the repository contains all the commits from the original repo; however, they aren't integrated into the local branches of the cloned repository. 26 | 27 | You'll find the commit named "Changed README in original repo" in the history. Notice that the commit includes `origin/main` and `origin/HEAD`. 28 | 29 | Now let's take a look at the "Renamed hello.html; moved style.css" commit. You'll see that the local `main` branch points to this very commit, not the new commit we've just fetched. 30 | 31 | This brings us to the conclusion that the `git fetch` command will fetch new commits from the remote repo, but won't merge them into the local branches. 32 | 33 | ## _01_ Check the README 34 | 35 | We can show that the cloned `README` file has not been changed. 36 | 37 | 38 | ``` 39 | cat README 40 | ``` 41 | 42 | 43 | 44 | ```git 45 | ==include[output/35-02.txt] 46 | ``` 47 | 48 | 49 | No changes, as you can see. -------------------------------------------------------------------------------- /pages/pt-BR/fetching_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "35. Trazendo modificações" 3 | --- 4 | 5 | ### Metas 6 | 7 | - Aprender como trazer modificações de um repositório remoto. 8 | 9 | 10 | ``` 11 | cd ../home 12 | git fetch 13 | git log --all 14 | ``` 15 | 16 | 17 |

Agora nós estamos no repositório `home`.

18 | 19 | 20 | ```git 21 | ==include[output/35-01.txt] 22 | ``` 23 | 24 | 25 | Neste momento, o repositório contém todos os commits do repositório original. Porém, eles não estão integrados com os branchs locais do repositório clonado. 26 | 27 | Você vai ver o commit de nome "Changed README in original repo" no histórico. Perceba que o commit inclui `origin/main` e `origin/HEAD`. 28 | 29 | Agora vamos dar uma olhada no commit "Renamed hello.html; moved style.css". Você vai ver que o branch `main` local aponta para esse commit, não para o commit que acabamos de trazer. 30 | 31 | Isso nos mostra que o comando `git fetch` vai trazer os novos commits do repositório remoto, mas não vai fundir eles com os branches locais. 32 | 33 | ## _01_ Cheque o README 34 | 35 | Nós podemos mostrar que o arquivo `README` clonado não foi modificado. 36 | 37 | 38 | ``` 39 | cat README 40 | ``` 41 | 42 | 43 | 44 | ```git 45 | ==include[output/35-02.txt] 46 | ``` 47 | 48 | 49 | Nenhuma mudança, como você pode ver. 50 | -------------------------------------------------------------------------------- /pages/ru/fetching_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "35. Подтягивание изменений" 3 | --- 4 | 5 | ### Цели 6 | 7 | - Научиться подтягивать изменения из удаленного репозитория. 8 | 9 | 10 | ``` 11 | cd ../home 12 | git fetch 13 | git log --all 14 | ``` 15 | 16 | 17 |

Сейчас мы находимся в репозитории `home`.

18 | 19 | 20 | ```git 21 | ==include[output/35-01.txt] 22 | ``` 23 | 24 | 25 | На данный момент в репозитории есть все коммиты из оригинального репозитория, но они не интегрированы в локальные ветки клонированного репозитория. 26 | 27 | В истории выше найдите коммит «Changed README in original repo». Обратите внимание, что коммит включает в себя коммиты `origin/main` и `origin/HEAD`. 28 | 29 | Теперь давайте посмотрим на коммит «Renamed hello.html; moved style.css». Вы увидите, что локальная ветка `main` указывает на этот коммит, а не на новый коммит, который мы только что подтянули. 30 | 31 | Выводом является то, что команда `git fetch` будет подтягивать новые коммиты из удаленного репозитория, но не будет сливать их с вашими наработками в локальных ветках. 32 | 33 | ## _01_ Проверьте README 34 | 35 | Мы можем продемонстрировать, что клонированный файл `README` не изменился. 36 | 37 | 38 | ``` 39 | cat README 40 | ``` 41 | 42 | 43 | 44 | ```git 45 | ==include[output/35-02.txt] 46 | ``` 47 | 48 | 49 | Как видите, никаких изменений. -------------------------------------------------------------------------------- /outline.yml: -------------------------------------------------------------------------------- 1 | index: 2 | setup: 1 3 | git_basics: 1 4 | more_setup: 1 5 | create_a_project: 1 6 | checking_status: 1 7 | making_changes: 1 8 | staging_changes: 1 9 | staging_and_committing: 1 10 | committing_changes: 1 11 | changes_not_files: 1 12 | history: 1 13 | getting_old_versions: 1 14 | tagging_versions: 1 15 | undoing_local_changes: 1 16 | undoing_staged_changes: 1 17 | undoing_committed_changes: 1 18 | removing_commits_from_a_branch: 1 19 | remove_the_oops_tag: 1 20 | amending_commits: 1 21 | creating_a_branch: 1 22 | navigating_branches: 1 23 | moving_files: 1 24 | changes_in_master: 1 25 | viewing_diverging_branches: 1 26 | merging: 1 27 | creating_a_conflict: 1 28 | resolving_conflicts: 1 29 | rebasing_vs_merging: 1 30 | resetting_the_style_branch: 1 31 | rebasing: 1 32 | merging_back_to_master: 1 33 | multiple_repositories: 1 34 | cloning_repositories: 1 35 | review_the_cloned_repository: 1 36 | what_is_origin: 1 37 | remote_branches: 1 38 | change_the_original_repository: 1 39 | fetching_changes: 1 40 | merging_pulled_changes: 1 41 | adding_a_tracking_branch: 1 42 | 43 | bare_repositories: 1 44 | adding_a_remote_repository: 1 45 | pushing_a_change: 1 46 | pulling_shared_changes: 1 47 | hosting_your_git_repositories: 1 48 | 49 | thank_you: 1 50 | aliases: 1 51 | git_internals_git_directory: 1 52 | git_internals_working_directly_with_git_objects: 1 -------------------------------------------------------------------------------- /pages/uk/multiple_repositories.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Частина II: Декілька репозиторіїв" 3 | --- 4 | 5 | Досі ми працювали лише з одним репозиторієм Git. Однак Git це **розподілена** система контролю версій, а це означає, що вона чудово підходить для роботи із декількома репозиторіями. Ці додаткові репозиторії можна зберігати локально, підключати через локальну мережу або через Інтернет. Вони також можуть бути розміщені на GitHub, GitLab, BitBucket або будь-якому іншому Git-хостингу. 6 | 7 | В наступному розділі ми вдамо, що вирішили взяти частину роботи додому. В минулі часи ви б просто зберегли цей репозиторій на флешку і принесли його додому. Сьогодні ми, швидше за все, викладемо репозиторій на GitHub. Насправді не має значення, як ви ділитеся своєю роботою: Git працюватиме однаково. Більшість інформації з цього розділу також можна застосувати до роботи з декількома репозиторіями, незалежно від того, чи зберігаються вони локально, чи до них надається спільний доступ через мережу. 8 | 9 | Отже, для простоти ми будемо вважати, що використовуємо два незалежних репозиторія, розташовуючи їх локально в окремих директоріях: `work` і `home`. 10 | 11 | Клон Git 12 | 13 |

Далі ми будемо одночасно вносити зміни в обидві копії наших репозиторіїв. Я виділятиму кроки, на яких ми перейшли до іншого репозиторія, блоками, подібними до цього.

-------------------------------------------------------------------------------- /output/28-01.txt: -------------------------------------------------------------------------------- 1 | $ git switch style 2 | Already on 'style' 3 | $ git rebase main 4 | Rebasing (1/3) Rebasing (2/3) Auto-merging hello.html 5 | CONFLICT (content): Merge conflict in hello.html 6 | error: could not apply 903eb1d... Included stylesheet into hello.html 7 | hint: Resolve all conflicts manually, mark them as resolved with 8 | hint: "git add/rm ", then run "git rebase --continue". 9 | hint: You can instead skip this commit: run "git rebase --skip". 10 | hint: To abort and get back to the state before "git rebase", run "git rebase --abort". 11 | Could not apply 903eb1d... Included stylesheet into hello.html 12 | $ git status 13 | interactive rebase in progress; onto 85c14e9 14 | Last commands done (2 commands done): 15 | pick 555372e Added css stylesheet 16 | pick 903eb1d Included stylesheet into hello.html 17 | Next command to do (1 remaining command): 18 | pick 0ee0113 Renamed hello.html; moved style.css 19 | (use "git rebase --edit-todo" to view and edit) 20 | You are currently rebasing branch 'style' on '85c14e9'. 21 | (fix conflicts and then run "git rebase --continue") 22 | (use "git rebase --skip" to skip this patch) 23 | (use "git rebase --abort" to check out the original branch) 24 | 25 | Unmerged paths: 26 | (use "git restore --staged ..." to unstage) 27 | (use "git add ..." to mark resolution) 28 | both modified: hello.html 29 | 30 | no changes added to commit (use "git add" and/or "git commit -a") 31 | -------------------------------------------------------------------------------- /pages/en/hosting_your_git_repositories.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "42. Hosting your Git repository" 3 | --- 4 | 5 | > Hey, congrats for making it this far! Please consider this a bonus topic. 6 | 7 | ### Goals 8 | 9 | - Learn how to set up Git server for sharing repositories. 10 | 11 | Want to make your own GitHub? There are many ways to share Git repositories over the network. Here is a quick and dirty way. 12 | 13 | ## _01_ Launch the Git server 14 | 15 | 16 | ``` 17 | # (From the "repositories" directory) 18 | git daemon --verbose --export-all --base-path=. 19 | ``` 20 | 21 | 22 | Now, go to your `repositories` directory in a separate terminal window. 23 | 24 | 25 | ``` 26 | # (From the "repositories" directory) 27 | git clone git://localhost/work.git network_work 28 | cd network_work 29 | ls 30 | ``` 31 | 32 | 33 | You will find a copy of the `work` project. 34 | 35 | ## _02_ Pushing to the Git Daemon 36 | 37 | If you want to allow push to the repository Git Daemon, add `--enable=receive-pack` tag to the `git daemon` command. Be attentive, this server does not perform authentication, so anyone can push changes to your repository. 38 | 39 | ## _03_ Sharing repositories 40 | 41 | At this point, sky is the limit. Go wild! Rent a server, buy a domain name, host your repositories on this server, and you'll enjoy your private GitHub! 42 | 43 | Seriously, though, you can host your own private [GitLab](https://gitlab.com/). It's free and open source. -------------------------------------------------------------------------------- /pages/en/multiple_repositories.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Part II: Working with multiple repositories" 3 | --- 4 | 5 | So far, we have been working with only one Git repository. However, Git is a **distributed** version control system, meaning it's great for working with several repositories. These additional repositories can be stored locally, accessed via a network connection, or over the Internet. They can also be hosted on GitHub, GitLab, BitBucket, or any other Git hosting service. 6 | 7 | In the next section, we will pretend that we decided to take some work home. In the day of yore, you could have carried this repository on a flash drive and brought it home. Nowadays, we would likely share the repository via GitHub. The truth is, it doesn't matter how you share your work: Git will work the same way. Most of the information in this section can also be applied to working with multiple repositories, whether they are stored locally or shared over a network. 8 | 9 | So, for the sake of simplicity, we will pretend that we are using two independent repositories, while having them locally in separate directories, `work` and `home`. 10 | 11 | Git clone 12 | 13 |

In the following lessons, we will simultaneously change both copies of our repositories. I'll highlight the steps where we switched to another repository in blocks like this one.

-------------------------------------------------------------------------------- /pages/ru/multiple_repositories.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Часть II: Несколько репозиториев" 3 | --- 4 | 5 | До сих пор мы работали только с одним Git-репозиторием. Однако Git - это **распределенная** система управления версиями, а значит, она отлично подходит для работы с несколькими репозиториями. Эти дополнительные репозитории могут храниться локально, быть доступными через сеть или Интернет. Они также могут быть размещены на GitHub, GitLab, BitBucket или любом другом Git-хостинге. 6 | 7 | В следующем разделе мы представим, что решили взять некоторую работу на дом. В былые времена можно было бы перенести этот репозиторий на флешку и взять его с собой домой. Сегодня мы, скорее всего, поделимся репозиторием через GitHub. На самом деле, не важно, как вы делитесь своей работой: Git будет работать одинаково. Большая часть информации, изложенной в этом разделе, может быть применена и для работы с несколькими репозиториями, независимо от того, хранятся ли они локально или передаются по сети. 8 | 9 | Поэтому для простоты представим, что мы используем два независимых репозитория, располагая их локально в разных директориях: `work` и `home`. 10 | 11 | Git clone 12 | 13 |

В следующих уроках мы будем одновременно изменять обе копии наших репозиториев. Я буду подсвечивать шаги, на которых мы переключались на другой репозиторий, в блоках, аналогичных этому.

-------------------------------------------------------------------------------- /pages/pt-BR/hosting_your_git_repositories.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "42. Divulgando o seu repositório" 3 | --- 4 | 5 | > Parabéns por ter chegado até aqui! Considere este tópico como um bônus. 6 | 7 | ### Metas 8 | 9 | - Aprender como configurar um servidor Git para compartilhar repositórios. 10 | 11 | Existem maneiras diferentes de compartilhar um repositório Git na rede. Essa é a mais rápida. 12 | 13 | ## _01_ Execute Git server 14 | 15 | 16 | ``` 17 | # (Do diretório "repositories") 18 | git daemon --verbose --export-all --base-path=. 19 | ``` 20 | 21 | 22 | Agora, vá ao seu diretório `repositories` num terminal separado. 23 | 24 | 25 | ``` 26 | # (Do diretório "repositories") 27 | git clone git://localhost/work.git network_work 28 | cd network_work 29 | ls 30 | ``` 31 | 32 | 33 | Você encontrará uma cópia do projeto `work`. 34 | 35 | ## _02_ Mandando para o Git Daemon 36 | 37 | Se você quer mover o repositório para o Git Daemon, adicione a tag `--enable=receive-pack` ao comando `git daemon`. Tenha atenção, esse servidor não tem autenticação, então qualquer um pode enviar mudanças para o seu repositório. 38 | 39 | 40 | ## Compartilhamento de repositórios 41 | 42 | Neste ponto, o céu é o limite. Vá à loucura! Alugue um servidor, compre um nome de domínio, hospede seus repositórios nesse servidor e você desfrutará de seu GitHub particular! 43 | 44 | Mas, falando sério, você pode hospedar seu próprio [GitLab] privado (https://gitlab.com/). Ele é gratuito e de código aberto. -------------------------------------------------------------------------------- /pages/pt-BR/multiple_repositories.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Parte II: Repositórios múltiplos" 3 | --- 4 | 5 | Até agora, trabalhamos com apenas um repositório Git. No entanto, o Git é um sistema de controle de versão **distribuído**, ou seja, é ótimo para trabalhar com vários repositórios. Esses repositórios adicionais podem ser armazenados localmente, acessados por meio de conexão de rede ou pela Internet. Eles também podem ser hospedados no GitHub, no GitLab, no BitBucket ou em qualquer outro serviço de hospedagem do Git. 6 | 7 | Na próxima seção, vamos fingir que decidimos levar algum trabalho para casa. Antigamente, você poderia carregar esse repositório em um pen drive e levá-lo para casa. Hoje em dia, provavelmente usaríamos o GitHub para compartilhar nosso trabalho entre computadores. A verdade é que não importa como você compartilha seu trabalho: o Git funcionará da mesma forma. A maioria das informações desta seção também pode ser aplicada ao trabalho com vários repositórios, independentemente de eles estarem armazenados localmente ou compartilhados em uma rede. 8 | 9 | Portanto, para simplificar, vamos fingir que estamos usando dois repositórios independentes, mantendo-os localmente em diretórios separados `work` e `home`. 10 | 11 | Git clone 12 | 13 |

Nas lições a seguir, faremos alterações em ambas as cópias de nossos repositórios simultaneamente. Destacarei as etapas em que mudamos para outro repositório em blocos como este.

-------------------------------------------------------------------------------- /pages/ru/resetting_the_style_branch.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "27. Сброс ветки style" 3 | --- 4 | 5 | ### Цели 6 | 7 | - Сбросить ветку `style` до точки перед первым слиянием. 8 | 9 | ## _01_ Сбросьте ветку `style` 10 | 11 | Давайте вернемся во времени на ветке `style` к точке _перед_ тем, как мы слили ее с веткой `main`. Мы можем сбросить ветку к любому коммиту при помощи команды `reset`. По сути, это изменение указателя ветки на любую точку дерева коммитов. 12 | 13 | В этом случае мы хотим вернуться в ветке `style` в точку перед слиянием с `main`. Нам необходимо найти последний коммит перед слиянием. 14 | 15 | 16 | ``` 17 | git switch style 18 | git log --graph 19 | ``` 20 | 21 | 22 | 23 | ```git 24 | ==include[output/27-01.txt] 25 | ``` 26 | 27 | 28 | Это немного трудно читать, но, глядя на данные, мы видим, что коммит «Renamed hello.html; moved style.css» был последним на ветке `style` перед слиянием. Давайте сбросим ветку `style` к этому коммиту. Чтобы сослаться на этот коммит, мы либо используем его хеш, либо посчитаем, что этот коммит находится за 2 коммита до `HEAD`, то есть `HEAD~2` в нотации Git. 29 | 30 | 31 | ``` 32 | git reset --hard HEAD~2 33 | ``` 34 | 35 | 36 | 37 | ```git 38 | ==include[output/27-02.txt] 39 | ``` 40 | 41 | 42 | ## _02_ Проверьте ветку 43 | 44 | Теперь проверим историю ветки `style`. В истории не должно быть коммитов слияния. 45 | 46 | 47 | ``` 48 | git log --graph 49 | ``` 50 | 51 | 52 | 53 | ```git 54 | ==include[output/27-03.txt] 55 | ``` 56 | -------------------------------------------------------------------------------- /pages/uk/resetting_the_style_branch.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "27. Відкочування гілки style" 3 | --- 4 | 5 | ### Цілі 6 | 7 | - Відкотити гілку `style` до точки перед першим злиттям. 8 | 9 | ## _01_ Відкотіть гілку `style` 10 | 11 | Повернімось в часі у гілці `style` до точки _перед_ тим, як ми злили її з гілкою `main`. Ми можемо відновити гілку до будь-якого коміту за допомогою команди `reset`. По суті, це зміна покажчика гілки на будь-яку точку дерева комітів. 12 | 13 | У цьому випадку ми хочемо повернутися в гілці `style` в точку перед злиттям з `main`. Нам необхідно знайти останній коміт перед злиттям. 14 | 15 | 16 | ``` 17 | git switch style 18 | git log --graph 19 | ``` 20 | 21 | 22 | 23 | ```git 24 | ==include[output/27-01.txt] 25 | ``` 26 | 27 | 28 | Це трохи важко читати, але, дивлячись на дані, ми бачимо, що коміт «Renamed hello.html; moved style.css» був останнім у гілці `style` перед злиттям. Давайте скинемо гілку `style` до цього коміту. Для посилання на цей коміт ми або використовуємо його хеш, або визначаємо, що цей коміт знаходиться за 2 коміти до `HEAD`, тобто `HEAD~2` у нотації Git. 29 | 30 | 31 | ``` 32 | git reset --hard HEAD~2 33 | ``` 34 | 35 | 36 | 37 | ```git 38 | ==include[output/27-02.txt] 39 | ``` 40 | 41 | 42 | ## _02_ Перевірте гілку 43 | 44 | Тепер перевіримо історію змін у гілці `style`. У ньому не повинно бути жодних комітів злиття. 45 | 46 | 47 | ``` 48 | git log --graph 49 | ``` 50 | 51 | 52 | 53 | ```git 54 | ==include[output/27-03.txt] 55 | ``` 56 | -------------------------------------------------------------------------------- /pages/en/resetting_the_style_branch.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "27. Resetting the style branch" 3 | --- 4 | 5 | ### Goals 6 | 7 | - Reset the branch `style` to the point before the first merge with `main`. 8 | 9 | ## _01_ Resetting the `style` branch 10 | 11 | Let us go to the `style` branch to the point _before_ we had merged it with the `main` branch. We can `reset` the branch to any commit. In fact, the `reset` command can change the branch pointer to point to any commit in the tree. 12 | 13 | Here, we want to go back in the `style` branch to a point before merging with the `main`. We have to find the last commit before the merge. 14 | 15 | 16 | ``` 17 | git switch style 18 | git log --graph 19 | ``` 20 | 21 | 22 | 23 | ```git 24 | ==include[output/27-01.txt] 25 | ``` 26 | 27 | 28 | It's a little hard to read, but we can see from the output that the "Renamed hello.html; moved style.css" commit was the latest on the `style` branch prior to the first merging with `main`. Let us reset the `style` branch to this commit. To reference that commit, we either use its hash, or deduct that this commit is 2 commits before the `HEAD`, or `HEAD~2` in Git notation. 29 | 30 | 31 | ``` 32 | git reset --hard HEAD~2 33 | ``` 34 | 35 | 36 | 37 | ```git 38 | ==include[output/27-02.txt] 39 | ``` 40 | 41 | 42 | ## _02_ Check the branch 43 | 44 | Now, lets check the log of the `style` branch. There should be no merge commits in the log. 45 | 46 | 47 | ``` 48 | git log --graph 49 | ``` 50 | 51 | 52 | 53 | ```git 54 | ==include[output/27-03.txt] 55 | ``` 56 | 57 | -------------------------------------------------------------------------------- /pages/pt-BR/resetting_the_style_branch.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "27. Resetando o branch style" 3 | --- 4 | 5 | ### Metas 6 | 7 | - Resetar o branch `style` para o ponto anterior ao primeiro merge. 8 | 9 | ## _01_ Resetando o branch `style` 10 | 11 | Vamos para o branch `style` no ponto _antes_ de darmos merge com o branch `main`. Podemos redefinir uma branch para qualquer commit usando o comando `reset`. Na verdade, isso faz com que o ponteiro do branch aponte para qualquer commit contido na árvore. 12 | 13 | Aqui, queremos voltar no `style` branch para um ponto anterior ao merge com o `main`. Temos que encontrar o último commit antes do merge 14 | 15 | 16 | ``` 17 | git switch style 18 | git log --graph 19 | ``` 20 | 21 | 22 | 23 | ```git 24 | ==include[output/27-01.txt] 25 | ``` 26 | 27 | 28 | É um pouco difícil de ler, mas podemos perceber pelos dados que o commit "Renamed hello.html; moved style.css" foi o último no branch `style` anterior ao merging. Vamos redefinir o ramo `style` para esse commit. Para fazer referência a esse commit, usamos seu hash ou deduzimos que esse commit está 2 commits antes do `HEAD`, ou `HEAD~2` na notação do Git. 29 | 30 | 31 | ``` 32 | git reset --hard HEAD~2 33 | ``` 34 | 35 | 36 | 37 | ```git 38 | ==include[output/27-02.txt] 39 | ``` 40 | 41 | 42 | ## _02_ Cheque o branch 43 | 44 | Agora, vamos verificar o registro da ramificação `style`. Não deve haver commits de mesclagem no registro. 45 | 46 | 47 | ``` 48 | git log --graph 49 | ``` 50 | 51 | 52 | 53 | ```git 54 | ==include[output/27-03.txt] 55 | ``` 56 | 57 | -------------------------------------------------------------------------------- /pages/ru/hosting_your_git_repositories.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "42. Размещение ваших Git-репозиториев" 3 | --- 4 | 5 | > Поздравляю с тем, что вы дошли до этого момента! Пожалуйста, считайте эту тему бонусной. 6 | 7 | ### Цели 8 | 9 | - Научиться настраивать Git-сервер для совместного использования репозиториев. 10 | 11 | Хотите создать свой собственный GitHub? Существует множество способов совместного использования репозиториев Git по сети. Здесь приведен простой и быстрый (но ненадежный и опасный) способ. 12 | 13 | ## _01_ Запуск Git-сервера 14 | 15 | 16 | ``` 17 | # (From the "repositories" directory) 18 | git daemon --verbose --export-all --base-path=. 19 | ``` 20 | 21 | 22 | Теперь в отдельном окне терминала перейдите в вашу директорию `repositories`: 23 | 24 | 25 | ``` 26 | # (From the "repositories" directory) 27 | git clone git://localhost/work.git network_work 28 | cd network_work 29 | ls 30 | ``` 31 | 32 | 33 | Вы увидите копию проекта `work`. 34 | 35 | ## _02_ Отправка изменений в Git Daemon 36 | 37 | Если вы хотите разрешить отправку изменений (`push`) в репозиторий Git Daemon, добавьте метку `--enable=receive-pack` к команде `git daemon`. Будьте осторожны, этот сервер не производит аутентификацию, поэтому любой сможет отправлять изменения в ваш репозиторий. 38 | 39 | ## _03_ Совместное использование репозиториев 40 | 41 | На этом этапе вам открываются безграничные возможности. Смелее! Возьмите в аренду сервер, купите доменное имя, разместите на этом сервере свои репозитории и наслаждайтесь своим личным GitHub! 42 | 43 | Если серьезно, то вы можете самостоятельно разместить свой личный сервер [GitLab](https://Gitlab.com/). Этот продукт бесплатный и с открытым исходным кодом. -------------------------------------------------------------------------------- /pages/uk/hosting_your_git_repositories.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "42. Розміщення ваших Git репозиторіїв" 3 | --- 4 | 5 | > Вітаю, що ви дійшли так далеко! Будь ласка, вважайте це бонусною темою. 6 | 7 | ### Цілі 8 | 9 | - Навчитися налаштовувати Git-сервер для спільного використання репозиторіїв. 10 | 11 | Хочете створити власний GitHub? Існує багато способів ділитися Git-репозиторіями локальною мережею чи через Інтернет. Ось спосіб, з яким це можна зробити швидкоруч (не для продакшену). 12 | 13 | ## _01_ Запуск Git-сервера 14 | 15 | 16 | ``` 17 | # (From the "repositories" directory) 18 | git daemon --verbose --export-all --base-path=. 19 | ``` 20 | 21 | 22 | Тепер в окремому вікні термінала перейдіть до вашої директорії `repositories`: 23 | 24 | 25 | ``` 26 | # (From the "repositories" directory) 27 | git clone git://localhost/work.git network_work 28 | cd network_work 29 | ls 30 | ``` 31 | 32 | 33 | Ви побачите копію проєкту `work`. 34 | 35 | ## _02_ Відправка змін в Git Daemon 36 | 37 | Якщо ви хочете дозволити відправку змін (`push`) в репозиторій Git Daemon, додайте мітку `--enable=receive-pack` до команди `git daemon`. Будьте обережні, цей сервер не робить аутентифікацію, тому будь-хто може відправляти зміни в ваш репозиторій. 38 | 39 | ## _03_ Спільне використання репозиторіїв 40 | 41 | На цьому етапі вам відкриваються безмежні можливості. Сміливіше! Візьміть в оренду сервер, купіть доменне ім'я, розмістіть на цьому сервері свої репозиторії та насолоджуйтеся своїм особистим GitHub! 42 | 43 | Якщо серйозно, то ви можете самостійно розмістити в мережі власний сервер [GitLab](https://gitlab.com/). Цей продукт безкоштовний, має відкритий вихідний код (та колись був співзаснований українцем). -------------------------------------------------------------------------------- /pages/en/undoing_local_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "12. Discarding local changes (before staging)" 3 | --- 4 | 5 | ### Goals 6 | 7 | - Learn how to discard the working directory changes. 8 | 9 | ## _01_ Checking out the `main` branch 10 | 11 | Make sure you are on the latest commit in the `main` branch before you continue. 12 | 13 | 14 | ``` 15 | git switch main 16 | ``` 17 | 18 | 19 | ## _02_ Change `hello.html` 20 | 21 | Sometimes you have modified a file in your local working directory, and you wish to just revert to what has already been committed. The `restore` command will handle that. 22 | 23 | Make changes to the `hello.html` file in the form of an unwanted comment. 24 | 25 | 26 | ```html 27 | 28 | 29 | 30 | 31 |

Hello, World!

32 | →← 33 | 34 | 35 | ``` 36 | 37 | 38 | ## _03_ Check the status 39 | 40 | First of all, check the working directory’s status. 41 | 42 | 43 | ``` 44 | git status 45 | ``` 46 | 47 | 48 | 49 | ```git 50 | ==include[output/12-01.txt] 51 | ``` 52 | 53 | 54 | We see that the `hello.html` file has been modified, but not staged yet. 55 | 56 | ## _04_ Undoing the changes in the working directory 57 | 58 | Use the `restore` command in order to reset the content of the file `hello.html`. 59 | 60 | 61 | ``` 62 | git restore hello.html 63 | git status 64 | cat hello.html 65 | ``` 66 | 67 | 68 | 69 | ```git 70 | ==include[output/12-02.txt] 71 | ``` 72 | 73 | 74 | The `status` command shows there were no unstaged changes in the working directory. And the "bad comment" is no longer contained in the file. -------------------------------------------------------------------------------- /pages/uk/undoing_local_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "12. Скасування локальних змін (до індексації)" 3 | --- 4 | 5 | ### Цілі 6 | 7 | - Навчитися скасовувати зміни в робочій директорії. 8 | 9 | ## _01_ Перейдіть на гілку `main` 10 | 11 | Переконайтеся, що ви перебуваєте на останньому коміті гілки `main`, перш ніж продовжити роботу. 12 | 13 | 14 | ``` 15 | git switch main 16 | ``` 17 | 18 | 19 | ## _02_ Змініть `hello.html` 20 | 21 | Іноді після того, як ви змінили файл у робочій директорії, ви передумали та хочете просто повернутися до того, що вже було закомічено. Команда `restore` впорається з цим завданням. 22 | 23 | Внесіть зміни у файл `hello.html` у вигляді небажаного коментаря. 24 | 25 | 26 | ```html 27 | 28 | 29 | 30 | 31 |

Hello, World!

32 | →← 33 | 34 | 35 | ``` 36 | 37 | 38 | ## _03_ Перевірте стан 39 | 40 | Спочатку перевірте стан робочої директорії. 41 | 42 | 43 | ``` 44 | git status 45 | ``` 46 | 47 | 48 | 49 | ```git 50 | ==include[output/12-01.txt] 51 | ``` 52 | 53 | 54 | Ми бачимо, що файл `hello.html` було змінено, але ще не проіндексовано. 55 | 56 | ## _04_ Скасування змін в робочій директорії 57 | 58 | Використовуйте команду `restore` для того, щоб відновити вміст файлу `hello.html`. 59 | 60 | 61 | ``` 62 | git restore hello.html 63 | git status 64 | cat hello.html 65 | ``` 66 | 67 | 68 | 69 | ```git 70 | ==include[output/12-02.txt] 71 | ``` 72 | 73 | 74 | Команда `status` показує нам, що в робочій директорії не було зроблено жодних незафіксованих змін. І «небажаний коментар» більше не є частиною вмісту файлу. -------------------------------------------------------------------------------- /pages/pt-BR/undoing_local_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "12. Descartando mudanças locais (antes do stage)" 3 | --- 4 | 5 | ### Metas 6 | 7 | - Aprender como descartar mudanças no repositório de trabalho. 8 | 9 | ## _01_ Acessando o branch `main` 10 | 11 | Verifique que você esta no último commit do branch `main` antes de continuar. 12 | 13 | 14 | ``` 15 | git switch main 16 | ``` 17 | 18 | 19 | ## _02_ Mude o `hello.html` 20 | 21 | Acontece de você modificar o arquivo no seu diretório de trabalho local e às vezes querer descartar as mudanças que você fez commit. É aqui que o comando `restore` vai te ajudar. 22 | 23 | Faça mudanças ao arquivo `hello.html` na forma de um comentário indesejado. 24 | 25 | 26 | ```html 27 | 28 | 29 | 30 | 31 |

Hello, World!

32 | →← 33 | 34 | 35 | ``` 36 | 37 | 38 | ## _03_ Confira o status 39 | 40 | Primeiro de tudo, confira o status do repositório de trabalho. 41 | 42 | 43 | ``` 44 | git status 45 | ``` 46 | 47 | 48 | 49 | ```git 50 | ==include[output/12-01.txt] 51 | ``` 52 | 53 | 54 | Nós vemos que o arquivo `hello.html` foi modificado, mas ainda não está no stage. 55 | 56 | ## _04_ Desfazendo as mudanças no diretório de trabalho 57 | 58 | Use o comando `restore` para redefinir o conteúdo do arquivo `hello.html`. 59 | 60 | 61 | ``` 62 | git restore hello.html 63 | git status 64 | cat hello.html 65 | ``` 66 | 67 | 68 | 69 | ```git 70 | ==include[output/12-02.txt] 71 | ``` 72 | 73 | 74 | O comando `status` mostra que não existem mudanças que não estão no stage no repositório de trabalho. E o "comentário ruim" não está mais no arquivo. 75 | -------------------------------------------------------------------------------- /pages/ru/undoing_local_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "12. Отмена локальных изменений (до индексации)" 3 | --- 4 | 5 | ### Цели 6 | 7 | - Научиться отменять изменения в рабочей директории. 8 | 9 | ## _01_ Переключитесь на ветку `main` 10 | 11 | Убедитесь, что вы находитесь на последнем коммите ветки `main`, прежде чем продолжить работу. 12 | 13 | 14 | ``` 15 | git switch main 16 | ``` 17 | 18 | 19 | ## _02_ Измените `hello.html` 20 | 21 | Иногда после того как вы изменили файл в рабочей директории, вы передумали и хотите просто вернуться к тому, что уже было закоммичено. Команда `restore` справится с этой задачей. 22 | 23 | Внесите изменение в файл `hello.html` в виде нежелательного комментария. 24 | 25 | 26 | ```html 27 | 28 | 29 | 30 | 31 |

Hello, World!

32 | →← 33 | 34 | 35 | ``` 36 | 37 | 38 | ## _03_ Проверьте состояние 39 | 40 | Сначала проверьте состояние рабочей директории. 41 | 42 | 43 | ``` 44 | git status 45 | ``` 46 | 47 | 48 | 49 | ```git 50 | ==include[output/12-01.txt] 51 | ``` 52 | 53 | 54 | Мы видим, что файл `hello.html` был изменен, но еще не проиндексирован. 55 | 56 | ## _04_ Отмена изменений в рабочем каталоге 57 | 58 | Используйте команду `restore`, чтобы сбросить содержимое файла `hello.html`. 59 | 60 | 61 | ``` 62 | git restore hello.html 63 | git status 64 | cat hello.html 65 | ``` 66 | 67 | 68 | 69 | ```git 70 | ==include[output/12-02.txt] 71 | ``` 72 | 73 | 74 | Команда `status` показывает нам, что в рабочей директории не было сделано никаких незафиксированных изменений. И «нежелательный комментарий» больше не является частью содержимого файла. 75 | -------------------------------------------------------------------------------- /pages/uk/undoing_staged_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "13. Скасування проіндексованих змін (перед комітом)" 3 | --- 4 | 5 | ### Цілі 6 | 7 | - Навчитися скасовувати зміни, які було проіндексовано. 8 | 9 | ## _01_ Внесіть зміни у файл і проіндексуйте їх 10 | 11 | Внесіть зміни у файл `hello.html` у вигляді небажаного коментаря 12 | 13 | 14 | ```html 15 | 16 | 17 | →← 18 | 19 | 20 |

Hello, World!

21 | 22 | 23 | ``` 24 | 25 | 26 | Проіндексуйте ці зміни. 27 | 28 | 29 | ``` 30 | git add hello.html 31 | ``` 32 | 33 | 34 | ## _02_ Перевірте стан 35 | 36 | Перевірте стан небажаної зміни. 37 | 38 | 39 | ``` 40 | git status 41 | ``` 42 | 43 | 44 | 45 | ```git 46 | ==include[output/13-01.txt] 47 | ``` 48 | 49 | 50 | Стани показує, що зміни було проіндексовано і готове до коміту. 51 | 52 | ## _03_ Відновлення індексу 53 | 54 | Команда `restore` з прапором `--staged` очищає область показу. 55 | 56 | 57 | ``` 58 | git restore --staged hello.html 59 | ``` 60 | 61 | 62 | 63 | ```git 64 | ==include[output/13-02.txt] 65 | ``` 66 | 67 | 68 | Команда `restore` з опцією `--staged` не змінює фактичні файли у робочому каталозі. Тому файл hello.html і надалі міститиме небажані коментарі. Однак слід бути обережними, оскільки `restore` без прапорця `--staged` також відкине зміни у робочому каталозі. 69 | 70 | ## _04_ Відновлення файлу 71 | 72 | Відновимо наш файл до стану останнього коміту. 73 | 74 | 75 | ``` 76 | git restore hello.html 77 | git status 78 | ``` 79 | 80 | 81 | 82 | ```git 83 | ==include[output/13-03.txt] 84 | ``` 85 | 86 | 87 | Наша робоча директорія знову чиста. -------------------------------------------------------------------------------- /pages/en/amending_commits.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "17. Amending commits" 3 | --- 4 | 5 | ### Goals 6 | 7 | - Learn how to modify an existing commit. 8 | 9 | ## _01_ Change the page and commit 10 | 11 | Put an author comment on the page. 12 | 13 | 14 | ```html 15 | →← 16 | 17 | 18 | 19 | 20 |

Hello, World!

21 | 22 | 23 | ``` 24 | 25 | 26 | 27 | ``` 28 | git add hello.html 29 | git commit -m "Added copyright statement" 30 | git log 31 | ``` 32 | 33 | 34 | 35 | ```git 36 | ==include[output/17-01.txt] 37 | ``` 38 | 39 | 40 | ## _02_ Oops... email required 41 | 42 | After making the commit you understand that every good commit should include the author's email. Edit the `hello.html` page to provide an email. 43 | 44 | 45 | ```html 46 | 47 | 48 | 49 | 50 | 51 |

Hello, World!

52 | 53 | 54 | ``` 55 | 56 | 57 | ## _03_ Change the previous commit 58 | 59 | We do not want to create another commit for adding the email address. Let us change the previous commit and add an email address. 60 | 61 | 62 | ``` 63 | git add hello.html 64 | git commit --amend -m "Added copyright statement with email" 65 | ``` 66 | 67 | 68 | 69 | ```git 70 | ==include[output/17-02.txt] 71 | ``` 72 | 73 | 74 | ## _04_ View history 75 | 76 | 77 | ``` 78 | git log 79 | ``` 80 | 81 | 82 | 83 | ```git 84 | ==include[output/17-03.txt] 85 | ``` 86 | 87 | 88 | The new "author/email" commit replaces the original "author" commit. The same effect can be achieved by resetting the last commit in the branch, and recommitting new changes. 89 | -------------------------------------------------------------------------------- /pages/pt-BR/amending_commits.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "17. Mudando commits" 3 | --- 4 | 5 | ### Metas 6 | 7 | - Aprender como modificar um commit já existente. 8 | 9 | ## _01_ Mude a página e faça um commit 10 | 11 | Coloque um comentário de autor na página. 12 | 13 | 14 | ```html 15 | →← 16 | 17 | 18 | 19 | 20 |

Hello, World!

21 | 22 | 23 | ``` 24 | 25 | 26 | 27 | ``` 28 | git add hello.html 29 | git commit -m "Added copyright statement" 30 | git log 31 | ``` 32 | 33 | 34 | 35 | ```git 36 | ==include[output/17-01.txt] 37 | ``` 38 | 39 | 40 | ## _02_ Oops... precisa do email 41 | 42 | Depois de fazer o commit, você percebe que todo bom comentário deveria incluir o email do autor. Edite a página `hello.html` para fornecer um email. 43 | 44 | 45 | ```html 46 | 47 | 48 | 49 | 50 | 51 |

Hello, World!

52 | 53 | 54 | ``` 55 | 56 | 57 | ## _03_ Mude o commit anterior 58 | 59 | Nós não queremos criar outro commit apenas para o email. Vamos mudar o commit anterior e adicionar o endereço de email. 60 | 61 | 62 | ``` 63 | git add hello.html 64 | git commit --amend -m "Added copyright statement with email" 65 | ``` 66 | 67 | 68 | 69 | ```git 70 | ==include[output/17-02.txt] 71 | ``` 72 | 73 | 74 | ## _04_ Olhar o histórico 75 | 76 | 77 | ``` 78 | git log 79 | ``` 80 | 81 | 82 | 83 | ```git 84 | ==include[output/17-03.txt] 85 | ``` 86 | 87 | 88 | O novo commit "author/email" substitui o commit original "author". O mesmo pode ser obtido usando o comando `reset` no branch e fazendo novamente o commit com as mudanças. 89 | -------------------------------------------------------------------------------- /pages/en/undoing_staged_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "13. Cancel staged changes (before committing)" 3 | --- 4 | 5 | ### Goals 6 | 7 | - Learn how to undo changes that have been staged. 8 | 9 | ## _01_ Edit file and stage changes 10 | 11 | Make changes to the `hello.html` file in the form of an unwanted comment 12 | 13 | 14 | ```html 15 | 16 | 17 | →← 18 | 19 | 20 |

Hello, World!

21 | 22 | 23 | ``` 24 | 25 | 26 | Stage the modified file. 27 | 28 | 29 | ``` 30 | git add hello.html 31 | ``` 32 | 33 | 34 | ## _02_ Check the status 35 | 36 | Check the status of unwanted changes . 37 | 38 | 39 | ``` 40 | git status 41 | ``` 42 | 43 | 44 | 45 | ```git 46 | ==include[output/13-01.txt] 47 | ``` 48 | 49 | 50 | Status shows that the change has been staged and is ready to commit. 51 | 52 | ## _03_ Restore the staging area 53 | 54 | The `restore` command with the `--staged` flag clears the staging area. 55 | 56 | 57 | ``` 58 | git restore --staged hello.html 59 | ``` 60 | 61 | 62 | 63 | ```git 64 | ==include[output/13-02.txt] 65 | ``` 66 | 67 | 68 | The `restore` command with the `--staged` option does not change the actual files in the working directory. Therefore, the hello.html still contains unwanted comments. You should be careful, though, because `restore` without the `--staged` flag will also drop the changes in the working directory. 69 | 70 | ## _04_ Restore the workign tree 71 | 72 | Let's restore our file to the state of the last commit. 73 | 74 | 75 | ``` 76 | git restore hello.html 77 | git status 78 | ``` 79 | 80 | 81 | 82 | ```git 83 | ==include[output/13-03.txt] 84 | ``` 85 | 86 | 87 | Our working directory is clean again. -------------------------------------------------------------------------------- /pages/ru/undoing_staged_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "13. Отмена проиндексированных изменений (перед коммитом)" 3 | --- 4 | 5 | ### Цели 6 | 7 | - Научиться отменять изменения, которые были проиндексированы. 8 | 9 | ## _01_ Измените файл и проиндексируйте изменения 10 | 11 | Внесите изменение в файл `hello.html` в виде нежелательного комментария 12 | 13 | 14 | ```html 15 | 16 | 17 | →← 18 | 19 | 20 |

Hello, World!

21 | 22 | 23 | ``` 24 | 25 | 26 | Проиндексируйте это изменение. 27 | 28 | 29 | ``` 30 | git add hello.html 31 | ``` 32 | 33 | 34 | ## _02_ Проверьте состояние 35 | 36 | Проверьте состояние нежелательного изменения. 37 | 38 | 39 | ``` 40 | git status 41 | ``` 42 | 43 | 44 | 45 | ```git 46 | ==include[output/13-01.txt] 47 | ``` 48 | 49 | 50 | Состояние показывает, что изменение было проиндексировано и готово к коммиту. 51 | 52 | ## _03_ Восстановление индекса 53 | 54 | Команда `restore` с флагом `--staged` очищает индекс. 55 | 56 | 57 | ``` 58 | git restore --staged hello.html 59 | ``` 60 | 61 | 62 | 63 | ```git 64 | ==include[output/13-02.txt] 65 | ``` 66 | 67 | 68 | Команда `restore` с опцией `--staged` не изменяет фактические файлы в рабочем каталоге. Поэтому hello.html по-прежнему содержит ненужные комментарии. Однако следует быть осторожным, поскольку команда `restore` без флага `--staged` также сбросит изменения в рабочем каталоге. 69 | 70 | ## _04_ Восстановление рабочего каталога 71 | 72 | Давайте восстановим наш файл до состояния последнего коммита. 73 | 74 | 75 | ``` 76 | git restore hello.html 77 | git status 78 | ``` 79 | 80 | 81 | 82 | ```git 83 | ==include[output/13-03.txt] 84 | ``` 85 | 86 | 87 | Наша рабочая директория опять чиста. 88 | -------------------------------------------------------------------------------- /pages/uk/amending_commits.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "17. Внесення змін до комітів" 3 | --- 4 | 5 | ### Цілі 6 | 7 | - Навчитися змінювати існуючі коміти. 8 | 9 | ## _01_ Змініть сторінку, а потім зробіть коміт 10 | 11 | Додайте в сторінку коментар автора. 12 | 13 | 14 | ```html 15 | →← 16 | 17 | 18 | 19 | 20 |

Hello, World!

21 | 22 | 23 | ``` 24 | 25 | 26 | 27 | ``` 28 | git add hello.html 29 | git commit -m "Added copyright statement" 30 | git log 31 | ``` 32 | 33 | 34 | 35 | ```git 36 | ==include[output/17-01.txt] 37 | ``` 38 | 39 | 40 | ## _02_ Ой... необхідний email 41 | 42 | Однак після створення коміту ви розумієте, що будь-який хороший коментар повинен включати електронну пошту автора. Оновіть сторінку `hello.html`, включивши в неї email. 43 | 44 | 45 | ```html 46 | 47 | 48 | 49 | 50 | 51 |

Hello, World!

52 | 53 | 54 | ``` 55 | 56 | 57 | ## _03_ Змініть попередній коміт 58 | 59 | Ми дійсно не хочемо створювати окремий коміт тільки заради електронної пошти. Змінімо попередній коміт, включивши в нього адресу електронної пошти. 60 | 61 | 62 | ``` 63 | git add hello.html 64 | git commit --amend -m "Added copyright statement with email" 65 | ``` 66 | 67 | 68 | 69 | ```git 70 | ==include[output/17-02.txt] 71 | ``` 72 | 73 | 74 | ## _04_ Перегляд історії 75 | 76 | 77 | ``` 78 | git log 79 | ``` 80 | 81 | 82 | 83 | ```git 84 | ==include[output/17-03.txt] 85 | ``` 86 | 87 | 88 | Ми можемо побачити, що оригінальний коміт «автор» замінений на коміт «автор/email». Цього ж ефекту можна досягти шляхом відкочування останнього коміту в гілці, і повторного коміту нових змін. -------------------------------------------------------------------------------- /pages/ru/amending_commits.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "17. Внесение изменений в коммиты" 3 | --- 4 | 5 | ### Цели 6 | 7 | - Научиться изменять существующие коммиты. 8 | 9 | ## _01_ Измените страницу, а затем сделайте коммит 10 | 11 | Добавьте в страницу комментарий автора. 12 | 13 | 14 | ```html 15 | →← 16 | 17 | 18 | 19 | 20 |

Hello, World!

21 | 22 | 23 | ``` 24 | 25 | 26 | 27 | ``` 28 | git add hello.html 29 | git commit -m "Added copyright statement" 30 | git log 31 | ``` 32 | 33 | 34 | 35 | ```git 36 | ==include[output/17-01.txt] 37 | ``` 38 | 39 | 40 | ## _02_ Ой... необходим email 41 | 42 | Однако после создания коммита вы понимаете, что любой хороший комментарий должен включать электронную почту автора. Обновите страницу `hello.html`, включив в нее email. 43 | 44 | 45 | ```html 46 | 47 | 48 | 49 | 50 | 51 |

Hello, World!

52 | 53 | 54 | ``` 55 | 56 | 57 | ## _03_ Измените предыдущий коммит 58 | 59 | Мы действительно не хотим создавать отдельный коммит только ради электронной почты. Давайте изменим предыдущий коммит, включив в него адрес электронной почты. 60 | 61 | 62 | ``` 63 | git add hello.html 64 | git commit --amend -m "Added copyright statement with email" 65 | ``` 66 | 67 | 68 | 69 | ```git 70 | ==include[output/17-02.txt] 71 | ``` 72 | 73 | 74 | ## _04_ Просмотр истории 75 | 76 | 77 | ``` 78 | git log 79 | ``` 80 | 81 | 82 | 83 | ```git 84 | ==include[output/17-03.txt] 85 | ``` 86 | 87 | 88 | Мы можем увидеть, что оригинальный коммит «автор» заменен коммитом «автор/email». Этого же эффекта можно достичь путем сброса последнего коммита в ветке, и повторного коммита новых изменений. 89 | -------------------------------------------------------------------------------- /pages/pt-BR/undoing_staged_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "13. Descartando mudanças no stage (antes do commit)" 3 | --- 4 | 5 | ### Metas 6 | 7 | - Aprender como desfazer mudanças que já estão no stage. 8 | 9 | ## _01_ Edite o arquivo e adicione as mudanças ao stage 10 | 11 | Faça mudanças ao arquivo `hello.html` na forma de um comentário indesejado. 12 | 13 | 14 | ```html 15 | 16 | 17 | →← 18 | 19 | 20 |

Hello, World!

21 | 22 | 23 | ``` 24 | 25 | 26 | Adicione o arquivo modificado ao stage. 27 | 28 | 29 | ``` 30 | git add hello.html 31 | ``` 32 | 33 | 34 | ## _02_ Verifique o status 35 | 36 | Verifique o status da mudança indesejada. 37 | 38 | 39 | ``` 40 | git status 41 | ``` 42 | 43 | 44 | 45 | ```git 46 | ==include[output/13-01.txt] 47 | ``` 48 | 49 | 50 | O status mostra que a mudança está no stage e pronta para um commit; 51 | 52 | ## _03_ Restaurar o índice 53 | 54 | O comando `restore` com o sinalizador `--staged` limpa a área de preparação. 55 | 56 | 57 | ``` 58 | git restore --staged hello.html 59 | ``` 60 | 61 | 62 | 63 | ```git 64 | ==include[output/13-02.txt] 65 | ``` 66 | 67 | 68 | O comando `restore` com a opção `--staged` não altera o diretório de trabalho. Portanto, o diretório de trabalho ainda contém comentários indesejados. No entanto, você deve ter cuidado, pois o comando `restore` sem o sinalizador `--staged` também eliminará as alterações no diretório de trabalho. 69 | 70 | ## _04_ Mudar para o estado do último commit 71 | 72 | Vamos restaurar nossa árvore de trabalho para o estado do último commit. 73 | 74 | 75 | ``` 76 | git restore hello.html 77 | git status 78 | ``` 79 | 80 | 81 | 82 | ```git 83 | ==include[output/13-03.txt] 84 | ``` 85 | 86 | 87 | Nosso diretório de trabalho está limpo novamente. 88 | -------------------------------------------------------------------------------- /pages/en/undoing_committed_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "14. Cancelling commits" 3 | --- 4 | 5 | ### Goals 6 | 7 | - Learn how to undo commits to the local repository. 8 | 9 | ## _01_ Cancelling commits 10 | 11 | Sometimes you realize that the new commits are wrong, and you want to cancel them. There are several ways to handle the issue, and we use the safest here. 12 | 13 | To cancel the commit we will create a new commit, cancelling the unwanted changes. 14 | 15 | ## _02_ Edit the file and make a commit 16 | 17 | Replace `hello.html` with the following file. 18 | 19 | 20 | ```html 21 | 22 | 23 | 24 | 25 |

Hello, World!

26 | →← 27 | 28 | 29 | ``` 30 | 31 | 32 | 33 | ``` 34 | git add hello.html 35 | git commit -m "Oops, we didn't want this commit" 36 | ``` 37 | 38 | 39 | ## _03_ Make a commit with new changes that discard previous changes 40 | 41 | To cancel the commit, we need to create a commit that deletes the changes saved by unwanted commit. 42 | 43 | 44 | ``` 45 | git revert HEAD 46 | ``` 47 | 48 | 49 | Go to the editor, where you can edit the default commit message or leave it as is. Save and close the file. 50 | 51 | You will see: 52 | 53 | 54 | ```git 55 | ==include[output/14-01.txt] 56 | ``` 57 | 58 | 59 | Since we have cancelled the last commit, we can use `HEAD` as the argument for cancelling. We may cancel any random commit in history, pointing out its hash value. 60 | 61 | ## _04_ Check the log 62 | 63 | Checking the log shows the unwanted cancellations and commits in our repository. 64 | 65 | 66 | ``` 67 | git log 68 | ``` 69 | 70 | 71 | 72 | ```git 73 | ==include[output/14-02.txt] 74 | ``` 75 | 76 | 77 | This technique can be applied to any commit (however there may be conflicts). It is safe to use even in public branches of remote repositories. 78 | 79 | ## _05_ Next 80 | 81 | Next let us look at the technique that can be used to remove the last commit from the history of the repository. 82 | -------------------------------------------------------------------------------- /pages/uk/undoing_committed_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "14. Скасування комітів" 3 | --- 4 | 5 | ### Цілі 6 | 7 | - Навчитися скасовувати коміти в локальному репозиторії. 8 | 9 | ## _01_ Скасування комітів 10 | 11 | Буває так, що ви робите коміт, а тоді розумієте, що допустили помилку, і хочете його скасувати. Є кілька способів вирішити цю проблему, я покажу вам найбезпечніший. 12 | 13 | Ми скасуємо коміт шляхом створення нового коміту, що скасовує небажані зміни. 14 | 15 | ## _02_ Змініть файл і зробіть коміт 16 | 17 | Змініть файл `hello.html` на наступний. 18 | 19 | 20 | ```html 21 | 22 | 23 | 24 | 25 |

Hello, World!

26 | →← 27 | 28 | 29 | ``` 30 | 31 | 32 | 33 | ``` 34 | git add hello.html 35 | git commit -m "Oops, we didn't want this commit" 36 | ``` 37 | 38 | 39 | ## _03_ Зробіть коміт з новими змінами, що скасовують попередні 40 | 41 | Щоб скасувати коміт, нам необхідно зробити коміт, що видаляє зміни, збережені небажаним комітом. 42 | 43 | 44 | ``` 45 | git revert HEAD 46 | ``` 47 | 48 | 49 | Перейдіть у редактор, де ви можете відредагувати коміт-повідомлення за замовчуванням або залишити все як є. Збережіть і закрийте файл. Ви побачите: 50 | 51 | 52 | ```git 53 | ==include[output/14-01.txt] 54 | ``` 55 | 56 | 57 | Через те що ми скасовували останній коміт, ми змогли використати `HEAD` як посилання на коміт для скасування. Ми можемо скасувати будь-який довільний коміт в історії, вказавши його хеш. 58 | 59 | ## _04_ Перевірте лог 60 | 61 | Перевірка логу показує небажані та скасовані коміти у нашому репозиторії. 62 | 63 | 64 | ``` 65 | git log 66 | ``` 67 | 68 | 69 | 70 | ```git 71 | ==include[output/14-02.txt] 72 | ``` 73 | 74 | 75 | Ця техніка працюватиме з будь-яким комітом (хоча, можливо, виникнуть конфлікти). Вона безпечна у використанні навіть у публічних гілках віддалених репозиторіїв. 76 | 77 | ## _05_ Далі 78 | 79 | Далі подивімось на техніку, яка може бути використана для видалення останніх комітів з історії репозиторія. 80 | -------------------------------------------------------------------------------- /pages/pt-BR/undoing_committed_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "14. Desfazendo commits" 3 | --- 4 | 5 | ### Metas 6 | 7 | - Aprender como desfazer commits no repositório local. 8 | 9 | ## _01_ Desfazendo commits 10 | 11 | Algumas vezes você percebe que os novos commits estão errados e você quer desfazê-los. Existem várias maneiras de resolver esse problema, mas nós usamos a mais segura aqui. 12 | 13 | Para desfazer o commit, vamos criar um novo commit desfazendo as modificações não desejadas. 14 | 15 | ## _02_ Edite o arquivo e faça um commit 16 | 17 | Substitua o arquivo `hello.html` com o seguinte. 18 | 19 | 20 | ```html 21 | 22 | 23 | 24 | 25 |

Hello, World!

26 | →← 27 | 28 | 29 | ``` 30 | 31 | 32 | 33 | ``` 34 | git add hello.html 35 | git commit -m "Oops, we didn't want this commit" 36 | ``` 37 | 38 | 39 | ## _03_ Faça um commit com as novas modificações que desfazem as modificações anteriores 40 | 41 | Para desfazer o commit, precisamos criar um commit que deleta as modificações feitas pelo commit indesejado. 42 | 43 | 44 | ``` 45 | git revert HEAD 46 | ``` 47 | 48 | 49 | Vá para o editor, onde você consegue editar a mensagem padrão do commit ou deixá-la como está. Salve e feche o arquivo. 50 | 51 | Você verá: 52 | 53 | 54 | ```git 55 | ==include[output/14-01.txt] 56 | ``` 57 | 58 | 59 | Já que desfizemos o último commit, nós podemos usar `HEAD` como o argumento para desfazê-lo. Nós podemos cancelar qualquer commit no histórico, apontando seu hash. 60 | 61 | ## _04_ Confira o log 62 | 63 | Conferir o log mostra os cancelamentos e commits indesejados no nosso repositório. 64 | 65 | 66 | ``` 67 | git log 68 | ``` 69 | 70 | 71 | 72 | ```git 73 | ==include[output/14-02.txt] 74 | ``` 75 | 76 | 77 | Essa técnica pode ser aplicada para qualquer commit (mas podem surgir conflitos). É seguro usá-la mesmo em branches públicos de repositórios remotos. 78 | 79 | ## _05_ Próximo 80 | 81 | A seguir vamos olhar a técnica que pode ser usada para remover o último commit do histórico do repositório. 82 | -------------------------------------------------------------------------------- /pages/uk/creating_a_conflict.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "24. Створення конфлікту" 3 | --- 4 | 5 | ### Цілі 6 | 7 | - Створення конфліктуючих змін в гілці `main`. 8 | 9 | Коли ви об'єднуєте дві гілки, Git намагається перенести зміни з однієї гілки до іншої. Якщо в обох гілках була змінена однакова частина файлу, Git не зможе об'єднати зміни автоматично. У цьому випадку Git повідомить про конфлікт і попросить вас вирішити його вручну. У цьому уроці ми змоделюємо конфлікт, а потім навчимося його вирішувати. 10 | 11 | У реальному житті конфлікти злиття трапляються регулярно під час роботи в команді. Наприклад, ви і ваш колега почали працювати над двома різними фічами, які впливають на одні й ті ж файли. Ваш колега закінчив свою роботу першим і об'єднав свої зміни в гілку `main`. Тепер ви також хочете об'єднати свої зміни до гілки `main`. Але гілка `main` тепер відрізняється від тієї, над якою ви починали працювати — у ній з'явився новий код, доданий вашим колегою. Ймовірно, Git не зможе об'єднати ваші зміни автоматично і попросить допомоги від людини. 12 | 13 | ## _01_ Поверніться у `main` і створіть конфлікт 14 | 15 | Пам'ятаєте, в нашій гілці `main` сторінка все ще називається `hello.html`? Поверніться до гілки `main` і внесіть наступні зміни: 16 | 17 | 18 | ``` 19 | git switch main 20 | ``` 21 | 22 | 23 | 24 | ```html 25 | 26 | 27 | 28 | →Hello World Page← 29 | 30 | 31 |

Hello, World!

32 | →

Let's learn Git together.

← 33 | 34 | 35 | ``` 36 | 37 | 38 | 39 | ``` 40 | git add hello.html 41 | git commit -m "Added meta title" 42 | ``` 43 | 44 | 45 | ## _02_ Перегляд гілок 46 | 47 | 48 | ``` 49 | git log --all --graph 50 | ``` 51 | 52 | 53 | 54 | ```git 55 | ==include[output/24-01.txt] 56 | ``` 57 | 58 | 59 | Після коміту «Added README» гілка `main` була об'єднана з гілкою `style`, але зараз в `main` є додатковий коміт, що не був злитий із `style`. 60 | 61 | ## _03_ Далі 62 | 63 | Остання зміна в `main` конфліктує з деякими змінами в `style`. У наступному кроці ми вирішимо цей конфлікт. -------------------------------------------------------------------------------- /pages/ru/undoing_committed_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "14. Отмена коммитов" 3 | --- 4 | 5 | ### Цели 6 | 7 | - Научиться отменять коммиты в локальном репозитории. 8 | 9 | ## _01_ Отмена коммитов 10 | 11 | Иногда вы понимаете, что новые коммиты являются неверными, и хотите их отменить. Есть несколько способов решения этого вопроса, здесь мы будем использовать самый безопасный. 12 | 13 | Мы отменим коммит путем создания нового коммита, отменяющего нежелательные изменения. 14 | 15 | ## _02_ Измените файл и сделайте коммит 16 | 17 | Измените файл `hello.html` на следующий. 18 | 19 | 20 | ```html 21 | 22 | 23 | 24 | 25 |

Hello, World!

26 | →← 27 | 28 | 29 | ``` 30 | 31 | 32 | 33 | ``` 34 | git add hello.html 35 | git commit -m "Oops, we didn't want this commit" 36 | ``` 37 | 38 | 39 | ## _03_ Сделайте коммит с новыми изменениями, отменяющими предыдущие 40 | 41 | Чтобы отменить коммит, нам необходимо сделать коммит, который удаляет изменения, сохраненные нежелательным коммитом. 42 | 43 | 44 | ``` 45 | git revert HEAD 46 | ``` 47 | 48 | 49 | Перейдите в редактор, где вы можете отредактировать коммит-сообщение по умолчанию или оставить все как есть. Сохраните и закройте файл. Вы увидите: 50 | 51 | 52 | ```git 53 | ==include[output/14-01.txt] 54 | ``` 55 | 56 | 57 | Так как мы отменили самый последний произведенный коммит, мы смогли использовать метку `HEAD` в качестве аргумента для отмены коммита. Мы можем отменить любой произвольной коммит в истории, указав его хеш. 58 | 59 | ## _04_ Проверьте лог 60 | 61 | Проверка лога показывает нежелательные и отмененные коммиты в наш репозиторий. 62 | 63 | 64 | ``` 65 | git log 66 | ``` 67 | 68 | 69 | 70 | ```git 71 | ==include[output/14-02.txt] 72 | ``` 73 | 74 | 75 | Эта техника будет работать с любым коммитом (хотя, возможно, возникнут конфликты). Она безопасна в использовании даже в публичных ветках удаленных репозиториев. 76 | 77 | ## _05_ Далее 78 | 79 | Далее давайте посмотрим на технику, которая может быть использована для удаления последних коммитов из истории репозитория. 80 | -------------------------------------------------------------------------------- /pages/ru/creating_a_conflict.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "24. Создание конфликта" 3 | --- 4 | 5 | ### Цели 6 | 7 | - Создание конфликтующих изменений в ветке `main`. 8 | 9 | При слиянии двух веток Git пытается перенести изменения из одной ветки в другую. Если в обеих ветках была изменена одна и та же часть файла, Git может не справиться с автоматическим слиянием изменений. В этом случае Git сообщит о конфликте и попросит разрешить его вручную. В этом уроке мы смоделируем конфликт, а затем научимся его разрешать. 10 | 11 | В реальной жизни конфликты слияния регулярно возникают при работе в команде. Например, вы и ваш коллега начали работать над двумя разными фичами, затрагивающими одни и те же файлы. Ваш коллега закончил работу первым и слил свои изменения в ветку `main`. Теперь вы хотите слить свои изменения в ветку `main`. Но ветка `main` теперь отличается от той, с которой вы начинали работать в начале — в ней появился новый код, присланный вашим коллегой. Вероятно, Git не сможет автоматически объединить ваши изменения и попросит помощи человека. 12 | 13 | ## _01_ Вернитесь в `main` и создайте конфликт 14 | 15 | Помните, что в нашей ветке `main` страница по-прежнему называется `hello.html`? Переключитесь обратно на ветку `main` и внесите следующие изменения: 16 | 17 | 18 | ``` 19 | git switch main 20 | ``` 21 | 22 | 23 | 24 | ```html 25 | 26 | 27 | 28 | →Hello World Page← 29 | 30 | 31 |

Hello, World!

32 | →

Let's learn Git together.

← 33 | 34 | 35 | ``` 36 | 37 | 38 | 39 | ``` 40 | git add hello.html 41 | git commit -m "Added meta title" 42 | ``` 43 | 44 | 45 | ## _02_ Просмотр веток 46 | 47 | 48 | ``` 49 | git log --all --graph 50 | ``` 51 | 52 | 53 | 54 | ```git 55 | ==include[output/24-01.txt] 56 | ``` 57 | 58 | 59 | После коммита «Added README» ветка `main` была объединена с веткой `style`, но в настоящее время в `main` есть дополнительный коммит, который не был слит с `style`. 60 | 61 | ## _03_ Далее 62 | 63 | Последнее изменение в `main` конфликтует с некоторыми изменениями в `style`. На следующем шаге мы решим этот конфликт. 64 | -------------------------------------------------------------------------------- /pages/en/creating_a_conflict.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "24. Creating a merge conflict" 3 | --- 4 | 5 | ### Goals 6 | 7 | - Create a conflicting change in the `main` branch. 8 | 9 | When you merge two branches, Git tries to move the changes from one branch to the other. If the same part of the file was changed in both branches, Git may not be able to combine the changes automatically. In this case, Git will report a conflict and ask you to resolve it manually. In this lesson, we will simulate a conflict and later learn how to resolve it. 10 | 11 | In real life merge conflicts happen regularly when working in the team. For example, you and your colleague started working on two different features, affecting the same files. Your colleague finished his work first and merged his changes to the `main` branch. Now you want to merge your own changes to the `main` branch as well. But the `main` branch is now different from the one you started working on—there is new code, submitted by your colleague. Most likely, Git will not be able to merge your changes automatically and will ask for human assistance. 12 | 13 | ## _01_ Switch back to the `main` and create conflict 14 | 15 | Remember, in our `main` branch, the page is still called `hello.html`? Switch back to the `main` branch and make the following changes: 16 | 17 | 18 | ``` 19 | git switch main 20 | ``` 21 | 22 | 23 | 24 | ```html 25 | 26 | 27 | 28 | →Hello World Page← 29 | 30 | 31 |

Hello, World!

32 | →

Let's learn Git together.

← 33 | 34 | 35 | ``` 36 | 37 | 38 | 39 | ``` 40 | git add hello.html 41 | git commit -m "Added meta title" 42 | ``` 43 | 44 | 45 | ## _02_ View branches 46 | 47 | 48 | ``` 49 | git log --all --graph 50 | ``` 51 | 52 | 53 | 54 | ```git 55 | ==include[output/24-01.txt] 56 | ``` 57 | 58 | 59 | After the "Added README" commit, the `main` branch has been merged with the `style` branch, but there is an additional `main` commit, which was not merged back to the `style` branch. 60 | 61 | ## _03_ Next 62 | 63 | The last change in `main` conflicts with some changes in the `style` branch. In the next step we will solve this conflict. 64 | -------------------------------------------------------------------------------- /pages/en/committing_changes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "7. Committing the changes" 3 | --- 4 | 5 | ### Goals 6 | 7 | - Learn to commit to the repository. 8 | 9 | ## _01_ Committing changes 10 | 11 | Well, enough about staging. Let's commit the staged changes to the repository. 12 | 13 | When you previously used `git commit` for committing the first `hello.html` version to the repository, you included the `-m` flag that gives a comment on the command line. The `commit` command allows interactively editing comments for the commit. And now, let's see how it works. 14 | 15 | If you omit the `-m` flag from the command line, Git will pop you into the editor of your choice from the list (in order of priority): 16 | 17 | - `GIT_EDITOR` environment variable; 18 | - `core.editor` configuration setting; 19 | - `VISUAL` environment variable; 20 | - `EDITOR` environment variable. 21 | 22 | > I have the `EDITOR` variable set to `vim`. If you prefer GUI editor, it's now possible to use VS Code as a [Git editor](https://code.visualstudio.com/docs/sourcecontrol/overview#_vs-code-as-git-editor). 23 | 24 | Let us commit now and check the status. 25 | 26 | 27 | ``` 28 | git commit 29 | ``` 30 | 31 | 32 | You will see the following in your editor: 33 | 34 | 35 | ```git 36 | | 37 | # Please enter the commit message for your changes. Lines starting 38 | # with '#' will be ignored, and an empty message aborts the commit. 39 | # 40 | # On branch main 41 | # Changes to be committed: 42 | # modified: hello.html 43 | # 44 | ``` 45 | 46 | 47 | On the first line, enter the comment: `Added h1 tag`. Save the file and exit the editor (to do it in default editor, press ESC and then type `:wq` and hit Enter). You should see: 48 | 49 | 50 | ```git 51 | ==include[output/07-01.txt] 52 | ``` 53 | 54 | 55 | "Waiting for Emacs…" is obtained from the `emacsclient` program sending the file to a running emacs program and waiting for it to be closed. The rest of the data is the standard commit messages. 56 | 57 | ## _02_ Checking the status 58 | 59 | At the end let us check the status. 60 | 61 | 62 | ``` 63 | git status 64 | ``` 65 | 66 | 67 | You will see: 68 | 69 | 70 | ```git 71 | ==include[output/07-02.txt] 72 | ``` 73 | 74 | 75 | The working directory is clean, you can continue working. 76 | -------------------------------------------------------------------------------- /pages/en/getting_old_versions.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: "10. Getting older versions" 3 | --- 4 | 5 | ### Goals 6 | 7 | - Learn how to check out any previous version into the working directory. 8 | 9 | Git make time traveling possible, at least for your project. The `checkout` command will update your working directory to any previous commit. 10 | 11 | ## _01_ Getting hashes of the previous commit 12 | 13 | 14 | ``` 15 | git log 16 | ``` 17 | 18 | 19 | 20 | ```git 21 | ==include[output/10-01.txt] 22 | ``` 23 | 24 | 25 | Check the log data and find the hash of the initial commit. You will find it in the last line of the output. Use the hash (its first 7 characters are enough) in the command below. After that check the contents of the `hello.html` file. 26 | 27 | 28 | ``` 29 | git checkout 30 | cat hello.html 31 | ``` 32 | 33 | 34 | > Many Git commands accept commit hashes as arguments. Commit hashes will vary from repository to repository, so when you see a command with the `` mark, it means that you need to substitute it with the actual hash from your repository. 35 | 36 | You will see: 37 | 38 | 39 | ```git 40 | ==include[output/10-02.txt] 41 | ``` 42 | 43 | 44 | Note that the current content of the `hello.html` file is the content that we started with in the very beginning. 45 | 46 | ## _02_ Returning to the latest version in the `main` branch 47 | 48 | To return to the latest version of our code, we need to switch to the default `main` branch. We can use the `switch` command to switch between branches. 49 | 50 | > The `checkout` command has been a swiss army knife in the world of Git for a long time. It has tons of various options that let you run entirely different things: switch branches, reset code, etc. At some point, the Git team decided to split the command into several commands. The `switch` command is one of them—its sole purpose is to switch between branches. The `checkout` command is still available, but it is no longer recommended to use it for switching branches. 51 | 52 | 53 | ``` 54 | git switch main 55 | cat hello.html 56 | ``` 57 | 58 | 59 | You will see: 60 | 61 | 62 | ```git 63 | ==include[output/10-03.txt] 64 | ``` 65 | 66 | 67 | `main` is the name of the default branch. By switching to a branch, you go to its latest version. 68 | --------------------------------------------------------------------------------