From fac91c14f28e20fa932c9b612051beaf62695918 Mon Sep 17 00:00:00 2001 From: subi Date: Fri, 22 Apr 2022 17:30:51 +0800 Subject: [PATCH 1/6] translate part of day35 --- zh_tw/Days/day35.md | 36 +++++++++++++++++------------------- 1 file changed, 17 insertions(+), 19 deletions(-) diff --git a/zh_tw/Days/day35.md b/zh_tw/Days/day35.md index e7d858e..ee37662 100644 --- a/zh_tw/Days/day35.md +++ b/zh_tw/Days/day35.md @@ -7,19 +7,19 @@ cover_image: null canonical_url: null id: 1049041 --- -## The Big Picture: Git - Version Control +## 概述: Git - 版本控制 -Before we get into git, we need to understand what version control is and why? In this opener for Git, we will take a look at what version control is, the basics of git. +在開始 Git 工具之前, 我們需要瞭解什麼是版本控制? 為什麼要使用它? 作為 Git 教學的開端, 我們會粗略帶過何謂版本控制和 Git 基礎概念. -### What is Version Control? +### 甚麼是版本控制? -Git is not the only version control system so here we want to cover what options and what methodologies are available around version control. +由於 Git 並不是唯一的版本控制工具，所以在這裡將會涵蓋版本控制有哪些選項和使用方法. -The most obvious and a big benefit of Version Control is the ability to track a project's history. We can look back over this repository using `git log` and see that we have many commits and many comments and what has happened so far in the project. Don't worry we will get into the commands later. Now think if this was an actual software project full of source code and multiple people are committing to our software at different times, different authors and then reviewers all are logged here so that we know what has happened, when, by whom and who reviewed. +版本控制最明顯且重要的功能是可以追蹤專案的歷史. 我們可以利用`git log` 指令回顧倉儲內,過去專案提交的紀錄和註解. 無須擔心,稍後就會說明要如何下指令. 讓我們想想, 如果這是實際的軟體專案, 有著滿滿的原始碼,許多開發者在不同的時間點提交軟體, 不同的作者和審稿人在這裡做紀錄, 我們得以知道發生了什麼事, 何時發生, 又是誰在審稿. ![](Images/Day35_Git1.png) -Version Control before it was cool, would have been something like manually creating a copy of your version before you made changes. It might be that you also comment out old useless code with the just in case mentality. +版本控制很炫, 就像是你在更動程式碼前手動複製一份檔案一樣. 你可能會為了以防萬一, 註解掉無用的舊程式碼, 而你隨時可以還原. ![](Images/Day35_Git2.png) @@ -75,11 +75,11 @@ Then we want to go ahead and commit our files, we do this with the `git commit - ![](Images/Day35_Git8.png) -We can now see what has happened within the history of the project. Using the `git log` command. +現在我們可以透過 `git log` 指令, 知道專案的歷史和發生何事. ![](Images/Day35_Git9.png) -We can also check the status of our repository by using `git status` this shows we have nothing to commit and we can add a new file called samplecode.ps1. If we then run the same `git status you will see that we file to be committed. +我們還能透過 `git status` 指令來檢查倉儲的狀態, 如下圖的前三行, 這表示我們還沒有提交檔案. 如果我們添加一個新檔 samplecode.ps1 , 再次輸入 `git status` 的時候, 會看到我們準備要提交的文件. ![](Images/Day35_Git10.png) @@ -115,20 +115,18 @@ But then equally we will want to move forward as well and we can do this the sam ![](Images/Day35_Git18.png) -The TLDR; +摘要 (TLDR) -- Tracking a projects history -- Managing multiple versions of a project -- Sharing code amongst developers and a wider scope of teams and tools -- Coordinating teamwork -- Oh and there is some time travel! +- 追蹤專案的歷史 +- 管理一個專案內不同版本的程式碼 +- 在開發人員在開發人員和更廣泛的團隊和工具之間共享程式碼 +- 協調團隊合作 +- 哦，還有一些做時間旅行! -This might have seemed a jump around but hopefully, you can see without really knowing the commands used the powers and the big picture behind Version Control. - -Next up we will be getting git installed and set up on your local machine and diving a little deeper into some other use cases and commands that we can achieve in Git. - +這個章節的內容似乎跳的有些快, 希望在尚未解說 Git 指令的強大之前, 你能對版本控制的功能有大致上的了解. +下一章,我們將會在你的電腦安裝和設置 Git ,並且更深入的解說 Git 的命令和使用案例, 以及 Git 能做到什麼. ## Resources @@ -139,5 +137,5 @@ Next up we will be getting git installed and set up on your local machine and di - [Git and GitHub for Beginners - Crash Course](https://www.youtube.com/watch?v=RGOj5yH7evk&t=8s) - [Complete Git and GitHub Tutorial](https://www.youtube.com/watch?v=apGV9Kg7ics) -See you on [Day 36](day36.md) +See you on [第 36 天](day36.md) From c441c0c711505f9b57688cc5b25c5fea81155d60 Mon Sep 17 00:00:00 2001 From: subineru Date: Sat, 23 Apr 2022 02:11:53 +0800 Subject: [PATCH 2/6] translate day35.md v2 --- zh_tw/Days/day35.md | 30 +++++++++++++++--------------- zh_tw/Days/day57.md | 4 ++-- zh_tw/Days/day78.md | 2 +- zh_tw/Days/day80.md | 4 ++-- 4 files changed, 20 insertions(+), 20 deletions(-) diff --git a/zh_tw/Days/day35.md b/zh_tw/Days/day35.md index ee37662..13b9492 100644 --- a/zh_tw/Days/day35.md +++ b/zh_tw/Days/day35.md @@ -9,43 +9,43 @@ id: 1049041 --- ## 概述: Git - 版本控制 -在開始 Git 工具之前, 我們需要瞭解什麼是版本控制? 為什麼要使用它? 作為 Git 教學的開端, 我們會粗略帶過何謂版本控制和 Git 基礎概念. +在開始 Git 工具之前, 我們需要瞭解什麼是版本控制,還有為什麼要使用它. 作為 Git 教學的開端, 我們會稍微帶過何謂版本控制以及 Git 基礎概念. ### 甚麼是版本控制? -由於 Git 並不是唯一的版本控制工具，所以在這裡將會涵蓋版本控制有哪些選項和使用方法. +由於 Git 並不是唯一的版本控制工具，所以這一節將會涵蓋版本控制有哪些選項和使用方法. -版本控制最明顯且重要的功能是可以追蹤專案的歷史. 我們可以利用`git log` 指令回顧倉儲內,過去專案提交的紀錄和註解. 無須擔心,稍後就會說明要如何下指令. 讓我們想想, 如果這是實際的軟體專案, 有著滿滿的原始碼,許多開發者在不同的時間點提交軟體, 不同的作者和審稿人在這裡做紀錄, 我們得以知道發生了什麼事, 何時發生, 又是誰在審稿. +版本控制最明顯且重要的功能是可以追蹤專案的歷史. 我們可以利用`git log` 指令回顧儲存庫(repository)內,過去專案提交的紀錄和註解. 讓我們想想, 如果這是實際的軟體專案, 有滿滿的原始碼, 而且許多開發者在不同的時間點提交軟體, 不同的作者和審稿人在這裡做紀錄, 有了歷史追蹤, 我們得以知道發生了什麼事, 何時發生, 又是誰在審稿. ![](Images/Day35_Git1.png) -版本控制很炫, 就像是你在更動程式碼前手動複製一份檔案一樣. 你可能會為了以防萬一, 註解掉無用的舊程式碼, 而你隨時可以還原. +版本控制很酷, 就像你在異動程式碼前, 手動複製一份. 你可能會為了以防萬一, 註解掉無用的舊程式碼, 而你隨時可以還原. ![](Images/Day35_Git2.png) -I have started using version control over not just source code but pretty much anything, talks about projects like this (90DaysOfDevOps) because why would you not want that rollback and log of everything that has gone on. +我不僅僅對原始碼做版本控制, 我甚至幾乎對所有的東西做版本控制, 就像談到這個 90DaysOfDevOps 這個專案, 當你不小心刪到你想要的文字, 然到不會想要擁有歷史紀錄和做資料回朔? -However, a big disclaimer **Version Control is not a Backup!** +然而, 在此聲明 **版本控制不是備份!** -Another benefit of Version Control is the ability to manage multiple versions of a project, Let's create an example, we have a free app that is available on all operating systems and then we have a paid-for app also available on all operating systems. The majority of the code is shared between both applications. We could copy and paste our code each commit to each app but that is going to be very messy especially as you scale your development to more than just one person, also mistakes will be made. +版本控制的另外一個好處是它可以對一個專案管理很多版本, 舉一個例子, 我們分別有一個免費版(FREE)和付費版(PAID)的程式, 兩者都能在所有的作業系統上面執行, 而且共享大部分的程式碼, 每次提交程式碼的時候, 都會複製並貼上到所有程式. 這樣做將會非常混亂, 尤其是當程式開發不只一個人的時候, 將會更容易發生錯誤. -The premium app is where we are going to have additional features, let's call them premium commits, the free edition will just contain the normal commits. +白金方案(Premium)的軟體擁有額外的功能, 在這裡我們稱為 premium commits, 免費版只包含 normal commits. -The way this is achieved in Version Control is through branching. +在版本控制中, 想要處理上述的問題就是透過分支(Branching). ![](Images/Day35_Git3.png) -Branching allows for two code streams for the same app as we stated above. But we will still want new features that land in our source code free version to be in our premium and to achieve this we have something called merging. +如上所述, 分支(Branching) 允許同一支程式擁有兩個程式碼流. 當我們想要把免費版本的額外功能變成白金付費方案的時候, 我們可以透過合併(merging). ![](Images/Day35_Git4.png) -Now, this same easy but merging can be complicated because you could have a team working on the free edition and you could have another team working on the premium paid for version and what if both change code that affects aspects of the overall code. Maybe a variable gets updated and breaks something. Then you have a conflict that breaks one of the features. Version Control cannot fix the conflicts that are down to you. But version control allows this to be easily managed. +現在, 合併(merging) 既可以簡單但也可以複雜, 如果你有一個團隊在免費版工作, 另一個團隊在白金付費版工作, 兩個團隊同時更改會影響整個程式碼的行為. 說不定只是更新了某個變數導致破壞某樣功能. 版本控制無法解決上述的衝突, 但是讓你更容易更輕鬆的管理. -The primary reason if you have not picked up so far for version control, in general, is the ability to collaborate. The ability to share code amongst developers and when I say code as I said before more and more we are seeing much more use cases for other reasons to use source control, maybe its a joint presentation you are working on with a colleague or a 90DaysOfDevOps challenge where you have the community offering their corrections and updates throughout the project. +目前為止, 我看到沒有使用版本控制的主要理由就是開發者間的協調能力夠好. 但是有越來越多的案例, 開發者之間正在用版本控制來分享程式碼, 也許是你和你的同事加入一個簡報, 或是你在加入一個社群, 對一個項目共向修正和更新, 就像這個儲存庫 90DaysOfDevOps. -Without version control how did teams of software developers even handle this? I find it hard enough when I am working on my projects to keep track of things. I expect they would split out the code into each functional module. Maybe a little part of the puzzle then was bringing the pieces together and then problems and issues before anything would get released. +我無法想像軟體開發團隊在沒有版本控制的情況下要怎麼處理問題? 當在我追蹤我自己的項目時, 我就發現他已經夠難了. 我希望團隊們能先把程式碼拆分一小部分的函數, 解決每一小部分的函數的問題之後再予與發佈, 事情將簡單的多. -With version control, we have a single source of truth. We might all still work on different modules but it enables us to collaborate better. +也就是說, 有了版本控制, 我們才有辦法做統整. 也許團隊們正在對不同的模組上進行開發, 但是就能夠協同合作的更好. ![](Images/Day35_Git5.png) @@ -87,7 +87,7 @@ Add our new file using the `git add samplecode.ps1` command and then we can run ![](Images/Day35_Git11.png) -Then issue `git commit -m "My Second Commit"` command. +然後下 `git commit -m "My Second Commit"` 指令. ![](Images/Day35_Git12.png) diff --git a/zh_tw/Days/day57.md b/zh_tw/Days/day57.md index 471b82a..1b82dbf 100644 --- a/zh_tw/Days/day57.md +++ b/zh_tw/Days/day57.md @@ -2,7 +2,7 @@ title: '#90DaysOfDevOps - An intro to Terraform - Day 57' published: false description: 90DaysOfDevOps - An intro to Terraform -tags: "devops, 90daysofdevops, learning" +tags: 'devops, 90daysofdevops, learning' cover_image: null canonical_url: null id: 1048710 @@ -56,7 +56,7 @@ Another thing to mention is that there are also modules available, and this is s The Terraform workflow looks like this: (*taken from the terraform site*) -![](https://www.terraform.io/_next/static/images/how-tf-works-2-88c36cecdbf1d3a92cc3976dd85ff8ad.png?fit=max&fm=webp&q=80&w=2500) +![](Images/Day57_IAC3.png) ### Terraform vs Vagrant diff --git a/zh_tw/Days/day78.md b/zh_tw/Days/day78.md index ef78ebc..3e44f0c 100644 --- a/zh_tw/Days/day78.md +++ b/zh_tw/Days/day78.md @@ -23,7 +23,7 @@ Pull approach - If you are talking to thousands of microservices or systems and Once again we see YAML for configuration for Prometheus. -![](https://cdn.jsdelivr.net/gh/prometheus/prometheus@c34257d069c630685da35bcef084632ffd5d6209/documentation/images/architecture.svg) +![](Images/Day78_Monitoring7.png) Later on you are going to see how this looks when deployed into Kubernetes, in particular we have the **PushGateway** which pulls our metrics from our jobs/exporters. diff --git a/zh_tw/Days/day80.md b/zh_tw/Days/day80.md index 131ac6b..7fd8324 100644 --- a/zh_tw/Days/day80.md +++ b/zh_tw/Days/day80.md @@ -2,7 +2,7 @@ title: '#90DaysOfDevOps - ELK Stack - Day 80' published: false description: 90DaysOfDevOps - ELK Stack -tags: "devops, 90daysofdevops, learning" +tags: 'devops, 90daysofdevops, learning' cover_image: null canonical_url: null id: 1048746 @@ -34,7 +34,7 @@ On top of the above mentioned components you might also see Beats which are ligh - Kibana uses Elasticsearch DB to Explore, Visualize, and Share -![](https://www.guru99.com/images/tensorflow/082918_1504_ELKStackTut1.png) +![](Images/Day80_Monitoring8.png) [Picture taken from Guru99](https://www.guru99.com/elk-stack-tutorial.html) From fc724b2324f57b522d8ef164d716356ec9e9dcda Mon Sep 17 00:00:00 2001 From: subineru Date: Sat, 23 Apr 2022 20:54:46 +0800 Subject: [PATCH 3/6] translate day35(preliminary draft) --- zh_tw/Days/day35.md | 52 ++++++++++++++++++++++----------------------- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/zh_tw/Days/day35.md b/zh_tw/Days/day35.md index 13b9492..238b408 100644 --- a/zh_tw/Days/day35.md +++ b/zh_tw/Days/day35.md @@ -1,7 +1,7 @@ --- -title: '#90DaysOfDevOps - The Big Picture: Git - Version Control - Day 35' +title: '#90DaysOfDevOps - 概述: Git - 版本控制 - 第 35 天' published: false -description: 90DaysOfDevOps - The Big Picture Git - Version Control +description: 90DaysOfDevOps - 概述 Git - 版本控制 tags: 'devops, 90daysofdevops, learning' cover_image: null canonical_url: null @@ -23,59 +23,59 @@ id: 1049041 ![](Images/Day35_Git2.png) -我不僅僅對原始碼做版本控制, 我甚至幾乎對所有的東西做版本控制, 就像談到這個 90DaysOfDevOps 這個專案, 當你不小心刪到你想要的文字, 然到不會想要擁有歷史紀錄和做資料回朔? +我不僅對原始碼做版本控制, 甚至是幾乎對所有的東西做版本控制, 就像談到 90DaysOfDevOps 這個專案, 當你不小心刪到你想要的文字, 難道說不會想要擁有歷史紀錄和做資料回朔的機制? 然而, 在此聲明 **版本控制不是備份!** -版本控制的另外一個好處是它可以對一個專案管理很多版本, 舉一個例子, 我們分別有一個免費版(FREE)和付費版(PAID)的程式, 兩者都能在所有的作業系統上面執行, 而且共享大部分的程式碼, 每次提交程式碼的時候, 都會複製並貼上到所有程式. 這樣做將會非常混亂, 尤其是當程式開發不只一個人的時候, 將會更容易發生錯誤. +版本控制的另外一個好處是它可以對一個專案同時管理很多個版本, 舉一個例子, 我們分別有一個免費版(FREE)和付費版(PAID)的程式, 兩者都能在所有的作業系統上面執行, 而且共享大部分的程式碼, 每次提交程式碼的時候, 都會複製並貼上到其他程式. 這樣做是不是會非常混亂, 尤其是當程式開發不只一個人的時候, 更容易發生錯誤. 白金方案(Premium)的軟體擁有額外的功能, 在這裡我們稱為 premium commits, 免費版只包含 normal commits. -在版本控制中, 想要處理上述的問題就是透過分支(Branching). +在版本控制中, 想要處理上述的問題需要透過分支(Branching). ![](Images/Day35_Git3.png) -如上所述, 分支(Branching) 允許同一支程式擁有兩個程式碼流. 當我們想要把免費版本的額外功能變成白金付費方案的時候, 我們可以透過合併(merging). +如上所述, 分支(Branching) 允許同一支程式擁有兩個程式碼分流. 當我們想要把免費版本的額外功能變成白金付費方案的時候, 我們會透過合併(merging). ![](Images/Day35_Git4.png) -現在, 合併(merging) 既可以簡單但也可以複雜, 如果你有一個團隊在免費版工作, 另一個團隊在白金付費版工作, 兩個團隊同時更改會影響整個程式碼的行為. 說不定只是更新了某個變數導致破壞某樣功能. 版本控制無法解決上述的衝突, 但是讓你更容易更輕鬆的管理. +現在, 合併(merging) 既可以簡單但也可以複雜, 譬如說你有一個團隊在開發免費版, 另一個團隊在開發白金付費版, 兩個團隊同時改動會影響整個程式碼的代碼, 又或只是更新了某個變數導致破壞某樣功能. 版本控制無法解決上述的衝突, 但是讓你更容易更輕鬆的管理. -目前為止, 我看到沒有使用版本控制的主要理由就是開發者間的協調能力夠好. 但是有越來越多的案例, 開發者之間正在用版本控制來分享程式碼, 也許是你和你的同事加入一個簡報, 或是你在加入一個社群, 對一個項目共向修正和更新, 就像這個儲存庫 90DaysOfDevOps. +目前為止, 我看到沒有使用版本控制的主要理由就是開發者間的協調能力夠好. 但是有越來越多的案例, 開發者之間正在用版本控制來分享程式碼, 可能是你和你的同事加入一個簡報, 或是你加入一個社群, 對一個項目共向修正和更新, 就像這個儲存庫 90DaysOfDevOps. -我無法想像軟體開發團隊在沒有版本控制的情況下要怎麼處理問題? 當在我追蹤我自己的項目時, 我就發現他已經夠難了. 我希望團隊們能先把程式碼拆分一小部分的函數, 解決每一小部分的函數的問題之後再予與發佈, 事情將簡單的多. +我無法想像軟體開發團隊在沒有版本控制的情況下要怎麼處理問題? 當在我追蹤我自己的項目時, 我就發現他已經夠難了. 我希望團隊們能先把程式碼拆分一小部分的函數, 解決每一小部分函數的問題之後再予與發佈, 事情將簡單的多. -也就是說, 有了版本控制, 我們才有辦法做統整. 也許團隊們正在對不同的模組上進行開發, 但是就能夠協同合作的更好. +也就是說, 有了版本控制, 才有辦法做統整. 像是團隊們正在對不同的模組上進行開發, 這時就能夠協同合作的更好. ![](Images/Day35_Git5.png) -Another thing to mention here is that it's not just developers that can benefit from Version Control, it's all members of the team to have visibility but also tools all having awareness or leverage, Project Management tools can be linked here, tracking the work. We might also have a build machine for example Jenkins which we will talk about in another module. A tool that Builds and Packages the system, automating the deployment tests and metrics. +另外值得一提的事情是版本控制不只僅受益於開發者, 團隊中的所有成員和其他工具也都有了能見度, 一些專案管理工具可以跟 git 建立鏈結, 跟蹤工作的狀況. 最知名的例子就是 Jenkinus. 一個可以建置、打包、自動測試和佈署軟體的系統. -### What is Git? +### 什麼是 Git? -Git is a tool that tracks changes to source code or any file, or we could also say Git is an open-source distributed version control system. +Git 是一個用來追蹤原始碼或任何檔案每次異動的工具, 或者我們可以說 Git 是一個開源的分布式版本控制系統. -There are many ways in which git can be used on our systems, most commonly or at least for me I have seen it in at the command line, but we also have graphical user interfaces and tools like Visual Studio Code that have git aware operations we can take advantage of. +我們的系統有很多種 Git 使用方法, 對我來說最常看到的用法是輸入指令, 但它也有圖形使用者介面, 如微軟開發的 Visual Studio Code 只要透過界面按鈕就可輕鬆管理. -Now we are going to run through a high-level overview before we even get Git installed on our local machine. +在教學如何安裝 Git 之前, 我們先瀏覽了一下 Git 怎麼使用. -Let's take the folder we created earlier. +我們先用之前建立的資料夾來當範例. ![](Images/Day35_Git2.png) -To use this folder with version control we first need to initiate this directory using the `git init command. For now, just think that this command puts our directory as a repository in a database somewhere on our computer. +首先, 如果想要對資料夾做版本控管, 就要輸入指令`git init`. 現在只要知道這個指令會把目錄建構成儲存庫(repository). ![](Images/Day35_Git6.png) -Now we can create some files and folders and our source code can begin or maybe it already has and we have something in here already. We can use the `git add .` command which puts all files and folders in our directory into a snapshot but we have not yet committed anything to that database. We are just saying all files with the `.` are ready to be added. +現在我們可以創建一些檔案或資料夾, 也或許你已經有放一些檔案了!? 我們可以輸入指令 `git add .` 將尚未提交的檔案做快照. 圖片中的句點代表的是把所有新增的檔案都添加進去. ![](Images/Day35_Git7.png) -Then we want to go ahead and commit our files, we do this with the `git commit -m "My First Commit"` command. We can give a reason for our commit and this is suggested so we know what has happened for each commit. +然後我們想要進一步提交檔案, 這個時候就可以輸入 `git commit -m "My First Commit"` . 建議提交時寫一些註解, 這將幫助我們了解發生了什麼事. ![](Images/Day35_Git8.png) -現在我們可以透過 `git log` 指令, 知道專案的歷史和發生何事. +現在我們可以透過 `git log` 指令, 回顧專案的歷史和註解. ![](Images/Day35_Git9.png) @@ -83,7 +83,7 @@ Then we want to go ahead and commit our files, we do this with the `git commit - ![](Images/Day35_Git10.png) -Add our new file using the `git add samplecode.ps1` command and then we can run `git status` again and see our file is ready to be committed. +輸入指令 `git add samplecode.ps1` 可以添加新檔案 samplecode.ps1. 然後可以再次輸入 `git status` 確認檔案準備被提交. ![](Images/Day35_Git11.png) @@ -91,7 +91,7 @@ Add our new file using the `git add samplecode.ps1` command and then we can run ![](Images/Day35_Git12.png) -Another `git status` now shows everything is clean again. +再輸入一次 `git status` 可以看見檔案都已提交. ![](Images/Day35_Git13.png) @@ -99,19 +99,19 @@ We can then use the `git log` command which shows the latest changes and first c ![](Images/Day35_Git14.png) -If we wanted to see the changes between our commits i.e what files have been added or modified we can use the `git diff b8f8 709a` +如果你想要審查兩個提交的版本之間的差異, 就可以輸入 `git diff b8f87d394 709a8256ab` 來看出有何檔案被新增或修改. ![](Images/Day35_Git15.png) -Which then displays what has changed in our case we added a new file. +於是以我們的案例來看, 很清楚的顯示我們添加了一個文件. ![](Images/Day35_Git16.png) -We can also and we will go deeper into this later on but we can jump around our commits i.e we can go time travelling! By using our commit number we can use the `git checkout 709a` command to jump back in time without losing our new file. +我們還可以透過指令 `git checkout 709a8256ab` 跳回之前提交的版本, 是不是很像時間旅行, 而且不會丟失我們的新檔案. 之後我們將會深入研究這個議題. ![](Images/Day35_Git17.png) -But then equally we will want to move forward as well and we can do this the same way with the commit number or you can see here we are using the `git switch -` command to undo our operation. +同理的我們可以用相同方法跳回 b8f87d394 版本, 或者你可以看到我用 `git switch -` 取消我的操作. ![](Images/Day35_Git18.png) From 739a3e13687c2e76a458c40a7c31ff68665fdcdf Mon Sep 17 00:00:00 2001 From: subineru Date: Sat, 23 Apr 2022 20:57:37 +0800 Subject: [PATCH 4/6] translate day35(preliminary draft) --- zh_tw/Days/day35.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh_tw/Days/day35.md b/zh_tw/Days/day35.md index 238b408..0f1473f 100644 --- a/zh_tw/Days/day35.md +++ b/zh_tw/Days/day35.md @@ -95,7 +95,7 @@ Git 是一個用來追蹤原始碼或任何檔案每次異動的工具, 或者 ![](Images/Day35_Git13.png) -We can then use the `git log` command which shows the latest changes and first commit. +我們可以輸入指令 `git log` 顯示最後的異動和第一次提交. ![](Images/Day35_Git14.png) From 44d8a46e8e03a16f037649732965675eaceea124 Mon Sep 17 00:00:00 2001 From: subineru Date: Sun, 24 Apr 2022 23:13:17 +0800 Subject: [PATCH 5/6] replace common and period. --- zh_tw/Days/day35.md | 87 ++++++++++++++++++++++----------------------- 1 file changed, 43 insertions(+), 44 deletions(-) diff --git a/zh_tw/Days/day35.md b/zh_tw/Days/day35.md index 0f1473f..15801c8 100644 --- a/zh_tw/Days/day35.md +++ b/zh_tw/Days/day35.md @@ -2,116 +2,116 @@ title: '#90DaysOfDevOps - 概述: Git - 版本控制 - 第 35 天' published: false description: 90DaysOfDevOps - 概述 Git - 版本控制 -tags: 'devops, 90daysofdevops, learning' +tags: 'devops，90daysofdevops，learning' cover_image: null canonical_url: null id: 1049041 --- ## 概述: Git - 版本控制 -在開始 Git 工具之前, 我們需要瞭解什麼是版本控制,還有為什麼要使用它. 作為 Git 教學的開端, 我們會稍微帶過何謂版本控制以及 Git 基礎概念. +在開始 Git 工具之前，我們需要瞭解什麼是版本控制,還有為什麼要使用它。作為 Git 教學的開端，我們會稍微帶過何謂版本控制以及 Git 基礎概念。 ### 甚麼是版本控制? -由於 Git 並不是唯一的版本控制工具，所以這一節將會涵蓋版本控制有哪些選項和使用方法. +由於 Git 並不是唯一的版本控制工具，所以這一節將會涵蓋版本控制有哪些選項和使用方法。 -版本控制最明顯且重要的功能是可以追蹤專案的歷史. 我們可以利用`git log` 指令回顧儲存庫(repository)內,過去專案提交的紀錄和註解. 讓我們想想, 如果這是實際的軟體專案, 有滿滿的原始碼, 而且許多開發者在不同的時間點提交軟體, 不同的作者和審稿人在這裡做紀錄, 有了歷史追蹤, 我們得以知道發生了什麼事, 何時發生, 又是誰在審稿. +版本控制最明顯且重要的功能是可以追蹤專案的歷史。我們可以利用`git log` 指令回顧儲存庫(repository)內,過去專案提交的紀錄和註解。 讓我們想想，如果這是實際的軟體專案，有滿滿的原始碼，而且許多開發者在不同的時間點提交軟體，不同的作者和審稿人在這裡做紀錄，有了歷史追蹤，我們得以知道發生了什麼事，何時發生，又是誰在審稿。 ![](Images/Day35_Git1.png) -版本控制很酷, 就像你在異動程式碼前, 手動複製一份. 你可能會為了以防萬一, 註解掉無用的舊程式碼, 而你隨時可以還原. +版本控制很酷，就像你在異動程式碼前，手動複製一份。 你可能會為了以防萬一，註解掉無用的舊程式碼，而你隨時可以還原。 ![](Images/Day35_Git2.png) -我不僅對原始碼做版本控制, 甚至是幾乎對所有的東西做版本控制, 就像談到 90DaysOfDevOps 這個專案, 當你不小心刪到你想要的文字, 難道說不會想要擁有歷史紀錄和做資料回朔的機制? +我不僅對原始碼做版本控制，甚至是幾乎對所有的東西做版本控制，就像談到 90DaysOfDevOps 這個專案，當你不小心刪到你想要的文字，難道不會想要擁有歷史紀錄和做資料回朔的機制？ -然而, 在此聲明 **版本控制不是備份!** +然而，在此聲明 **版本控制不是備份!** -版本控制的另外一個好處是它可以對一個專案同時管理很多個版本, 舉一個例子, 我們分別有一個免費版(FREE)和付費版(PAID)的程式, 兩者都能在所有的作業系統上面執行, 而且共享大部分的程式碼, 每次提交程式碼的時候, 都會複製並貼上到其他程式. 這樣做是不是會非常混亂, 尤其是當程式開發不只一個人的時候, 更容易發生錯誤. +版本控制的另外一個好處是它可以對一個專案同時管理很多個版本，舉一個例子，我們分別有一個免費版(FREE)和付費版(PAID)的程式，兩者都能在所有的作業系統上面執行，而且共享大部分的程式碼，每次提交程式碼的時候，都會複製並貼上到其他程式。 這樣做是不是會非常混亂，尤其是當程式開發不只一個人的時候，更容易發生錯誤。 -白金方案(Premium)的軟體擁有額外的功能, 在這裡我們稱為 premium commits, 免費版只包含 normal commits. +白金方案(Premium)的軟體擁有額外的功能，在這裡我們稱為 premium commits，免費版只包含 normal commits。 -在版本控制中, 想要處理上述的問題需要透過分支(Branching). +在版本控制中，想要處理上述的問題需要透過分支(Branching)。 ![](Images/Day35_Git3.png) -如上所述, 分支(Branching) 允許同一支程式擁有兩個程式碼分流. 當我們想要把免費版本的額外功能變成白金付費方案的時候, 我們會透過合併(merging). +如上所述，分支(Branching) 允許同一支程式擁有兩個程式碼分流。當我們想要把免費版本的額外功能變成白金付費方案的時候，我們會透過合併(merging)。 ![](Images/Day35_Git4.png) -現在, 合併(merging) 既可以簡單但也可以複雜, 譬如說你有一個團隊在開發免費版, 另一個團隊在開發白金付費版, 兩個團隊同時改動會影響整個程式碼的代碼, 又或只是更新了某個變數導致破壞某樣功能. 版本控制無法解決上述的衝突, 但是讓你更容易更輕鬆的管理. +現在，合併(merging) 既可以簡單但也可以複雜，譬如說你有一個團隊在開發免費版，另一個團隊在開發白金付費版，兩個團隊同時改動會影響整個程式碼的代碼，又或只是更新了某個變數導致破壞某樣功能。版本控制無法解決上述的衝突，但是讓你更容易更輕鬆的管理。 -目前為止, 我看到沒有使用版本控制的主要理由就是開發者間的協調能力夠好. 但是有越來越多的案例, 開發者之間正在用版本控制來分享程式碼, 可能是你和你的同事加入一個簡報, 或是你加入一個社群, 對一個項目共向修正和更新, 就像這個儲存庫 90DaysOfDevOps. +目前為止，我看到沒有使用版本控制的主要理由就是開發者間的協調能力夠好。但是有越來越多的案例，開發者之間正在用版本控制來分享程式碼，可能是你和你的同事加入一個簡報，或是你加入一個社群，對一個項目共向修正和更新，就像這個儲存庫 90DaysOfDevOps。 -我無法想像軟體開發團隊在沒有版本控制的情況下要怎麼處理問題? 當在我追蹤我自己的項目時, 我就發現他已經夠難了. 我希望團隊們能先把程式碼拆分一小部分的函數, 解決每一小部分函數的問題之後再予與發佈, 事情將簡單的多. +我無法想像軟體開發團隊在沒有版本控制的情況下要怎麼處理問題？當在我追蹤我自己的項目時，我就發現他已經夠難了。 我希望團隊們能先把程式碼拆分一小部分的函數，解決每一小部分函數的問題之後再予與發佈，事情將簡單的多。 -也就是說, 有了版本控制, 才有辦法做統整. 像是團隊們正在對不同的模組上進行開發, 這時就能夠協同合作的更好. +也就是說，有了版本控制，才有辦法做統整。 像是團隊們正在對不同的模組上進行開發，這時就能夠協同合作的更好。 ![](Images/Day35_Git5.png) -另外值得一提的事情是版本控制不只僅受益於開發者, 團隊中的所有成員和其他工具也都有了能見度, 一些專案管理工具可以跟 git 建立鏈結, 跟蹤工作的狀況. 最知名的例子就是 Jenkinus. 一個可以建置、打包、自動測試和佈署軟體的系統. +另外值得一提的事情是版本控制不只僅受益於開發者，團隊中的所有成員和其他工具也都有了能見度，一些專案管理工具可以跟 git 建立鏈結，跟蹤工作的狀況。最知名的例子就是 Jenkinus。 一個可以建置、打包、自動測試和佈署軟體的系統。 ### 什麼是 Git? -Git 是一個用來追蹤原始碼或任何檔案每次異動的工具, 或者我們可以說 Git 是一個開源的分布式版本控制系統. +Git 是一個用來追蹤原始碼或任何檔案每次異動的工具，或者我們可以說 Git 是一個開源的分布式版本控制系統。 -我們的系統有很多種 Git 使用方法, 對我來說最常看到的用法是輸入指令, 但它也有圖形使用者介面, 如微軟開發的 Visual Studio Code 只要透過界面按鈕就可輕鬆管理. +我們的系統有很多種 Git 使用方法，對我來說最常看到的用法是輸入指令，但它也有圖形使用者介面，如微軟開發的 Visual Studio Code 只要透過界面按鈕就可輕鬆管理。 -在教學如何安裝 Git 之前, 我們先瀏覽了一下 Git 怎麼使用. +在教學如何安裝 Git 之前，我們先瀏覽了一下 Git 怎麼使用。 -我們先用之前建立的資料夾來當範例. +我們先用之前建立的資料夾來當範例。 ![](Images/Day35_Git2.png) -首先, 如果想要對資料夾做版本控管, 就要輸入指令`git init`. 現在只要知道這個指令會把目錄建構成儲存庫(repository). +首先，如果想要對資料夾做版本控管，就要輸入指令`git init`。現在只要知道這個指令會把目錄建構成儲存庫(repository)。 ![](Images/Day35_Git6.png) -現在我們可以創建一些檔案或資料夾, 也或許你已經有放一些檔案了!? 我們可以輸入指令 `git add .` 將尚未提交的檔案做快照. 圖片中的句點代表的是把所有新增的檔案都添加進去. +現在我們可以創建一些檔案或資料夾，也或許你已經有放一些檔案了!? 我們可以輸入指令 `git add .` 將尚未提交的檔案做快照。圖片中的句點代表的是把所有新增的檔案都添加進去。 ![](Images/Day35_Git7.png) -然後我們想要進一步提交檔案, 這個時候就可以輸入 `git commit -m "My First Commit"` . 建議提交時寫一些註解, 這將幫助我們了解發生了什麼事. +然後我們想要進一步提交檔案，這個時候就可以輸入 `git commit -m "My First Commit"`。建議提交時寫一些註解，這將幫助我們了解發生了什麼事。 -![](Images/Day35_Git8.png) +![](Images/Day35_Git8.ng) -現在我們可以透過 `git log` 指令, 回顧專案的歷史和註解. +現在我們可以透過 `git log` 指令，回顧專案的歷史和註解。 ![](Images/Day35_Git9.png) -我們還能透過 `git status` 指令來檢查倉儲的狀態, 如下圖的前三行, 這表示我們還沒有提交檔案. 如果我們添加一個新檔 samplecode.ps1 , 再次輸入 `git status` 的時候, 會看到我們準備要提交的文件. +我們還能透過 `git status` 指令來檢查倉儲的狀態，如下圖的前三行，這表示我們還沒有提交檔案。 如果我們添加一個新檔 samplecode。ps1 ，再次輸入 `git status` 的時候，會看到我們準備要提交的文件。 ![](Images/Day35_Git10.png) -輸入指令 `git add samplecode.ps1` 可以添加新檔案 samplecode.ps1. 然後可以再次輸入 `git status` 確認檔案準備被提交. +輸入指令 `git add samplecode。ps1` 可以添加新檔案 samplecode。ps1。然後可以再次輸入 `git status` 確認檔案準備被提交。 ![](Images/Day35_Git11.png) -然後下 `git commit -m "My Second Commit"` 指令. +然後下 `git commit -m "My Second Commit"` 指令。 ![](Images/Day35_Git12.png) -再輸入一次 `git status` 可以看見檔案都已提交. +再輸入一次 `git status` 可以看見檔案都已提交。 ![](Images/Day35_Git13.png) -我們可以輸入指令 `git log` 顯示最後的異動和第一次提交. +我們可以輸入指令 `git log` 顯示最後的異動和第一次提交。 ![](Images/Day35_Git14.png) -如果你想要審查兩個提交的版本之間的差異, 就可以輸入 `git diff b8f87d394 709a8256ab` 來看出有何檔案被新增或修改. +如果你想要審查兩個提交的版本之間的差異，就可以輸入 `git diff b8f87d394 709a8256ab` 來看出有何檔案被新增或修改。 ![](Images/Day35_Git15.png) -於是以我們的案例來看, 很清楚的顯示我們添加了一個文件. +於是以我們的案例來看，很清楚的顯示我們添加了一個文件。 ![](Images/Day35_Git16.png) -我們還可以透過指令 `git checkout 709a8256ab` 跳回之前提交的版本, 是不是很像時間旅行, 而且不會丟失我們的新檔案. 之後我們將會深入研究這個議題. +我們還可以透過指令 `git checkout 709a8256ab` 跳回之前提交的版本，是不是很像時間旅行，而且不會丟失我們的新檔案。 之後我們將會深入研究這個議題。 ![](Images/Day35_Git17.png) -同理的我們可以用相同方法跳回 b8f87d394 版本, 或者你可以看到我用 `git switch -` 取消我的操作. +同理的我們可以用相同方法跳回 b8f87d394 版本，或者你可以看到我用 `git switch -` 取消我的操作。 ![](Images/Day35_Git18.png) @@ -124,18 +124,17 @@ Git 是一個用來追蹤原始碼或任何檔案每次異動的工具, 或者 - 哦，還有一些做時間旅行! -這個章節的內容似乎跳的有些快, 希望在尚未解說 Git 指令的強大之前, 你能對版本控制的功能有大致上的了解. +這個章節的內容似乎跳的有些快，希望在尚未解說 Git 指令的強大之前，你能對版本控制的功能有大致上的了解。 -下一章,我們將會在你的電腦安裝和設置 Git ,並且更深入的解說 Git 的命令和使用案例, 以及 Git 能做到什麼. +下一章,我們將會在你的電腦安裝和設置 Git，並且更深入的解說 Git 的命令和使用案例，以及 Git 能做到什麼。 ## Resources -- [What is Version Control?](https://www.youtube.com/watch?v=Yc8sCSeMhi4) -- [Types of Version Control System](https://www.youtube.com/watch?v=kr62e_n6QuQ) -- [Git Tutorial for Beginners](https://www.youtube.com/watch?v=8JJ101D3knE&t=52s) -- [Git for Professionals Tutorial](https://www.youtube.com/watch?v=Uszj_k0DGsg) -- [Git and GitHub for Beginners - Crash Course](https://www.youtube.com/watch?v=RGOj5yH7evk&t=8s) -- [Complete Git and GitHub Tutorial](https://www.youtube.com/watch?v=apGV9Kg7ics) - -See you on [第 36 天](day36.md) +- [What is Version Control?](https://www。youtube。com/watch?v=Yc8sCSeMhi4) +- [Types of Version Control System](https://www。youtube。com/watch?v=kr62e_n6QuQ) +- [Git Tutorial for Beginners](https://www。youtube。com/watch?v=8JJ101D3knE&t=52s) +- [Git for Professionals Tutorial](https://www。youtube。com/watch?v=Uszj_k0DGsg) +- [Git and GitHub for Beginners - Crash Course](https://www。youtube。com/watch?v=RGOj5yH7evk&t=8s) +- [Complete Git and GitHub Tutorial](https://www。youtube。com/watch?v=apGV9Kg7ics) +See you on [第 36 天](day36.md) \ No newline at end of file From 871005323ff62bef0e5954ac6a3f3572d232e783 Mon Sep 17 00:00:00 2001 From: subineru Date: Wed, 27 Apr 2022 21:53:02 +0800 Subject: [PATCH 6/6] finish day35 --- zh_tw/Days/day35.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh_tw/Days/day35.md b/zh_tw/Days/day35.md index 15801c8..9ec1830 100644 --- a/zh_tw/Days/day35.md +++ b/zh_tw/Days/day35.md @@ -128,7 +128,7 @@ Git 是一個用來追蹤原始碼或任何檔案每次異動的工具，或者 下一章,我們將會在你的電腦安裝和設置 Git，並且更深入的解說 Git 的命令和使用案例，以及 Git 能做到什麼。 -## Resources +## 資源 - [What is Version Control?](https://www。youtube。com/watch?v=Yc8sCSeMhi4) - [Types of Version Control System](https://www。youtube。com/watch?v=kr62e_n6QuQ)