From b02dd843bad4206b110f6e188dfea82ece75c717 Mon Sep 17 00:00:00 2001 From: Pallat Anchaleechamaikorn Date: Sun, 22 Feb 2015 11:49:29 +0700 Subject: [PATCH 01/46] git basics translated to Thai. --- book/02-git-basics/1-git-basics.asc | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/book/02-git-basics/1-git-basics.asc b/book/02-git-basics/1-git-basics.asc index 14d3d34b0..2d309761d 100644 --- a/book/02-git-basics/1-git-basics.asc +++ b/book/02-git-basics/1-git-basics.asc @@ -1,10 +1,11 @@ [[_git_basics_chapter]] -== Git Basics +== Git เบื้องต้น -If you can read only one chapter to get going with Git, this is it. -This chapter covers every basic command you need to do the vast majority of the things you'll eventually spend your time doing with Git. -By the end of the chapter, you should be able to configure and initialize a repository, begin and stop tracking files, and stage and commit changes. -We'll also show you how to set up Git to ignore certain files and file patterns, how to undo mistakes quickly and easily, how to browse the history of your project and view changes between commits, and how to push and pull from remote repositories. +ถ้าคุณจะอ่านเพียงบทเดียวให้เข้าใจ Git บทนี้แหล่ะใช่เลย +เพราะเรากำลังจะแสดงคำสั่งพื้นฐานที่คุณจะต้องใช้มากที่สุดใน Git +เมื่อจบบท คุณน่าจะตั้งค่าและเริ่มต้นสร้าง repository ได้ และ ทำ stage และ commit สิ่งที่แก้ไขได้ +แล้วเรายังจะแสดงให้คุณเห็นว่าจะตั้งค่า Git ให้ละเว้นไฟล์หรือรูปแบบของไฟล์ไหนได้ ทำอย่างไรจะย้อนกลับเมื่อเกิดความผิดพลาดได้อย่างรวดเร็วและง่ายดาย +ทำอย่างไรหากต้องการสำรวจประวัติของโปรเจ็คและมองหาการสิ่งที่แก้ไขไปในแต่ละ commit และทำอย่างไรถึงจะ push และ pull ของจาก remote repository ต่างๆได้ include::sections/getting-a-repository.asc[] @@ -20,7 +21,7 @@ include::sections/tagging.asc[] include::sections/aliases.asc[] -=== Summary +=== สรุป -At this point, you can do all the basic local Git operations – creating or cloning a repository, making changes, staging and committing those changes, and viewing the history of all the changes the repository has been through. -Next, we'll cover Git's killer feature: its branching model. +ตอนนี้ คุณสามารถจัดการ Git ในเครื่องคุณขั้นพื้นฐานได้ทุกอย่างแล้ว - สร้าง หรือ โคลน repository, แก้ไข, นำเข้า stage และ commit สิ่งที่แก้ไขนั้น, และดูประวัติการแก้ไขทั้งหมดใน repository ได้ +บทต่อไป เราจะไปดู เรื่องโหดๆใน Git กัน นั่นก็คือการแตก branch From fa0f053a9b3d3241cd9caf1915725de184199c2f Mon Sep 17 00:00:00 2001 From: Pallat Anchaleechamaikorn Date: Sun, 22 Feb 2015 12:48:26 +0700 Subject: [PATCH 02/46] Clone --- .../sections/getting-a-repository.asc | 53 +++++++++---------- 1 file changed, 25 insertions(+), 28 deletions(-) diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc index 91bf18d8c..2bd86b2c3 100644 --- a/book/02-git-basics/sections/getting-a-repository.asc +++ b/book/02-git-basics/sections/getting-a-repository.asc @@ -1,25 +1,25 @@ [[_getting_a_repo]] -=== Getting a Git Repository +=== ลองดูสัก 1 repository -You can get a Git project using two main approaches. -The first takes an existing project or directory and imports it into Git. -The second clones an existing Git repository from another server. +คุณสามารถเริ่มมีโปรเจ็คใน Git ได้สองวิธีหลักๆคือ +วิธีแรก เอาโปรเจ็คที่มีอยู่แล้ว หรือ directory ก็ได้ มา import เข้าไปใน Git +วิธีที่สองคือโคลน มาจาก repository ที่มีอยู่จาก server ใด้สักแห่ง -==== Initializing a Repository in an Existing Directory +==== การสร้าง Repository จากไดเรคทอรี่ที่สร้างไว้แล้ว -If you're starting to track an existing project in Git, you need to go to the project's directory and type +ถ้าคุณกำลังจะเริ่ม track โปรเจ็คที่ทำไว้แล้วใน git คุณต้องไปที่ directory ของโปรเจ็คนั้น และพิมพ์คำสั่ง [source,console] ---- $ git init ---- -This creates a new subdirectory named `.git` that contains all of your necessary repository files – a Git repository skeleton. -At this point, nothing in your project is tracked yet. -(See <<_git_internals>> for more information about exactly what files are contained in the `.git` directory you just created.)(((git commands, init))) +คำสั่งนี้จะสร้าง directory ย่อยขึ้นมาใหม่ ชื่อว่า `.git` ซึ่งใช้เก็บทุกสิ่งที่จำเป็นของไฟล์ทั้งหมดใน repository - เรียกว่าโครงร่างของ git +และตอนนี้จะยังไม่มีอะไรถูก track (ดู <<_git_internals>> สำหรับรายละเอียดเพิ่มเติมว่าอะไรที่ถูกเก็บอยู่ในไดเรคทอรี่ `.git` ที่เพิ่งถูกสร้างขึ้นมา)(((git commands, init))) -If you want to start version-controlling existing files (as opposed to an empty directory), you should probably begin tracking those files and do an initial commit. -You can accomplish that with a few `git add` commands that specify the files you want to track, followed by a `git commit`: +ถ้าคุณต้องการเริ่มทำ เวอร์ชั่นคอนโทรลพวกไฟล์ที่มีอยู่เดิม (ซึ่งต่างจากไดเร็คทอรี่ที่ว่าง) +คุณควรเริ่มการ track ไฟล์พวกนั้น และ commit +ซึ่งคุณสามารถทำมันได้แค่ไม่กี่คำสั่ง โดยคำสั่ง `git add` จะบอกว่าไฟล์ไหนที่คุณต้องการ track ตามด้วยคำสั่ง `git commit`: [source,console] ---- @@ -28,37 +28,34 @@ $ git add LICENSE $ git commit -m 'initial project version' ---- -We'll go over what these commands do in just a minute. -At this point, you have a Git repository with tracked files and an initial commit. +เราจะได้เห็นว่าคำสั่งเหล่านี้ใช้เวลานิดเดียว ซึ่งตรงนี้คุณก็จะได้ Git repository พร้อมไฟล์ที่ถูก track และได้ commit แล้ว [[_git_cloning]] -==== Cloning an Existing Repository +==== การโคลน repository ที่มีอยู่แล้ว -If you want to get a copy of an existing Git repository – for example, a project you'd like to contribute to – the command you need is `git clone`. -If you're familiar with other VCS systems such as Subversion, you'll notice that the command is "clone" and not "checkout". -This is an important distinction – instead of getting just a working copy, Git receives a full copy of nearly all data that the server has. -Every version of every file for the history of the project is pulled down by default when you run `git clone`. -In fact, if your server disk gets corrupted, you can often use nearly any of the clones on any client to set the server back to the state it was in when it was cloned (you may lose some server-side hooks and such, but all the versioned data would be there – see <<_git_on_the_server>> for more details). +ถ้าคุณต้องการได้ repository ที่มีอยู่แล้ว - ตัวอย่างเช่น มีโปรเจ็คหนึ่งที่คุณสนใจอยากมีส่วนร่วม - คำสั่งที่คุณต้องการคือ `git clone` +ถ้าคุณคุ้นเคยกับระบบ VCS อื่นๆยกตัวอย่างเช่น Subversion ขอให้รู้ไว้ว่า คำสั่ง "clone" ไม่ใช่ "checkout" +ซึ่งนี่คือความต่างที่สำคัญมาก - แทนที่จะเอาแค่สำเนา Git จะรับเอาสำเนาเกือบทั้งหมดของข้อมูลทุกชิ้นที่เซิฟเวอร์มี +รวมถึงทุกๆเวอร์ชั่นของทุกๆไฟล์ที่มีในประวัติของโปรเจ็คลงมา เมื่อคุณใช้คำสั่ง `git clone` +นั่นแปลว่า ถ้าเกิดอะไรขึ้นกับดิสบนเซิฟเวอร์ คุณสามารถจะใช้โคลนจาก client ไหนก็ได้กลับมาคืนไว้ใน server ซึ่งจะได้ state สุดท้ายที่ถูกโคลนไป (คุณอาจจะเสียบางอย่างที่ฝั่ง server มีไปบ้าง แต่ทุกๆเวอร์ชั่นจะยังอยู่ - ดู <<_git_on_the_server>> สำหรับรายละเอียดเพิ่มเติม) -You clone a repository with `git clone [url]`.(((git commands, clone))) -For example, if you want to clone the Git linkable library called libgit2, you can do so like this: +คุณโคลน repository ได้ด้วยคำสั่ง `git clone [url]`.(((git commands, clone))) ตัวอย่างเช่น ถ้าคุณต้องการโคลนไลบรารี่ Git linkable หรือเรียกว่า libgit2 คำสามารถทำได้ดังนี้ [source,console] ---- $ git clone https://github.com/libgit2/libgit2 ---- -That creates a directory named ``libgit2'', initializes a `.git` directory inside it, pulls down all the data for that repository, and checks out a working copy of the latest version. -If you go into the new `libgit2` directory, you'll see the project files in there, ready to be worked on or used. -If you want to clone the repository into a directory named something other than ``libgit2'', you can specify that as the next command-line option: +เสร็จแล้วจะเกิดไดเร็คทอรี่ชื่อ ``libgit2'' พร้อมกับการสร้างไดเร็คทอรี่ .git อยู่ในนั้น ดึงข้อมูลทั้งหมดของจาก repository ลงมา และได้สำเนางานเวอร์ชั่นล่าสุดเรียบร้อย +ถ้าคุณลองเข้าไปในไดเรคทอรี่ `libgit2` ที่ถูกสร้างขึ้นมาใหม่นี้ คุณก็จะเห็นไฟล์ของโปรเจ็คในนั้น พร้อมให้ทำงาน หรือใช้ได้เลย +ถ้าคุณต้องารโคลน repository ให้เข้าไปไว้ในไดเร็คทอรี่ชื่ออื่นนอกเหนือจาก ``libgit2'' คุณสามารถระบุเจาะจงลงไปได้เลยตามคำสั่งต่อไปนี้: [source,console] ---- $ git clone https://github.com/libgit2/libgit2 mylibgit ---- -That command does the same thing as the previous one, but the target directory is called `mylibgit`. +ซึ่งคำสั่งนี้จะทำเหมือนคำสั่งก่อนหน้านี้เพียงแต่จะนำทั้งหมดไปอยู่ในไดเรคทอรี่ชื่อ `mylibgit` แทน -Git has a number of different transfer protocols you can use. -The previous example uses the `https://` protocol, but you may also see `git://` or `user@server:path/to/repo.git`, which uses the SSH transfer protocol. -<<_git_on_the_server>> will introduce all of the available options the server can set up to access your Git repository and the pros and cons of each. +Git มีหลายโปรโตคอลสำหรับถ่ายโอนไฟล์ให้เลือกใช้ โดยตัวอย่างก่อนหน้านี้ได้ใช้ โปรโตคอล `https://` แต่คุณอาจจะได้เห็นแบบอื่นด้วยเช่น `git://` หรือ `user@server:path/to/repo.git` ซึ่งใช้โปรโตคอล SSH +<<_git_on_the_server> จะแนะนำตัวเลือกทั้งหมดที่เป็นไปได้ที่เซิฟเวอร์จะตั้งค่าให้เข้าถึง Git repository ได้ รวมถึงข้อดีข้อเสียของแต่ละตัวเลือก From 3ffaa7c8512041f462f362c1dad96396b56df693 Mon Sep 17 00:00:00 2001 From: Pallat Anchaleechamaikorn Date: Sun, 22 Feb 2015 14:29:29 +0700 Subject: [PATCH 03/46] git status, .gitignore --- .../sections/recording-changes.asc | 140 +++++++++--------- 1 file changed, 69 insertions(+), 71 deletions(-) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index ec00e12ff..461288af2 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -1,24 +1,24 @@ -=== Recording Changes to the Repository +=== การบันทึกการเปลี่ยนแปลงใน repository -You have a bona fide Git repository and a checkout or working copy of the files for that project. -You need to make some changes and commit snapshots of those changes into your repository each time the project reaches a state you want to record. +คุณมี repository สักหนึ่งตัว และทำสำเนามาแล้ว +ทีนี้คุณต้องการแก้ไขออะไรสักอย่างและ อยาก commit snapshots นั้นไว้ใน repository ทุกๆครั้งที่คุณต้องการ -Remember that each file in your working directory can be in one of two states: tracked or untracked. -Tracked files are files that were in the last snapshot; they can be unmodified, modified, or staged. -Untracked files are everything else – any files in your working directory that were not in your last snapshot and are not in your staging area. -When you first clone a repository, all of your files will be tracked and unmodified because you just checked them out and haven't edited anything. +จงจำไว้ว่าแต่ละไฟล์ในไดเรคทอรี่การทำงานนี้ สามารถมีได้ เพียงสถาวะเดียวจาก สอง สถาวะนี้คือ: tracked หรือ untracked +Tracked คือไฟล์ที่อยู่ใน snapshot สุดท้าย ซึ่งสามารถเป็น unmodified หรือ modified หรือ staged ก็ได้ +Untracked คือไฟล์อื่นๆ ไฟล์ทั้งหมดในไดเรคทอรี่การทำงาน ที่ไม่ได้อยู่ใน snapshot สุดท้าย และไม่อยู่ใน staging ด้วย +เมื่อคุณโคลน repository มาครั้งแรก ทุกไฟล์จะเป็น tracked และ unmodified เพราะคุณเพิ่งจะเอามันลงมา และยังไม่ได้แก้ไขใดๆ -As you edit files, Git sees them as modified, because you've changed them since your last commit. -You stage these modified files and then commit all your staged changes, and the cycle repeats. +เมื่อคุณแก้ไขไฟล์ Git จะเห็นว่ามันเป็น modified เพราะว่าคุณแก้ไขมันไปจาก commit สุดท้าย +คุณก็นำพวกที่ modified นี้เข้า stage แล้วก็ commit ทั้งหมดที่เข้ามาใน stage และก็ทำวนเวียนไปเรื่อยๆเป็นวงจร -.The lifecycle of the status of your files. +.วงจรชีวิตสถานะไฟล์ของคุณ. image::images/lifecycle.png[The lifecycle of the status of your files.] [[_checking_status]] -==== Checking the Status of Your Files +==== การตรวจสอบสถานะไฟล์ต่างๆของคุณ -The main tool you use to determine which files are in which state is the `git status` command.(((git commands, status))) -If you run this command directly after a clone, you should see something like this: +เครื่องมือหลักๆสำหรับหาว่าไฟล์ไหนอยู่ในสถานะไหนก็คือคำสั่ง `git status` (((git commands, status))) +ถ้าคุณรันคำสั่งนี้ตรงๆหลังจากที่เพิ่งโคลนมา คุณจะเห็นบางอย่างคล้ายๆแบบนี้: [source,console] ---- @@ -27,14 +27,12 @@ On branch master nothing to commit, working directory clean ---- -This means you have a clean working directory – in other words, there are no tracked and modified files. -Git also doesn't see any untracked files, or they would be listed here. -Finally, the command tells you which branch you're on and informs you that it has not diverged from the same branch on the server. -For now, that branch is always ``master'', which is the default; you won't worry about it here. -<<_git_branching>> will go over branches and references in detail. +นี่หมายความว่าคุณมีไดเร็คทอรี่ของการทำงานที่สะอาดสุดๆ หรืออีกนัยหนึ่งคือ ไม่มีไฟล์ไหนถูก track และ modified เลย +ในขณะเดียวกัน git ก็ยังไม่เห็นว่ามีไฟล์ไหนที่สถานะเป็น untracked หรือไม่มีรายการอะไรควรแสดงให้เห็น +สุดท้าย คำสั่งนี้ บอกคุณว่าคุณกำลังอยู่ที่ branch ไหน และแจ้งให้คุณทราบว่าไม่มีอะไรผิดแปลกไปจาก branch เดียวกันบน server +ซึ่งตอนนี้ branch นั้นยังคงเป็น ``master'' ซึ่งเป็นค่าตั้งต้น; คุณอย่าเพิ่งกังวลเรื่องนี้ <<_git_branching>> จะพาคุณไปดูเรื่อง branch และอธิบายรายละเอียดให้ -Let's say you add a new file to your project, a simple README file. -If the file didn't exist before, and you run `git status`, you see your untracked file like so: +สมมุติว่า คุณเพิ่มไฟล์ใหม่เข้ามาในโปรเจ็ค เอาง่ายๆเช่นไฟล์ README ถ้าไฟล์นี้ไม่เคยมีอยู่เดิม และคุณรันคำสั่ง`git status` คุณจะเห็นไฟล์ที่เป็น untracked แบบนี้: [source,console] ---- @@ -49,23 +47,22 @@ Untracked files: nothing added to commit but untracked files present (use "git add" to track) ---- -You can see that your new README file is untracked, because it's under the ``Untracked files'' heading in your status output. -Untracked basically means that Git sees a file you didn't have in the previous snapshot (commit); Git won't start including it in your commit snapshots until you explicitly tell it to do so. -It does this so you don't accidentally begin including generated binary files or other files that you did not mean to include. -You do want to start including README, so let's start tracking the file. +คุณจะเห็นว่าไฟล์ README ของคุณอยู่ในสถานะ untracked เพราะว่ามันถูกแสดงอยู่ใต้คำว่า ``Untracked files'' บนหน้าจอ +untracked โดยปกตินั้นหมายความว่า git เห็นว่าไฟล์นี้ ไม่มีใน snapshot ก่อนหน้านี้(commit); git จะไม่เริ่มต้นรวมไฟล์นี้ลงไปใน commit จนกว่าคุณจะบอกมันอย่างชัดเจนก่อน +ซึ่งมันทำแบบนี้เพื่อป้องกันอันตรายหากคุณไม่ได้ตั้งใจจะรวมเอาไฟล์ไบนารี่หรือไฟล์อะไรก็ไม่รู้เข้าไปด้วย สิ่งที่คุณต้องทำเมื่ออยากรวมไฟล์ README เอาละ เรามาเริ่ม track ไฟล์กันเลย [[_tracking_files]] -==== Tracking New Files +==== การ track ไฟล์ใหม่ -In order to begin tracking a new file, you use the command `git add`.(((git commands, add))) -To begin tracking the README file, you can run this: +คำสั่งให้เริ่ม track ไฟล์ใหม่ ให้คุณใช้คำสั่ง `git add`.(((git commands, add))) +เพื่อเริ่ม track README คุณสามารถรันคำสั่งนี้เลย: [source,console] ---- $ git add README ---- -If you run your status command again, you can see that your README file is now tracked and staged to be committed: +ถ้าคุณรันคำสั่ง status อีกที คุณจะเห็นว่าไฟล์ README ของคุณมีสถานะเป็น tracked และ staged เพื่อรอที่จะเป็น committed: [source,console] ---- @@ -78,15 +75,15 @@ Changes to be committed: ---- -You can tell that it's staged because it's under the ``Changes to be committed'' heading. -If you commit at this point, the version of the file at the time you ran `git add` is what will be in the historical snapshot. -You may recall that when you ran `git init` earlier, you then ran `git add (files)` – that was to begin tracking files in your directory.(((git commands, init)))(((git commands, add))) -The `git add` command takes a path name for either a file or a directory; if it's a directory, the command adds all the files in that directory recursively. +คุณบอกได้ว่าสถานะของมันเป็น staged แล้ว ก็เพราะมันถูกแสดงอยู่ใต้คำว่า “Changes to be committed” บนหัวมัน +ถ้าคุณ commit ที่จุดนี้เลย เวอร์ชั่นของไฟล์ ณ จุดที่คุณได้รันคำสั่ง git add จะกลายเป็นประวัติไปอยู่ใน snapshot +คุณอาจจะย้อนสถานะมันได้ถึง เมื่อตอนที่คุณได้รันคำสั่ง git init เมื่อครู่นี้ และจากนั้นคุณได้รันคำสั่ง`git add (files)` ซึ่งตอนนั้นเป็นการเริ่มการติดตามไฟล์ในไดเร็คทอรี่ของคุณแล้ว(((git commands, init)))(((git commands, add))) +คำสั่ง `git add` จะเก็บเอาชื่อพาร์ท รวมถึงไฟล์และไดเร็คทอรี่ไว้ ถุ้าสิ่งที่เพิ่มไว้เป็นไดเร็คทอรี่ คำสั่งจะเพิ่มไฟล์ทั้งหมดในไดเร็คทอรี่ให้เลย -==== Staging Modified Files +==== การทำ stage modified -Let's change a file that was already tracked. -If you change a previously tracked file called ``CONTRIBUTING.md'' and then run your `git status` command again, you get something that looks like this: +ลองเปลี่ยนแปลงไฟล์สักไฟล์ที่สถานะเป็น tracked +ถ้าคุณแก้ไขไฟล์ ``CONTRIBUTING.md'' ให้เปลี่ยนไปจาก tracked ก่อนหน้านี้ และรันคำสั่ง `git status` อีกครั้ง คุณจะได้ข้อความทำนองนี้: [source,console] ---- @@ -105,9 +102,10 @@ Changes not staged for commit: ---- -The ``CONTRIBUTING.md'' file appears under a section named ``Changed but not staged for commit'' – which means that a file that is tracked has been modified in the working directory but not yet staged. -To stage it, you run the `git add` command. `git add` is a multipurpose command – you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved. It may be helpful to think of it more as ``add this content to the next commit'' rather than ``add this file to the project''.(((git commands, add))) -Let's run `git add` now to stage the ``CONTRIBUTING.md'' file, and then run `git status` again: +ไฟล์ ``CONTRIBUTING.md'' จะโผล่มาอยู่ภายใต้ส่วนของคำว่า ``Changed but not staged for commit'' ซึ่งหมายความว่าไฟล์นั้น สถานะเป็น tracked และกำลังถูกแก้ไขในไดเร็คทอรี่แต่ยังไม่เข้า stage +และเพื่อจะทำ stage มัน คุณลองรันคำสั่ง `git add` ดู `git add` เป็นคำสั่งสารพัดประโยชน์ คุณสามารถใช้มันเพื่อ เริ่ม track ไฟล์ใหม่ หรือเพื่อ เริ่มนำไฟล์เข้า stage และเพื่อทำอะไรอย่างอื่นอีกเช่นเมื่อต้องทำ merge-conflict เสร็จแล้ว +มันอาจจะช่วยคุณได้มาก หากจะคิดว่าสิ่งนี้นั้นคือการ ``เพิ่มเนื้อหานี้เข้าไปใน commit ถัดไป'' มากกว่าที่จะคิดว่า ``เพิ่มไฟล์นี้เข้าไปในโปรเจค'' (((git commands, add))) +เอาละ มาลองรัน `git add` เลย เพื่อนำไฟล์ ``CONTRIBUTING.md'' เข้า stage จากนั้นรันคำสั่ง `git status` อีกครั้ง: [source,console] ---- @@ -122,10 +120,10 @@ Changes to be committed: ---- -Both files are staged and will go into your next commit. -At this point, suppose you remember one little change that you want to make in `CONTRIBUTING.md` before you commit it. -You open it again and make that change, and you're ready to commit. -However, let's run `git status` one more time: +ทั้งสองไฟล์เป็น staged แล้ว และกำลังก้าวเข้าสู่ commit ถัดไป +ณ จุดนี้ สมมุติว่าคุณเพิ่งนึกขึ้นได้ว่าอยากจะแก้ไขอะไรอีกนิดหน่อยใน `CONTRIBUTING.md` ก่อนที่จะ commit มัน +คุณเปิดไฟล์ขึ้นมาอีกครั้งและแก้ไขมัน จากนั้นคุณพร้อมที่จะ commit แล้ว +ไม่ว่าจะอย่างไรก็ตาม ลองรันคำสั่ง `git status` อีกสักที: [source,console] ---- @@ -146,12 +144,12 @@ Changes not staged for commit: ---- -What the heck? -Now `CONTRIBUTING.md` is listed as both staged _and_ unstaged. -How is that possible? -It turns out that Git stages a file exactly as it is when you run the `git add` command. -If you commit now, the version of `CONTRIBUTING.md` as it was when you last ran the `git add` command is how it will go into the commit, not the version of the file as it looks in your working directory when you run `git commit`. -If you modify a file after you run `git add`, you have to run `git add` again to stage the latest version of the file: +อะไรฟะ? +ตอนนี้ มันถูกแสดงว่ามีสองสถานะคือ staged และ unstaged +มันเป็นงี้ได้ไง? +มันกลายเป็นว่า stage ของไฟล์เป็นตามที่คุณรันคำสั่ง `git add` +ถ้าคุณ commit ตอนนี้ เวอร์ชั่นของ `CONTRIBUTING.md` คือไฟล์เมื่อตอนที่คุณรัน `git add` ซึ่งคือของที่จะไปสู่การ commit, ไม่ใช่เวอร์ชั่นที่คุณเห็นจริงๆในไดเรคทอรี่เมื่อตอนที่คุณรัน `git commit` +ถ้าคุณแก้ไขไฟล์หลังจากที่คุณรันคำสั่ง `git add` คุณต้องรัน `git add` อีกที เพื่อนำเวอร์ชั่นสุดท้ายของไฟล์เข้า stage: [source,console] ---- @@ -165,9 +163,10 @@ Changes to be committed: modified: CONTRIBUTING.md ---- -==== Short Status +==== สถานะแบบย่อ -While the `git status` output is pretty comprehensive, it's also quite wordy. Git also has a short status flag so you can see your changes in a more compact way. If you run `git status -s` or `git status --short` you get a far more simplified output from the command. +เมื่อผลลัพธ์ของคำสั่ง `git status` นั้นครอบคลุมทุกสิ่งอย่าง แต่มันก็ยังเวิ่นเว้อมากไป Git ก็เลยมีเครื่องหมายการแสดงสถานะอย่างย่อไว้ให้ด้วย เพื่อให้คุณเห็นการเปลี่ยนแปลงในรูปแบบกระทัดรัด +ถ้าคุณรัน `git status -s` หรือ `git status --short` คุณจะได้ผลลัพธ์ที่ดูง่ายจากคำสั่งนี้ [source,console] ---- @@ -179,15 +178,15 @@ M lib/simplegit.rb ?? LICENSE.txt ---- -New files that aren't tracked have a `??` next to them, new files that have been added to the staging area have an `A`, modified files have an `M` and so on. There are two columns to the output - the left hand column indicates that the file is staged and the right hand column indicates that it's modified. So for example in that output, the `README` file is modified in the working directory but not yet staged, while the `lib/simplegit.rb` file is modified and staged. The `Rakefile` was modified, staged and then modified again, so there are changes to it that are both staged and unstaged. +modified จะมี `M` โดยแสดงเป็น สองคอลัมน์ ซึ่งทางซ้ายบอก stage ของไฟล์ และทางขวาคือของที่ถูกแก้ไข ดังตัวอย่างที่แสดงมานี้ ไฟล์ `README` ถูกแก้ไขแล้วในไดเรคทอรี่ แต่ยังไม่เข้า stage ในขณะที่ `lib/simplegit.rb ถูกแก้ไขและเข้า stage แล้ว ส่วน `Rakefile` เคยถูกแก้ไข เข้า stage แล้ว และถูกแก้ไขอีกครั้ง ดังนั้นสถานะการเปลี่ยนแปลงของมันจึงมีสองอย่างคือ staged และ unstaged [[_ignoring]] -==== Ignoring Files +==== การละเว้นไฟล์ใดๆ -Often, you'll have a class of files that you don't want Git to automatically add or even show you as being untracked. -These are generally automatically generated files such as log files or files produced by your build system. -In such cases, you can create a file listing patterns to match them named `.gitignore`.(((ignoring files))) -Here is an example `.gitignore` file: +บ่อยครั้ง คุณอาจจะมีคลาสหรือไฟล์ที่คุณไม่อยากให้ git เพิ่มให้โดยอัตโนมัติ หรือ ไม่อยากให้โชว์เป็น untracked +ซึ่งโดยปกติจะเป็นไฟล์ที่ถูกสร้างขั้นมาเองเช่น log ไฟล์ หรือไฟล์ที่ถูกสร้างโดยระบบ +ในกรณีนี้ คุณสามารถสร้างไฟล์สำหรับใส่รูปแบบไฟล์พวกนี้ไว้ใน `.gitignore`.(((ignoring files))) +นี่คือตัวอย่างไฟล์ `.gitignore`: [source,console] ---- @@ -196,23 +195,22 @@ $ cat .gitignore *~ ---- -The first line tells Git to ignore any files ending in ``.o'' or ``.a'' – object and archive files that may be the product of building your code. -The second line tells Git to ignore all files that end with a tilde (`~`), which is used by many text editors such as Emacs to mark temporary files. -You may also include a log, tmp, or pid directory; automatically generated documentation; and so on. -Setting up a `.gitignore` file before you get going is generally a good idea so you don't accidentally commit files that you really don't want in your Git repository. +ในบรรทัดแรก คือการบอกให้ git ละเว้นไฟล์ใดๆก็ตามที่ลงท้ายด้วย ``.o'' หรือ ``.a'' ซึ่งอาจจะเป็น ออปเจ็ค และ archive file ที่เกิดจากการที่คุณ building โค้ดของคุณ +บรรทัดที่สอง คือการบอกให้ git ละเว้นทุกไฟล์ที่ลงท้ายด้วยสัญลักษณ์ (~) ซึ่งมันถูกใช้จากหลายๆ text editor เช่น Emacs เพื่อสร้าง temporary files +คุณอาจจะเพิ่ม log หรือ tmp หรือ pid เข้าไปด้วย รวมทั้งพวกเอกสารที่ถูกสร้างขึ้นมาเองทั้งหลาย ดังนั้น จงทำ .gitignore ขั้นมาก่อนที่คุณจะไปมีไอเดียบรรเจิด เพื่อที่คุณจะไม่ต้องเจอเหตุไม่คาดฝัน เวลา commit ไฟล์ที่จะไม่ต้องการมันจริงๆใน repository ของคุณ -The rules for the patterns you can put in the `.gitignore` file are as follows: +กฎของรูปแบบต่างๆที่คุณจะใส่ลงไปใน `.gitignore` ได้มีดังนี้: -* Blank lines or lines starting with `#` are ignored. -* Standard glob patterns work. -* You can end patterns with a forward slash (`/`) to specify a directory. -* You can negate a pattern by starting it with an exclamation point (`!`). +* บรรทัดที่ว่าง หรือบรรทัดที่เริ่มต้นด้วย`#` จะถูกละเว้นไปเลย +* รูปแบบสากลนั้นใช้ได้เลย +* คุณสามารถจบรูปแบบด้วย ('/') สำหรับเจาะจงไปที่ไดเร็คทอรี่ +* สามารถใช้ การปฏิเสธรูปแบบด้วยการเริ่มต้นด้วยเครื่องหมาย ('!') -Glob patterns are like simplified regular expressions that shells use. -An asterisk (`*`) matches zero or more characters; `[abc]` matches any character inside the brackets (in this case a, b, or c); a question mark (`?`) matches a single character; and brackets enclosing characters separated by a hyphen(`[0-9]`) matches any character between them (in this case 0 through 9). -You can also use two asterisks to match nested directories; `a/**/z` would match `a/z`, `a/b/z`, `a/b/c/z`, and so on. +รูปแบบสากลก็คล้ายๆ regular ecpressions ที่เชลล์ใช้นั่นแหล่ะ +เช่น สัญลักษณ์ (`*`) ตรงกับอักษร ศูนย์ตัว หรือมากกว่านั้น `[abc]` ตรงกับอักษรใดๆภายในเครื่องหมายก้ามปู (ในที่นี้คือ a, b หรือ c) เครื่องหมายคำถาม (`?`) ตรงกับอักษรใดๆหนึ่งตัว และเครื่องหมายก้ามปูครอบไว้ด้วยอักษรที่มี เครื่องหมายลบคั่นกลาง (`[0-9]`) ตรงกับอักษรใดๆระหว่างนั้น (ในที่นี้คือ 0 ถึง 9) +คุณสามารถใช้สัญลักษณ์สองตัวเพื่ออ้างถึง ได้เรคทอรี่ซ้อนกันได้ `a/**/z` สามารถแทน `a/z`, `a/b/z`, `a/b/c/z`, หรืออื่นๆได้ด้วย -Here is another example .gitignore file: +ต่อไปนี้คืออีกตัวอย่างของไฟล์ .gitignore: [source] ---- @@ -235,9 +233,9 @@ doc/*.txt doc/**/*.txt ---- -[TIP] +[เคล็ดลับ] ==== -GitHub maintains a fairly comprehensive list of good `.gitignore` file examples for dozens of projects and languages at https://github.com/github/gitignore[] if you want a starting point for your project. +GitHub เขามีรายการของ `.gitignore` ที่ทำไว้ดีแล้ว นับเป็นโหลๆของภาษาต่างๆ ที่ https://github.com/github/gitignore[] ถ้าคุณต้องการนำมาเริ่มในโปรเจคของคุณ ==== [[_git_diff_staged]] From f56b6da2ea364c01a428670434e16caacb7df8bc Mon Sep 17 00:00:00 2001 From: Pallat Anchaleechamaikorn Date: Sun, 22 Feb 2015 21:29:23 +0700 Subject: [PATCH 04/46] commit --- .../sections/recording-changes.asc | 67 +++++++++---------- 1 file changed, 30 insertions(+), 37 deletions(-) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 461288af2..64be3ed42 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -239,15 +239,13 @@ GitHub เขามีรายการของ `.gitignore` ที่ทำ ==== [[_git_diff_staged]] -==== Viewing Your Staged and Unstaged Changes +==== การดูว่าแก้ไขอะไรไปใน Staged และ Unstaged -If the `git status` command is too vague for you – you want to know exactly what you changed, not just which files were changed – you can use the `git diff` command.(((git commands, diff))) -We'll cover `git diff` in more detail later, but you'll probably use it most often to answer these two questions: What have you changed but not yet staged? -And what have you staged that you are about to commit? -Although `git status` answers those questions very generally by listing the file names, `git diff` shows you the exact lines added and removed – the patch, as it were. +ถ้าคำสั่ง `git status` มันคลุมเครือเกินไปสำหรับคุณแล้วละก็ คุณจำเป็นต้องรู้ให้ได้จริงๆว่าคุณแก้ไขอะไรลงไป ไม่ใช่แค่รู้ว่าไฟล์ไหนถูกแก้ไขเท่านั้น คุณลองใช้คำสั่ง `git diff`ดู (((git commands, diff))) + ซึ่งเดี๋ยวเราจะไปดูกันในรายละเอียดของ `git diff` ภายหลัง แต่คุณจะต้องใช้มันบ่อยมากๆเพื่อตอบสองคำถามนี้ อะไรที่คุณแก้ไขไปแล้วยังไม่เข้า stage และ อะไรที่คุณเข้า stage และอะไรที่เข้า stage ไปแล้วใช่สิ่งที่จะ commit หรือเปล่า +แม้ว่า `git status` จะตอบคำถามพวกนี้ได้แบบกว้างๆโดยแสดงรายชื่อไฟล์ออกมา แค่คำสั่ง `git diff` จะแสดงให้คุณเห็นจริงๆว่าบรรทัดไหนถูกเพิ่ม บรรทัดไหนถูกลบ การแก้ไขทั้งหมดอย่างที่มันเป็นจริงๆ -Let's say you edit and stage the `README` file again and then edit the `CONTRIBUTING.md` file without staging it. -If you run your `git status` command, you once again see something like this: +ยกตัวอย่างเช่น คุณแก้ไข และเข้า stage ให้ไฟล์ `README` อีกครั้ง จากนั้นคุณก็ไปแก้ไขไฟล์ `CONTRIBUTING.md` โดยไม่เอาเข้า staging ถ้าคุณรันคำสั่ง `git status` คุณจะเห็นอะไรแบบนี้อีกครั้งหนึ่ง: [source,console] ---- @@ -265,7 +263,7 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -To see what you've changed but not yet staged, type `git diff` with no other arguments: +เพื่อจะให้เห็นว่าคุณแก้ไขอะไรไปแล้วยังไม่เอาเข้า stage ลองพิมพ์ `git diff` โดยไม่ต้องใส่อาร์กิวเม้นท์: [source,console] ---- @@ -286,11 +284,9 @@ index 8ebb991..643e24f 100644 that highlights your work in progress (and note in the PR title that it's ---- -That command compares what is in your working directory with what is in your staging area. -The result tells you the changes you've made that you haven't yet staged. +คำสั่งนั้นจะเปรียบเทียบว่าอะไรในไดเร็คทอรี่การทำงานของคุณต่างกับสิ่งที่อยู่ใน staging โดยจะบอกคุณว่าคุณแก้ไขอะไรไปแล้วยังไม่เข้า stage -If you want to see what you've staged that will go into your next commit, you can use `git diff --staged`. -This command compares your staged changes to your last commit: +ถ้าคุณอยากจะเห็นว่าอะไรที่เข้า stage ไปแล้ว และกำลังจะเข้าไปอยู่ใน commit ถัดไป คุณสามารถใช้คำสั่ง `git diff --staged` คำสั่งนี้จะเปรียบเทียบของที่เข้า stage ไปแล้วกับ commit สุดท้ายให้: [source,console] ---- @@ -307,7 +303,7 @@ index 0000000..03902a1 It's important to note that `git diff` by itself doesn't show all changes made since your last commit – only changes that are still unstaged. This can be confusing, because if you've staged all of your changes, `git diff` will give you no output. -For another example, if you stage the `CONTRIBUTING.md` file and then edit it, you can use `git diff` to see the changes in the file that are staged and the changes that are unstaged. If our environment looks like this: +สำหรับตัวอย่างอื่นๆ ถ้าคุณจะนำ `CONTRIBUTING.md`เข้า stage และแก้ไขมัน คุณสามารถใช้ `git diff` เพื่อดูการแก้ไขในไฟล์ที่เป็น staged แล้วว่าอะไรทำให้มันเป็น unstaged ถ้าสิ่งแวดล้อมของเราดูคล้ายๆแบบนี้: [source,console] ---- @@ -327,7 +323,7 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -Now you can use `git diff` to see what is still unstaged +ตอนนี้คุณสามารถใช้ `git diff` เพื่อดูว่าอะไรที่ยังคงไม่เข้า stage ได้ [source,console] ---- @@ -343,7 +339,7 @@ index 643e24f..87f08c8 100644 +# test line ---- -and `git diff --cached` to see what you've staged so far (--staged and --cached are synonyms): +และคำสั่ง `git diff --cached` เพื่อดูว่าอะไรเปลี่ยนไปจนกระทั่งเข้า stage (--staged and --cached are synonyms): [source,console] ---- @@ -364,30 +360,29 @@ index 8ebb991..643e24f 100644 that highlights your work in progress (and note in the PR title that it's ---- -[NOTE] +[บันทึก] .Git Diff in an External Tool ==== -We will continue to use the `git diff` command in various ways throughout the rest of the book. There is another way to look at these diffs if you prefer a graphical or external diff viewing program instead. If you run `git difftool` instead of `git diff`, you can view any of these diffs in software like Araxis, emerge, vimdiff and more. Run `git difftool --tool-help` to see what is available on your system. +เรายังสามารถใช้คำสั่ง `git diff` ในวิธีอื่นได้อีกตลอดการเวลาที่เหลือของหนังสือเล่มนี้ วิธีอื่นที่จะดูความแตกต่าง ถ้าคุณต้องการดูในแบบกราฟฟิค หรือดูผ่านโปรแกรมเฉพาะงานนี้แทน ถ้าคุรัน `git difftool` แทน `git diff` คุณจะได้ดูว่ามีอะไรต่างกันในไฟล์ผ่านโปรแกรมอย่างเช่น Araxis, emerge, vimdiff หรืออย่างอื่น ลองรัน `git difftool --tool-help` เพื่อดูว่ามีอะไรพร้อมให้คุณใช้บ้าง ==== [[_committing_changes]] -==== Committing Your Changes +==== การ commit สิ่งที่แก้ไข -Now that your staging area is set up the way you want it, you can commit your changes. -Remember that anything that is still unstaged – any files you have created or modified that you haven't run `git add` on since you edited them – won't go into this commit. -They will stay as modified files on your disk. -In this case, let's say that the last time you ran `git status`, you saw that everything was staged, so you're ready to commit your changes.(((git commands, status))) -The simplest way to commit is to type `git commit`:(((git commands, commit))) +ตอนนี้ พื้นที่ของ staging ของคุณสร้างขึ้นในแบบที่คุณต้องการ คุณสามารถ commit การเปลี่ยนแปลงของคุณได้ +จำไว้ว่าอะไรก็ตามที่เป็น unstaged คือไฟล์ที่ถูกสร้างขึ้นใหม่ หรือถูกแก้ไขโดยที่ยังไม่ได้รัน `git add` เลยตั้งแต่คุณแก้ไขพวกมัน ซึ่งจะมันจะไม่ไปสู่การ commitได้เลย +ไฟล์พวกนี้จะยังคงเป็นแค่ไฟล์ที่ถูกแก้ไขในดิสต์ของคุณเอง +ในกรณีนี้ สมมุติว่า เมื่อครั้งสุดท้ายที่คุณรันคำสั่ง git status คุณได้เห็นทุกอย่างเข้า stage แล้ว แล้วคุณก็ได้ commit การเปลี่ยนแปลงแล้วด้วย (((git commands, status))) +ทางที่ง่ายที่สุดที่จะ commit คือพิมพ์ว่า `git commit`:(((git commands, commit))) [source,console] ---- $ git commit ---- -Doing so launches your editor of choice. -(This is set by your shell's `$EDITOR` environment variable – usually vim or emacs, although you can configure it with whatever you want using the `git config --global core.editor` command as you saw in <<_getting_started>>).(((editor, changing default)))(((git commands, config))) +การทำแบบนี้จะทำให้เปิด editor ขึ้นมา (ซึ่งถูกเซ็ตไว้ในตัวแปร `$EDITOR` ใน เชลล์ ซึ่งโดยปกติจะเป็น vim หรือ emacs อย่างไรก็ตามคุณสามารถคอนฟิกมันตามต้องการได้โดยใช้คำสั่ง `git config --global core.editor` ดังที่คุณเห็นมาแล้วใน <<_getting_started>>) (((editor, changing default)))(((git commands, config))) -The editor displays the following text (this example is a Vim screen): +editor จะแสดงข้อความตามนี้ (ตัวอย่างนี้เป็นหน้าจอของ vim): [source] ---- @@ -405,13 +400,11 @@ The editor displays the following text (this example is a Vim screen): ".git/COMMIT_EDITMSG" 9L, 283C ---- -You can see that the default commit message contains the latest output of the `git status` command commented out and one empty line on top. -You can remove these comments and type your commit message, or you can leave them there to help you remember what you're committing. -(For an even more explicit reminder of what you've modified, you can pass the `-v` option to `git commit`. -Doing so also puts the diff of your change in the editor so you can see exactly what changes you're committing.) -When you exit the editor, Git creates your commit with that commit message (with the comments and diff stripped out). +โดยปกติคุณจะได้เห็นข้อความของ commit สุดท้ายแสดงในผลลัพธ์ของคำส่ง `git status` ถูกบอกไว้ที่บรรทัดว่างๆบนสุดนี้ +คุณสามารถลบข้อความพวกนี้และพิมพ์ข้อความของ commit ของคุณลงไป หรือจะปล่อยไว้อย่างนั้นเพื่อช่วยเตือนความจำว่าอะไรคือสิ่งที่คุณจะ commit ก็ได้ +(เพื่อย้ำเตือนเวลาที่คุณแก้ไขอะไรลงไป และคุณยังสามารถใส่ค่า `-v` ลงไปในคำสั่ง `git commit` จะทำให้มันใส่การเปลี่ยนแปลงต่างๆเหมือน git diff ลงไปใน editor ให้คุณเห็นเลยว่าจริงๆคุณทำอะไรไว้บ้าง) เมื่อคุณออกจาก editor git จะสร้าง commit พร้อม ข้อความในนั้น (พร้อมข้อความอื่นๆ และเอาสิ่งที่เปลี่ยนแปลงออกไป) -Alternatively, you can type your commit message inline with the `commit` command by specifying it after a -m flag, like this: +หรืออีกวิธีหนึ่ง คุณสามารถพิมพ์ข้อความสำหรับ `commit` ลงไปในบรรทัดของคำสั่ง commit ด้วยการใส่ -m ตามหลังแบบนี้: [source,console] ---- @@ -421,12 +414,12 @@ $ git commit -m "Story 182: Fix benchmarks for speed" create mode 100644 README ---- -Now you've created your first commit! -You can see that the commit has given you some output about itself: which branch you committed to (`master`), what SHA-1 checksum the commit has (`463dc4f`), how many files were changed, and statistics about lines added and removed in the commit. +ถึงตอนนี้คุณก็ได้สร้าง commit แรกแล้ว! +และก็ได้เห็นว่า commit นั้นให้ผลลัพธ์เกี่ยวกับตัวมัน: ว่า branch ไหนที่คุณได้ commit ไป (`master`), SHA-1 checksum เลขอะไรที่มันได้ (`463dc4f`), กี่ไฟล์ที่ถูกแก้ไข, และบรรทัดที่เท่าไหร่บ้างที่ถูกเพิ่ม และถูกลบออกใน commit นี้ -Remember that the commit records the snapshot you set up in your staging area. -Anything you didn't stage is still sitting there modified; you can do another commit to add it to your history. -Every time you perform a commit, you're recording a snapshot of your project that you can revert to or compare to later. +จงจำไว้ว่า commit จะจำ snapshot ที่คุณทำไว้ใน staging ของคุณ +อะไรที่คุณไม่ได้ทำ stage ไว้ก็จะยังคงเป็น modified อยู่แบบเดิม; ซึ่งคุณสามารถทำ commit อื่น เพื่อเพิ่มมันเข้าไว้ในประวัติได้ +ทุกครั้งที่คุณ commit คุณกำลังบันทึก snapshot ของโปรเจคของคุณซึ่งนั่นจะทำให้คุณสามารถย้อนกลับไปหรือกลับไปเปรียบเทียบทีหลังได้ ==== Skipping the Staging Area From a859f698a6ae4eb5ba21553cec7821bf4d4c2424 Mon Sep 17 00:00:00 2001 From: Pallat Anchaleechamaikorn Date: Sat, 14 Mar 2015 21:59:55 +0700 Subject: [PATCH 05/46] remove file --- .../sections/recording-changes.asc | 45 +++++++++---------- 1 file changed, 21 insertions(+), 24 deletions(-) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 64be3ed42..77bb9dfcd 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -421,12 +421,11 @@ $ git commit -m "Story 182: Fix benchmarks for speed" อะไรที่คุณไม่ได้ทำ stage ไว้ก็จะยังคงเป็น modified อยู่แบบเดิม; ซึ่งคุณสามารถทำ commit อื่น เพื่อเพิ่มมันเข้าไว้ในประวัติได้ ทุกครั้งที่คุณ commit คุณกำลังบันทึก snapshot ของโปรเจคของคุณซึ่งนั่นจะทำให้คุณสามารถย้อนกลับไปหรือกลับไปเปรียบเทียบทีหลังได้ -==== Skipping the Staging Area +==== การข้าม staging area (((staging area, skipping))) -Although it can be amazingly useful for crafting commits exactly how you want them, the staging area is sometimes a bit more complex than you need in your workflow. -If you want to skip the staging area, Git provides a simple shortcut. -Adding the `-a` option to the `git commit` command makes Git automatically stage every file that is already tracked before doing the commit, letting you skip the `git add` part: +แม้ว่ามันจะมีประโยชน์มากในการสร้าง commit ตามที่คุณต้องการ แต่ staging area ก็เป็นอะไรที่ยุ่งยากไปบ้างในบางครั้ง +ถ้าคุณต้องการข้าม staging area ละก็ Git ให้ทางลัดโดยเพิ่ม `-a` ลงไปในคำสั่ง `git commit` ซึ่งมันจะสร้าง stage ให้ทุกไฟล์ที่ track แล้วก่อนจะทำการ commit ซึ่งทำให้คุณข้ามขั้นตอนของ `git add` ได้เลย: [source,console] ---- @@ -444,16 +443,16 @@ $ git commit -a -m 'added new benchmarks' 1 file changed, 5 insertions(+), 0 deletions(-) ---- -Notice how you don't have to run `git add` on the ``CONTRIBUTING.md'' file in this case before you commit. +นี่แสดงให้เห็นว่า ทำอย่างไรคุณถึงจะไม่ต้องรันคำสั่ง `git add` ให้กับไฟล์ ``CONTRIBUTING.md'' ในกรณีนี้ก่อนที่คุณจะ commit [[_removing_files]] -==== Removing Files +==== การลบไฟล์ (((files, removing))) -To remove a file from Git, you have to remove it from your tracked files (more accurately, remove it from your staging area) and then commit. -The `git rm` command does that, and also removes the file from your working directory so you don't see it as an untracked file the next time around. +เพื่อที่จะลบไฟล์ออกจาก Git คุณต้องลบมันออกจาก tracked files (หรือที่ถูกต้องคือ ลบมันออกจาก staging area) แล้วก็ commit +คำสั่ง `git rm` คือสิ่งนี้ และมันยังลบไฟล์ออกจาก working directory ให้ด้วย ดังนั้น ในเวลาต่อมาคุณจะไม่เห็นมันเป็น untracked -If you simply remove the file from your working directory, it shows up under the ``Changed but not updated'' (that is, _unstaged_) area of your `git status` output: +ถ้คุณลบมันออกจาก working directory เอง มันจะแสดงว่า ``Changed but not updated'' (มันคือ _unstaged_) ในผลลัพธ์ของ `git status`: [source,console] ---- @@ -470,7 +469,7 @@ Changes not staged for commit: no changes added to commit (use "git add" and/or "git commit -a") ---- -Then, if you run `git rm`, it stages the file's removal: +จากนั้น ถ้าคุณรันคำสั่ง `git rm` มันจะ stages ว่าไฟล์ได้ถูกลบออกไปแล้ว: [source,console] ---- @@ -484,39 +483,37 @@ Changes to be committed: deleted: PROJECTS.md ---- -The next time you commit, the file will be gone and no longer tracked. -If you modified the file and added it to the index already, you must force the removal with the `-f` option. -This is a safety feature to prevent accidental removal of data that hasn't yet been recorded in a snapshot and that can't be recovered from Git. +จากนั้นเมื่อคุณ commit ไฟล์จะหายไปและจะไม่ถูก tracked อีก +ถ้าคุณไปแก้ไขไฟล์นั่น และ เอามันเข้ามาใน index แล้ว คุณต้องบังคับลบมันด้วย `-f` +นี่เป็นแนวทางที่ปลอดภัยที่จะป้องกันการลบข้อมูล โดยไม่ได้บันทึกใน snapshot และมันจะไม่ถูกลบไปจาก Git -Another useful thing you may want to do is to keep the file in your working tree but remove it from your staging area. -In other words, you may want to keep the file on your hard drive but not have Git track it anymore. -This is particularly useful if you forgot to add something to your `.gitignore` file and accidentally staged it, like a large log file or a bunch of `.a` compiled files. -To do this, use the `--cached` option: +หากคุณต้องการเก็บไฟล์ไว้ใน working tree แต่อยากลบมันออกจาก staging area +หรืออีกนัยหนึ่ง คุณอยากเก็บมันไว้ในฮาร์ดไดร์ฟแต่ไม่อยากให้ Git มา track มัน +นี่เป็นประโยชน์สำหรับงานนี้โดยเฉพาะ ถ้าคุณลืมเพิ่มของพวกนี้เข้าไปในไฟล์ `.gitignore` และเผลอไป stage มันเข้าให้ ซึ่งมันอาจจะเป็น log file ขนาดใหญ่มาก หรือเป็นไฟล์ที่คอมไพล์แล้วอย่าง `.a` +ให้ทำแบบนี้คือใช้ตัวช่วย `--cached`: [source,console] ---- $ git rm --cached README ---- -You can pass files, directories, and file-glob patterns to the `git rm` command. -That means you can do things such as +คุณสามารถใช้ ไฟล์, ไดเร็คทอรี่ และ รูปแบบของไฟล์ในคำสั่ง `git rm` +นั่นหมายความว่าคุณสามารถทำแบบนี้ได้ [source,console] ---- $ git rm log/\*.log ---- -Note the backslash (`\`) in front of the `*`. -This is necessary because Git does its own filename expansion in addition to your shell's filename expansion. -This command removes all files that have the `.log` extension in the `log/` directory. -Or, you can do something like this: +ข้อควรจำ backslash (`\`) ที่หน้าดอกจัน `*` เป็นสิ่งจำเป็น เพราะ Git อธิบายชื่อไฟล์ตาม shell ของคุณ +คำสั่งนี้จะลบทุกไฟล์ที่มีนามสกุล `.log` ในไดเร็คทอรี่ `log/` หรือจะทำแบบนี้ก็ได้: [source,console] ---- $ git rm \*~ ---- -This command removes all files that end with `~`. +คำสั่งนี้จะลบทุกไฟล์ที่ลงท้ายด้วย `~` [[_git_mv]] ==== Moving Files From b4391a01723b02abe26107f87f5644a27018025a Mon Sep 17 00:00:00 2001 From: Pallat Anchaleechamaikorn Date: Sat, 13 Jun 2015 21:28:01 +0700 Subject: [PATCH 06/46] moving files --- .../sections/recording-changes.asc | 22 ++++++++----------- 1 file changed, 9 insertions(+), 13 deletions(-) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 77bb9dfcd..040b9cbc0 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -516,23 +516,21 @@ $ git rm \*~ คำสั่งนี้จะลบทุกไฟล์ที่ลงท้ายด้วย `~` [[_git_mv]] -==== Moving Files +==== การย้ายไฟล์ (((files, moving))) -Unlike many other VCS systems, Git doesn't explicitly track file movement. -If you rename a file in Git, no metadata is stored in Git that tells it you renamed the file. -However, Git is pretty smart about figuring that out after the fact – we'll deal with detecting file movement a bit later. - -Thus it's a bit confusing that Git has a `mv` command. -If you want to rename a file in Git, you can run something like +ไม่เหมือนกับระบบ VCS อื่นใด git จะไม่ track การย้ายไฟล์โดยตรง +ถ้าคุณเปลี่ยนชื่อไฟล์ใน git จะไม่มีอะไรบอกมันว่าคุณได้เปลี่ยนชื่อไฟล์ +แต่อย่างไรก็ดี git ฉลาดพอที่จะรู้ว่าสิ่งที่เกิดขึ้นคืออะไร โดยเราจะใช้การตรวจจับการย้ายไฟล์ +ดังนั้น มันจึงค่อนข้างยุ่งนิดหน่อย เพราะว่า git จะใช้คำสั่ง `mv` ถ้าคุณต้องการเปลี่ยนชื่อไฟล์ คุณสามารถใช้คำสั่งแบบนี้ [source,console] ---- $ git mv file_from file_to ---- -and it works fine. -In fact, if you run something like this and look at the status, you'll see that Git considers it a renamed file: +และมันก็ใช้งานได้ดี +ความจริง ถ้าคุณรันคำสั่งแบบนี้แล้วดูผลลัพธ์ คุณจะเห็นว่า git จะบอกว่าคุณได้เปลี่ยนชื่อไฟล์: [source,console] ---- @@ -545,7 +543,7 @@ Changes to be committed: renamed: README.md -> README ---- -However, this is equivalent to running something like this: +และมีอีกวิธีที่ได้ผลลัพธ์แบบเดียวกันตามนี้: [source,console] ---- @@ -554,6 +552,4 @@ $ git rm README.md $ git add README ---- -Git figures out that it's a rename implicitly, so it doesn't matter if you rename a file that way or with the `mv` command. -The only real difference is that `mv` is one command instead of three – it's a convenience function. -More important, you can use any tool you like to rename a file, and address the add/rm later, before you commit. +Git จะรู้ว่านี่เป็นการเปลี่ยนชื่อไฟล์โดยปริยาย ดังนั้นคุณก็ไม่ต้องกังวลว่าคุณจะเปลี่ยนชื่อไฟล์ด้วยวิธีนี่ หรือจะใช้คำสั่ง `mv` เพราะสิ่งที่ต่างกันก็เพียงแค่ คำสั่ง `mv` ก็คือคำสั่งเดียวที่ใช้แทน 3 คำสั่ง มันเป็นวิธีช่วยอำนวยความสำดวกเท่านั้น อีกอย่าง คุณสามารถใช้เครื่องมืออะไรก็ได้ในการเปลี่ยนชื่อไฟล์ แล้วค่อยบอกด้วยคำสั่ง rm และ add ตามหลัง ก่อนที่คุณจะ commit From c1e6d9941a83c030bf737fb74938dc160a24ca61 Mon Sep 17 00:00:00 2001 From: Pallat Anchaleechamaikorn Date: Sat, 13 Jun 2015 21:47:21 +0700 Subject: [PATCH 07/46] git_aliases --- book/02-git-basics/sections/aliases.asc | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/book/02-git-basics/sections/aliases.asc b/book/02-git-basics/sections/aliases.asc index 22b1d5b36..703298820 100644 --- a/book/02-git-basics/sections/aliases.asc +++ b/book/02-git-basics/sections/aliases.asc @@ -1,13 +1,12 @@ [[_git_aliases]] -=== Git Aliases +=== นามแฝงใน git (((aliases))) -Before we finish this chapter on basic Git, there's just one little tip that can make your Git experience simpler, easier, and more familiar: aliases. -We won't refer to them or assume you've used them later in the book, but you should probably know how to use them. +ก่อนจะจบบทนี้ใน git เบื้องต้น นี่คือเกร็ดเล็กน้อย คุณสามารถสร้างประสบการณ์ที่เรียบง่ายขึ้น สะดวกมากขึ้น และคุ้นเคยมากขึ้นด้วย นามแฝง +เราจะไม่คาดหวังว่าคุณจะใช้มันภายหลังจากอ่านหนังสือ แต่คุณควรรู้ว่ามันใช้งานอย่างไร -Git doesn't automatically infer your command if you type it in partially. -If you don't want to type the entire text of each of the Git commands, you can easily set up an alias for each command using `git config`.(((git commands, config))) -Here are a couple of examples you may want to set up: +git จะไม่แนะนำคำสั่งแบบอัตโนมัติเมื่อคุณเริ่มพิมพ์คำสั่ง ถ้าคุณไม่อยากที่จะต้องพิมพ์คำสั่งทั้งหมด คุณสามารถทำให้มันง่ายขึ้นด้วยการตั้งนามแฝงให้คำสั่งด้วยการใช้ `git config`.(((git commands, config))) +และนี่คือตัวอย่างนิดหน่อยที่คุณอาจจะต้องการตั้งค่า: [source,console] ---- From f257d6e4537f44ec22864071252dc4937f0585c5 Mon Sep 17 00:00:00 2001 From: Pallat Anchaleechamaikorn Date: Sat, 4 Jul 2015 18:47:30 +0700 Subject: [PATCH 08/46] git diff - a little part --- book/02-git-basics/sections/recording-changes.asc | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 040b9cbc0..3a33a99b4 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -300,8 +300,9 @@ index 0000000..03902a1 +My Project ---- -It's important to note that `git diff` by itself doesn't show all changes made since your last commit – only changes that are still unstaged. -This can be confusing, because if you've staged all of your changes, `git diff` will give you no output. + +ข้อสำคัญที่ควรจำไว้ว่า `git diff` จะไม่แสดงการแก้ไขเปลี่ยนแปลงทั้งหมดนับจากการ commit ครั้งล่าสุด โดยมันจะแสดงเฉพาะส่วนที่ยังไม่ถูกเข้า stage เท่านั้น +นี่อาจทำให้สับสน เพราะถ้าคุณเอาของที่แก้ไขเข้า stage ไปแล้ว `git diff` จะไม่บอกอะไรคุณเลย สำหรับตัวอย่างอื่นๆ ถ้าคุณจะนำ `CONTRIBUTING.md`เข้า stage และแก้ไขมัน คุณสามารถใช้ `git diff` เพื่อดูการแก้ไขในไฟล์ที่เป็น staged แล้วว่าอะไรทำให้มันเป็น unstaged ถ้าสิ่งแวดล้อมของเราดูคล้ายๆแบบนี้: From e1457fa893aad8be6b46ad65e33d4ada6b5037f3 Mon Sep 17 00:00:00 2001 From: Pallat Anchaleechamaikorn Date: Sat, 4 Jul 2015 19:11:35 +0700 Subject: [PATCH 09/46] alias done --- book/02-git-basics/sections/aliases.asc | 28 ++++++++++++------------- 1 file changed, 13 insertions(+), 15 deletions(-) diff --git a/book/02-git-basics/sections/aliases.asc b/book/02-git-basics/sections/aliases.asc index 703298820..f68786792 100644 --- a/book/02-git-basics/sections/aliases.asc +++ b/book/02-git-basics/sections/aliases.asc @@ -16,35 +16,33 @@ $ git config --global alias.ci commit $ git config --global alias.st status ---- -This means that, for example, instead of typing `git commit`, you just need to type `git ci`. -As you go on using Git, you'll probably use other commands frequently as well; don't hesitate to create new aliases. +ตัวอย่างเช่น แทนที่คุณจะพิมพ์ว่า `git commit` ก็เปลี่ยนเป็น `git ci` แทน +เมื่อคุณใช้ git คุณอาจจะต้องใช้คำสั่งอื่นๆบ่อยเหมือนกัน เพราะฉะนั้น อย่าลังเลที่จะสร้างนามแฝง -This technique can also be very useful in creating commands that you think should exist. -For example, to correct the usability problem you encountered with unstaging a file, you can add your own unstage alias to Git: +ด้วยเทคนิคนี้ คุณยังสามารถใช้มันสร้างคำสั่งที่คุณอยากได้ ที่คุณอยากให้มีเพิ่มขึ้น +ตัวอย่างเช่น เมื่อคุณต้องการแก้ไขปัญหากับไฟล์ที่ยังไม่เข้า stage คุณสามารถเพิ่มนามแฝงใน git แบบนี้: [source,console] ---- $ git config --global alias.unstage 'reset HEAD --' ---- -This makes the following two commands equivalent: - +นี่จะทำให้สองคำสั่งต่อไปนี้มีค่าเท่ากัน: [source,console] ---- $ git unstage fileA $ git reset HEAD fileA ---- -This seems a bit clearer. -It's also common to add a `last` command, like this: +นี่จะทำให้ดูชัดเจนขึ้น +มันจะดูเป็นธรรมชาติเมื่อเพิ่มคำสั่ง `last` แบบนี้ [source,console] ---- $ git config --global alias.last 'log -1 HEAD' ---- -This way, you can see the last commit easily: - +แบบนี้คุณจะเห็น commit สุดท้ายได้ง่ายขึ้น: [source,console] ---- $ git last @@ -57,11 +55,11 @@ Date: Tue Aug 26 19:48:51 2008 +0800 Signed-off-by: Scott Chacon ---- -As you can tell, Git simply replaces the new command with whatever you alias it for. -However, maybe you want to run an external command, rather than a Git subcommand. -In that case, you start the command with a `!` character. -This is useful if you write your own tools that work with a Git repository. -We can demonstrate by aliasing `git visual` to run `gitk`: +git ง่ายที่จะแทนที่คำสั่งใหม่ด้วยนามแฝงที่คุณทำขึ้น +อย่างไรก็ดี คุณอาจจะต้องการรันคำสั่งอื่น แทนที่จะใช้คำสั่งย่อยๆของ git เอง +ในกรณีนี้ คุณน่าจะเริ่มต้นคำสั่งด้วยอักษร `!` +นี่จะเป็นประโยชน์ถ้าคุณเขียนเครื่องมือมาใช้กับ repo ของคุณ +โดยเราสามารถทดลองตั้งชื่อ `git visual` ใหม่ด้วย `gitk`: [source,console] ---- From feb2dfa8736d40b0e00862879e90b527297e5618 Mon Sep 17 00:00:00 2001 From: Pallat Anchaleechamaikorn Date: Sat, 4 Jul 2015 20:38:07 +0700 Subject: [PATCH 10/46] begin with remotes --- book/02-git-basics/sections/remotes.asc | 33 +++++++++++++------------ 1 file changed, 17 insertions(+), 16 deletions(-) diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index dc6d1ca70..95b47c51a 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -1,18 +1,18 @@ [[_remote_repos]] -=== Working with Remotes +=== การทำงานกับ remotes -To be able to collaborate on any Git project, you need to know how to manage your remote repositories. -Remote repositories are versions of your project that are hosted on the Internet or network somewhere. -You can have several of them, each of which generally is either read-only or read/write for you. -Collaborating with others involves managing these remote repositories and pushing and pulling data to and from them when you need to share work. -Managing remote repositories includes knowing how to add remote repositories, remove remotes that are no longer valid, manage various remote branches and define them as being tracked or not, and more. -In this section, we'll cover some of these remote-management skills. +เพื่อให้สามารถทำงานร่วมกันใน git คุณต้องรู้ว่าจะจัดการการ remote ไปยัง repo ได้อย่างไร +Remote repository เป็นการทำเวอร์ชั่นของโปรเจ็คคุณบน internet หรือ ที่ใดสักแห่งในเน็ตเวิร์ก +และคุณจะทำมันมากแค่ไหนก็ได้ แต่ละเวอร์ชั่น จะทำเป็นแบบ อ่านได้อย่างเดียว หรือแบบ อ่านและเขียนด้วยก็ได้ +การทำงานร่วมกับคนอื่น โดยการจัดการ repo แบบ remote นี้ ทำให้การ push และ pull สามารทำได้เมื่อคุณต้องการแชร์งาน +การจัดการ repo แบบ remote นี้รวมถึงความรู้ว่าจะเพิ่ม remote repositories หรือลบ อย่างไรให้ถูกต้อง และจัดการ branch ของ remote อีกจำนวนมากอย่างไร และทำอย่างไรที่จะระบุว่ามันถูก track แล้วหรือยัง +ในบทนี้ เราจะกล่าวรวมไปถึงความรู้บางส่วนในการจัดการการ remote อีกด้วย -==== Showing Your Remotes +==== การแสดง remotes ของคุณ -To see which remote servers you have configured, you can run the `git remote` command.(((git commands, remote))) -It lists the shortnames of each remote handle you've specified. -If you've cloned your repository, you should at least see origin – that is the default name Git gives to the server you cloned from: +เพื่อจะเห็นว่าคุณมี remote อะไรบ้าง ให้ใช้คำสั่ง `git remote` (((git commands, remote))) +มันจะแสดงรายการ remote ที่คุณมีอยู่ ออกมาเป็นชื่อแบบสั้น +ถ้าคุณมี repo ที่โคลนมา อย่างน้อย คุณควรเห็น origin - ซึ่งเป็นค่าเริ่มต้นของชื่อ ที่ git ตั้งให้กับ server ที่คุณโคลน repo มา [source,console] ---- @@ -28,7 +28,7 @@ $ git remote origin ---- -You can also specify `-v`, which shows you the URLs that Git has stored for the shortname to be used when reading and writing to that remote: +คุณยังสามารถใช้ `-v` เพื่อให้แสดงว่า URLs ของ remote คืออะไร [source,console] ---- @@ -37,8 +37,8 @@ origin https://github.com/schacon/ticgit (fetch) origin https://github.com/schacon/ticgit (push) ---- -If you have more than one remote, the command lists them all. -For example, a repository with multiple remotes for working with several collaborators might look something like this. +ถ้าคุณมี remote มากกว่าหนึ่ง คำสั่งนี้จะแสดงออกมาทั้งหมด +ตัวอย่างเช่น มี repo หนึ่ง มีหลาย remote สำหรับทำงานกับคนหลายกลุ่ม อาจจะให้ผลลัพธ์แบบนี้ [source,console] ---- @@ -56,9 +56,10 @@ origin git@github.com:mojombo/grit.git (fetch) origin git@github.com:mojombo/grit.git (push) ---- -This means we can pull contributions from any of these users pretty easily. We may additionally have permission to push to one or more of these, though we can't tell that here. +หมายความว่าคุณสามารถ pull งานได้จากทุกๆที่ในรายการนี้ แถมยังง่ายด้วย +เราอาจจะเพิ่มเรื่องสิทธิในการ push สำหรับ repo ใดก็ได้ในนี้ แต่เรายังไม่กล่าวถึงมันที่นี่ -Notice that these remotes use a variety of protocols; we'll cover more about this in <<_git_on_the_server>>. +ข้อสังเกตคือ remote พวกนี้ใช้โปรโตคอลหลายแบบ ซึ่งเราจะให้รายละเอียดในเรื่องนี้ต่อที่ <<_git_on_the_server>> ==== Adding Remote Repositories From 0572d9d6a37d33a561d383f114c8ca26c557b812 Mon Sep 17 00:00:00 2001 From: Pallat Date: Sun, 26 Jul 2015 22:23:03 +0700 Subject: [PATCH 11/46] add remote --- book/02-git-basics/sections/remotes.asc | 37 +++++++++++++------------ 1 file changed, 19 insertions(+), 18 deletions(-) diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index 95b47c51a..97cb6627c 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -5,7 +5,7 @@ Remote repository เป็นการทำเวอร์ชั่นของโปรเจ็คคุณบน internet หรือ ที่ใดสักแห่งในเน็ตเวิร์ก และคุณจะทำมันมากแค่ไหนก็ได้ แต่ละเวอร์ชั่น จะทำเป็นแบบ อ่านได้อย่างเดียว หรือแบบ อ่านและเขียนด้วยก็ได้ การทำงานร่วมกับคนอื่น โดยการจัดการ repo แบบ remote นี้ ทำให้การ push และ pull สามารทำได้เมื่อคุณต้องการแชร์งาน -การจัดการ repo แบบ remote นี้รวมถึงความรู้ว่าจะเพิ่ม remote repositories หรือลบ อย่างไรให้ถูกต้อง และจัดการ branch ของ remote อีกจำนวนมากอย่างไร และทำอย่างไรที่จะระบุว่ามันถูก track แล้วหรือยัง +การจัดการ repo แบบ remote นี้รวมถึงความรู้ว่าจะเพิ่ม remote repositories หรือลบ อย่างไรให้ถูกต้อง และจัดการ branch ของ remote อีกจำนวนมากอย่างไร และทำอย่างไรที่จะระบุว่ามันถูก track แล้วหรือยัง ในบทนี้ เราจะกล่าวรวมไปถึงความรู้บางส่วนในการจัดการการ remote อีกด้วย ==== การแสดง remotes ของคุณ @@ -56,15 +56,15 @@ origin git@github.com:mojombo/grit.git (fetch) origin git@github.com:mojombo/grit.git (push) ---- -หมายความว่าคุณสามารถ pull งานได้จากทุกๆที่ในรายการนี้ แถมยังง่ายด้วย +หมายความว่าคุณสามารถ pull งานได้จากทุกๆที่ในรายการนี้ แถมยังง่ายด้วย เราอาจจะเพิ่มเรื่องสิทธิในการ push สำหรับ repo ใดก็ได้ในนี้ แต่เรายังไม่กล่าวถึงมันที่นี่ -ข้อสังเกตคือ remote พวกนี้ใช้โปรโตคอลหลายแบบ ซึ่งเราจะให้รายละเอียดในเรื่องนี้ต่อที่ <<_git_on_the_server>> +ข้อสังเกตคือ remote พวกนี้ใช้โปรโตคอลหลายแบบ ซึ่งเราจะให้รายละเอียดในเรื่องนี้ต่อที่ <<_git_on_the_server>> -==== Adding Remote Repositories +==== การเพิ่มรีโมทให้ repositories -We've mentioned and given some demonstrations of adding remote repositories in previous sections, but here is how to do it explicitly.(((git commands, remote))) -To add a new remote Git repository as a shortname you can reference easily, run `git remote add [shortname] [url]`: +เราได้กล่าวถึงเรื่องนี้และได้สาธิตให้เห็นการเพิ่มรีโมทให้กับ repositories กันมาแล้วก่อนหน้านี้ แต่ตอนนี้เราจะทำให้ชัดเจนขึ้น +ด้วยการเพิ่มรีโมทและตั้งชื่อย่อ เพื่อให้ง่ายสำหรับอ้างถึงด้วยการรันคำสั่ง `git remote add [shortname] [url]`: [source,console] ---- @@ -78,8 +78,8 @@ pb https://github.com/paulboone/ticgit (fetch) pb https://github.com/paulboone/ticgit (push) ---- -Now you can use the string `pb` on the command line in lieu of the whole URL. -For example, if you want to fetch all the information that Paul has but that you don't yet have in your repository, you can run `git fetch pb`: +ทีนี่คุณก็สามารถใช้ `pb` ในคำสั่ง แทนที่จะใช้ URL เต็มๆได้แล้ว +ตัวอย่างเช่น ถ้าคุณต้องการจะ fetch (ดึงค่าของ repositories ล่าสุดลงมาจากรีโมท) ข้อมูลที่ Paul มี แต่คุณยังไม่มีใน repo คุณสามารถใช้คำสั่ง `git fetch pb`: [source,console] ---- @@ -93,27 +93,28 @@ From https://github.com/paulboone/ticgit * [new branch] ticgit -> pb/ticgit ---- -Paul's master branch is now accessible locally as `pb/master` – you can merge it into one of your branches, or you can check out a local branch at that point if you want to inspect it. -(We'll go over what branches are and how to use them in much more detail in <<_git_branching>>.) +ทีนี้ใน local repo ของคุณก็จะสามารถเข้าถึง branch ชื่อ master ของ Paul ได้ด้วยชื่อ `pb/master` คุณอยากจะ merge มันเข้ากับ branch ไหนของคุณ หรือ คุณอยากจะ check out ไปที่ branch นั้นเพื่อจะตรวจดูเลยก็ได้ +(เราจะไปใน branch ต่างๆและทำอะไรกับมันได้เยอะแยะต่อใน <<_git_branching>>.) [[_fetching_and_pulling]] -==== Fetching and Pulling from Your Remotes +==== การ fetch และการ pull จากรีโมท -As you just saw, to get data from your remote projects, you can run:(((git commands, fetch))) +อย่างที่เห็น เราดึงข้อมูลจากรีโมทโปรเจ็คได้ด้วยคำสั่ง : (((git commands, fetch))) [source,console] ---- $ git fetch [remote-name] ---- -The command goes out to that remote project and pulls down all the data from that remote project that you don't have yet. -After you do this, you should have references to all the branches from that remote, which you can merge in or inspect at any time. +คำสั่งนี้จะไปดึงข้อมูลของโปรเจ็คจากรีโมทที่คุณยังไม่มีลงมาที่โลคอลให้ +หลังจากคำสั่งนี้ คุณจะสามารถเข้าถึง branch ทั้งหมดที่มีในรีโมท ทำให้สามารถ merge หรือตรวจสอบข้อมูลใน branch พวกนั้นได้ตลอดเวลา -If you clone a repository, the command automatically adds that remote repository under the name ``origin''. -So, `git fetch origin` fetches any new work that has been pushed to that server since you cloned (or last fetched from) it. -It's important to note that the `git fetch` command pulls the data to your local repository – it doesn't automatically merge it with any of your work or modify what you're currently working on. -You have to merge it manually into your work when you're ready. +ถ้าคุณ clone repo อะไรมาก็ตาม คำสั่ง clone จะเพิ่มรีโมทให้ repo นั้นอัตโนมัติและตั้งชื่อว่า ``origin'' +ดังนั้นคำสั่ง `git fetch origin` จะดึงข้อมูลใหม่ทั้งหมด นับตั้งแต่คุณ clone มันลงมา (หรือนับตั้งแต่ครั้งสุดท้ายที่คุณใช้คำสั่ง fetch) +ข้อสำคัญที่ต้องจำไว้คือ `git fetch`  จะดึงข้อมูลลงมาที่ local ให้ก็จริง แต่มันไม่ได้ merge ข้อมูลให้อัตโนมัติ +คุณจะต้องสั่ง merge เองเมื่อคุณต้องการ +ถ้าคุณมี branch ที่สร้างมาเพื่อทำงานกับ branch บนรีโมทโดยตรงßß If you have a branch set up to track a remote branch (see the next section and <<_git_branching>> for more information), you can use the `git pull` command to automatically fetch and then merge a remote branch into your current branch.(((git commands, pull))) This may be an easier or more comfortable workflow for you; and by default, the `git clone` command automatically sets up your local master branch to track the remote master branch (or whatever the default branch is called) on the server you cloned from. Running `git pull` generally fetches data from the server you originally cloned from and automatically tries to merge it into the code you're currently working on. From 8f94dc14de8f3b68ce6f8f147bcf1d02019055f0 Mon Sep 17 00:00:00 2001 From: Pallat Anchaleechamaikorn Date: Sun, 9 Aug 2015 11:21:18 +0700 Subject: [PATCH 12/46] finished fetching and pulling --- book/02-git-basics/sections/remotes.asc | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index 97cb6627c..900b23262 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -114,10 +114,8 @@ $ git fetch [remote-name] ข้อสำคัญที่ต้องจำไว้คือ `git fetch`  จะดึงข้อมูลลงมาที่ local ให้ก็จริง แต่มันไม่ได้ merge ข้อมูลให้อัตโนมัติ คุณจะต้องสั่ง merge เองเมื่อคุณต้องการ -ถ้าคุณมี branch ที่สร้างมาเพื่อทำงานกับ branch บนรีโมทโดยตรงßß -If you have a branch set up to track a remote branch (see the next section and <<_git_branching>> for more information), you can use the `git pull` command to automatically fetch and then merge a remote branch into your current branch.(((git commands, pull))) -This may be an easier or more comfortable workflow for you; and by default, the `git clone` command automatically sets up your local master branch to track the remote master branch (or whatever the default branch is called) on the server you cloned from. -Running `git pull` generally fetches data from the server you originally cloned from and automatically tries to merge it into the code you're currently working on. +ถ้าคุณสร้าง branch ที่เอาไว้ใช้ทำงานกับ รีโมทโดยตรง (ให้อ่านตอนถัดไป และ <<_git_branching> เพื่อดูรายละเอียดเพิ่มเติม) คุณสามารถใช้คำสั่ง `git pull` เพื่อดึงของจากรีโมทลงมา merge กับของใน branch ได้เลย (((git commands, pull))) หรือจะใช้อีกวิธีที่ง่ายกว่า ด้วยคำสั่ง `git clone` มันจะสร้าง branch ของ master ที่ local สำหรับติดตาม (track) master branch บนรีโมทให้แบบเบ็ดเสร็จ (อาจจะเป็น branch อะไรก็ได้ที่เป็นค่าตั้งต้น แล้วแต่จะเรียก) ตามเซิร์ฟเวอร์ที่เราโคลนลงมา +โดยปกติการสั่ง `git pull` จะเป็นการดึงข้อมูลจากเซิร์ฟเวอร์ที่โคลนมา และมันจะพยายาม merge ของเข้ากับงานที่คุณทำอยู่ให้ทันที [[_pushing_remotes]] ==== Pushing to Your Remotes From a05012625b3d69ebb4e01477da74e81567e20c51 Mon Sep 17 00:00:00 2001 From: Pallat Anchaleechamaikorn Date: Sun, 9 Aug 2015 11:32:17 +0700 Subject: [PATCH 13/46] completed pushing remotes --- book/02-git-basics/sections/remotes.asc | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index 900b23262..04dc93ff0 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -118,21 +118,20 @@ $ git fetch [remote-name] โดยปกติการสั่ง `git pull` จะเป็นการดึงข้อมูลจากเซิร์ฟเวอร์ที่โคลนมา และมันจะพยายาม merge ของเข้ากับงานที่คุณทำอยู่ให้ทันที [[_pushing_remotes]] -==== Pushing to Your Remotes +==== การ push ของขึ้นไปบนรีโมท -When you have your project at a point that you want to share, you have to push it upstream. -The command for this is simple: `git push [remote-name] [branch-name]`.(((git commands, push))) -If you want to push your master branch to your `origin` server (again, cloning generally sets up both of those names for you automatically), then you can run this to push any commits you've done back up to the server: +เมื่อคุณทำงานถึงจุดที่ต้องการจะแชร์ของในโปรเจค คุณจะต้อง push มันขึ้นไปที่ต้นทาง ด้วยคำสั่งง่ายๆ `git push [remote-name] [branch-name]`.(((git commands, push))) +เช่น ถ้าคุณต้องการ push ของใน branch master ไปที่ server ชื่อ `origin` (ขอบอกอีกครั้งว่า เมื่อคุณโคลนของลงมา ชื่อ origin และ master จะถูกสร้างให้เองทันที) เมื่อคุณรันคำสั่งนี้ มันจะ push ของทุก commits ที่คุณมี ขึ้นไปเก็บไว้บนเซิร์ฟเวอร์ทันที [source,console] ---- $ git push origin master ---- -This command works only if you cloned from a server to which you have write access and if nobody has pushed in the meantime. -If you and someone else clone at the same time and they push upstream and then you push upstream, your push will rightly be rejected. -You'll have to pull down their work first and incorporate it into yours before you'll be allowed to push. -See <<_git_branching>> for more detailed information on how to push to remote servers. +คำสั่งนี้จะสำเร็จก็ต่อเมื่อ คุณมีสิทธิ์เข้าถึงเซิร์ฟเวอร์นั้นได้ และไม่มีใคร push ของตัดหน้าคุณก่อน +ซึ่งถ้ามีใครสักคน โคลนของมาจากที่เดียวกับคุณ แล้วเขาก็ push ของก่อนคุณ คำสั่ง push ของคุณจะถูกปฏิเสธ +คุณก็จะต้อง pull ของลงมาใหม่ก่อน เพื่อรวมของเข้าด้วยกัน มันจึงจะยอมให้คุณ push ได้ +โปรดอ่าน <<_git_branching>> สำหรับรายละเอียดว่าทำอย่างไรเมื่อต้อง push ของเข้า รีโมท [[_inspecting_remote]] ==== Inspecting a Remote From 0468aad0be6ab3e1cef72444529af408b310ebcc Mon Sep 17 00:00:00 2001 From: Pallat Anchaleechamaikorn Date: Sun, 9 Aug 2015 12:01:20 +0700 Subject: [PATCH 14/46] completed _inspecting_remote --- book/02-git-basics/sections/remotes.asc | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index 04dc93ff0..55bb3d507 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -134,10 +134,10 @@ $ git push origin master โปรดอ่าน <<_git_branching>> สำหรับรายละเอียดว่าทำอย่างไรเมื่อต้อง push ของเข้า รีโมท [[_inspecting_remote]] -==== Inspecting a Remote +==== การตรวจสอบรีโมท -If you want to see more information about a particular remote, you can use the `git remote show [remote-name]` command.(((git commands, remote))) -If you run this command with a particular shortname, such as `origin`, you get something like this: +ถ้าคุณต้องการดูข้อมูลเกี่ยวกับ รีโมทใดก็ตาม คุณสามารถสั่ง `git remote show [remote-name]` command.(((git commands, remote))) +ถ้าคุณรันคำสั่งนี้ ด้วยชื่อย่อเช่น `origin` คุณจะได้ข้อมูลทำนองนี้ [source,console] ---- @@ -155,12 +155,10 @@ $ git remote show origin master pushes to master (up to date) ---- -It lists the URL for the remote repository as well as the tracking branch information. -The command helpfully tells you that if you're on the master branch and you run `git pull`, it will automatically merge in the master branch on the remote after it fetches all the remote references. -It also lists all the remote references it has pulled down. +มันจะแสดงรายการของ URL ตลอดจนข้อมูลของ branch ที่ถูกติดตามอยู่ +คำสั่งนี้มีประโยชน์มาก มันบอกคุณว่าถ้าคุณทำงานบน master branch และคุณรันคำสั่ง `git pull` มันจะ merge ของเข้า master branch ให้ทันทีหลังจากที่มันดึงของทั้งหมดที่ รีโมทอ้างถึง และยังแสดงการอ้างถึงทั้งหมดที่มันดึงลงมาให้ด้วย -That is a simple example you're likely to encounter. -When you're using Git more heavily, however, you may see much more information from `git remote show`: +นั่นเป็นตัวอย่างง่ายๆที่คุณอาจจะได้เจอ เมื่อคุณใช้ Git อย่างโชกโชน จนทำให้คุณเห็นข้อมูลมากขึ้นจากคำสั่ง `git remote show` [source,console] ---- @@ -186,8 +184,8 @@ $ git remote show origin master pushes to master (up to date) ---- -This command shows which branch is automatically pushed to when you run `git push` while on certain branches. -It also shows you which remote branches on the server you don't yet have, which remote branches you have that have been removed from the server, and multiple branches that are automatically merged when you run `git pull`. +คำสั่งนี้จะแสดงให้เห็นว่ามี branch ไหนที่จะถูก push เมื่อคุณรันคำสั่ง `git push` while on certain branches. +และยังบอกอีกว่า รีโมท branch ไหนบนเซิร์ฟเวอร์ที่คุณยังไม่มี และ branch ไหนบ้างที่คุณมีอยู่ แต่ถูกลบไปแล้วบนเซิร์ฟเวอร์ และ branch ไหนบ้างที่จะถูก merge เมื่อคุณรันคำสั่ง `git pull` ==== Removing and Renaming Remotes From 0a5cba8d17d7260be7209fee89f02ed4fdce764a Mon Sep 17 00:00:00 2001 From: Pallat Anchaleechamaikorn Date: Sun, 9 Aug 2015 13:01:10 +0700 Subject: [PATCH 15/46] fix inspecing remote --- book/02-git-basics/sections/remotes.asc | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index 55bb3d507..a12e0dcf7 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -184,8 +184,7 @@ $ git remote show origin master pushes to master (up to date) ---- -คำสั่งนี้จะแสดงให้เห็นว่ามี branch ไหนที่จะถูก push เมื่อคุณรันคำสั่ง `git push` while on certain branches. -และยังบอกอีกว่า รีโมท branch ไหนบนเซิร์ฟเวอร์ที่คุณยังไม่มี และ branch ไหนบ้างที่คุณมีอยู่ แต่ถูกลบไปแล้วบนเซิร์ฟเวอร์ และ branch ไหนบ้างที่จะถูก merge เมื่อคุณรันคำสั่ง `git pull` +คำสั่งนี้จะแสดงให้เห็นว่ามี branch ไหนที่จะถูก push เมื่อคุณรันคำสั่ง git push ในขณะที่คุณอยู่ที่ branch นั้น และยังบอกอีกว่า รีโมท branch ไหนบนเซิร์ฟเวอร์ที่คุณยังไม่มี และ branch ไหนบ้างที่คุณมีอยู่ แต่ถูกลบไปแล้วบนเซิร์ฟเวอร์ และ branch ไหนบ้างที่จะถูก merge เมื่อคุณรันคำสั่ง git pullสั่ง `git pull` ==== Removing and Renaming Remotes From 3770105e3635bbcb57b654e5207cba3b35e076c4 Mon Sep 17 00:00:00 2001 From: Pallat Anchaleechamaikorn Date: Sun, 9 Aug 2015 13:30:17 +0700 Subject: [PATCH 16/46] renaming and removing remotes --- book/02-git-basics/sections/remotes.asc | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index a12e0dcf7..98cd43e6f 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -186,10 +186,12 @@ $ git remote show origin คำสั่งนี้จะแสดงให้เห็นว่ามี branch ไหนที่จะถูก push เมื่อคุณรันคำสั่ง git push ในขณะที่คุณอยู่ที่ branch นั้น และยังบอกอีกว่า รีโมท branch ไหนบนเซิร์ฟเวอร์ที่คุณยังไม่มี และ branch ไหนบ้างที่คุณมีอยู่ แต่ถูกลบไปแล้วบนเซิร์ฟเวอร์ และ branch ไหนบ้างที่จะถูก merge เมื่อคุณรันคำสั่ง git pullสั่ง `git pull` -==== Removing and Renaming Remotes +==== การลบและเปลี่ยนชื่อรีโมท -If you want to rename a reference you can run `git remote rename` to change a remote's shortname.(((git commands, remote))) -For instance, if you want to rename `pb` to `paul`, you can do so with `git remote rename`: +ถ้าคุณต้องการเปลี่ยนชื่อที่อ้างถึงรีโมท คุณสามารถใช้คำสั่ง + `git remote rename` เพื่อเปลี่ยนชื่อที่อ้างถึงรีโมท (((git commands, remote))) + +ตัวอย่างเช่น ถ้าคุณต้องการเปลี่ยนชื่อ `pb` ไปเป็น `paul`คุณสามารถทำมันด้วยคำสั่ง `git remote rename`: [source,console] ---- @@ -199,10 +201,10 @@ origin paul ---- -It's worth mentioning that this changes your remote branch names, too. -What used to be referenced at `pb/master` is now at `paul/master`. +มันเปลี่ยนชื่อรีโมท branch ของคุณด้วยนะ +จากที่เคยอ้างถึง `pb/master` ตอนนี้เปลี่ยนเป็น `paul/master` แล้ว -If you want to remove a remote for some reason – you've moved the server or are no longer using a particular mirror, or perhaps a contributor isn't contributing anymore – you can use `git remote rm`: +ถ้าคุณต้องการจะลบรีโมท ไม่ว่าจะด้วยเหตุผลอะไรก็ตาม เช่น คุณย้ายเซิร์ฟเวอร์ หรือ จะไม่ใช้ทำงานต่อแล้ว หรืออาจเป็นเพราะ ผู้ที่รับผิดชอบโปรเจ็ค ไม่ดูและต่อแล้ว คุณสามารถใช้คำสั่ง `git remote rm`: [source,console] ---- @@ -210,3 +212,4 @@ $ git remote rm paul $ git remote origin ---- + From 51ffec540e0a03e90d192adf515b9a4ac3f03ea8 Mon Sep 17 00:00:00 2001 From: Pallat Anchaleechamaikorn Date: Sun, 9 Aug 2015 13:57:49 +0700 Subject: [PATCH 17/46] some of part of tag creating --- book/02-git-basics/sections/tagging.asc | 28 ++++++++++++------------- 1 file changed, 13 insertions(+), 15 deletions(-) diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index 980ab0043..15e5cfd41 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -1,15 +1,15 @@ [[_git_tagging]] -=== Tagging +=== การติดแท็ก(tags) (((tags))) -Like most VCSs, Git has the ability to tag specific points in history as being important. -Typically people use this functionality to mark release points (v1.0, and so on). -In this section, you'll learn how to list the available tags, how to create new tags, and what the different types of tags are. +ก็ไม่ต่างจากระบบ VCSs อื่นๆ Git สามารถติดแท็กลงไปตรงจุดที่ต้องการโดยเฉพาะเพื่อระบุความสำคัญลงไปใน history +โดยปกติแล้ว เราจะใช้ฟังก์ชั่นนี้เพื่อ กำหนดจุดที่จะปล่อยของ(release) (v1.0 และอื่นๆ) +ทีนี้เราก็จะมาเรียนวิธีที่จะขอดูรายชื่อแท็ก วิธีสร้างแท็ก และความแตกต่างของแท็กว่ามีชนิดไหนบ้างกัน -==== Listing Your Tags +==== แสดงรายการที่คุณแท็กไว้ -Listing the available tags in Git is straightforward. -Just type `git tag`:(((git commands, tag))) +การแสดงรายการแท็กใน Git ไม่อ้อมค้อมครับ แค่พิมพ์คำสั่ง +`git tag`:(((git commands, tag))) [source,console] ---- @@ -18,11 +18,9 @@ v0.1 v1.3 ---- -This command lists the tags in alphabetical order; the order in which they appear has no real importance. +คำสั่งนี้จะแสดงรายชื่อแท็กโดยเรียงตามตัวอักษร; โดยลำดับที่ปรากฎไม่ได้เรียกตามความสำคัญใดๆ -You can also search for tags with a particular pattern. -The Git source repo, for instance, contains more than 500 tags. -If you're only interested in looking at the 1.8.5 series, you can run this: +คุณสามารถค้นหาแท็กได้ด้วยการเจาะจงรูปแบบ เช่น ใน repo มีมากกว่า 500 แท็ก ถ้าคุณสนใจที่จะมองหาแถวๆลำดับที่ 1.8.5 คุณสามารถใช้คำสั่งดังนี้: [source,console] ---- @@ -39,13 +37,13 @@ v1.8.5.4 v1.8.5.5 ---- -==== Creating Tags +==== การสร้างแท็ก -Git uses two main types of tags: lightweight and annotated. +ปกติ Git จะใช้แท็กอยู่สองชนิดหลักๆคือ : lightweight และ annotated. -A lightweight tag is very much like a branch that doesn't change – it's just a pointer to a specific commit. +แท็กแบบ lightweight จะเหมือนกับ branch มากซึ่งมันจะไม่มีการเปลี่ยนแปลง และมันเป็นแค่การกำหนดความสำคัญลงไปที่ commit นั้นๆ -Annotated tags, however, are stored as full objects in the Git database. +แท็กแบบ Annotated จะเก็บทุก object ลงในฐานข้อมูลของ Git They're checksummed; contain the tagger name, e-mail, and date; have a tagging message; and can be signed and verified with GNU Privacy Guard (GPG). It's generally recommended that you create annotated tags so you can have all this information; but if you want a temporary tag or for some reason don't want to keep the other information, lightweight tags are available too. From 3400da1748283e09e5d86df1b85865462018b3b1 Mon Sep 17 00:00:00 2001 From: Pallat Anchaleechamaikorn Date: Sun, 9 Aug 2015 16:05:37 +0700 Subject: [PATCH 18/46] create tag --- book/02-git-basics/sections/tagging.asc | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index 15e5cfd41..f200c1f24 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -44,8 +44,15 @@ v1.8.5.5 แท็กแบบ lightweight จะเหมือนกับ branch มากซึ่งมันจะไม่มีการเปลี่ยนแปลง และมันเป็นแค่การกำหนดความสำคัญลงไปที่ commit นั้นๆ แท็กแบบ Annotated จะเก็บทุก object ลงในฐานข้อมูลของ Git -They're checksummed; contain the tagger name, e-mail, and date; have a tagging message; and can be signed and verified with GNU Privacy Guard (GPG). -It's generally recommended that you create annotated tags so you can have all this information; but if you want a temporary tag or for some reason don't want to keep the other information, lightweight tags are available too. +==== การสร้างแท็ก + +ปกติ Git จะใช้แท็กอยู่สองชนิดหลักๆคือ : lightweight และ annotated. + +แท็กแบบ lightweight จะเหมือนกับ branch มากซึ่งมันจะไม่มีการเปลี่ยนแปลง และมันเป็นแค่การกำหนดความสำคัญลงไปที่ commit นั้นๆ + +แท็กแบบ Annotated จะเก็บทุก object ลงในฐานข้อมูลของ Git +โดยมันจะถูก checksummed จากสิ่งที่ถูกเก็บไว้ ไม่ว่าจะเป็น ชื่อแท็ก อีเมล์ และวันที่ มีข้อความที่ติดแท็ก และสามารถลงนามและตรวจสอบได้ตามมาตรฐาน GPG +คำแนะนำโดยทั่วไป เมื่อคุณสร้าง annotated tags คุณสามารถเก็บรายละเอียดทั้งหมดนี้ไว้ได้ แต่ถ้าคุณต้องการติดแท็กแค่ชั่วคราว หรือด้วยเหตุผลอะไรก็ตามที่คุณไม่ต้องการเก็บข้อมูลอื่นๆเลย การใช้ lightweight tags น่าจะเป็นทางเลือกที่เหมาะสมกว่า [[_annotated_tags]] ==== Annotated Tags From 7159d5e2cb36e587239a5e2cec22e2a1f64d6baf Mon Sep 17 00:00:00 2001 From: Pallat Anchaleechamaikorn Date: Sun, 9 Aug 2015 16:18:25 +0700 Subject: [PATCH 19/46] Annotated Tags --- book/02-git-basics/sections/tagging.asc | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index f200c1f24..967223388 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -58,8 +58,7 @@ v1.8.5.5 ==== Annotated Tags (((tags, annotated))) -Creating an annotated tag in Git is simple. -The easiest way is to specify `-a` when you run the `tag` command:(((git commands, tag))) +การสร้างแท็กแบบ annotated ใน Git ทำได้ง่ายมาก โดยการใส่ `-a` เวลารันคำสั่ง `tag` :(((git commands, tag))) [source,console] ---- @@ -70,10 +69,10 @@ v1.3 v1.4 ---- -The `-m` specifies a tagging message, which is stored with the tag. -If you don't specify a message for an annotated tag, Git launches your editor so you can type it in. +`-m` ใช้สำหรับระบุข้อความที่จะเก็บไว้กับแท็กนั้น +ถ้าคุณไม่ระบุข้อความลงไป Git จะเปิด editor ขึ้นมาให้คุณใส่ข้อความลงไป -You can see the tag data along with the commit that was tagged by using the `git show` command: +คุณสามารถดูข้อมูลของแท็ก พร้อมกับ commit ที่ถูกติดแท็กได้โดยใช้คำสั่ง`git show`: [source,console] ---- @@ -91,7 +90,7 @@ Date: Mon Mar 17 21:52:11 2008 -0700 changed the version number ---- -That shows the tagger information, the date the commit was tagged, and the annotation message before showing the commit information. +ผลลัพธ์แสดงให้เห็นข้อมูลผู้ที่ติดแท็ก วันที่ที่ commit ถูกแท็ก และข้อความของ annotated ก่อนจะแสดงรายละเอียดของ commit ==== Lightweight Tags From 20c50f409ce20ef6106642038203fe2217ed0de9 Mon Sep 17 00:00:00 2001 From: Pallat Anchaleechamaikorn Date: Sun, 9 Aug 2015 16:25:04 +0700 Subject: [PATCH 20/46] Lightweight Tags --- book/02-git-basics/sections/tagging.asc | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index 967223388..7c43c75d9 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -95,9 +95,9 @@ Date: Mon Mar 17 21:52:11 2008 -0700 ==== Lightweight Tags (((tags, lightweight))) -Another way to tag commits is with a lightweight tag. -This is basically the commit checksum stored in a file – no other information is kept. -To create a lightweight tag, don't supply the `-a`, `-s`, or `-m` option: +อีกทางเลือกหนึ่งของการแท็กคือติดแบบ lightweight +ซึ่งเป็นแบบพื้นฐานในการตรวจสอบ(checksum)ไฟล์ที่ถูกเก็บไว้ โดยไม่ต้องการเก็บข้อมูลอื่นๆเลย +การสร้าง lightweight tag ไม่ต้องใช้ออปชั่น `-a`, `-s`, หรือ `-m` : [source,console] ---- @@ -110,8 +110,7 @@ v1.4-lw v1.5 ---- -This time, if you run `git show` on the tag, you don't see the extra tag information.(((git commands, show))) -The command just shows the commit: +ตอนนี้ถ้าคุณรันคำสั่ง `git show` คุณก็จะไม่เห็นข้อมูลอะไรพิเศษเลยนอกจากข้อมูลของ commit นั้น: [source,console] ---- From 37e6d1d1950d68869ca7c2cda3fd3e3854c18cf9 Mon Sep 17 00:00:00 2001 From: Pallat Anchaleechamaikorn Date: Sun, 9 Aug 2015 16:32:41 +0700 Subject: [PATCH 21/46] Later tag --- book/02-git-basics/sections/tagging.asc | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index 7c43c75d9..da819b4a0 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -122,10 +122,9 @@ Date: Mon Mar 17 21:52:11 2008 -0700 changed the version number ---- -==== Tagging Later +==== การติดแท็กทีหลัง -You can also tag commits after you've moved past them. -Suppose your commit history looks like this: +คุณยังสามารถติดแท็กลงไปใน commit ที่ผ่านไปแล้วได้ ยกตัวอย่างเช่น ถ้าประวัติของ commit ของคุณเป็นแบบนี้: [source,console] ---- @@ -142,16 +141,16 @@ a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support 8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme ---- +ตอนนี้ สมมติว่าคุณลืมติดแท็ก v1.2 ให้โปรเจ็ค เมื่อตอนที่ commit ว่า ``updated rakefile'' Now, suppose you forgot to tag the project at v1.2, which was at the ``updated rakefile'' commit. -You can add it after the fact. -To tag that commit, you specify the commit checksum (or part of it) at the end of the command: +คุณสามารถเพิ่มแท็กไปที่ commit นั้นตรงๆ โดยระบุเลข checksum ลงไปเลย (หรือแค่บางส่วนก็ได้) ที่ท้ายคำสั่ง: [source,console] ---- $ git tag -a v1.2 9fceb02 ---- -You can see that you've tagged the commit:(((git commands, tag))) +ทีนี้คุณก็จะได้เห็นแท็กของ commit นั้น:(((git commands, tag))) [source,console] ---- From 6d12d7508abba4f6c56a280b45f441474be3fb93 Mon Sep 17 00:00:00 2001 From: Pallat Anchaleechamaikorn Date: Sun, 9 Aug 2015 17:25:45 +0700 Subject: [PATCH 22/46] completed --- book/02-git-basics/sections/tagging.asc | 25 +++++++++++++++---------- 1 file changed, 15 insertions(+), 10 deletions(-) diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index da819b4a0..b22bd887f 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -177,11 +177,13 @@ Date: Sun Apr 27 20:43:35 2008 -0700 ---- [[_sharing_tags]] -==== Sharing Tags +==== การแชร์แท็ก -By default, the `git push` command doesn't transfer tags to remote servers.(((git commands, push))) -You will have to explicitly push tags to a shared server after you have created them. -This process is just like sharing remote branches – you can run `git push origin [tagname]`. +โดยปกติ คำสั่ง `git push` จะไม่ส่งแท็กขึ้นไปบนรีโมทเซิร์ฟเวอร์ +(((git commands, push))) +คุณจะต้อง push มันขึ้นไปเองตรงๆ เพื่อบอกเซิร์ฟเวอร์ให้รู้หลังจากที่คุณสร้างมันขึ้นมา +ขั้นตอนก็เหมือนกับการแชร์ branch โดยการใช้คำสั่ง +`git push origin [tagname]`. [source,console] ---- @@ -195,8 +197,9 @@ To git@github.com:schacon/simplegit.git * [new tag] v1.5 -> v1.5 ---- -If you have a lot of tags that you want to push up at once, you can also use the `--tags` option to the `git push` command. -This will transfer all of your tags to the remote server that are not already there. +ถ้าคุณมีแท็กจำนวนมากที่ต้องการจะ push ในคราวเดียว คุณทำได้โดยใส่ออปชั่น `--tags` เข้าไปในคำสั่ง `git push` +แบบนี้มันจะส่งทุกๆแท็กที่คุณมีขึ้นไปบนรีโมทเซิร์ฟเวอร์ให้ + [source,console] ---- @@ -209,12 +212,14 @@ To git@github.com:schacon/simplegit.git * [new tag] v1.4-lw -> v1.4-lw ---- -Now, when someone else clones or pulls from your repository, they will get all your tags as well. +ทีนี้ เวลามีใครสักคน โคลน หรือ pull ของจาก repo ของคุณ เขาก็จะได้รับแท็กทั้งหมดด้วย ==== Checking out Tags -You can't really check out a tag in Git, since they can't be moved around. -If you want to put a version of your repository in your working directory that looks like a specific tag, you can create a new branch at a specific tag: +คุณไม่สามารถ check out ไปที่แท็กได้จริงๆ เพราะมันขยับไปไหนไม่ได้เลย +*จากผู้แปล การแก้ไขข้อมูลที่ tag ในอดีต จะเกิดทางแยกของประวัติศาสตร์* + +ถ้าคุณต้องการ push เวอร์ชั่นที่คุณทำงานอยู่ขึ้นไปตรงๆพร้อม แท็กแบบเฉพาะเจาะจง คุณสามารถสร้าง branch ใหม่ที่ แท็กของคุณได้เลย: [source,console] ---- @@ -222,4 +227,4 @@ $ git checkout -b version2 v2.0.0 Switched to a new branch 'version2' ---- -Of course if you do this and do a commit, your `version2` branch will be slightly different than your `v2.0.0` tag since it will move forward with your new changes, so do be careful. +แน่นอนว่า ถ้าคุณทำแบบนี้ และ commit อะไรสักอย่างลงไปใน branch `version2` จะเกิดข้อแตกต่างนิดหน่อยเมื่อเทียบ จากแท็ก `v2.0.0`และมันจะเดินหน้าต่อไปในทางของมันเอง ดังนั้นโปรดระมัดระวังเมื่อจะทำแบบนี้ From cb0d964fde5df3cd4bc2fabae81b4f945658b965 Mon Sep 17 00:00:00 2001 From: Pallat Anchaleechamaikorn Date: Sun, 9 Aug 2015 18:09:38 +0700 Subject: [PATCH 23/46] revise --- .../sections/getting-a-repository.asc | 50 +++++++++---------- 1 file changed, 25 insertions(+), 25 deletions(-) diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc index 2bd86b2c3..2bb276432 100644 --- a/book/02-git-basics/sections/getting-a-repository.asc +++ b/book/02-git-basics/sections/getting-a-repository.asc @@ -1,25 +1,25 @@ [[_getting_a_repo]] -=== ลองดูสัก 1 repository +=== เริ่มจาก หนึ่ง repo -คุณสามารถเริ่มมีโปรเจ็คใน Git ได้สองวิธีหลักๆคือ -วิธีแรก เอาโปรเจ็คที่มีอยู่แล้ว หรือ directory ก็ได้ มา import เข้าไปใน Git -วิธีที่สองคือโคลน มาจาก repository ที่มีอยู่จาก server ใด้สักแห่ง +คุณสามารถได้ git repo มาด้วยวิธีหลักๆ สองวิธีคือ +หนึ่ง ไปเอาโปรเจ็คเก่าหรือไดเร็คทอรี่มา อิมพอร์ตเข้า git +หรือสอง โคลนมาจาก git repo ที่มีอยู่แล้วมาจากสักเซิร์ฟเวร์อนึง -==== การสร้าง Repository จากไดเรคทอรี่ที่สร้างไว้แล้ว +==== การสร้าง repo ใน ไดเร็คทอรี่เก่า -ถ้าคุณกำลังจะเริ่ม track โปรเจ็คที่ทำไว้แล้วใน git คุณต้องไปที่ directory ของโปรเจ็คนั้น และพิมพ์คำสั่ง +ถ้าคุณจะเริ่ม ติดตาม(track) โปรเจคที่มีอยู่ด้วย git คุณต้องไปที่ไดเร็คทอรี่ที่โปรเจ็คนั้นอยู่แล้วก็พิมพ์ว่า [source,console] ---- $ git init ---- -คำสั่งนี้จะสร้าง directory ย่อยขึ้นมาใหม่ ชื่อว่า `.git` ซึ่งใช้เก็บทุกสิ่งที่จำเป็นของไฟล์ทั้งหมดใน repository - เรียกว่าโครงร่างของ git -และตอนนี้จะยังไม่มีอะไรถูก track (ดู <<_git_internals>> สำหรับรายละเอียดเพิ่มเติมว่าอะไรที่ถูกเก็บอยู่ในไดเรคทอรี่ `.git` ที่เพิ่งถูกสร้างขึ้นมา)(((git commands, init))) +มันจะสร้างไดเร็คทอรี่ย่อยที่ชื่อ `.git` เอาไว้เก็บทุกอย่างที่จำเป็นกับ repo หรือเรียกว่าโครงสร้างของ git repo ก็ได้ +แต่ตอนนี้ของในโปรเจคจะยังไม่มีอะไรถูก track เลย +(ดูที่ <<_git_internals>> หากต้องการข้อมูลเพิ่มเติมว่าที่จริงแล้ว ไฟล์อะไรที่อยู่ใน `.git` ที่คุณเพิ่งสร้างมันขึ้นมาเมื่อครู่)(((git commands, init))) -ถ้าคุณต้องการเริ่มทำ เวอร์ชั่นคอนโทรลพวกไฟล์ที่มีอยู่เดิม (ซึ่งต่างจากไดเร็คทอรี่ที่ว่าง) -คุณควรเริ่มการ track ไฟล์พวกนั้น และ commit -ซึ่งคุณสามารถทำมันได้แค่ไม่กี่คำสั่ง โดยคำสั่ง `git add` จะบอกว่าไฟล์ไหนที่คุณต้องการ track ตามด้วยคำสั่ง `git commit`: +ถ้าคุณต้องการเริ่มการทำ version-control กับไฟล์เดิมๆ (เมื่อเทียบกับไดเร็คทอรี่เปล่าๆ) คุณควรเริ่มกระบวนการติดตามไฟล์เหล่านั้น และ เริ่มทำสิ่งที่เรียกว่า commit +คุณสามารถทำสิ่งเหล่านี้ได้ด้วยคำสั่ง `git add` เพื่อเริ่มติดตามไฟล์ที่สนใจ ตามด้วยคำสั่ง `git commit`: [source,console] ---- @@ -28,34 +28,34 @@ $ git add LICENSE $ git commit -m 'initial project version' ---- -เราจะได้เห็นว่าคำสั่งเหล่านี้ใช้เวลานิดเดียว ซึ่งตรงนี้คุณก็จะได้ Git repository พร้อมไฟล์ที่ถูก track และได้ commit แล้ว +ตอนนี้คุณมี git repo พร้อมกับไฟล์ที่ถูก track และ commit แล้ว [[_git_cloning]] -==== การโคลน repository ที่มีอยู่แล้ว +==== การโคลน repo ที่ถูกสร้างไว้แล้ว -ถ้าคุณต้องการได้ repository ที่มีอยู่แล้ว - ตัวอย่างเช่น มีโปรเจ็คหนึ่งที่คุณสนใจอยากมีส่วนร่วม - คำสั่งที่คุณต้องการคือ `git clone` -ถ้าคุณคุ้นเคยกับระบบ VCS อื่นๆยกตัวอย่างเช่น Subversion ขอให้รู้ไว้ว่า คำสั่ง "clone" ไม่ใช่ "checkout" -ซึ่งนี่คือความต่างที่สำคัญมาก - แทนที่จะเอาแค่สำเนา Git จะรับเอาสำเนาเกือบทั้งหมดของข้อมูลทุกชิ้นที่เซิฟเวอร์มี -รวมถึงทุกๆเวอร์ชั่นของทุกๆไฟล์ที่มีในประวัติของโปรเจ็คลงมา เมื่อคุณใช้คำสั่ง `git clone` -นั่นแปลว่า ถ้าเกิดอะไรขึ้นกับดิสบนเซิฟเวอร์ คุณสามารถจะใช้โคลนจาก client ไหนก็ได้กลับมาคืนไว้ใน server ซึ่งจะได้ state สุดท้ายที่ถูกโคลนไป (คุณอาจจะเสียบางอย่างที่ฝั่ง server มีไปบ้าง แต่ทุกๆเวอร์ชั่นจะยังอยู่ - ดู <<_git_on_the_server>> สำหรับรายละเอียดเพิ่มเติม) +ถ้าคุณต้องการสำเนาจาก git repo ที่ถูกสร้างไว้แล้วสักอัน ตัวอย่างเช่น จากโปรเจ็คที่คุณต้องการเข้าร่วม คุณต้องใช้คำสั่ง `git clone`. +ถ้าคุณคุ้นเคยกับระบบ VCS มาก่อนเช่น Subversion คุณควรรู้ว่าคำสั่ง "clone" เทียบไม่ได้กับคำสั่ง "checkout" มันมีความแตกต่างกันอย่างมากคือ แทนที่จะรับมาแค่สำเนาที่ต้องทำงาน git จะรับ สำเนาทั้งหมดจนเท่าที่จะเป็นไปได้มาจากเซิร์ฟเวอร์เท่าที่จะมีให้ โดยจะเอามาทุกเวอร์ชั่นของทุกไฟล์จากทุกประวัติศาสตร์ของโปรเจค เมื่อคุณรันคำสั่ง `git clone`. +ในความเป็นจริง ถ้าหากดิสก์บนเซิร์ฟเวอร์เกิดพังขึ้นมา คุณสามารถนำเวอร์ชั่นที่ใกล้เคียงจากใครก็ได้ที่ โคลนโปรเจ็คไปกลับมาคืนให้เซิร์ฟเวอร์ได้ โดยมันจะย้อนกลับไปที่สถานะเดียวกับเมื่อตอนที่ถูกโคลนไป (คุณอาจจะเสียบางอย่างที่เกี่ยวข้องกับฝั่งเซิร์ฟเวอร์ไปบ้าง แต่เวอร์ชั่นทั้งหมดของข้อมูลยังคงอยู่) + – ดูที่ <<_git_on_the_server>> หากต้องการข้อมูลเพิ่มเติม). -คุณโคลน repository ได้ด้วยคำสั่ง `git clone [url]`.(((git commands, clone))) ตัวอย่างเช่น ถ้าคุณต้องการโคลนไลบรารี่ Git linkable หรือเรียกว่า libgit2 คำสามารถทำได้ดังนี้ +คุณโคลน repo ได้ด้วยคำสั่ง `git clone [url]`.(((git commands, clone))) +ตัวอย่าง ถ้าคุณต้องการโคลน git ของ linkable library หรือเรียกว่า libgit2 คุณสามารถทำแบบนี้ได้: [source,console] ---- $ git clone https://github.com/libgit2/libgit2 ---- -เสร็จแล้วจะเกิดไดเร็คทอรี่ชื่อ ``libgit2'' พร้อมกับการสร้างไดเร็คทอรี่ .git อยู่ในนั้น ดึงข้อมูลทั้งหมดของจาก repository ลงมา และได้สำเนางานเวอร์ชั่นล่าสุดเรียบร้อย -ถ้าคุณลองเข้าไปในไดเรคทอรี่ `libgit2` ที่ถูกสร้างขึ้นมาใหม่นี้ คุณก็จะเห็นไฟล์ของโปรเจ็คในนั้น พร้อมให้ทำงาน หรือใช้ได้เลย -ถ้าคุณต้องารโคลน repository ให้เข้าไปไว้ในไดเร็คทอรี่ชื่ออื่นนอกเหนือจาก ``libgit2'' คุณสามารถระบุเจาะจงลงไปได้เลยตามคำสั่งต่อไปนี้: +จากนั้นมันจะสร้างไดเร็คทอรี่ชื่อ ``libgit2'', initializes a ` พร้อมไดเร็คทอรี่ .git ข้างใน ดึงข้อมูลทั้งหมดจาก repo ลงมา และ check out ไปที่เวอร์ชั่นสุดท้ายให้ +ถ้าคุณเข้าไปในไดเร็คทอรี่ `libgit2` ที่เพิ่งถูกสร้างนี้ คุณจะเห็นไฟล์ของโปรเจค พร้อมให้คุณทำงานทันที +ถ้าคุณต้องการโคลน repo เข้าไปในไดเร็คทอรี่ชื่ออื่นแทน ``libgit2'' คุณสามารถระบุมันลงไปในคำสั่งได้ตามนี้: [source,console] ---- $ git clone https://github.com/libgit2/libgit2 mylibgit ---- -ซึ่งคำสั่งนี้จะทำเหมือนคำสั่งก่อนหน้านี้เพียงแต่จะนำทั้งหมดไปอยู่ในไดเรคทอรี่ชื่อ `mylibgit` แทน +คำสั่งนี้จะทำเหมือนคำสั่งก่อนหน้านี้ แต่ชื่อไดเร็คทอรี่จะเป็น `mylibgit` แทน -Git มีหลายโปรโตคอลสำหรับถ่ายโอนไฟล์ให้เลือกใช้ โดยตัวอย่างก่อนหน้านี้ได้ใช้ โปรโตคอล `https://` แต่คุณอาจจะได้เห็นแบบอื่นด้วยเช่น `git://` หรือ `user@server:path/to/repo.git` ซึ่งใช้โปรโตคอล SSH -<<_git_on_the_server> จะแนะนำตัวเลือกทั้งหมดที่เป็นไปได้ที่เซิฟเวอร์จะตั้งค่าให้เข้าถึง Git repository ได้ รวมถึงข้อดีข้อเสียของแต่ละตัวเลือก +Git มีหลายโปรโตคอลให้ใช้ในการทรานส์เฟอร์ข้อมูล ที่ผ่านมาเราใช้ `https://` แต่คุณอาจจะใช้ `git://` หรือ `user@server:path/to/repo.git` หากต้องการใช้โปรโตคอล SSH แทน +<<_git_on_the_server>> จะนำเสนอตัวเลือกทั้งหมดที่เซิร์ฟเวอร์สามารถตั้งค่าการเข้าถึง git repo รวมถึงข้อดีข้อเสียของแต่ละวิธี From 9dffaa987a5e1ba4140ee0021bf14536e2db154b Mon Sep 17 00:00:00 2001 From: Pallat Anchaleechamaikorn Date: Sun, 9 Aug 2015 18:12:08 +0700 Subject: [PATCH 24/46] this file need new translate --- book/02-git-basics/sections/recording-changes.asc | 1 + 1 file changed, 1 insertion(+) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 3a33a99b4..8a391f462 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -1,3 +1,4 @@ +อยากแปลใหม่ === การบันทึกการเปลี่ยนแปลงใน repository คุณมี repository สักหนึ่งตัว และทำสำเนามาแล้ว From aa893524270fec5d9080572c3ef38c6ba271ec32 Mon Sep 17 00:00:00 2001 From: Pallat Anchaleechamaikorn Date: Sun, 9 Aug 2015 20:33:12 +0700 Subject: [PATCH 25/46] completed --- book/02-git-basics/sections/undoing.asc | 80 ++++++++++++------------- 1 file changed, 40 insertions(+), 40 deletions(-) diff --git a/book/02-git-basics/sections/undoing.asc b/book/02-git-basics/sections/undoing.asc index 8f468bc31..d522a83e7 100644 --- a/book/02-git-basics/sections/undoing.asc +++ b/book/02-git-basics/sections/undoing.asc @@ -1,26 +1,26 @@ [[_undoing]] -=== Undoing Things +=== การแก้ไขสิ่งต่างๆ -At any stage, you may want to undo something. -Here, we'll review a few basic tools for undoing changes that you've made. -Be careful, because you can't always undo some of these undos. -This is one of the few areas in Git where you may lose some work if you do it wrong. +เมื่อใดก็ตาม ที่คุณต้องการจะแก้ไขบางอย่าง +ตอนนี้ เราจะมาพิจารณาดูเครื่องมือพื้นฐานที่จะช่วยให้คุณแก้ไข สิ่งที่คุณทำลงไป +โปรดระมัดระวัง เพราะในบรรดาสิ่งที่แก้ไขได้ทั้งหมด จะมีบางอย่างที่คุณห้ามแก้ไขมันจริงๆ +นี่เป็นหนึ่งในข้อผิดพลาด ที่อาจจะทำให้งานของคุณหายไปหากคุณทำผิดขั้นตอน -One of the common undos takes place when you commit too early and possibly forget to add some files, or you mess up your commit message. -If you want to try that commit again, you can run commit with the `--amend` option: +หนึ่งในข้อผิดพลาดที่พบได้บ่อย เวลาคุณ commit ด้วยความเร็วสูงกว่าแสง และลืมเพิ่มบางไฟล์เข้าไป หรือ commit ด้วยข้อความเละๆ +ถ้าคุณอยากจะ commit ซ้ำ คุณสามารถสั่ง commit ด้วยออปชั่นนี้: [source,console] ---- $ git commit --amend ---- -This command takes your staging area and uses it for the commit. -If you've made no changes since your last commit (for instance, you run this command immediately after your previous commit), then your snapshot will look exactly the same, and all you'll change is your commit message. +คำสั่งนี้จะหยิบเอาของใน staging มา commit ใหม่ +ถ้าคุณไม่ได้แก้ไขอะไรนับจาก commit สุดท้ายนะ (ตัวอย่างเช่น คุณรันคำสั่งนี้ทันทีหลังจาก commit สุดท้าย) หากทุกอย่างเหมือนกันละก็ สิ่งที่คุณจะแก้ไขได้ก็คือ ข้อความที่คุณ commit นั่นแหล่ะ -The same commit-message editor fires up, but it already contains the message of your previous commit. -You can edit the message the same as always, but it overwrites your previous commit. +มันจะเปิด editor ขึ้นมาให้คุณ พร้อมข้อความของ commit ก่อนหน้านั้น +คุณสามารถแก้ไขข้อความได้ และมันจะไปทับข้อความก่อนหน้านี้ -As an example, if you commit and then realize you forgot to stage the changes in a file you wanted to add to this commit, you can do something like this: +ดังตัวอย่าง ถ้าคุณ commit เสร็จ แล้วนึกขึ้นได้ว่าลืมนำไฟล์นึงเข้า stage และคุณต้องการเอามันเข้าไปใน commit นี้ด้วย คุณสามารถทำเลียนแบบตัวอย่างนี้ได้: [source,console] ---- @@ -29,16 +29,16 @@ $ git add forgotten_file $ git commit --amend ---- -You end up with a single commit – the second commit replaces the results of the first. +เมื่อทำเสร็จคุณจะได้เพียงหนึ่ง commit เพราะ commit ที่สองจะไปแทนที่อันแรก [[_unstaging]] -==== Unstaging a Staged File +==== การเอาไฟล์ที่เข้า stage ไปแล้วออกจาก staging -The next two sections demonstrate how to wrangle your staging area and working directory changes. -The nice part is that the command you use to determine the state of those two areas also reminds you how to undo changes to them. -For example, let's say you've changed two files and want to commit them as two separate changes, but you accidentally type `git add *` and stage them both. -How can you unstage one of the two? -The `git status` command reminds you: +สองช่วงต่อไปนี้ จะแสดงให้เห็นว่า ทำอย่างไรหากจะควบคุม ระหว่างเขตของ staging และ เขตที่ใช้ทำงาน +มีคำสั่งดีๆ ให้คุณใช้ตัดสิน ว่าของควรอยู่ที่ไหนในสองเขตนั้น และบอกคุณว่าทำอย่างไรหากต้องการแก้ไขมัน +ตัวอย่างเช่น คุณอาจจะแก้ไขไฟล์ สองไฟล์ และต้องการจะ commit ทั้งสองไฟล์แยกเป็นไฟล์ละ commit แต่คุณดันพิมพ์ลงไปว่า `git add *` กลายเป็นว่าทั้งสองไฟล์เข้า stage ไปแล้ว +ทีนี้จะเอาไฟล์นึงออกจาก stage ได้อย่างไร? +คำสั่ง `git status` บอกคุณว่า: [source,console] ---- @@ -52,8 +52,8 @@ Changes to be committed: modified: CONTRIBUTING.md ---- -Right below the ``Changes to be committed'' text, it says use `git reset HEAD ...` to unstage. -So, let's use that advice to unstage the `CONTRIBUTING.md` file: +ใต้ข้อความ ``Changes to be committed'', มันบอกให้ใช้คำสั่ง ` git reset HEAD ...` เพื่อเอาของออกจาก stage +งั้นเรามาลองใช้คำแนะนำเพื่อเอาไฟล์ `CONTRIBUTING.md` ออกจาก stage กัน: [source,console] ---- @@ -74,22 +74,22 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -The command is a bit strange, but it works. -The `CONTRIBUTING.md` file is modified but once again unstaged. +คำสั่งนี้มันอาจจะดูแปลก แต่มันใช่อ่ะ +ทำให้ไฟล์ `CONTRIBUTING.md`กลับไปอยู่นอก stage อีกครั้ง [NOTE] ===== -While `git reset` _can_ be a dangerous command if you call it with `--hard`, in this instance the file in your working directory is not touched. Calling `git reset` without an option is not dangerous - it only touches your staging area. +คำสั่ง `git reset` อาจเป็นอันตรายได้ หากคุณสั่งมันแล้วตามด้วย `--hard`, แต่ในตัวอย่างนี้มันจะไม่ไปแตะของในเขตที่ใช้ทำงานเลย เพราะคำสั่ง `git reset` โดยไม่มีออปชั่น จะไม่อันตรายเพราะมันจะแตะเฉพาะของในเขต staging เท่านั้น ===== -For now this magic invocation is all you need to know about the `git reset` command. We'll go into much more detail about what `reset` does and how to master it to do really interesting things in <<_git_reset>>. +ทีนี้ การร่ายมนต์นี้ก็จะทำให้คุณอยากรู้เกี่ยวกับคำสั่ง `git reset` ขึ้นมาแน่ๆ เราจะลงไปในรายละเอียดให้มากขึ้นเพื่อดูให้รู้ว่า `reset` ทำอะไร และจะควบคุมมันอย่างไรให้มันทำสิ่งที่น่าสนใจใน <<_git_reset>>. -==== Unmodifying a Modified File +==== การยกเลิกการแก้ไขไฟล์ -What if you realize that you don't want to keep your changes to the `CONTRIBUTING.md` file? -How can you easily unmodify it – revert it back to what it looked like when you last committed (or initially cloned, or however you got it into your working directory)? -Luckily, `git status` tells you how to do that, too. -In the last example output, the unstaged area looks like this: +ถ้าคุณพบว่าคุณไม่อยากได้สิ่งที่คุณแก้ไขในไฟล์ `CONTRIBUTING.md` คุณจะทำอย่างไร +มีวิธีง่ายๆที่ยกเลิกมันไหม ให้มันย้อนกลับไปเป็นเหมือน commit ล่าสุด (หรือเป็นเหมือนเมื่อตอนที่เพิ่งโคลนมา หรือเหมือนเมื่อตอนที่คุณเพิ่งจะได้ไฟล์มาใหม่ๆ) +โชคดีที่คำสั่ง `git status` บอกวิธีให้เราด้วย +ในตัวอย่างสุดท้ายที่ผ่านมา ผลลัพธ์แสดงข้อความทำนองนี้: [source,console] ---- @@ -100,8 +100,8 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -It tells you pretty explicitly how to discard the changes you've made. -Let's do what it says: +มันบอกคุณชัดเจนว่าทำอย่างไรถึงจะยกเลิกการแก้ไขที่คุณทำไว้ +มาดูกันว่ามันบอกเราว่าอย่างไร: [source,console] ---- @@ -115,16 +115,16 @@ Changes to be committed: ---- -You can see that the changes have been reverted. +คุณจะเห็นว่าการเปลี่ยนแปลงทั้งหมดจะถูกย้อนกลับไป -[IMPORTANT] +[สำคัญ] ===== -It's important to understand that `git checkout -- [file]` is a dangerous command. Any changes you made to that file are gone – you just copied another file over it. -Don't ever use this command unless you absolutely know that you don't want the file. +มันสำคัญมากที่จะต้องเข้าใจว่าคำสั่ง `git checkout -- [file]` เป็นคำสั่งที่อันตราย เพราะไม่ว่าอะไรที่คุณแก้ไขลงไปในไฟล์นั้นจะหายไปหมด ราวกับไฟล์ถูกทับด้วยไฟล์อื่น +อย่าใช้คำสั่งนี้ เว้นแต่คุณจะแน่ใจว่าคุณไม่ต้องการไฟล์นั้นแล้วจริงๆ ===== -If you would like to keep the changes you've made to that file but still need to get it out of the way for now, we'll go over stashing and branching in <<_git_branching>>; these are generally better ways to go. +ถ้าคุณยังต้องการที่จะเก็บการแก้ไขไฟล์นั้นเอาไว้แต่ยังไม่อยากเก็บตอนนี้ เราจะไปดูเรื่องการซ่อนของ และการทำ branch กันที่ <<_git_branching>>; ซึ่งเป็นทางที่ดีกว่าที่เราจะใช้ -Remember, anything that is __committed__ in Git can almost always be recovered. -Even commits that were on branches that were deleted or commits that were overwritten with an `--amend` commit can be recovered (see <<_data_recovery>> for data recovery). -However, anything you lose that was never committed is likely never to be seen again. +โปรดจำไว้ว่า สิ่งใดก็ตามที่ถูก __committed__ ลงใน Git สามารถกู้คืนได้ตลอดเวลา +แม้ว่า commit นั้นจะอยู่บน branch ที่ถูกลบไปแล้ว หรือ commit นั้นจะถูกทับด้วยคำสั่ง `--amend` ก็ยังสามารถกูคืนได้ (see <<_data_recovery>> for data recovery). +แต่อะไรก็แล้วแต่ ที่คุณไม่เคย commit ไว้ ก็อย่าหวังจะได้เห็นมันอีกตลอดกาล From 357876c4b0d2e5e26544810ddaacf6eadeae4173 Mon Sep 17 00:00:00 2001 From: Pallat Anchaleechamaikorn Date: Wed, 12 Aug 2015 19:38:38 +0700 Subject: [PATCH 26/46] git log --- .../sections/viewing-history.asc | 60 ++++++++----------- 1 file changed, 25 insertions(+), 35 deletions(-) diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc index ecef33616..8b5c2e3a9 100644 --- a/book/02-git-basics/sections/viewing-history.asc +++ b/book/02-git-basics/sections/viewing-history.asc @@ -1,18 +1,17 @@ [[_viewing_history]] -=== Viewing the Commit History +=== การดูประวัติ commit -After you have created several commits, or if you have cloned a repository with an existing commit history, you'll probably want to look back to see what has happened. -The most basic and powerful tool to do this is the `git log` command. +หลังจากที่คุณได้สร้าง commit มาตั้งมากมาย หรืออาจจะโคลนของมาจาก repo ไหนสักแห่ง คุณอาจจะเริ่มอยากจะดูย้อนกลับไปบ้างว่าเกิดอะไรขึ้นบ้าง +เครื่องมีอที่มีประสิทธิภาพดีมากๆที่ถูกใช้บ่อยที่สุดก็คือคำสั่ง `git log` -These examples use a very simple project called ``simplegit''. -To get the project, run +นี่คือตัวอย่างโปรเจ็คอย่างง่ายชื่อว่า ``simplegit'' ลองเอามารันดู [source,console] ---- git clone https://github.com/schacon/simplegit-progit ---- -When you run `git log` in this project, you should get output that looks something like this:(((git commands, log))) +เมื่อคุณรัน `git log` ในโปรเจ็ค คุณควรได้เห็นผลลัพธ์แบบนี้:(((git commands, log))) [source,console] ---- @@ -36,14 +35,13 @@ Date: Sat Mar 15 10:31:28 2008 -0700 first commit ---- -By default, with no arguments, `git log` lists the commits made in that repository in reverse chronological order – that is, the most recent commits show up first. -As you can see, this command lists each commit with its SHA-1 checksum, the author's name and e-mail, the date written, and the commit message. +ปกติถ้าไม่ได้ออปชั่นอะไร คำสั่ง `git log` จะแสดงรายการของ commit แบบย้อนลำดับเหตุการณ์ให้ หมายความว่า จะแสดง commit ล่าสุดก่อน อย่างที่เห็นนี้ แต่ละ commit จะแสดงค่า SHA-1 checksum, ชื่อผู้เขียน และ อีเมล์, วันที่เขียน และข้อความของ commit นั้น -A huge number and variety of options to the `git log` command are available to show you exactly what you're looking for. -Here, we'll show you some of the most popular. + เนื่องจากคำสั่ง `git log` มีออปชั่นจำนวนมาก เราเลยจะแสดงให้คุณดูแค่บางคำสั่งที่เป็นที่นิยมจริงๆ -One of the more helpful options is `-p`, which shows the difference introduced in each commit. -You can also use `-2`, which limits the output to only the last two entries: +ออปชั่นหนึ่งที่มีประโยชน์อย่างมากคือ `-p` มันจะแสดงให้เห็นมีแต่ละ commit มีอะไรที่ต่างกันบ้าง + +คุณสามารถเพิ่ม `-2` เพื่อจำกัดผลลัพธ์ให้แสดงแค่ 2 รายการ: [source,console] ---- @@ -90,10 +88,8 @@ index a0a60ae..47c6340 100644 \ No newline at end of file ---- -This option displays the same information but with a diff directly following each entry. -This is very helpful for code review or to quickly browse what happened during a series of commits that a collaborator has added. -You can also use a series of summarizing options with `git log`. -For example, if you want to see some abbreviated stats for each commit, you can use the `--stat` option: +ออปชั่นนี้แสดงข้อมูลเหมือนปกติ แต่จะเพิ่มส่วนแสดงสิ่งที่แตกต่างกันในแต่ละรายการ ซึ่งจะช่วยให้เราทบทวนโค้ดได้อย่างรวดเร็วว่าเกิดอะไรขึ้นบ้างในแต่ะล commit ที่ผู้ร่วมงานเพิ่มเข้ามา +คุณยังสามารถเพิ่มออปชั่นต่อท้ายได้เรื่อยๆกับคำสั่ง `git log` ตัวอย่างเช่น ถ้าคุณต้องการจะดูสถิติแบบย่อของแต่ละ commit คุณสามารถใช้ออปชั่น `--stat` ได้ด้วย: [source,console] ---- @@ -128,14 +124,11 @@ Date: Sat Mar 15 10:31:28 2008 -0700 3 files changed, 54 insertions(+) ---- -As you can see, the `--stat` option prints below each commit entry a list of modified files, how many files were changed, and how many lines in those files were added and removed. -It also puts a summary of the information at the end. +อย่างที่เห็น ออปชั่น `--stat` แสดงผลลัพธ์ด้านล่างว่าแต่ละ commit มีไฟล์อะไรบ้างที่ถูกแก้ไข มีกี่ไฟล์ และกี่บรรทัดที่ถูกเพิ่ม และกี่บรรทัดถูกลบออก พร้อมสรุปให้ในตอนท้ายอีกด้วย -Another really useful option is `--pretty`. -This option changes the log output to formats other than the default. -A few prebuilt options are available for you to use. -The `oneline` option prints each commit on a single line, which is useful if you're looking at a lot of commits. -In addition, the `short`, `full`, and `fuller` options show the output in roughly the same format but with less or more information, respectively: +ออปชั่นอื่นที่มีประโยช์จริงๆก็คือ `--pretty` `จะเปลี่ยนรูปแบบการแสดงผลลัพธ์ไปเป็นรูปแบบอื่นนอกเหนือจากแบบปกติ +ซึ่งมีให้เลือกใช้ไม่มากนัก เช่น `oneline` จะแสดงแต่ละ commit จบภายในบรรทัดเดียว ซึ่งเหมาะสำหรับใช้ดู commit ทีละมากๆ +หรือออปชั่นอื่นๆอีกเช่น `short`, `full`, และ `fuller` จะแสดงผลลัพธ์ แบบ คร่าวๆในรูปแบบเดียวกัน โดยแสดงข้อมูลน้อยหรือมากขึ้นตามลำดับ: [source,console] ---- @@ -145,8 +138,8 @@ ca82a6dff817ec66f44342007202690a93763949 changed the version number a11bef06a3f659402fe7563abf99ad00de2209e6 first commit ---- -The most interesting option is `format`, which allows you to specify your own log output format. -This is especially useful when you're generating output for machine parsing – because you specify the format explicitly, you know it won't change with updates to Git:(((log formatting))) +ออปชั่นที่น่าสนใจที่สุดคือ `format` เพราะมันยอมให้คุณกำหนดรูปแบบการแสดงผลได้เอง +นี่มันเป็นประโยชน์มากเมื่อคุณกำหนดรูปแบบให้เครื่องแปลงเป็นผลลัพธ์ให้ และการกำหนดลงไปแบบนี้ มันจะไม่มีอะไรเปลี่ยนไปเมื่อ git มีการอัพเดท:(((log formatting))) [source,console] ---- @@ -156,7 +149,7 @@ ca82a6d - Scott Chacon, 6 years ago : changed the version number a11bef0 - Scott Chacon, 6 years ago : first commit ---- -<> lists some of the more useful options that format takes. +<> นี่คือรายการบางส่วนของออปชั่นใช้ใน format [[pretty_format]] .Useful options for `git log --pretty=format` @@ -180,13 +173,11 @@ a11bef0 - Scott Chacon, 6 years ago : first commit | `%s` | Subject |================================ -You may be wondering what the difference is between _author_ and _committer_. -The author is the person who originally wrote the work, whereas the committer is the person who last applied the work. -So, if you send in a patch to a project and one of the core members applies the patch, both of you get credit – you as the author, and the core member as the committer. -We'll cover this distinction a bit more in <<_distributed_git>>. +คุณอาจจะสงสัยว่ามีอะไรต่างกันระหว่าง _author_ และ _committer_ +author คือคนแรกที่เขียนงาน ส่วน committer คือคนที่แก้ไขงาน ดังนั้น ถ้าคุณเติมงานเข้าไปในโปรเจค และมีใครสักคนแก้ไขส่วนของคุณต่อ คุณทั้งคู่จะได้เครดิตในงานนั้น โดยคุณเป็น author ส่วนอีกคนก็เป็น committer +เราจะสำรวจข้อแตกต่างนี้ต่อใน <<_distributed_git>>. -The oneline and format options are particularly useful with another `log` option called `--graph`. -This option adds a nice little ASCII graph showing your branch and merge history: +ออปชั่น oneline มีประโยชน์มากโดยเฉพาะกับ ออปชั่น `log` และออปชั่นที่ชื่อ `--graph` โดยมันจะเพิ่มรหัส ASCII สวยๆเพื่อมาแสดงเป็นภาพของ branch และประวัติการ merge: [source,console] ---- @@ -203,10 +194,9 @@ $ git log --pretty=format:"%h %s" --graph * 11d191e Merge branch 'defunkt' into local ---- -This type of output will become more interesting as we go through branching and merging in the next chapter. +ผลลัพธ์ชนิดนี้จะเริ่มมีความสำคัญมากเมื่อเราไปถึงบทที่กล่าวถึงการทำ branch และการ merge -Those are only some simple output-formatting options to `git log` – there are many more. -<> lists the options we've covered so far, as well as some other common formatting options that may be useful, along with how they change the output of the log command. +พวกนั้นคือบางส่วนของการจัดรูปแบบ ที่ใช้ในออปชั่น `git log` และนี่คืออีกจำนวนหนึ่ง <> รายการของออปชั่น ที่เราพบว่ามีบางรูปแบบที่อาจจะมีประโยชน์ พร้อมวิธีที่พวกเขาใช้ในการเปลี่ยนข้อมูลที่แสดงออกมา [[log_options]] .Common options to `git log` From d207767ca3eaafa2ff6628191c657d2baf4e7194 Mon Sep 17 00:00:00 2001 From: Pallat Anchaleechamaikorn Date: Wed, 12 Aug 2015 20:11:24 +0700 Subject: [PATCH 27/46] limit --- .../sections/viewing-history.asc | 31 ++++++++----------- 1 file changed, 13 insertions(+), 18 deletions(-) diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc index 8b5c2e3a9..801e3bb04 100644 --- a/book/02-git-basics/sections/viewing-history.asc +++ b/book/02-git-basics/sections/viewing-history.asc @@ -214,39 +214,34 @@ $ git log --pretty=format:"%h %s" --graph | `--pretty` | Show commits in an alternate format. Options include oneline, short, full, fuller, and format (where you specify your own format). |================================ -==== Limiting Log Output +==== การจำกัดจำนวนผลลัพธ์ที่แสดง -In addition to output-formatting options, `git log` takes a number of useful limiting options – that is, options that let you show only a subset of commits. -You've seen one such option already – the `-2` option, which show only the last two commits. -In fact, you can do `-`, where `n` is any integer to show the last `n` commits. -In reality, you're unlikely to use that often, because Git by default pipes all output through a pager so you see only one page of log output at a time. +ในส่วนเสริมของออปชั่น `git log` มีหลายตัวที่ใช้จำกัดจำนวนเพื่อให้แสดงแค่บางส่วนของ commit อย่างที่คุณเคยเห็นแล้วว่า ออปชั่น `-2` ทำให้แสดงแค่สอง commit ล่าสุด และจริงๆแล้วคุณสามาระใส่เลขเท่าไหรก็ได้ ซึ่งมันจะแสดง commit ตามจำนวนตัวเลขนั้น +ในการใช้งานจริง คุณจะไม่ค่อยได้ใช้มันบ่อยนัก เพราะโดยปกติแล้ว Git จะแสดงข้อความออกมาเป็นหน้าอยู่แล้ว และคุณก็จะเห็นได้แค่ทีละหน้าเท่านั้น -However, the time-limiting options such as `--since` and `--until` are very useful. -For example, this command gets the list of commits made in the last two weeks: +อย่างไรก็ตาม ออปชั่นของช่วงเวลา เช่น `--since` และ `--until` กลับได้ใช้มาก ตัวอย่างเช่น คำสั่งนี้จะแสดงรายการของ commit ของสองสัปดาห์ล่าสุด: [source,console] ---- $ git log --since=2.weeks ---- -This command works with lots of formats – you can specify a specific date like `"2008-01-15"`, or a relative date such as `"2 years 1 day 3 minutes ago"`. +คำสั่งนี้ทำงานได้กับรูปแบบเวลาหลายๆแบบ คุณสามารถใช้แบบ `"2008-01-15"` หรือจะใช้การอ้างอิงช่วงเวลาเช่น `"2 years 1 day 3 minutes ago"` -You can also filter the list to commits that match some search criteria. -The `--author` option allows you to filter on a specific author, and the `--grep` option lets you search for keywords in the commit messages. -(Note that if you want to specify both author and grep options, you have to add `--all-match` or the command will match commits with either.) +คุณยังสามารถกรอง commit ตามเงื่อนไขการค้นหาได้อีกเช่น `--author` ใช้กรองเอาเฉพาะชื่อผู้เขียนที่ต้องการ และ `--grep` ให้คุณค้นหาด้วยคำในข้อความ commit (โปรดจำไว้ว่า ถ้าคุณต้องการใช้ออปชั่นทั้งสองนี้พร้อมกัน คุณต้องเพิ่ม `--all-match` หรือคำสั่งที่จะบอกให้เทียบเงื่อนไขแต่ละตัว) -Another really helpful filter is the `-S` option which takes a string and only shows the commits that introduced a change to the code that added or removed that string. For instance, if you wanted to find the last commit that added or removed a reference to a specific function, you could call: +ตัวกรองอื่นที่มีประโยชน์มากคือ `-S` โดยมันจะจับเอาข้อความที่ถูกแก้ไขในโค้ด ไม่ว่าจะถูกเพิ่ม หรือถูกลบออก ยกตัวอย่างเช่น ถ้าคุณต้องการค้นหา commit ล่าสุดที่มีการเพิ่มหรือลบ เฉพาะที่ฟังก์ชั่นที่สนใจ คุณควรทำแบบนี้: [source,console] ---- $ git log -Sfunction_name ---- -The last really useful option to pass to `git log` as a filter is a path. -If you specify a directory or file name, you can limit the log output to commits that introduced a change to those files. -This is always the last option and is generally preceded by double dashes (`--`) to separate the paths from the options. +ตัวกรองสุดท้านที่มีประโยชน์กับออปชั่น `git log` คือการกรองพาร์ท +ถ้าคุณต้องการเจาะจงไปที่ไดเร็คทอรี่ไหน หรือไฟล์ไหนคุณสามารถจำกัดผลลัพธ์ของ commit ที่มีการแก้ไขเปลี่ยนไฟล์ที่ไฟล์นั้นได้ +นี่เป็นออปชั่นสุดท้ายเสมอ และมันนำหน้าด้วยเครื่องหมายลบสองตัว (`--`) เพื่อแยกส่วนของพาร์ท ออกจากออปชั่น -In <> we'll list these and a few other common options for your reference. +ใน <> เราจะแสดงรายการของเรื่องนี้และคำสั่งอื่นอีกเล็กน้อย [[limit_options]] .Options to limit the output of `git log` @@ -262,7 +257,7 @@ In <> we'll list these and a few other common options for your re | `-S` | Only show commits adding or removing code matching the string |================================ -For example, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano and were not merges in the month of October 2008, you can run something like this:(((log filtering))) +ตัวอย่าง ถ้าคุณต้องการเห็นว่า commit ไหนแก้ไขไฟล์ทดสอบใน Git ที่เก็บซอสโค้ด ที่มีประวัติ commit โดย Junio Hamano และไม่ได้ merge ในเดือน ตุลาคม 2008 คุณสามารถรันคำสั่งแบบนี้:(((log filtering))) [source,console] ---- @@ -276,4 +271,4 @@ d1a43f2 - reset --hard/read-tree --reset -u: remove unmerged new paths b0ad11e - pull: allow "git pull origin $something:$current_branch" into an unborn branch ---- -Of the nearly 40,000 commits in the Git source code history, this command shows the 6 that match those criteria. +ในจำนวนราวๆ 40,000 commit ใน Git ซอสโค้ด คำสั่งนี้แสดงเพียงแค่ 6 commit ที่ตรงตามเงื่อนไข From 0d071d013c311f13b051480fce47257ff802913e Mon Sep 17 00:00:00 2001 From: Pallat Anchaleechamaikorn Date: Wed, 12 Aug 2015 21:22:03 +0700 Subject: [PATCH 28/46] new translate to staging modifiled files --- .../sections/recording-changes.asc | 91 +++++++++---------- 1 file changed, 45 insertions(+), 46 deletions(-) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 8a391f462..a1eb3cffb 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -1,25 +1,25 @@ -อยากแปลใหม่ -=== การบันทึกการเปลี่ยนแปลงใน repository +=== การบันทึกการแก้ไขลงไปใน Repository +คุณมีหนึ่ง Repo ที่ได้มาอย่างถูกต้อง และ checkout หรือ กำลังทำงานอยู่กับไฟล์ในโปรเจคนั้นอยู่ +และคุณต้องการแก้ไขอะไรบางอย่าง และ commit เพื่อเก็บ snapshots ของการแก้ไขนั้นลงไปใน repo ทุกครั้งที่คุณทำงานไปถึงจุดที่คุณต้องการ -คุณมี repository สักหนึ่งตัว และทำสำเนามาแล้ว -ทีนี้คุณต้องการแก้ไขออะไรสักอย่างและ อยาก commit snapshots นั้นไว้ใน repository ทุกๆครั้งที่คุณต้องการ +จำไว้ว่าแต่ละไฟล์ในไดเร็คทอรี่ที่คุณทำงานอยู่ จะมีได้แค่สถานะเดียวระหว่าง tracked หรือ untracked -จงจำไว้ว่าแต่ละไฟล์ในไดเรคทอรี่การทำงานนี้ สามารถมีได้ เพียงสถาวะเดียวจาก สอง สถาวะนี้คือ: tracked หรือ untracked -Tracked คือไฟล์ที่อยู่ใน snapshot สุดท้าย ซึ่งสามารถเป็น unmodified หรือ modified หรือ staged ก็ได้ -Untracked คือไฟล์อื่นๆ ไฟล์ทั้งหมดในไดเรคทอรี่การทำงาน ที่ไม่ได้อยู่ใน snapshot สุดท้าย และไม่อยู่ใน staging ด้วย -เมื่อคุณโคลน repository มาครั้งแรก ทุกไฟล์จะเป็น tracked และ unmodified เพราะคุณเพิ่งจะเอามันลงมา และยังไม่ได้แก้ไขใดๆ +ไฟล์ที่อยู่สถานะ tracked คือพวกที่ได้เข้าไปอยู่ใน snapshot ล่าสุด พวกมันพร้อมจะไปส่งสถานะ unmodified, modified, หรือ staged +ส่วนไฟล์ที่อยู่สถานะ untracked คือไฟล์ที่คุณยังไม่สนใจ ยังไม่แก้ไข ยังไม่เข้าไปอยู่ใน snapshot ล่าสุด และยังไม่อยู่ในพื้นที่ที่เรียกว่า staging +เมื่อตอนที่คุณโคลน repository ลงมา ไฟล์ทั้งหมดของคุณจะมีสถานะเป็น tracked และ unmodified เพราะว่าคุณเพิ่งจะ checkout พวกมันลงมา และก็ยังไม่ได้แก้ไขอะไรเลย -เมื่อคุณแก้ไขไฟล์ Git จะเห็นว่ามันเป็น modified เพราะว่าคุณแก้ไขมันไปจาก commit สุดท้าย -คุณก็นำพวกที่ modified นี้เข้า stage แล้วก็ commit ทั้งหมดที่เข้ามาใน stage และก็ทำวนเวียนไปเรื่อยๆเป็นวงจร +เมื่อคุณแก้ไขไฟล์ Git จะเห็นว่ามันเปลี่ยนไปจากเดิม เพราะว่าคุณทำให้มันเปลี่ยนไปจาก commit ล่าสุด +สถานะของมันจะเป็น modified และเมื่อคุณ commit พวกไฟล์ที่สถานะเป็น staged ทั้งหมด วงจรก็วนไปเรื่อยๆ -.วงจรชีวิตสถานะไฟล์ของคุณ. +. +.วงจรชีวิตของสถานะของไฟล์ของคุณ image::images/lifecycle.png[The lifecycle of the status of your files.] [[_checking_status]] -==== การตรวจสอบสถานะไฟล์ต่างๆของคุณ +==== การตรวจสอบสถานะของไฟล์คุณ -เครื่องมือหลักๆสำหรับหาว่าไฟล์ไหนอยู่ในสถานะไหนก็คือคำสั่ง `git status` (((git commands, status))) -ถ้าคุณรันคำสั่งนี้ตรงๆหลังจากที่เพิ่งโคลนมา คุณจะเห็นบางอย่างคล้ายๆแบบนี้: +เครื่องมือหลักที่คุณใช้ในการตัดสินว่าไฟล์ไหนอยู่ในสถานะไหนก็คือคำสั่ง `git status` (((git commands, status))) +ถ้าคุณรันคำสั่งนี้ทันทีหลังจากที่คุณโคลนโปรเจคลงมา คุณควรจะเห็นแบบนี้: [source,console] ---- @@ -28,12 +28,13 @@ On branch master nothing to commit, working directory clean ---- -นี่หมายความว่าคุณมีไดเร็คทอรี่ของการทำงานที่สะอาดสุดๆ หรืออีกนัยหนึ่งคือ ไม่มีไฟล์ไหนถูก track และ modified เลย -ในขณะเดียวกัน git ก็ยังไม่เห็นว่ามีไฟล์ไหนที่สถานะเป็น untracked หรือไม่มีรายการอะไรควรแสดงให้เห็น -สุดท้าย คำสั่งนี้ บอกคุณว่าคุณกำลังอยู่ที่ branch ไหน และแจ้งให้คุณทราบว่าไม่มีอะไรผิดแปลกไปจาก branch เดียวกันบน server -ซึ่งตอนนี้ branch นั้นยังคงเป็น ``master'' ซึ่งเป็นค่าตั้งต้น; คุณอย่าเพิ่งกังวลเรื่องนี้ <<_git_branching>> จะพาคุณไปดูเรื่อง branch และอธิบายรายละเอียดให้ +นี่หมายความว่าไดเร็ดทอรี่ของคุณสะอาด หรือจะบอกว่ามันไม่มีไฟล์ที่มีสถานะ tracked และ modified เลยนั่นเอง +Git จะไม่เห็นไฟล์ที่เป็น untracked หรือ พวกมันอาจจะไม่ถูกแสดงให้เห็นตอนนี้ +ตอนท้ายของคำสั่งนี้จะบอกคุณว่า branch ที่คุณอยู่คือที่ไหน และแจ้งให้คุณทราบว่า ไม่มีอะไรแตกต่างไปจาก branch เดียวกันนี้บนเซิร์ฟเวอร์เลย +ตอนนี้ branch นั้นคือ ``master'' เสมอ มันเป็นค่าพื้นฐาน และคุณยังไม่ต้องกังวลในเรื่องนี้ +<<_git_branching>> เราจะไปดูรายละเอียดกันต่อภายหลัง -สมมุติว่า คุณเพิ่มไฟล์ใหม่เข้ามาในโปรเจ็ค เอาง่ายๆเช่นไฟล์ README ถ้าไฟล์นี้ไม่เคยมีอยู่เดิม และคุณรันคำสั่ง`git status` คุณจะเห็นไฟล์ที่เป็น untracked แบบนี้: +ทดลองเพิ่มไฟล์ใหม่เข้าไปในโปรเจคของคุณชื่อว่า README ถ้าไฟล์นี้ไม่เคยมีมาก่อน และคุณรันคำสั่ง `git status` คุณจะเห็นไฟล์นี้มีสถานะเป็น untracked แบบนี้: [source,console] ---- @@ -48,22 +49,23 @@ Untracked files: nothing added to commit but untracked files present (use "git add" to track) ---- -คุณจะเห็นว่าไฟล์ README ของคุณอยู่ในสถานะ untracked เพราะว่ามันถูกแสดงอยู่ใต้คำว่า ``Untracked files'' บนหน้าจอ -untracked โดยปกตินั้นหมายความว่า git เห็นว่าไฟล์นี้ ไม่มีใน snapshot ก่อนหน้านี้(commit); git จะไม่เริ่มต้นรวมไฟล์นี้ลงไปใน commit จนกว่าคุณจะบอกมันอย่างชัดเจนก่อน -ซึ่งมันทำแบบนี้เพื่อป้องกันอันตรายหากคุณไม่ได้ตั้งใจจะรวมเอาไฟล์ไบนารี่หรือไฟล์อะไรก็ไม่รู้เข้าไปด้วย สิ่งที่คุณต้องทำเมื่ออยากรวมไฟล์ README เอาละ เรามาเริ่ม track ไฟล์กันเลย +คุณจะเห็นไฟล์ใหม่ที่ชื่อ README มีสถานะเป็น untracked เพราะว่ามันอยู่ใต้ตัวข้อ ``Untracked files'' ในรายงานผลลัพธ์ที่หน้าจอ +โดยปกติ untracked จะหมายความว่า git เห็นว่าไฟล์นี้ไม่เคยมีใน commit มาก่อน และมันจะไม่เอาไฟล์นี้เข้ามาใน commit จนกว่าคุณจะบอกมันเอง +มันทำแบบนี้เพราะ คุณจะได้ไม่มาพบทีหลังว่า มันเอาไฟล์ไบนารี่ที่ถูกสร้างขึ้นมาเข้าไป หรือไฟล์อื่นใดก็ตามที่คุณไม่อยากให้มันเข้าไปอยู่ในโปรเจคคุณโดยไม่ตั้งใจ +ทีนี้คุณอยากเอาไฟล์ README เข้าไป ให้เริ่มติดตาม(track)ไฟล์นี้กัน [[_tracking_files]] -==== การ track ไฟล์ใหม่ +==== การติดตาม(Track) ไฟล์ใหม่ -คำสั่งให้เริ่ม track ไฟล์ใหม่ ให้คุณใช้คำสั่ง `git add`.(((git commands, add))) -เพื่อเริ่ม track README คุณสามารถรันคำสั่งนี้เลย: +ตามลำดับแล้ว การเริ่มติดตามหรือ tracking ไฟล์ใหม่ ให้คุณใช้คำสั่ง `git add`.(((git commands, add))) +เพื่อติดตามไฟล์ README คุณใช้คำสั่งนี้: [source,console] ---- $ git add README ---- -ถ้าคุณรันคำสั่ง status อีกที คุณจะเห็นว่าไฟล์ README ของคุณมีสถานะเป็น tracked และ staged เพื่อรอที่จะเป็น committed: +ถ้าคุณรันคำสั่งเพื่อดูสถานะอีกครั้ง คุณจะเห็นว่าไฟล์ README เปลี่ยนสถานะเป็น tracked และ staged เพื่อพร้อมจะเปลี่ยนเป็น committed: [source,console] ---- @@ -76,15 +78,15 @@ Changes to be committed: ---- -คุณบอกได้ว่าสถานะของมันเป็น staged แล้ว ก็เพราะมันถูกแสดงอยู่ใต้คำว่า “Changes to be committed” บนหัวมัน -ถ้าคุณ commit ที่จุดนี้เลย เวอร์ชั่นของไฟล์ ณ จุดที่คุณได้รันคำสั่ง git add จะกลายเป็นประวัติไปอยู่ใน snapshot -คุณอาจจะย้อนสถานะมันได้ถึง เมื่อตอนที่คุณได้รันคำสั่ง git init เมื่อครู่นี้ และจากนั้นคุณได้รันคำสั่ง`git add (files)` ซึ่งตอนนั้นเป็นการเริ่มการติดตามไฟล์ในไดเร็คทอรี่ของคุณแล้ว(((git commands, init)))(((git commands, add))) -คำสั่ง `git add` จะเก็บเอาชื่อพาร์ท รวมถึงไฟล์และไดเร็คทอรี่ไว้ ถุ้าสิ่งที่เพิ่มไว้เป็นไดเร็คทอรี่ คำสั่งจะเพิ่มไฟล์ทั้งหมดในไดเร็คทอรี่ให้เลย +คุณเรียกตรงนี้ว่า staged ได้เพราะมันถูกแสดงภายใต้ตัวข้อ ``Changes to be committed'' +ถ้าคุณ commit ตอนนี้ หมายความว่าคุณได้ทำเวอร์ชั่นให้ไฟล์ ที่คุณได้รันคำสั่ง `git add` เอาไว้ ลงไปในประวัติของ snapshot +คุณอาจจะย้อนไปดูว่าเมื่อตอนที่คุณรันคำสั่ง `git init` และคุณก็รันคำส่ัง `git add (files)` นั่นคือคุณได้เริ่มติดตามไฟล์ในไดเร็คทอรี่ของคุณแล้ว(((git commands, init)))(((git commands, add))) +คำสั่ง `git add` รับได้ทั้งชื่อไฟล์ และชื่อไดเร็กทอรี่ และถ้าเป็นชื่อไดเร็กทอรี่ มันจะวิ่งเข้าไปหาชื่อไฟล์ทั้งหมดเอง -==== การทำ stage modified +==== การเปลี่ยนสถานะของไฟล์ -ลองเปลี่ยนแปลงไฟล์สักไฟล์ที่สถานะเป็น tracked -ถ้าคุณแก้ไขไฟล์ ``CONTRIBUTING.md'' ให้เปลี่ยนไปจาก tracked ก่อนหน้านี้ และรันคำสั่ง `git status` อีกครั้ง คุณจะได้ข้อความทำนองนี้: +ลองแก้ไขไฟล์ที่สถานะเปลี่ยนไปเป็น tracked แล้วดู +ถ้าคุณแก้ไฟล์ที่ชื่อ ``CONTRIBUTING.md''` ที่สถานะเป็น tracked แล้ว และลองรันคำสั่ง `git status` อีกครั้ง คุณจะเห็นแบบนี้: [source,console] ---- @@ -103,10 +105,10 @@ Changes not staged for commit: ---- -ไฟล์ ``CONTRIBUTING.md'' จะโผล่มาอยู่ภายใต้ส่วนของคำว่า ``Changed but not staged for commit'' ซึ่งหมายความว่าไฟล์นั้น สถานะเป็น tracked และกำลังถูกแก้ไขในไดเร็คทอรี่แต่ยังไม่เข้า stage -และเพื่อจะทำ stage มัน คุณลองรันคำสั่ง `git add` ดู `git add` เป็นคำสั่งสารพัดประโยชน์ คุณสามารถใช้มันเพื่อ เริ่ม track ไฟล์ใหม่ หรือเพื่อ เริ่มนำไฟล์เข้า stage และเพื่อทำอะไรอย่างอื่นอีกเช่นเมื่อต้องทำ merge-conflict เสร็จแล้ว -มันอาจจะช่วยคุณได้มาก หากจะคิดว่าสิ่งนี้นั้นคือการ ``เพิ่มเนื้อหานี้เข้าไปใน commit ถัดไป'' มากกว่าที่จะคิดว่า ``เพิ่มไฟล์นี้เข้าไปในโปรเจค'' (((git commands, add))) -เอาละ มาลองรัน `git add` เลย เพื่อนำไฟล์ ``CONTRIBUTING.md'' เข้า stage จากนั้นรันคำสั่ง `git status` อีกครั้ง: +ไฟล์ ``CONTRIBUTING.md''`` จะปรากฎอยู่ใต้หัวข้อ ``Changed but not staged for commit''`` หมายความว่าไฟล์นั้นมีสถานะ tracked และถูกแก้ไข และการแก้ไขนั้นยังไม่ถือว่าเป็น staged +การจะนำมันเข้า staged คุณจะต้องรันคำสั่ง `git add` อีกครั้ง +คำสั่ง `git add`นี้สารพัดประโยชน์ ใช้เพื่อเริ่ม track ไฟล์ใหม่ก็ได้ เพื่อนำไฟล์เข้า stage และทำอย่างอื่นอีกเช่น เมื่อแก้ปัญหา merge-conflicted {การรวมไฟล์และเกิดส่วนที่ขัดแย้งขึ้น} มันน่าจะช่วยได้มากถ้าคิดซะว่า คำสั่งนี้มีไว้เพื่อ ``เพิ่มเนื้อหา เพื่อไปสู่การ commit''`` แทนที่จะคิดว่าเป็นการ ``เพิ่มไฟล์เข้าโปรเจค''`` (((git commands, add))) +ทีนี้ลองรัน `git add` เพื่อเอาไฟล์ ``CONTRIBUTING.md''` เข้า stage และลองรัน `git status` อีกครั้ง: [source,console] ---- @@ -121,10 +123,8 @@ Changes to be committed: ---- -ทั้งสองไฟล์เป็น staged แล้ว และกำลังก้าวเข้าสู่ commit ถัดไป -ณ จุดนี้ สมมุติว่าคุณเพิ่งนึกขึ้นได้ว่าอยากจะแก้ไขอะไรอีกนิดหน่อยใน `CONTRIBUTING.md` ก่อนที่จะ commit มัน -คุณเปิดไฟล์ขึ้นมาอีกครั้งและแก้ไขมัน จากนั้นคุณพร้อมที่จะ commit แล้ว -ไม่ว่าจะอย่างไรก็ตาม ลองรันคำสั่ง `git status` อีกสักที: +ตอนนี้ทั้งสองไฟล์มีสถานะเป็น staged และพร้อมจะไปสู่การ commit แต่ทีนี้ สมมติว่าคุณนึกขึ้นได้ว่า คุณอยากจะแก้ไขอะไรนิดหน่อยที่ไฟล์ `CONTRIBUTING.md` ก่อนที่จะ commit คุณเลยเปิดไฟล์นี้ขึ้นมาแล้วแก้ไขมัน เสร็จแล้วคุณก็เลยจะ commit +อย่างไรเสีย ลองรัน `git status` ดูอีกสั้งครั้งเถิด: [source,console] ---- @@ -146,11 +146,10 @@ Changes not staged for commit: ---- อะไรฟะ? -ตอนนี้ มันถูกแสดงว่ามีสองสถานะคือ staged และ unstaged -มันเป็นงี้ได้ไง? -มันกลายเป็นว่า stage ของไฟล์เป็นตามที่คุณรันคำสั่ง `git add` -ถ้าคุณ commit ตอนนี้ เวอร์ชั่นของ `CONTRIBUTING.md` คือไฟล์เมื่อตอนที่คุณรัน `git add` ซึ่งคือของที่จะไปสู่การ commit, ไม่ใช่เวอร์ชั่นที่คุณเห็นจริงๆในไดเรคทอรี่เมื่อตอนที่คุณรัน `git commit` -ถ้าคุณแก้ไขไฟล์หลังจากที่คุณรันคำสั่ง `git add` คุณต้องรัน `git add` อีกที เพื่อนำเวอร์ชั่นสุดท้ายของไฟล์เข้า stage: +ตอนนี้ไฟล์ `CONTRIBUTING.md` มันมีสองสถานะคือ staged และ unstaged เป็นไปได้ไง? +มันบอกคุณว่า stage จริงๆของมันจะเป็นเหมือนตอนที่คุณรันคำสั่ง `git add` นะ +ถ้าคุณ commit ตอนนี้ เวอร์ชั่นของไฟล์ `CONTRIBUTING.md` จะเป็นของ ตอนที่คุณได้รันคำสั่ง `git add` ไม่ใช่เวอร์ชั่นที่คุณเพิ่มจะแก้ไขก่อนที่คุณจะสั่ง `git commit` +ถ้าคุณแก้ไขไฟล์หลังจากที่คุณรันคำสั่ง `git add` คุณจะต้องรันคำสั่ง `git add` ใหม่อีกครั้ง เพื่อเอาเวอร์ชั่นสุดท้ายเข้าสู่ stage: [source,console] ---- From 4cf54aee641b058a47202f81e6b5a70f06235157 Mon Sep 17 00:00:00 2001 From: Pallat Anchaleechamaikorn Date: Wed, 12 Aug 2015 22:50:17 +0700 Subject: [PATCH 29/46] branching --- book/03-git-branching/1-git-branching.asc | 28 ++++++++++++----------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/book/03-git-branching/1-git-branching.asc b/book/03-git-branching/1-git-branching.asc index 77fb9e603..a0c67626a 100644 --- a/book/03-git-branching/1-git-branching.asc +++ b/book/03-git-branching/1-git-branching.asc @@ -2,15 +2,17 @@ == Git Branching (((branches))) -Nearly every VCS has some form of branching support. -Branching means you diverge from the main line of development and continue to do work without messing with that main line. -In many VCS tools, this is a somewhat expensive process, often requiring you to create a new copy of your source code directory, which can take a long time for large projects. +เกือบจะทุกๆ VCS สามารถทำเรื่อง branch ได้ +การทำ branch หมายถึงการแยกตัวออกจากสายหลักของการพัฒนาโปรแกรม และทำมันต่อเนื่องไปโดยไม่ยุ่งเกี่ยวกับสายหลักเลย +เครื่องมือพวก VCS จำนวนมากมีกระบวนการที่แพง ส่วนมากจะต้องการทำสำเนาซอสโค้ดทั้งไดเร็คทอรี่ ซึ่งนั่นจะกินเวลานานมากถ้าโปรเจคนั้นมีขนาดใหญ่ + +บางคนถึงกับบอกว่า การทำ branch ของ Git นั้นมันคือ ``killer feature'' และส่งผลให้ Git แตกต่างจาก VCS อื่นๆ +แล้วมันพิเศษยังไง? +แนวทางการทำ branch ของ Git นั้นใช้ทรัพยากรน้อยอย่างเหลือเชื่อ การสร้าง branch เร็วถึงขนาดว่า เสร็จทันทีที่สั่ง และการเปลี่ยนไปมาระหว่าง branch นั้นก็เร็วมากๆ + +Git แตกต่างจาก VCS จำนวนมาก เพราะว่า Git กระตุ้นให้การทำงานกับ branch นั้นทำได้บ่อยขึ้น และทำได้หลายครั้งในหนึ่งวัน +การเข้าใจและเรียนรู้ฟีเจอร์นี้ จะให้อำนาจแก่คุณ ให้เครื่องมือที่พิเศษ และจะเปลี่ยนวิธีการพัฒนาโปรแกรมของคุณไปเลย -Some people refer to Git's branching model as its ``killer feature,'' and it certainly sets Git apart in the VCS community. -Why is it so special? -The way Git branches is incredibly lightweight, making branching operations nearly instantaneous, and switching back and forth between branches generally just as fast. -Unlike many other VCSs, Git encourages workflows that branch and merge often, even multiple times in a day. -Understanding and mastering this feature gives you a powerful and unique tool and can entirely change the way that you develop. include::sections/nutshell.asc[] @@ -24,9 +26,9 @@ include::sections/remote-branches.asc[] include::sections/rebasing.asc[] -=== Summary +=== บทสรุป -We've covered basic branching and merging in Git. -You should feel comfortable creating and switching to new branches, switching between branches and merging local branches together. -You should also be able to share your branches by pushing them to a shared server, working with others on shared branches and rebasing your branches before they are shared. -Next, we'll cover what you'll need to run your own Git repository-hosting server. +ตอนนี้เราได้รู้พื้นฐานการทำ branch และการ merge ใน Git ได้ครอบคลุมทั้งหมดแล้ว +คุณน่าจะรู้สึกว่าการสร้าง branch และการสลับไปมาระหว่าง branch ในเครื่องคุณเป็นเรื่องง่ายขึ้นมาบ้างแล้ว +และคุณก็น่าจะสามารถ ส่ง branch ของคุณขึ้นไปแบ่งปันให้คนอื่นบนเซิร์ฟเวอร์ได้ สามารถทำงานร่วมกับผู้อื่นผ่าน branch ที่แชร์ขึ้นไป และการทำ rebase ที่ branch ของคุณก่อนจะถูก แชร์ +ในบทต่อไปเราจะไปเรียนรู้ว่า คุณจะทำอย่างไรถ้าต้องการจะมีเซิร์ฟเวอร์สำหรับ Git เป็นของตัวเอง From 65ad88fbc981b6693d80f60679ae2d8c7ab57819 Mon Sep 17 00:00:00 2001 From: Pallat Anchaleechamaikorn Date: Thu, 13 Aug 2015 10:22:26 +0700 Subject: [PATCH 30/46] remove duplicate section --- book/02-git-basics/sections/tagging.asc | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index b22bd887f..ae3d96ce0 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -39,14 +39,7 @@ v1.8.5.5 ==== การสร้างแท็ก -ปกติ Git จะใช้แท็กอยู่สองชนิดหลักๆคือ : lightweight และ annotated. - -แท็กแบบ lightweight จะเหมือนกับ branch มากซึ่งมันจะไม่มีการเปลี่ยนแปลง และมันเป็นแค่การกำหนดความสำคัญลงไปที่ commit นั้นๆ - -แท็กแบบ Annotated จะเก็บทุก object ลงในฐานข้อมูลของ Git -==== การสร้างแท็ก - -ปกติ Git จะใช้แท็กอยู่สองชนิดหลักๆคือ : lightweight และ annotated. +ปกติ Git จะใช้แท็กอยู่สองชนิดหลักๆคือ : lightweight และ annotated แท็กแบบ lightweight จะเหมือนกับ branch มากซึ่งมันจะไม่มีการเปลี่ยนแปลง และมันเป็นแค่การกำหนดความสำคัญลงไปที่ commit นั้นๆ From e1e6faee6e5562e95385d5e465fae102266d8446 Mon Sep 17 00:00:00 2001 From: Pallat Anchaleechamaikorn Date: Fri, 14 Aug 2015 09:51:52 +0700 Subject: [PATCH 31/46] checkout --- book/03-git-branching/1-git-branching.asc | 28 +++++++++++------------ 1 file changed, 13 insertions(+), 15 deletions(-) diff --git a/book/03-git-branching/1-git-branching.asc b/book/03-git-branching/1-git-branching.asc index a0c67626a..77fb9e603 100644 --- a/book/03-git-branching/1-git-branching.asc +++ b/book/03-git-branching/1-git-branching.asc @@ -2,17 +2,15 @@ == Git Branching (((branches))) -เกือบจะทุกๆ VCS สามารถทำเรื่อง branch ได้ -การทำ branch หมายถึงการแยกตัวออกจากสายหลักของการพัฒนาโปรแกรม และทำมันต่อเนื่องไปโดยไม่ยุ่งเกี่ยวกับสายหลักเลย -เครื่องมือพวก VCS จำนวนมากมีกระบวนการที่แพง ส่วนมากจะต้องการทำสำเนาซอสโค้ดทั้งไดเร็คทอรี่ ซึ่งนั่นจะกินเวลานานมากถ้าโปรเจคนั้นมีขนาดใหญ่ - -บางคนถึงกับบอกว่า การทำ branch ของ Git นั้นมันคือ ``killer feature'' และส่งผลให้ Git แตกต่างจาก VCS อื่นๆ -แล้วมันพิเศษยังไง? -แนวทางการทำ branch ของ Git นั้นใช้ทรัพยากรน้อยอย่างเหลือเชื่อ การสร้าง branch เร็วถึงขนาดว่า เสร็จทันทีที่สั่ง และการเปลี่ยนไปมาระหว่าง branch นั้นก็เร็วมากๆ - -Git แตกต่างจาก VCS จำนวนมาก เพราะว่า Git กระตุ้นให้การทำงานกับ branch นั้นทำได้บ่อยขึ้น และทำได้หลายครั้งในหนึ่งวัน -การเข้าใจและเรียนรู้ฟีเจอร์นี้ จะให้อำนาจแก่คุณ ให้เครื่องมือที่พิเศษ และจะเปลี่ยนวิธีการพัฒนาโปรแกรมของคุณไปเลย +Nearly every VCS has some form of branching support. +Branching means you diverge from the main line of development and continue to do work without messing with that main line. +In many VCS tools, this is a somewhat expensive process, often requiring you to create a new copy of your source code directory, which can take a long time for large projects. +Some people refer to Git's branching model as its ``killer feature,'' and it certainly sets Git apart in the VCS community. +Why is it so special? +The way Git branches is incredibly lightweight, making branching operations nearly instantaneous, and switching back and forth between branches generally just as fast. +Unlike many other VCSs, Git encourages workflows that branch and merge often, even multiple times in a day. +Understanding and mastering this feature gives you a powerful and unique tool and can entirely change the way that you develop. include::sections/nutshell.asc[] @@ -26,9 +24,9 @@ include::sections/remote-branches.asc[] include::sections/rebasing.asc[] -=== บทสรุป +=== Summary -ตอนนี้เราได้รู้พื้นฐานการทำ branch และการ merge ใน Git ได้ครอบคลุมทั้งหมดแล้ว -คุณน่าจะรู้สึกว่าการสร้าง branch และการสลับไปมาระหว่าง branch ในเครื่องคุณเป็นเรื่องง่ายขึ้นมาบ้างแล้ว -และคุณก็น่าจะสามารถ ส่ง branch ของคุณขึ้นไปแบ่งปันให้คนอื่นบนเซิร์ฟเวอร์ได้ สามารถทำงานร่วมกับผู้อื่นผ่าน branch ที่แชร์ขึ้นไป และการทำ rebase ที่ branch ของคุณก่อนจะถูก แชร์ -ในบทต่อไปเราจะไปเรียนรู้ว่า คุณจะทำอย่างไรถ้าต้องการจะมีเซิร์ฟเวอร์สำหรับ Git เป็นของตัวเอง +We've covered basic branching and merging in Git. +You should feel comfortable creating and switching to new branches, switching between branches and merging local branches together. +You should also be able to share your branches by pushing them to a shared server, working with others on shared branches and rebasing your branches before they are shared. +Next, we'll cover what you'll need to run your own Git repository-hosting server. From ea09ee828010ae006b914ddf59643db7500505e6 Mon Sep 17 00:00:00 2001 From: roofimon Date: Sat, 13 Feb 2016 14:30:37 +0700 Subject: [PATCH 32/46] Done about vcs --- .../sections/about-version-control.asc | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/book/01-introduction/sections/about-version-control.asc b/book/01-introduction/sections/about-version-control.asc index a29ed2f56..15915218a 100644 --- a/book/01-introduction/sections/about-version-control.asc +++ b/book/01-introduction/sections/about-version-control.asc @@ -1,14 +1,13 @@ === About Version Control (((version control))) -What is "version control", and why should you care? -Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. -For the examples in this book you will use software source code as the files being version controlled, though in reality you can do this with nearly any type of file on a computer. - -If you are a graphic or web designer and want to keep every version of an image or layout (which you would most certainly want to), a Version Control System (VCS) is a very wise thing to use. -It allows you to revert files back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. -Using a VCS also generally means that if you screw things up or lose files, you can easily recover. -In addition, you get all this for very little overhead. +อะไรคือ Version Control แล้วทำไมเราต้องสนใจมันด้วย +อะไรคือ version control แล้วทำไมต้องใช้ด้วย บางคนอาจบอกว่า “ก็จำได้ว่าทำอะไรไปมีไรป่ะ” แต่สุดท้ายผ่านไปสองเดือนก็ลืมหมด version control +คือระบบที่บันทึกการเปลี่ยนแปลงทั้งหมดที่เกิดขึ้นกับไฟล์หรือชุดของไฟล์ที่เรากำลัง ทำงานกับมันอยู่และเมื่อมีการบันทึกการเปลี่ยนแปลง ทุกครั้งที่เกิดปัญหาแก้ไฟล์มั่วจำไม่ได้ +เราก็สามารถย้อนกลับ ไปหาเวอร์ชั่นใดๆก่อนหน้าได้เสมอ โดยที่ตัวอย่างที่จะใช้ในหนังสือเล่มนี้จะเป็นไฟล์ที่ทรัพย์สินอันสำคัญเช่น source code จะถูกควบคุมโดย version control +แต่อย่างไรก็ตามสำหรับการนำไปใช้งานจริงนั้นเราสามารถประยุกต์ใช้กับ ไฟล์ประเภทไหนก็ได้ เช่นถ้าคุณเป็น graphic designer และอยากจะเก็บเวอร์ชั่นของภาพที่เราทำไปให้หมดทุกอัน +สิ่งที่ช่วยเรื่องเหล่านี้ ได้คือ Version Control System (VCS) มันคือสิ่งที่คุณ “ต้อง” ใช้เพราะมันจะช่วยให้เราถอยไปถอยมาได้ไม่ว่าจะเป็น ระดับไฟล์หรือระดับโปรเจค +ถ้ามันเละมากแก้มั่วไปหมดก็สามารถถอยกลับไปได้ วื๊บๆ ดังนั้นไอ้พวกข้ออ้างไฟล์หาย ไฟล์พังเพื่อขอเลื่อนโปรเจคหรือส่งงานข้าจะใช้ไม่ได้อีกต่อไป ==== Local Version Control Systems From a93afdc8cfc87e746a9e507d6a121190843e4d41 Mon Sep 17 00:00:00 2001 From: roofimon Date: Sat, 13 Feb 2016 14:47:30 +0700 Subject: [PATCH 33/46] Done introduction --- book/01-introduction/1-introduction.asc | 16 ++++++---------- 1 file changed, 6 insertions(+), 10 deletions(-) diff --git a/book/01-introduction/1-introduction.asc b/book/01-introduction/1-introduction.asc index 0809ab839..a56b1c7c0 100644 --- a/book/01-introduction/1-introduction.asc +++ b/book/01-introduction/1-introduction.asc @@ -1,9 +1,7 @@ [[_getting_started]] -== Getting Started - -This chapter will be about getting started with Git. -We will begin by explaining some background on version control tools, then move on to how to get Git running on your system and finally how to get it set up to start working with. -At the end of this chapter you should understand why Git is around, why you should use it and you should be all set up to do so. +== เริ่มต้นปฐมบทแห่ง Git +บทนี้เป็นบทแห่งการเริ่มต้นที่จะบอกเล่าเรื่องราวที่มาที่ไปของสิ่งที่เรียกว่า version contol tools จากนั้นเราก็จะถูกดึง มาเข้าเรื่อง Git +ว่าเราจะไปทำยังไงให้ Git มาอยู่ในเครื่องเราได้ ทำไงให้มันทำงานได้และเมื่อจบบทนี้เราจะได้รู้ว่า ทำไมต้อง Git นั่นสิทำไม? include::sections/about-version-control.asc[] @@ -19,8 +17,6 @@ include::sections/first-time-setup.asc[] include::sections/help.asc[] -=== Summary - -You should have a basic understanding of what Git is and how it's different from the centralized version control system you may have previously been using. -You should also now have a working version of Git on your system that's set up with your personal identity. -It's now time to learn some Git basics. +=== สรุป +จบบทนี้เราควรเข้าใจเรื่องพื้นฐานต่างๆเกี่ยวกับ Git และรู้ว่ามันแตกต่างจาก centralized version control อย่างไร นอกจากนี้เราจะมี git ติดตั้งไว้ในเครื่องของเราแล้วด้วย account ของเราเอง +ดังนั้นถึงเวลาที่เราจะได้เรียนรู้พื็นฐานของ Git กันแล้ว From 6a5e4a41c5e3c7e7244825bf4fbcaff2053aba96 Mon Sep 17 00:00:00 2001 From: roofimon Date: Sat, 13 Feb 2016 14:54:16 +0700 Subject: [PATCH 34/46] Finish Local Version Control Systems --- .../sections/about-version-control.asc | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/book/01-introduction/sections/about-version-control.asc b/book/01-introduction/sections/about-version-control.asc index 15915218a..06be6e4af 100644 --- a/book/01-introduction/sections/about-version-control.asc +++ b/book/01-introduction/sections/about-version-control.asc @@ -2,7 +2,7 @@ (((version control))) อะไรคือ Version Control แล้วทำไมเราต้องสนใจมันด้วย -อะไรคือ version control แล้วทำไมต้องใช้ด้วย บางคนอาจบอกว่า “ก็จำได้ว่าทำอะไรไปมีไรป่ะ” แต่สุดท้ายผ่านไปสองเดือนก็ลืมหมด version control +อะไรคือ version control แล้วทำไมต้องใช้ด้วย บางคนอาจบอกว่า “ก็จำได้ว่าทำอะไรไปมีไรป่ะ” แต่สุดท้ายผ่านไปสองเดือนก็ลืมหมด version control คือระบบที่บันทึกการเปลี่ยนแปลงทั้งหมดที่เกิดขึ้นกับไฟล์หรือชุดของไฟล์ที่เรากำลัง ทำงานกับมันอยู่และเมื่อมีการบันทึกการเปลี่ยนแปลง ทุกครั้งที่เกิดปัญหาแก้ไฟล์มั่วจำไม่ได้ เราก็สามารถย้อนกลับ ไปหาเวอร์ชั่นใดๆก่อนหน้าได้เสมอ โดยที่ตัวอย่างที่จะใช้ในหนังสือเล่มนี้จะเป็นไฟล์ที่ทรัพย์สินอันสำคัญเช่น source code จะถูกควบคุมโดย version control แต่อย่างไรก็ตามสำหรับการนำไปใช้งานจริงนั้นเราสามารถประยุกต์ใช้กับ ไฟล์ประเภทไหนก็ได้ เช่นถ้าคุณเป็น graphic designer และอยากจะเก็บเวอร์ชั่นของภาพที่เราทำไปให้หมดทุกอัน @@ -12,18 +12,16 @@ ==== Local Version Control Systems (((version control,local))) -Many people's version-control method of choice is to copy files into another directory (perhaps a time-stamped directory, if they're clever). -This approach is very common because it is so simple, but it is also incredibly error prone. -It is easy to forget which directory you're in and accidentally write to the wrong file or copy over files you don't mean to. - -To deal with this issue, programmers long ago developed local VCSs that had a simple database that kept all the changes to files under revision control. +ย่อหน้าที่แล้วมีคำว่า VCS เยอะมากเอ๊ะแล้วจริงๆเขาทำด้วยอะไรกัน? คำตอบเริ่มจากทำกันบ้านๆก็ได้ไม่ต้องคิดมาก copy file ที่ต้องการไว้บ่อยๆจะแก้ก็ copy ทิ้งไว้ก่อนแล้วตั้งชื่อ directory +ให้สอดคล้องกัน ทำไปเรื่อยๆนี่ไง VCS กราบส์ OTL ทำแบบนี้ก็ไม่ผิดแต่มันเยอะส์บางทีลืมบ้างอะไรบ้างก็บ้าบอกันได้เลยทีเดียวเพราะไม่รู้อันไหนแน่ที่ต้อง +เอากลับมาใช้และเพื่อแก้ไขปัญหาเรื่องนี้โปรแกรมเมอร์ (อีกแล้วไม่ใช่ tester) ได้สร้าง VCS ที่มี database แปะมาด้วยสำหรับการเก็บประวัติการเปลี่ยนแปลงทั้งหลายทั้งปวง .Local version control. image::images/local.png[Local version control diagram] -One of the more popular VCS tools was a system called RCS, which is still distributed with many computers today. -Even the popular Mac OS X operating system includes the `rcs` command when you install the Developer Tools. -RCS works by keeping patch sets (that is, the differences between files) in a special format on disk; it can then re-create what any file looked like at any point in time by adding up all the patches. +หนึ่งใน VCS ในตำนานที่ยังคงอยู่ค้ำฟ้ามาจนถึงปัจจุบันคือ rcs ยกตัวอย่างเช่นใน Mac OS X เองก็ยังคงมีคำสั่ง rcs ให้เราใช้งานได้หลังจากที่เราติดตั้ง Developer Tools +ลงในเครื่องโดยที่เจ้า rcs นี้จะทำหน้าที่เก็บความแตกต่างของไฟล์หรือที่เรียกว่า patch sets เพื่อใช้สำหรับการสร้างไฟล์ขึ้นมาใหม่ในกรณีที่เกิด file lock หลังจากที่เราลง +patch ใหม่ลงไปในเครื่องดังนั้น rcs ก็จะเป็นตัวอย่างที่ดีของการทำ local repository แต่ของแบบนี้ก็ดีถ้าเราทำอะไรคนเดียว ==== Centralized Version Control Systems From 19c473a8f4979b1706811ce633ae8613dd6d84a0 Mon Sep 17 00:00:00 2001 From: roofimon Date: Sat, 13 Feb 2016 15:00:42 +0700 Subject: [PATCH 35/46] Finish Centralized Version Control Systems --- .../sections/about-version-control.asc | 21 ++++++++----------- 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/book/01-introduction/sections/about-version-control.asc b/book/01-introduction/sections/about-version-control.asc index 06be6e4af..9e8851d05 100644 --- a/book/01-introduction/sections/about-version-control.asc +++ b/book/01-introduction/sections/about-version-control.asc @@ -26,23 +26,20 @@ patch ใหม่ลงไปในเครื่องดังนั้น r ==== Centralized Version Control Systems (((version control,centralized))) -The next major issue that people encounter is that they need to collaborate with developers on other systems. -To deal with this problem, Centralized Version Control Systems (CVCSs) were developed. -These systems, such as CVS, Subversion, and Perforce, have a single server that contains all the versioned files, and a number of clients that check out files from that central place. (((CVS)))(((Subversion)))(((Perforce))) -For many years, this has been the standard for version control. +ในกรณีที่เราต้องการทำงานร่วมกับคนอื่นๆแล้วเราจะแบ่งปันโค้ดเทพของกันและกันได้อย่างไรนี่ไอ้ของแบบ Local Repo คงไม่เหมาะเท่าไหร่ ดังนั้นของใหม่ที่เกิดถัดมาคือ +Centralized Version Control System (CVCSs) และตัวอย่างของระบบแบบนี้คือ CVS, Subversion และ Perforce นั่นเองซึ่งหัวใจหลักของการทำงานแบบนี้คือจะต้องมี server +หนึ่งตัวที่รับหน้าที่เก็บของให้ทั้งหมด ทั้งไฟล์ที่เกิดการเปลี่ยนแปลงและจำนวน user ที่ check out ไฟล์จาก server และอย่างที่เรารู้ว่า Centralize Repo เป็นมาตรฐานของ VCS มานานหลายปี .Centralized version control. image::images/centralized.png[Centralized version control diagram] -This setup offers many advantages, especially over local VCSs. -For example, everyone knows to a certain degree what everyone else on the project is doing. -Administrators have fine-grained control over who can do what; and it's far easier to administer a CVCS than it is to deal with local databases on every client. +สำหรับการ setup ระบบแบบ Centralize เองก็มีข้อดีหลายอย่างมากที่ดีกว่า local VCSs ยกตัวอย่างเช่นทุกๆคนในทีมจะรู้ว่าคนอื่นๆในทีมที่เหลือกำลังทำอะไรอยู่ +ส่วนผู้ที่ดูแลระบบก็สามารถจัดการกับสิทธิ์การทำงานของ user ทุกคนได้ซึ่งนี้ก็เป็นข้อดีที่เหนือกว่าการมานั่งกำหนดอะไรอะไรที่ local database ทีละเครื่องมากมายนัก + +แต่อย่างไรก็ตามการทำงานในลักษณะนี้เองก็มีข้อเสียที่น่าสนใจอยู่หนึ่งอย่างและดูเหมือนว่าจะร้ายแรงมากคือในกรณีที่ server พังไปสักชั่วโมงจะทำให้คนที่ทำงานอยู่ไม่สามารถส่งอะไรเข้ามา update +ได้เลยและถ้าเอาให้หนักหน่อยในกรณีที่ไม่มีการสำรองข้อมูลไว้เราจะพบกับฝันร้ายขั้นร้ายแรงคือ เราจะเสีย history ทั้งหมดของระบบไปหมดเลย (แรงดีเนอะ) ดังนั้นนี่คือด้วนมืดของ +Centrlaized Repo -However, this setup also has some serious downsides. -The most obvious is the single point of failure that the centralized server represents. -If that server goes down for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they're working on. -If the hard disk the central database is on becomes corrupted, and proper backups haven't been kept, you lose absolutely everything – the entire history of the project except whatever single snapshots people happen to have on their local machines. -Local VCS systems suffer from this same problem – whenever you have the entire history of the project in a single place, you risk losing everything. ==== Distributed Version Control Systems From de29d5cb11446005dbaa408faf7b8aae6cfe6eb1 Mon Sep 17 00:00:00 2001 From: roofimon Date: Sat, 13 Feb 2016 15:02:41 +0700 Subject: [PATCH 36/46] Finish Distributed Version Control Systems --- .../sections/about-version-control.asc | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/book/01-introduction/sections/about-version-control.asc b/book/01-introduction/sections/about-version-control.asc index 9e8851d05..553d85784 100644 --- a/book/01-introduction/sections/about-version-control.asc +++ b/book/01-introduction/sections/about-version-control.asc @@ -44,13 +44,15 @@ Centrlaized Repo ==== Distributed Version Control Systems (((version control,distributed))) -This is where Distributed Version Control Systems (DVCSs) step in. -In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don't just check out the latest snapshot of the files: they fully mirror the repository. -Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it. -Every clone is really a full backup of all the data. +หลังจากที่เราเห็นด้านมืดของ Centralize Rep ไปแล้วเราก็จะได้รู้จักกับสิ่งที่เรียกว่า Distributed Version Control system (DVCSs) ตัวอย่างของระบบแบบนี้คือ +(Git, Mercurial, Bazaar หรือ Darcs) โดยที่ความแปลกของระบบแบบนี้คือแทนที่เครื่อง client จะทำการ check out เอา snapshot +ล่าสุดไปไว้บนเครื่องมันจะทำสิ่งที่ยิ่งใหญ่กว่านั้นคือมันทำ full mirror ข้อมูลทั้งหมดของโปรเจคที่กำลังทำงานลงมาไว้ที่เครื่องเลยดังนั้นการทำงานแบบนี้จะแก้ปัญหาเรื่อง +Server พังแล้วไม่สามารถย้อนกลับไปเอา history กลับคืนมาได้เพราะข้อมูลที่อยู่บนเครื่อง client ก็สามารถถูกส่งกลับขึ้นไปเพื่อ restore ระบบได้ทั้งหมดเหมือนกันดังนั้นการ check out ของ +DVCS ก็คือการทำ Full Backup นั่นเองดังรูป .Distributed version control. image::images/distributed.png[Distributed version control diagram] -Furthermore, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project. -This allows you to set up several types of workflows that aren't possible in centralized systems, such as hierarchical models. +นอกจากนี้แล้วระบบแบบนี้ยังถูกออกแบบให้มีความสามารถในการทำงานกับ remote repository +ได้มากกว่าหนึ่งที่ด้วยนั่นหมายความว่าเราสามารถทำงานแจมกับพรรคพวกได้มากกว่าหนึงที่ในโปรเจคเดียวกัน ดังนั้นเราจะสามารถ setup workflow +ได้หลายประเภทเพื่อให้รองรับการทำงานของเราและสิ่งนี้ทำไม่ได้ใน Centralize Repository นะจ๊ะย้ำ From ca0f8a87f148cc022827222594ba639d4776fc3b Mon Sep 17 00:00:00 2001 From: roofimon Date: Sat, 13 Feb 2016 15:12:55 +0700 Subject: [PATCH 37/46] Finish Snapshots --- book/01-introduction/sections/basics.asc | 26 +++++++++--------------- 1 file changed, 10 insertions(+), 16 deletions(-) diff --git a/book/01-introduction/sections/basics.asc b/book/01-introduction/sections/basics.asc index 118001417..3a411958f 100644 --- a/book/01-introduction/sections/basics.asc +++ b/book/01-introduction/sections/basics.asc @@ -1,32 +1,26 @@ === Git Basics So, what is Git in a nutshell? -This is an important section to absorb, because if you understand what Git is and the fundamentals of how it works, then using Git effectively will probably be much easier for you. -As you learn Git, try to clear your mind of the things you may know about other VCSs, such as Subversion and Perforce; doing so will help you avoid subtle confusion when using the tool. -Git stores and thinks about information much differently than these other systems, even though the user interface is fairly similar, and understanding those differences will help prevent you from becoming confused while using it.(((Subversion)))(((Perforce))) +เอาล่ะ มาดูกันว่า Git in a nutshell เป็นยังไง? ส่วนนี้เป็นส่วนสำคัญที่ท่านจะต้องดูดไป เพราะเมื่อไหร่ที่ท่านเข้าใจแก่นแท้ของ Git และเข้าใจว่ามันทำงานยังไง เมื่อนั้น การใช้ Git อย่างมีประสิทธิภาพสูงสุดก็ไม่ยากละ ขณะที่เรียนรู้ Git พยายามลืม VCSs ตัวที่ผ่านๆมาให้หมด (เช่น Subversion และพวกพ้อง) เพราะมันจะป้องกันความงงที่จะเกิดขึ้นระหว่างใช้ Git ได้ Git มองและจำข้อมูลต่างกับระบบอื่นๆค่อนข้างเยอะ แม้ว่า UI มันจะดูคล้ายๆตัวอื่นก็ตาม ทำความเข้าใจความแตกต่าง แล้วเวลาใช้จะไม่งง.(((Subversion)))(((Perforce))) -==== Snapshots, Not Differences +==== Snapshots, ไม่ใช่ความเปลี่ยนแปลง -The major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data. -Conceptually, most other systems store information as a list of file-based changes. -These systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they keep as a set of files and the changes made to each file over time. +หลักๆเลย Git ต่างกับ VCS อื่นๆ (Subversion และเพื่อนๆ) ตรงที่วิธีที่ Git มองข้อมูลที่มันเก็บ โดยคอนเซปแล้ว ระบบอื่นๆจะเก็บข้อมูลในรูปของ listของความเปลี่ยนแปลง +ระบบเหล่านี้ (CVS, Subversion, Perforce, Bazaar ฯลฯ) คิดว่าข้อมูลที่มันเก็บคือ set ของ files และความเปลี่ยนแปลงที่เกิดขึ้นกับแต่ละ file ในเวลาที่ดำเนินไป .Storing data as changes to a base version of each file. image::images/deltas.png[Storing data as changes to a base version of each file.] -Git doesn't think of or store its data this way. -Instead, Git thinks of its data more like a set of snapshots of a miniature filesystem. -Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. -To be efficient, if files have not changed, Git doesn't store the file again, just a link to the previous identical file it has already stored. -Git thinks about its data more like a *stream of snapshots*. +Git ไม่ได้มองหรือจำข้อมูลที่มันเก็บอย่างนั้น ในทางกลับกัน Git มองข้อมูลมันเหมือนกับเป็น set ของ snapshots ของ filesystem ขนาดจิ๋ว ทุกๆครั้งที่คุณ commit +หรือ save project ใน Git มันจะถ่ายรูปว่า files ของเราหน้าตาเป็นไง ณ บัดนั้น และเก็บ reference ไปยัง snapshot (รูปถ่าย) นั้น และเพื่อให้มีประสิทธิภาพ +ถ้า file ไม่ถูกแก้ไข Git จะไม่จำ file นั้นๆซ้ำ แค่เก็บ link ไปยัง file เก่าที่เหมือนกันเป๊ะๆ ที่มันเคยจำไว้แล้วเฉยๆ *stream of snapshots*. .Storing data as snapshots of the project over time. image::images/snapshots.png[Git stores data as snapshots of the project over time.] -This is an important distinction between Git and nearly all other VCSs. -It makes Git reconsider almost every aspect of version control that most other systems copied from the previous generation. -This makes Git more like a mini filesystem with some incredibly powerful tools built on top of it, rather than simply a VCS. -We'll explore some of the benefits you gain by thinking of your data this way when we cover Git branching in <<_git_branching>>. +นี่ความความแตกต่างที่สำคัญระหว่าง Git และ VCSs อื่นๆเกือบทั่วโลก มันทำให้ Git ต้องคิดใหม่ ทำใหม่เกือบทุกๆอย่าง ขณะที่ระบบอื่นๆแค่ copy มาจากรุ่นก่อนๆ +มันทำให้ Git เหมือนเป็น filesystem ขนาดจิ๋วที่มากับ tools อันทรงพลังที่สร้างขึ้นมาครอบมันมากกว่าที่จะเป็นแค่ VCS ธรรมดา +เด๋วเราค่อยมาโชว์ของดีที่ได้จากการมองข้อมูลในลักษณะนี้ในหัวข้อ branching ใน Chapter 3 <<_git_branching>>. ==== Nearly Every Operation Is Local From 545cd7eb3db74b662a9d1348695512b10693bc27 Mon Sep 17 00:00:00 2001 From: roofimon Date: Sat, 13 Feb 2016 15:14:50 +0700 Subject: [PATCH 38/46] Done git has intregity --- book/01-introduction/sections/basics.asc | 29 ++++++------------------ 1 file changed, 7 insertions(+), 22 deletions(-) diff --git a/book/01-introduction/sections/basics.asc b/book/01-introduction/sections/basics.asc index 3a411958f..a57c2ece3 100644 --- a/book/01-introduction/sections/basics.asc +++ b/book/01-introduction/sections/basics.asc @@ -24,39 +24,24 @@ image::images/snapshots.png[Git stores data as snapshots of the project over tim ==== Nearly Every Operation Is Local -Most operations in Git only need local files and resources to operate – generally no information is needed from another computer on your network. -If you're used to a CVCS where most operations have that network latency overhead, this aspect of Git will make you think that the gods of speed have blessed Git with unworldly powers. -Because you have the entire history of the project right there on your local disk, most operations seem almost instantaneous. +ส่วนใหญ่แล้ว operation ใน Git ต้องการแค่ file และทรัพยากรบนเครื่องในการทำงาน ไม่จำเป็นต้องมีข้อมูลอื่นใดจากเครื่องอื่นๆใน network ถ้าคุณคุ้นเคยกับ CVCS ที่ operation ส่วนใหญ่ต้องทนกับความช้าของ network แล้วละก็ คุณจะรู้สึกราวกับว่าเทพแห่งความเร็วนั้นอวยพร Git ด้วยความเร็วส์ที่ไม่อายบรรยาย เพราะว่าคุณมี history ทั้งหมดของ project เก็บอยู่ที่นี่ในเครื่องของตัวเอง operation ทั้งหลายแหล่จึงรวดเร็วทันใจ -For example, to browse the history of the project, Git doesn't need to go out to the server to get the history and display it for you – it simply reads it directly from your local database. -This means you see the project history almost instantly. -If you want to see the changes introduced between the current version of a file and the file a month ago, Git can look up the file a month ago and do a local difference calculation, instead of having to either ask a remote server to do it or pull an older version of the file from the remote server to do it locally. +ยกตัวอย่างเช่นการค้นหา history ของ project Git ไม่จำเป็นต้องวิ่งไป server เพื่อดึง history แล้วหิ้วกลับมาแสดงผลให้คุณ มันแค่อ่านจาก database บนเครื่องก็ได้แล้ว นั่นหมายความว่าคุณสามารถเห็น project history ได้ในอึดใจเดียว ถ้าอยากดูความเปลี่ยนแปลงที่เกิดขึ้นบน file ซักอันระหว่าง version ปัจจุบันกับเมื่อเดือนที่แล้ว Git สามารถค้นหา file เมื่อเดือนที่แล้วบนเครื่องแล้วคำนวนหาสิ่งที่เปลี่ยนแปลงไปให้ได้ทันที แทนที่จะต้องไปอ้อน server ที่อยู่ไกลๆให้คำนวนให้หรือไปขอ file เดือนก่อนจาก server แล้วค่อยเอามาคำนวน -This also means that there is very little you can't do if you're offline or off VPN. -If you get on an airplane or a train and want to do a little work, you can commit happily until you get to a network connection to upload. -If you go home and can't get your VPN client working properly, you can still work. -In many other systems, doing so is either impossible or painful. -In Perforce, for example, you can't do much when you aren't connected to the server; and in Subversion and CVS, you can edit files, but you can't commit changes to your database (because your database is offline). -This may not seem like a huge deal, but you may be surprised what a big difference it can make. +นั่นหมายความว่าคุณแทบจะไม่มีอะไรที่ทำไม่ได้ในกรณีที่ไม่ได้ต่อเนตหรือต่อ VPN ไม่ว่าจะกำลังนั่งรถ นั่งเรือ นั่งเครื่องบินอยู่ ถ้ามีอะไรกระจุ๊กกระจิ๊กอยากทำก็สามารถทำแล้ว commit เก็บไว้ได้อย่างสบายอารมณ์ ไว้ต่อเนตได้เมื่อไหร่ก็ค่อย upload ถ้าสมมติอยู่บ้านแล้วไม่สามารถ set VPN ได้ ก็ยังจะทำงานได้อยู่ ถ้าเป็นระบบอื่นๆ จะทำให้ได้แบบนี้แทบจะเป็นไปไม่ได้ ถึงได้ก็เลือดตาแทบกระเด็นหล่ะ เช่นสมมติใช้ Perforce คุณแทบจะทำอะไรไม่ได้เลยถ้าไม่ต่ออยู่กับ server หรือกรณี Subversion และ CVS ถึงจะแก้ file ได้ ก็ commit ใส่ database ไม่ได้ (เพราะไม่ได้ต่อกับ database) ถึงเรื่องแค่นี้จะดูเป็นเรื่องเล็ก แต่ถ้าลองได้ใช้จริงจะรู้ว่าชีวิตมันรู้สึกแตกต่างกันขนาดไหน -==== Git Has Integrity +==== Git นั้นเที่ยงธรรม -Everything in Git is check-summed before it is stored and is then referred to by that checksum. -This means it's impossible to change the contents of any file or directory without Git knowing about it. -This functionality is built into Git at the lowest levels and is integral to its philosophy. -You can't lose information in transit or get file corruption without Git being able to detect it. +ทุกอย่างใน Git ถูก checksum ก่อนจะถูก save และจะถูกอ้างอิงถึงด้วย checksum นั้นๆ นั่นหมายความว่าไม่มีทางที่จะมีข้อมูลใน file หรือ directory เปลี่ยนไปโดยที่ Git จะไม่รู้เรื่อง ความสามารถนี้ถูกฝังไว้ในแก่นลึกสุดใจของ Git และหล่อหลอมเข้ากับจิตวิญญาณของมัน คุณไม่มีวันเจอ file เสียหรือพังไประหว่างถ่ายโอนข้อมูลโดยที่ Git ตรวจจับไม่เจอแน่นอน -The mechanism that Git uses for this checksumming is called a SHA-1 hash.(((SHA-1))) -This is a 40-character string composed of hexadecimal characters (0–9 and a–f) and calculated based on the contents of a file or directory structure in Git. -A SHA-1 hash looks something like this: +กลไกที่ Git ใช้ในการทำ checksum เรียกว่า SHA-1 hash ซึ่งเป็นเลขฐาน 16 ยาว 40 ตัวอักษรที่ถูกคำนวนมาจากเนื้อหาภายใน file หรือโครงสร้าง directory ภายใน Git SHA-1 hash มีหน้าตาประมาณนี้ [source] ---- 24b9da6552252987aa493b52f8696cd6d3b00373 ---- -You will see these hash values all over the place in Git because it uses them so much. -In fact, Git stores everything in its database not by file name but by the hash value of its contents. +คุณจะเห็นค่า hash เหล่านี้กระจายตัวอยู่ทั่ว Git มันถูกใช้เยอะมว้ากก เอาจริงๆแล้ว Git ไม่ได้เก็บข้อมูลเป็น file แต่เก็บลง database ซึ่งสามารถเข้าถึงข้อมูลได้ด้วยค่า hash ของเนื้อหาใน file ==== Git Generally Only Adds Data From fa4369ac312b5031ab01ff6570d8eaf6dd97d49d Mon Sep 17 00:00:00 2001 From: roofimon Date: Sat, 13 Feb 2016 15:25:28 +0700 Subject: [PATCH 39/46] Finish basic --- book/01-introduction/sections/basics.asc | 48 +++++++++--------------- 1 file changed, 18 insertions(+), 30 deletions(-) diff --git a/book/01-introduction/sections/basics.asc b/book/01-introduction/sections/basics.asc index a57c2ece3..751b677f1 100644 --- a/book/01-introduction/sections/basics.asc +++ b/book/01-introduction/sections/basics.asc @@ -22,7 +22,7 @@ image::images/snapshots.png[Git stores data as snapshots of the project over tim มันทำให้ Git เหมือนเป็น filesystem ขนาดจิ๋วที่มากับ tools อันทรงพลังที่สร้างขึ้นมาครอบมันมากกว่าที่จะเป็นแค่ VCS ธรรมดา เด๋วเราค่อยมาโชว์ของดีที่ได้จากการมองข้อมูลในลักษณะนี้ในหัวข้อ branching ใน Chapter 3 <<_git_branching>>. -==== Nearly Every Operation Is Local +==== โดยรวมแล้ว Git มีแต่เพิ่มข้อมูล ส่วนใหญ่แล้ว operation ใน Git ต้องการแค่ file และทรัพยากรบนเครื่องในการทำงาน ไม่จำเป็นต้องมีข้อมูลอื่นใดจากเครื่องอื่นๆใน network ถ้าคุณคุ้นเคยกับ CVCS ที่ operation ส่วนใหญ่ต้องทนกับความช้าของ network แล้วละก็ คุณจะรู้สึกราวกับว่าเทพแห่งความเร็วนั้นอวยพร Git ด้วยความเร็วส์ที่ไม่อายบรรยาย เพราะว่าคุณมี history ทั้งหมดของ project เก็บอยู่ที่นี่ในเครื่องของตัวเอง operation ทั้งหลายแหล่จึงรวดเร็วทันใจ @@ -43,45 +43,33 @@ image::images/snapshots.png[Git stores data as snapshots of the project over tim คุณจะเห็นค่า hash เหล่านี้กระจายตัวอยู่ทั่ว Git มันถูกใช้เยอะมว้ากก เอาจริงๆแล้ว Git ไม่ได้เก็บข้อมูลเป็น file แต่เก็บลง database ซึ่งสามารถเข้าถึงข้อมูลได้ด้วยค่า hash ของเนื้อหาใน file -==== Git Generally Only Adds Data +==== โดยรวมแล้ว Git มีแต่เพิ่มข้อมูล -When you do actions in Git, nearly all of them only add data to the Git database. -It is hard to get the system to do anything that is not undoable or to make it erase data in any way. -As in any VCS, you can lose or mess up changes you haven't committed yet; but after you commit a snapshot into Git, it is very difficult to lose, especially if you regularly push your database to another repository. +เมื่อคุณทำ action ใดๆใน Git เกือบทุกอย่างจะเป็นการเพิ่มข้อมูลลงไปใน Git database มันยากมากที่จะทำอะไรลงไปแล้ว undo ไม่ได้ คล้ายกับ VCS อื่นๆคือคุณยังสามรถทำ file หาย หรือว่าทำของเละเทะได้ ถ้าคุณยังไม่ได้ commit แต่เมื่อไหร่ที่คุณ commit ไปใน Git ซัก snapshot นึงแล้ว มันแทบจะไม่มีวันหายเลย โดยเฉพาะอย่างยิ่งเวลาคุณคอย push database ของคุณไปใส่ repository อื่นอย่างสม่ำเสมอ -This makes using Git a joy because we know we can experiment without the danger of severely screwing things up. -For a more in-depth look at how Git stores its data and how you can recover data that seems lost, see <<_undoing>>. +การใช้ Git จึงกลายเป็นความบันเทิงเพราะเรารู้ว่าเราสามารถทำการทดลองอะไรก็ได้โดยไม่กลัวว่าจะทำอะไรพัง ไว้ค่อยมาเจาะลึกว่า Git เก็บข้อมูลยังไง และเวลาทำอะไรเละเทะไปแล้วจะกู้กลับมายังไงในบท “Under the Covers” ใน Chapter 9., see <<_undoing>>. -==== The Three States +==== State ทั้งสาม -Now, pay attention. -This is the main thing to remember about Git if you want the rest of your learning process to go smoothly. -Git has three main states that your files can reside in: committed, modified, and staged. -Committed means that the data is safely stored in your local database. -Modified means that you have changed the file but have not committed it to your database yet. -Staged means that you have marked a modified file in its current version to go into your next commit snapshot. +เอาล่ะ! ตั้งสมาธิให้ดี นี่คือแก่นของวรยุทธ์ที่จะต้องจำให้ขึ้นใจถ้าอยากให้การศึกษา Git เป็นไปอย่างราบรื่น Git มีสาม state หลักสำหรับ file ทุก file: committed, modified และ staged +Committed แปลว่าข้อมูลถูกจัดเก็บอย่างปลอดภัยใน database บนเครื่อง, +Modified แปลว่าคุณได้แก้ file ไปแต่ยังไม่ได้ commit มันใส่ database, +Staged แปลว่าคุณได้ mark file ที่ถูก modify ใน version นี้ให้มันถูก commit ใน snapshot หน้า -This leads us to the three main sections of a Git project: the Git directory, the working directory, and the staging area. +3 state นี้ชักนำให้เกิด 3 ก๊กใน Git project นั่นคือ Git directory, working directory, และ staging area .Working directory, staging area, and Git directory. image::images/areas.png["Working directory, staging area, and Git directory."] -The Git directory is where Git stores the metadata and object database for your project. -This is the most important part of Git, and it is what is copied when you clone a repository from another computer. +Git directory คือที่ที่ Git เก็บ metadata และ object database สำหรับ project ของคุณ นี่คือส่วนที่สำคัญที่สุดของ Git และมันคือสิ่งที่ถูก copy มาเวลาที่คุณ clone repository มาจาก computer เครื่องอื่น -The working directory is a single checkout of one version of the project. -These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify. +working directory คือ checkout อันหนึ่งๆของซัก version นึงของ project ซึ่ง file เหล่านี้จะถูกดึงออกมาจาก compressed database ใน Git directory และเอามาวางบน disk ให้คุณใช้หรือว่าแก้ไขมัน -The staging area is a file, generally contained in your Git directory, that stores information about what will go into your next commit. -It's sometimes referred to as the ``index'', but it's also common to refer to it as the staging area. +staging area คือ file ธรรมดาไม่ซับซ้อน ซึ่งจะอยู่ใน Git directory ของคุณ มันจะเก็บข้อมูลว่าอะไรบ้างที่จะถูกรวมไปใน commit ถัดไป บางคนก็เรียกมันว่า index แต่คนส่วนใหญ่จะเรียกมันว่า staging area -The basic Git workflow goes something like this: +โดยเบสิคแล้ว flow ของ Git จะดำเนินไปดังนี้: -1. You modify files in your working directory. -2. You stage the files, adding snapshots of them to your staging area. -3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory. - -If a particular version of a file is in the Git directory, it's considered committed. -If it's modified but has been added to the staging area, it is staged. -And if it was changed since it was checked out but has not been staged, it is modified. -In <<_git_basics_chapter>>, you'll learn more about these states and how you can either take advantage of them or skip the staged part entirely. +คุณแก้ไข file ใน working directory +คุณ stage file เหล่านั้น (เพิ่ม snapshot ของ file เหล่านั้นใน staging area ของคุณ) +คุณ commit ซึ่งเป็นการเอา snapshot ของ file นั้นๆใน staging area มา save เก็บไว้ Git directory ตลอดกาล +ถ้า file ซัก version นึงถูกเก็บลง git directory แล้ว file นั้นจะมีสถานะ committed ถ้ามันโดนแก้และถูก add เข้าไปใน staging area มันจะมีสถานะ staged ถ้ามันถูกแก้ไขเฉยๆไปจากตอนที่ถูก check out แต่ยังไม่เคยถูก stage มันจะมีสถานะ modified ใน Chapter 2 คุณจะเข้าใจ state ทั้ง 3 นี้เพิ่มขึ้น และได้เรียนรู้วิธีที่จะใช้ประโยชน์จากพวกมันและวิธีการลัดข้ามส่วน staged ไปเลย From 037fb8da49fc64b554aeee17089baa1bfd4ad496 Mon Sep 17 00:00:00 2001 From: roofimon Date: Sat, 13 Feb 2016 15:47:50 +0700 Subject: [PATCH 40/46] Done first time --- .../sections/first-time-setup.asc | 54 +++++++------------ 1 file changed, 20 insertions(+), 34 deletions(-) diff --git a/book/01-introduction/sections/first-time-setup.asc b/book/01-introduction/sections/first-time-setup.asc index c3d12fbf3..36db1626e 100644 --- a/book/01-introduction/sections/first-time-setup.asc +++ b/book/01-introduction/sections/first-time-setup.asc @@ -1,28 +1,19 @@ [[_first_time]] -=== First-Time Git Setup +=== ติดตั้ง Git ครั้งแรก -Now that you have Git on your system, you'll want to do a few things to customize your Git environment. -You should have to do these things only once on any given computer; they'll stick around between upgrades. -You can also change them at any time by running through the commands again. +หลังจากมี Git บนเครื่องแล้ว ต้อง customize Git environment ซักนิดก่อน ขั้นตอนนี้ทำแค่ครั้งเดียวพอ ถึง upgrade version ก็ไม่ต้องมานั่ง set ใหม่ ถ้าวันหลังอยากจะเปลี่ยนมันก็เปลี่ยนได้ตลอดเวลา แค่ run command ซ้ำแค่นั้นเอง -Git comes with a tool called `git config` that lets you get and set configuration variables that control all aspects of how Git looks and operates.(((git commands, config))) -These variables can be stored in three different places: +Git มากับ tool ที่เรียกว่า git config เปิดช่องให้ get หรือ set ตัวแปร configuration ที่ควบคุมการหน้าตา, คำสั่ง และทำงานของ Git ได้ ตัวแปรเหล่านี้ถูกแบ่งเก็บใน 3 ที่ดังนี้: -1. `/etc/gitconfig` file: Contains values for every user on the system and all their repositories. - If you pass the option `--system` to `git config`, it reads and writes from this file specifically. -2. `~/.gitconfig` or `~/.config/git/config` file: Specific to your user. - You can make Git read and write to this file specifically by passing the `--global` option. -3. `config` file in the Git directory (that is, `.git/config`) of whatever repository you're currently using: Specific to that single repository. +1. file /etc/gitconfig: เก็บข้อมูล user ทุกคนในระบบรวมถึง repository ทั้งหลาย ถ้าคุณส่ง option --system ให้ git config มันจะอ่านหรือเขียนใน file นี้ตรงๆ +2. file ~/.gitconfig: เป็น file เฉพาะของ user คุณเท่านั้น สามารถเจาะจงให้ Git เขียนหรืออ่าน file นี้ได้โดยการส่ง --global option ให้มัน +3. config file ใน git directory (ซึ่งอยู่ที่ .git/config) ของ repository ใดๆที่คุณใช้งาน: เฉพาะเจาะจงกับ repository นั้นๆ แต่ละ level คอยบังค่าที่ set ใน level ก่อนๆ ฉะนั้น ค่าที่ set ไว้ใน .git/config ก็จะบังค่าใน /etc/gitconfig -Each level overrides values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`. +บน Windows นั้น Git อ่านค่าใน file .gitconfig ใน $HOME directory (ส่วนใหญ่จะอยู่ที่ C:\Documents and Settings\$USER) มันดูค่าใน /etc/gitconfig ด้วยเหมือนกัน แต่ต้องอ้างอิงกับ MSys root ซึ่งจะอยู่ที่ที่คุณ ลง Git ไว้ตอนที่ run installer -On Windows systems, Git looks for the `.gitconfig` file in the `$HOME` directory (`C:\Users\$USER` for most people). -It also still looks for `/etc/gitconfig`, although it's relative to the MSys root, which is wherever you decide to install Git on your Windows system when you run the installer. +==== Identity ของคุณ -==== Your Identity - -The first thing you should do when you install Git is to set your user name and e-mail address. -This is important because every Git commit uses this information, and it's immutably baked into the commits you start creating: +อย่างแรกที่ควรทำหลังจากลง Git คือการ set user name และ e-mail address ของคุณ ที่มันจำเป็นเพราะทุกๆ commit ใน Git จะใช้ข้อมูลนี้และมันจะถูกสลักลงไปในแต่ละ commit ที่คุณส่ง: [source,console] ---- @@ -30,31 +21,27 @@ $ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com ---- -Again, you need to do this only once if you pass the `--global` option, because then Git will always use that information for anything you do on that system. -If you want to override this with a different name or e-mail address for specific projects, you can run the command without the `--global` option when you're in that project. - -Many of the GUI tools will help you do this when you first run them. +ย้ำอีกครั้ง คุณจำเป็นต้อง set ค่าเหล่านี้แค่ครั้งเดียวถ้าคุณใช้ option --global เพราะ Git จะใช้ข้อมูลนั้นสำหรับทุกๆ action ที่คุณใช้บน system นั้น ถ้าอยากทับค่านั้นด้วชื่อหรือ e-mail address อื่น สำหรับบาง project คุณก็ทำได้โดยการ run command แล้วไม่ต้องส่ง option --global เข้าไปเวลาคนทำ project นั้น -==== Your Editor +==== Editor ของคุณ -Now that your identity is set up, you can configure the default text editor that will be used when Git needs you to type in a message. -If not configured, Git uses your system's default editor, which is generally Vim. -If you want to use a different text editor, such as Emacs, you can do the following: +หลังจาก setup Identity ของคุณแล้ว คุณก็สามารถเลือก default text editor ที่จะถูกเลือกใช้เวลา Git ต้องการให้คุณพิมพ์ message ได้ โดยปรกติแล้ว Git จะใช้ default editor ของระบบคุณ ซึ่งส่วนใหญ่จะเป็น Vi หรือ Vim ถ้าคุณอยากใช้ตัวอื่นเช่น Emacs ก็ทำได้ตังนี้: [source,console] ---- $ git config --global core.editor emacs ---- -[WARNING] +[คำเตือน] ==== -Vim and Emacs are popular text editors often used by developers on Unix based systems like Linux and Mac. If you are not familiar with either of these editors or are on a Windows system, you may need to search for instructions for how to set up your favorite editor with Git. -If you don't set an editor like this and you don't know what Vim or Emacs are, you will likely get into a really confusing state when they are launched. +Vim และ Emacs เป็น editor ที่ได้รับความนิยมสูงมากในหมู่นักพัฒนาในโลกของ Unix เช่น Linux หรือ Mac +ถ้าไม่ถนัดกับการใช้งาน editor สองตัวนี้หรือเราเป็นแฟนคลับ Windows เราก็ต้องไปค้นหาข้อมูลต่อไปว่าเราจะ set up ให้ editor ที่เราทำงานอยู่ให้ทำงานกับ Git ได้อย่างไร +ดังนัั้นถ้าเราไม่คุ้นชินกับ editor และไม่ถนัดกับการใช้งานทั้ง vim และ emacs เราจะสับสนมากกับการใช้งานเมื่อเปิด editor สองตัวนี้ออกมา ==== -==== Checking Your Settings +==== ตรวจสอบ Settings -If you want to check your settings, you can use the `git config --list` command to list all the settings Git can find at that point: +ถ้าอยาก check settings ของคุณ คุณสามารถใช้คำสั่ง git config --list เพื่อจะ list settings ทั้งหลายแหล่ที่ Git มี ณ ตอนนั้นมาให้ดูได้: [source,console] ---- @@ -68,10 +55,9 @@ color.diff=auto ... ---- -You may see keys more than once, because Git reads the same key from different files (`/etc/gitconfig` and `~/.gitconfig`, for example). -In this case, Git uses the last value for each unique key it sees. +บาง key อาจจะซ้ำเพราะ Git อ่านค่า key เดียวกันจาก file ต่างๆ (เช่นจาก /etc/gitconfig และ ~/.gitconfig เป็นต้น) ในกรณีนั้น Git จะใช้ค่าสุดท้ายที่มันเห็น -You can also check what Git thinks a specific key's value is by typing `git config `:(((git commands, config))) +คุณตรวจสอบได้ด้วยว่า Git มันกำลังคิดว่าค่าของ key นั้นๆเป็นอะไรโดยพิมพ์ว่า git config {key}:(((git commands, config))) [source,console] ---- From 908146d7c7f27dbf9ed8dd397c15cad57fd134c3 Mon Sep 17 00:00:00 2001 From: roofimon Date: Sat, 13 Feb 2016 16:00:01 +0700 Subject: [PATCH 41/46] Finish Help --- book/01-introduction/sections/help.asc | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/book/01-introduction/sections/help.asc b/book/01-introduction/sections/help.asc index 119a8aff0..3dfc8ac5a 100644 --- a/book/01-introduction/sections/help.asc +++ b/book/01-introduction/sections/help.asc @@ -1,7 +1,7 @@ [[_git_help]] -=== Getting Help +=== ขอความช่วยเหลือ -If you ever need help while using Git, there are three ways to get the manual page (manpage) help for any of the Git commands: +ถ้าต้องการความช่วยเหลือขณะใช้ Git มี 3 ทางที่จะดู help สำหรับ command ใดๆของ Git ใน manual page (manpage): [source,console] ---- @@ -10,13 +10,11 @@ $ git --help $ man git- ---- -For example, you can get the manpage help for the config command by running(((git commands, help))) +เช่นถ้าอยากดู help สำหรับคำสั่ง config ใน manpage ก็แค่ [source,console] ---- $ git help config ---- -These commands are nice because you can access them anywhere, even offline. -If the manpages and this book aren't enough and you need in-person help, you can try the `#git` or `#github` channel on the Freenode IRC server (irc.freenode.net). -These channels are regularly filled with hundreds of people who are all very knowledgeable about Git and are often willing to help.(((IRC))) +command แบบนี้มันเจ๋งตรงที่เรียกจากตรงไหนก็ได้แม้ว่าจะไม่ได้ต่อเนตก็ตาม ถ้า manpage ทั้งหลายและหนังสือเล่มนี้ยังเอาไม่อยู่และคุณต้องการคนช่วย ให้ลองไปที่ Freenode IRC (irc.freenode.net) ที่ห้อง #git หรือ #github ดู ห้องเหล่านี้โดยปรกติจะมีคนเป็นร้อยๆที่มีความรู้เรื่อง Git และชอบช่วยเหลือ From 4e10375b017b53c35857a8d5856ce94ff8c7cb2e Mon Sep 17 00:00:00 2001 From: roofimon Date: Sat, 13 Feb 2016 16:06:55 +0700 Subject: [PATCH 42/46] Finish history --- book/01-introduction/sections/history.asc | 23 ++++++++--------------- 1 file changed, 8 insertions(+), 15 deletions(-) diff --git a/book/01-introduction/sections/history.asc b/book/01-introduction/sections/history.asc index df3ebe449..689eaf213 100644 --- a/book/01-introduction/sections/history.asc +++ b/book/01-introduction/sections/history.asc @@ -1,20 +1,13 @@ === A Short History of Git -As with many great things in life, Git began with a bit of creative destruction and fiery controversy. +เฉกเช่นสิ่งมหัศจรรย์ทั้งหลายแหล่ในโลก, Git เริ่มต้นมาจากดราม่าส์เล็กๆ ณ ชุมชนหนึ่งในดาวนี้ Linux kernel เป็น open source โปรเจคอันนึงที่มีขนาดใหญ่พอสมควร เกือบทั้งชีวิตของการ maintenance kernel ของ Linux นี้ (ช่วงปี 1991–2002) การเปลี่ยนแปลงต่างๆถูกส่งไปส่งมาในรูปแบบ patch และ zip files จนกระทั่งปี 2002 Linux kernel project ก็เริ่มใช้ DVCS ที่เรียกว่า BitKeeper -The Linux kernel is an open source software project of fairly large scope.(((Linux))) -For most of the lifetime of the Linux kernel maintenance (1991–2002), changes to the software were passed around as patches and archived files. -In 2002, the Linux kernel project began using a proprietary DVCS called BitKeeper.(((BitKeeper))) +ในปี 2005 ความสัมพันธ์ระหว่าง community ที่พัฒนา Linux kernel กับบริษัท commercial ที่พัฒนา BitKeeper ก็สะบั้นลง ไอ้ tool ที่เคยใช้ได้ฟรีมาตลอดก็จุ๊งไป ทำให้ community ที่พัฒนา Linux (โดยเฉพาะท่านเทพ Linus Torvalds ที่เป็นบิดาแห่ง Linux) ต้องพัฒนา tool ขึ้นมาใช้เอง โดยอิงจากประสบการณ์ที่ได้เรียนรู้ระหว่างใช้งาน BitKeeper ระบบใหม่มีเป้าหมายบางประการ ดังนี้: -In 2005, the relationship between the community that developed the Linux kernel and the commercial company that developed BitKeeper broke down, and the tool's free-of-charge status was revoked. -This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper.(((Linus Torvalds))) -Some of the goals of the new system were as follows: +* ความเร็วส์ +* design ที่ simple +* ต้องพัฒนาไปพร้อมๆกันที่ละหลายๆคนได้ (ประมาณ 1000 branches) +* distributed สุดๆ +* ใช้กับโปรเจคใหญ่ๆอย่าง Linux kernel ได้ดี (ทั้งเรื่องความเร็วส์และขนาดของข้อมูล) -* Speed -* Simple design -* Strong support for non-linear development (thousands of parallel branches) -* Fully distributed -* Able to handle large projects like the Linux kernel efficiently (speed and data size) - -Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities. -It's incredibly fast, it's very efficient with large projects, and it has an incredible branching system for non-linear development (See <<_git_branching>>). +ตั้งแต่ถูกคลอดมาในปี 2005, Git ก็พัฒนาและเติบโตจนเป็นของที่ใช้ง่าย แต่ก็ยังคงไว้ซึ่งข้อดีข้างต้นนี้ นั่นเร็วส์สุดยิด, เหมาะกับโปรเจคขนาดยักษ์ และพัฒนาไปพร้อมๆกันทีละหลายๆ branch อย่างน่าอัศจรรย์ (ดูได้ใน Chapter 3). From d92cbd572f21ff93928a4d5b003576c79d5e6d25 Mon Sep 17 00:00:00 2001 From: roofimon Date: Sat, 13 Feb 2016 16:26:37 +0700 Subject: [PATCH 43/46] Finish command line --- book/01-introduction/sections/command-line.asc | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/book/01-introduction/sections/command-line.asc b/book/01-introduction/sections/command-line.asc index 71888c23c..00b73dc0a 100644 --- a/book/01-introduction/sections/command-line.asc +++ b/book/01-introduction/sections/command-line.asc @@ -1,11 +1,12 @@ -=== The Command Line +=== Command Line -There are a lot of different ways to use Git. +การใช้งาน Git สามารถใช้งานได้หลายรูปแบบ There are the original command line tools, and there are many graphical user interfaces of varying capabilities. +เราสามารถใช้ได้ทั้งเครื่องมือที่เป็น command line interface และนอกจากนี้ยังมีเครื่องมือที่เป็น gui อีกหลายตัวและแต่ละตัวก็จะมีความสามารถที่แตกต่างกัน For this book, we will be using Git on the command line. -For one, the command line is the only place you can run *all* Git commands – most of the GUIs only implement some subset of Git functionality for simplicity. -If you know how to run the command line version, you can probably also figure out how to run the GUI version, while the opposite is not necessarily true. -Also, while your choice of graphical client is a matter of personal taste, _all_ users will have the command-line tools installed and available. +สำหรับหนังสือเล่มนี้เราจะใช้ command line เป็นหลักเนื่องจากเครื่องมือที่เป็น command line เราสามารถใช้คำสั่งของ git ได้ทุกคำสั่งซึ่งต่างจากเครื่องมือที่เป็น GUI เพราะในบางครั้ง +เราจะไม่สามารถใช้บางคำสั่งจาก GUI ได้ อีกเรื่องที่น่าสนใจคือถ้าเราสามารถเรียกคำสั่งต่างๆจาก command line ได้เราก็จะสามารถหาวิธีเรียกใช้งานของบน GUI ได้แต่ในทางกลับกันเรา +จะไม่สามารถเรียกคำสั่งที่ถูกต้องได้ถ้าเรามีความเคยชินแต่กับการใช้งาน GUI -So we will expect you to know how to open Terminal in Mac or Command Prompt or Powershell in Windows. -If you don't know what we're talking about here, you may need to stop and research that quickly so that you can follow the rest of the examples and descriptions in this book. +ดังนั้นหนังสือเล้มนี้จุงคาดหวังว่า ทุกคนสามารถเปิด command prompt หรือ powershell บน windows ได้ +แต่ก็อย่าวิตกจนเกินไปถ้ายังใช้งาน command line interface ไม่คล่องเพราะถ้าทำตามหนังสือเล่มนี้ไปเรื่อยๆก็จะเริ่มชินกับการใช้งาน command line ไปเอง From 92a9ed36447384c7aae9cf229aeeef00041097f9 Mon Sep 17 00:00:00 2001 From: roofimon Date: Fri, 4 Mar 2016 22:50:11 +0700 Subject: [PATCH 44/46] Finish note about master --- book/03-git-branching/sections/nutshell.asc | 34 +++++++-------------- 1 file changed, 11 insertions(+), 23 deletions(-) diff --git a/book/03-git-branching/sections/nutshell.asc b/book/03-git-branching/sections/nutshell.asc index 846518bd6..250e6b6a6 100644 --- a/book/03-git-branching/sections/nutshell.asc +++ b/book/03-git-branching/sections/nutshell.asc @@ -1,15 +1,11 @@ [[_git_branches_overview]] === Branches in a Nutshell -To really understand the way Git does branching, we need to take a step back and examine how Git stores its data. +เพื่อทำความเข้าใจวิธีที่ Git แตก branch เราต้องย้อนกลับมาดูว่า Git เก็บข้อมูลยังไง ตามที่คุณอาจจะจำได้จาก Chapter 1 ว่า Git ไม่ได้เก็บข้อมูลเป็นลำดับของความเปลี่ยนแปลงต่อเวลาแต่เก็บเป็นลำดับของ snapshot ต่อเวลา -As you may remember from <<_getting_started>>, Git doesn't store data as a series of changesets or differences, but instead as a series of snapshots. +เวลาคุณ commit ใน Git นั้น Git จะเก็บเป็น object ของการ commit ซึ่งประกอบด้วย pointer ชี้ไปยัง snapshot ของ content ที่คุณ stage ไว้, metadata ของชื่อผู้แก้ไขและ message ที่บันทึกไว้ และ pointer ที่ชี้ไปยัง parent ลำดับถัดไปของ commit นั้นๆ (ซึ่งอาจจะไม่มีก็ได้ถ้าเป็น commit ครั้งแรก, อาจจะมีอันเดียวชี้ไปยัง parent ของ commit ปรกติทั่วไปหรืออาจจะมี parent หลายอันสำหรับ commit ที่เป็นผลจากการ merge หลายๆ branch เข้าด้วยกัน) -When you make a commit, Git stores a commit object that contains a pointer to the snapshot of the content you staged. -This object also contains the author's name and email, the message that you typed, and pointers to the commit or commits that directly came before this commit (its parent or parents): zero parents for the initial commit, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches. - -To visualize this, let's assume that you have a directory containing three files, and you stage them all and commit. -Staging the files checksums each one (the SHA-1 hash we mentioned in <<_getting_started>>), stores that version of the file in the Git repository (Git refers to them as blobs), and adds that checksum to the staging area: +ลองจินตนาการว่าคุณมี directory อันนึงที่มี file อยู่ข้างใน 3 files แล้วคุณก็ stage ทั้งหมดและ commit การ stage file จะสร้าง checksum ของแต่ละ file (ไอ้ SHA-1 hash ที่บอกไว้ใน Chapter 1 นั่นแหละ), แล้วบันทึก version ของ file นั้นๆใน Git repository (Git อ้างอิงพวกมันแบบ blobs) และเพิ่ม checksum นั้นลงไปใน staging area: [source,console] ---- @@ -17,29 +13,24 @@ $ git add README test.rb LICENSE $ git commit -m 'initial commit of my project' ---- -When you create the commit by running `git commit`, Git checksums each subdirectory (in this case, just the root project directory) and stores those tree objects in the Git repository. -Git then creates a commit object that has the metadata and a pointer to the root project tree so it can re-create that snapshot when needed.(((git commands, commit))) +เมื่อคุณทำการ commit ด้วยคำสั่ง git commit Git จะคำนวน checksum ของแต่ละ subdirectory (ในกรณีนี้ก็มีแค่ root project directory) และบันทึกโครงสร้างของ directory ใน Git repository หลังจากนั้น Git ก็จะสร้าง commit object ที่มี metadata และ pointer ชี้ไปยังโครงสร้างของ root project เพื่อที่มันจะได้สร้าง snapshot นั้นขึ้นมาใหม่ได้เมื่อต้องการ -Your Git repository now contains five objects: one blob for the contents of each of your three files, one tree that lists the contents of the directory and specifies which file names are stored as which blobs, and one commit with the pointer to that root tree and all the commit metadata. +Git repository ของคุณตอนนี้จะมี 5 objects: blob แต่ละ blob สำหรับ content ของแต่ละ file ใน 3 files นั้น, โครงสร้าง root directory ที่เก็บ list ของสิ่งของในนั้นและบันทึกว่า file ไหนถูกเก็บใส่ blob ไหน และ 1 commit ที่มี pointer อันนึงชี้ไปยังโครงสร้างของ root directory กับพวก metadata ของ commit นั้น ซึ่งหน้าตาของข้อมูลใน Git repository ของคุณก็มีคอนเซปประมาณรูป Figure 3-1. .A commit and its tree image::images/commit-and-tree.png[A commit and its tree.] -If you make some changes and commit again, the next commit stores a pointer to the commit that came immediately before it. +ถ้าคุณทำการแก้ไขใดๆ แล้ว commit ซ้ำอีกครั้ง commit อันถัดไปจะเก็บในรูป pointer ชี้ไปยัง commit ก่อนหน้า ทำไปอีก 2 commits history ของคุณน่าจะมีหน้าตาประมาณรูป .Commits and their parents image::images/commits-and-parents.png[Commits and their parents.] -A branch in Git is simply a lightweight movable pointer to one of these commits. -The default branch name in Git is `master`. -As you start making commits, you're given a master branch that points to the last commit you made. -Every time you commit, it moves forward automatically. +branch อันนึงใน Git เป็นแค่ pointer ฉบับกระเป๋าของ commits เหล่านี้ ชื่อโดย default ของ branch ใน Git คือ master ขณะที่คุณ commit ครั้งแรกส่งกำลังส่ง master branch อันนึงที่ points กลับไปยัง commit ก่อนหน้า ทุกครั้งที่คุณ commit มันก็ค่อยๆขยับไปๆโดยอัตโนมัติ [NOTE] ==== -The ``master'' branch in Git is not a special branch.(((master))) -It is exactly like any other branch. -The only reason nearly every repository has one is that the `git init` command creates it by default and most people don't bother to change it. +branch ชื่อ master ใน Git ไม่ใช่ branch พิเศษอะไรเลย (((master))) มันเป็นเพียง branch ธรรมดาเหมือนกับ branch อื่นๆแต่สาเหตุที่ทำให้ทุกๆ repository ต้องมี branch +นี้เพราะมันถูกสร้างขึ้นมาเป็น branch แรกโดยคำสั่ง 'git init' และเมื่อมันถูกสร้างแล้วมันก็ไม่เคยถูกเปลี่ยนเลย อาจเป็นเพราะไม่มีใครสนใจจะเปลี่ยนมันด้วยมั้ง ==== .A branch and its commit history @@ -49,17 +40,14 @@ image::images/branch-and-history.png[A branch and its commit history.] ==== Creating a New Branch (((branches, creating))) -What happens if you create a new branch? -Well, doing so creates a new pointer for you to move around. -Let's say you create a new branch called testing. -You do this with the `git branch` command:(((git commands, branch))) +แล้วจะเกิดอะไรขึ้นถ้าคุณสร้าง branch ใหม่? ก็แค่สร้าง pointer อันใหม่เพื่อที่จะโยกย้ายไปมาตามใจ ยกตัวอย่างว่าคุณสร้าง branch ใหม่ชื่อว่า testing ซึ่งสามารถทำได้ด้วยคำสั่ง git branch: [source,console] ---- $ git branch testing ---- -This creates a new pointer at the same commit you're currently on. +มันจะสร้าง pointer อันใหม่ใน commit ปัจจุบันที่คุณอยู่ .Two branches pointing into the same series of commits image::images/two-branches.png[Two branches pointing into the same series of commits.] From 445b9564971d538e71815567cd1f9d5e632f22f5 Mon Sep 17 00:00:00 2001 From: roofimon Date: Fri, 4 Mar 2016 23:42:33 +0700 Subject: [PATCH 45/46] HEAD --- book/03-git-branching/sections/nutshell.asc | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/book/03-git-branching/sections/nutshell.asc b/book/03-git-branching/sections/nutshell.asc index 250e6b6a6..802cf42fc 100644 --- a/book/03-git-branching/sections/nutshell.asc +++ b/book/03-git-branching/sections/nutshell.asc @@ -37,7 +37,7 @@ branch ชื่อ master ใน Git ไม่ใช่ branch พิเศษ image::images/branch-and-history.png[A branch and its commit history.] [[_create_new_branch]] -==== Creating a New Branch +==== การสร้าง Branch ใหม่ (((branches, creating))) แล้วจะเกิดอะไรขึ้นถ้าคุณสร้าง branch ใหม่? ก็แค่สร้าง pointer อันใหม่เพื่อที่จะโยกย้ายไปมาตามใจ ยกตัวอย่างว่าคุณสร้าง branch ใหม่ชื่อว่า testing ซึ่งสามารถทำได้ด้วยคำสั่ง git branch: @@ -52,17 +52,16 @@ $ git branch testing .Two branches pointing into the same series of commits image::images/two-branches.png[Two branches pointing into the same series of commits.] -How does Git know what branch you're currently on? -It keeps a special pointer called `HEAD`. -Note that this is a lot different than the concept of `HEAD` in other VCSs you may be used to, such as Subversion or CVS. -In Git, this is a pointer to the local branch you're currently on. -In this case, you're still on master. -The `git branch` command only _created_ a new branch – it didn't switch to that branch. +แล้ว Git รู้ได้ไงนะว่าเรากำลังทำงานอยู่บน Branch ไหน? +รู้สิเพราะมันมี pointer พิเศษชื่อ `HEAD` อยู่ อย่างไรก็ตามคำว่า `HEAD` ของ Git นี่ต่างจาก VCS ที่พวกเราเคยใช้เช่น Subversion, CVS อย่างมากมาย +ใน Git นั้นเจ้า HEAD จะชี้ไปที่ local branch ที่เรากำลังทำงานอยู่ซึ่งถ้าเรายังไม่มีการเปลี่ยน branch ไปไหนมันก็จะชี้ไว้ที่ Master ดังนั้น `git branch` +จึงเป็นคำสั่งที่มีไว้สร้าง branch เพียงเท่านั้นมันไม่ได้ switch branch ให้เราแม้แต่นิดเดียว + .HEAD pointing to a branch image::images/head-to-master.png[HEAD pointing to a branch.] -You can easily see this by running a simple `git log` command that shows you where the branch pointers are pointing. This option is called `--decorate`. +ซึ่งถ้าเราอยากรู้ว่าตอนนี้ HEAD อยู่ที่ไหนเราสามารถใช้คำสั่ง `git log` เพื่อแสดงข้อมูลออกมาได้และการแสดงข้อมูลแบบนี้เราจะต้องส่ง option เพิ่มที่ชื่อ decorate เข้าไปด้วยดังนี้ [source,console] ---- From d0f51e68ea408613c576b6a11ac8274211284b31 Mon Sep 17 00:00:00 2001 From: roofimon Date: Sat, 5 Mar 2016 07:35:10 +0700 Subject: [PATCH 46/46] switch barnch --- book/03-git-branching/sections/nutshell.asc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/book/03-git-branching/sections/nutshell.asc b/book/03-git-branching/sections/nutshell.asc index 802cf42fc..45b04ef2b 100644 --- a/book/03-git-branching/sections/nutshell.asc +++ b/book/03-git-branching/sections/nutshell.asc @@ -71,14 +71,14 @@ f30ab (HEAD, master, testing) add feature #32 - ability to add new 98ca9 initial commit of my project ---- -You can see the ``master'' and ``testing'' branches that are right there next to the `f30ab` commit. +เราจะเห็น branch ชื่อ ``master'' และ ``testing'' อยู่เคียงข้างกันที่ commit หมายเลข `f30ab` [[_switching_branches]] ==== Switching Branches (((branches, switching))) -To switch to an existing branch, you run the `git checkout` command.(((git commands, checkout))) -Let's switch to the new testing branch: +ดังนั้นถ้าเราต้องการเปลี่ยน branch เพื่อไปทำงานที่ branch ใหม่เราสามารถทำได้ด้วยการใช้ำคำสั่ง `git checkout`(((git commands, checkout))) +เราไปทำงานที่ branch ชื่อ testing กัน [source,console] ----