Quan điểm khi sử dụng Git - Phần 2

2.3 Git Basics - Viewing the Commit History

Viewing the Commit History




Those are only some simple output-formatting options to git log — there are many more. Common options to git log lists the options we’ve covered so far (chúng tôi đã đề cập đến giờ), as well as (cũng như) some other common formatting options that may be useful, along with how they change the output of the log command.

Table 2. Common options to git log
OptionDescription
-p
Show the patch introduced with each commit.
--stat
Show statistics for files modified in each commit.
--shortstat
Display only the changed/insertions/deletions line from the --stat command.
--name-only
Show the list of files modified after the commit information.
--name-status
Show the list of files affected with added/modified/deleted information as well.
--abbrev-commit
Show only the first few characters of the SHA-1 checksum instead of all 40.
--relative-date
Display the date in a relative format (for example, “2 weeks ago”) instead of using the full date format.
--graph
Display an ASCII graph of the branch and merge history beside the log output.
--pretty
Show commits in an alternate format. Options include oneline, short, full, fuller, and format (where you specify your own format).
--oneline
Shorthand for --pretty=oneline --abbrev-commit used together.

Limiting Log Output

In addition(ngoài các) to output-formatting options, git log takes a number (có một số) of useful limiting options — that is, options that let you show only a subset(tập con) of commits. You’ve seen (bạn đã thấy) one such option already (một tùy chọn như vậy) — the -2 option, which displays only the last two commits. In fact (trong thực tế), you can do -<n>, where n is any integer to show the last n commits. In reality (thực tế), you’re unlikely to use that often (bạn không thể sử dụng thường xuyên như vậy), because Git by default pipes all output through a pager (hiển thị đầu ra trong một trang) so you see only one page of log output at a time.

 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:

 
$ git log --since=2.weeks
This command works with lots of formats — you can specify a specific date (ngày cụ thể) like "2008-01-15", or a relative date such as "2 years 1 day 3 minutes ago".

 You can also filter(lọc) the list to commits that match some search criteria(tiêu chí). 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
You can specify more than one instance of both the --author and --grep search criteria, which will limit the commit output to commits that match any of the --author patterns and any of the --grep patterns; however, adding the --all-match option further limits (giới hạn hơn nữa) the output to just (chỉ) those commits that match all --grep patterns.

 Another really helpful filter is the -S option (colloquially(thông tục) referred to as Git’s “pickaxe” option), which takes a string and shows only those(những) commits that changed the number of occurrences (số lần thay đổi) of that string. For instance (ví dụ), if you wanted to find the last commit that added or removed a reference to a specific function, you could call:

 
$ git log -S function_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(giới thiệu) a change to those files. This is always the last option and is generally preceded (thường đi trước) by double dashes (--) to separate (để tách) the paths from the options.

 In Options to limit the output of git log we’ll list these and a few other common options for your reference.
Table 3. Options to limit the output of git log
OptionDescription
-<n>
Show only the last n commits
--since, --after
Limit the commits to those made after the specified date.
--until, --before
Limit the commits to those made before the specified date.
--author
Only show commits in which the author entry matches the specified string.
--committer
Only show commits in which the committer entry matches the specified string.
--grep
Only show commits with a commit message containing the string
-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 in the month of October 2008 and are not merge commits, you can run something like this:

 
$ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \
   --before="2008-11-01" --no-merges -- t/
5610e3b - Fix testcase failure when extended attributes are in use
acd3b9e - Enhance hold_lock_file_for_{update,append}() API
f563754 - demonstrate breakage of detached checkout with symbolic link HEAD
d1a43f2 - reset --hard/read-tree --reset -u: remove unmerged new paths
51a94af - Fix "checkout --track -b newbranch" on detached HEAD
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.(Trong số gần 40.000 cam kết trong lịch sử mã nguồn Git, lệnh này cho thấy 6 phù hợp với các tiêu chí đó.)

 Tip
Preventing(ngăn chặn) the display of merge commits.
Depending(tùy thuộc) on the workflow used in your repository, it’s possible that a sizable percentage (có thể có một tỉ lệ lớn) of the commits in your log history are just merge commits, which typically(thường) aren’t very informative. To prevent(ngăn) the display of merge commits cluttering up (làm lộn xộn) your log history, simply add the log option --no-merges.

2.4 Git Basics - Undoing Things

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 (bạn đã thực hiện). Be careful (Hãy cận thận), because you can’t always undo (không thể luôn hoàn tác) some of these undos. This is one of the few areas (một số ít lĩnh vực) in Git where you may lose(mất) some work if you do it wrong.

 One of the common undos takes place (diễn ra) when you commit too early (quá sớm) and possibly forget (có thể quên) to add some files, or you mess up (hỏng) your commit message. If you want to redo that commit, make the additional changes (thực hiện các thay đổi bổ sung) you forgot, stage them, and commit again using the --amend option:

 
$ git commit --amend
This command takes(lấy) your staging area and uses it for the commit. If you’ve made no changes since your last commit (nếu bạn không thực hiện thay đổi nào từ lần commit cuối cùng) (for instance, you run this command immediately after your previous commit (ví dụ như bạn chạy lệnh này ngay sau lệnh commit trước đó)), then your snapshot will look exactly the same (giống hệt nhau), and all you’ll change is your commit message.

 The same commit-message editor fires up (kích hoạt), but it already contains (đã chứa) the message of your previous commit. You can edit the message the same as always (giống như mọi khi), but it overwrites your previous commit.

 As an example, if you commit and then realize(nhận ra) you forgot to stage the changes in a file you wanted to add to this commit, you can do something like this:
$ git commit -m 'initial commit'
$ git add forgotten_file
$ git commit --amend
You end up with a single commit — the second commit replaces the results of the first.

 Note
It’s important to understand (điều quan trọng cần nhớ) that when you’re amending your last commit, you’re not so much fixing it (bạn không sửa chửa nhiều) as replacing it entirely with a new (như thay thế nó hoàn toàn bằng 1 commit mới), improved(cải tiến) commit that pushes(đẩy) the old commit out of the way and puts the new commit in its place. Effectively (hiệu quả), it’s as if the previous commit never happened (như thể commit trước đó chưa từng xảy ra), and it won’t show up in your repository history.

 The obvious value (giá trị rõ ràng) to amending commits is to make minor improvements (thực hiện các cãi tiến) to your last commit, without cluttering(không làm lộn xộn) your repository history with commit messages of the form, “Oops, forgot to add a file” or “Darn, fixing a typo in last commit”.

Unstaging a Staged File

The next two sections (hai phần tiếp theo) demonstrate(mô tả) how to work with your staging area and working directory changes. The nice part is that the command you use to determine(xác định) 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(vô tình) type git add * and stage them both. How can you unstage one of the two? The git status command reminds you:

 
$ git add *
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README
    modified:   CONTRIBUTING.md
Right below the “Changes to be committed” text, it says use git reset HEAD <file>... to unstage. So, let’s use that advice to unstage the CONTRIBUTING.md file:

 
$ git reset HEAD CONTRIBUTING.md
Unstaged changes after reset:
M CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md
The command is a bit strange(lạ hoắc), but it works. The CONTRIBUTING.md file is modified but once again unstaged.

 Note
It’s true that git reset can be a dangerous command (một lệnh nguy hiểm), especially(đặc biệt) if you provide the --hard flag. However, in the scenario described above (trong kịch bản được mô tả ở trên), the file in your working directory is not touched(đụng chạm), so it’s relatively safe (tương đối an toàn).

 For now this magic invocation(phép gọi này) is all you need to know about the git reset command. We’ll go into much more detail (chúng tôi sẻ đi vào chi tiết hơn) about what reset does and how to master it (làm chủ nó) to do really interesting things (điều thực sự thú vị) in Reset Demystified.

Unmodifying a Modified File

What if you realize(nhận ra) 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 (nó trông giống) 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:

 
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md
It tells you pretty explicitly how to discard the changes you’ve made(Nó cho bạn biết rõ ràng cách loại bỏ các thay đổi bạn đã thực hiện.). Let’s do what it says:

 
$ git checkout -- CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README
You can see that the changes have been reverted.

 Important
It’s important to understand that git checkout -- <file> is a dangerous(nguy hiểm) command. Any changes you made to that file are gone(biến mất) — Git just copied another file over it (Git vừa chép một tập tin khác lên đó.). Don’t ever (không bao giờ) use this command unless(trừ khi) you absolutely know (hoàn toàn biết rằng) that you don’t want the file.

 If you would like to keep the changes you’ve made to that file but still need (vẫn cần) to get it out of the way for now (xóa bỏ nó bây giờ), we’ll go over (đi sâu hơn) stashing and branching in Git Branching; these are generally better ways to go (đây là những cách tốt hơn để đi.).

 Remember, anything that is committed in Git can almost(hầu như) always be recovered. Even (ngay cả khi) commits that were on (ở trên các) 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 (không bao giờ được nhìn thấy 1 lần nữa).

2.5 Git Basics - Working with Remotes

Working with Remotes

To be able to collaborate (để có thể cộng tác) 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(một số) of them, each of which generally (mỗi cái trong số đó thường) is either(hoặc) read-only or read/write for you. Collaborating(cộng tác) with others involves managing these remote repositories (người khác liên quan đến việc quản lý các kho lưu trữ từ xa này) 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(khác nhau) remote branches and define them as being tracked or not, and more. In this section, we’ll cover some of these remote-management skills.

 Note
Remote repositories can be on your local machine.
It is entirely possible (hoàn toàn có thể) that you can be working with a “remote”(từ xa) repository that is, in fact (trên thực tế), on the same host you are. The word “remote” does not necessarily (không cần thiết) imply that(ngụ ý rằng) the repository is somewhere else on the network or Internet, only that it is elsewhere (chỉ ở nơi khác). Working with such a remote repository would still involve (vẫn liên quan đến) all the standard pushing, pulling and fetching operations as with any other remote.

Showing Your Remotes

To see which remote servers you have configured, you can run the git remote command. It lists the shortnames of each remote handle you’ve specified (đã chỉ định). If you’ve cloned your repository, you should at least see origin — that is the default name Git gives(cung cấp) to the server you cloned from:

 
$ git clone https://github.com/schacon/ticgit
Cloning into 'ticgit'...
remote: Reusing existing pack: 1857, done.
remote: Total 1857 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (1857/1857), 374.35 KiB | 268.00 KiB/s, done.
Resolving deltas: 100% (772/772), done.
Checking connectivity... done.
$ cd ticgit
$ 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:

 
$ git remote -v
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 (một số cộng tác viên trông giống như thế này).

 
$ cd grit
$ git remote -v
bakkdoor  https://github.com/bakkdoor/grit (fetch)
bakkdoor  https://github.com/bakkdoor/grit (push)
cho45     https://github.com/cho45/grit (fetch)
cho45     https://github.com/cho45/grit (push)
defunkt   https://github.com/defunkt/grit (fetch)
defunkt   https://github.com/defunkt/grit (push)
koke      git://github.com/koke/grit.git (fetch)
koke      git://github.com/koke/grit.git (push)
origin    git@github.com:mojombo/grit.git (fetch)
origin    git@github.com:mojombo/grit.git (push)
This means we can pull contributions (kéo sự đóng góp) 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 (mặc dù chúng tôi không thể nói điều đó ở đây).

 Notice that (Lưu yhs rằng) these remotes use a variety of protocols (nhiều phương thức truyền tải khác nhau); we’ll cover more (giới thiệu thêm) about this in Getting Git on a Server.

Adding Remote Repositories

We’ve mentioned(đề cập) and given some demonstrations(biểu lộ) of how the git clone command implicitly(ngầm định) adds the origin remote for you. Here’s how to add a new remote explicitly(một cách rõ ràng). To add a new remote Git repository as a shortname you can reference easily, run git remote add <shortname> <url>:

 
$ git remote
origin
$ git remote add pb https://github.com/paulboone/ticgit
$ git remote -v
origin https://github.com/schacon/ticgit (fetch)
origin https://github.com/schacon/ticgit (push)
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 (thay cho) of the whole URL. For example, if you want to fetch all the information that Paul has but that you don’t yet have (chưa có) in your repository, you can run git fetch pb:

 
$ git fetch pb
remote: Counting objects: 43, done.
remote: Compressing objects: 100% (36/36), done.
remote: Total 43 (delta 10), reused 31 (delta 5)
Unpacking objects: 100% (43/43), done.
From https://github.com/paulboone/ticgit
 * [new branch]      master     -> pb/master
 * [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(kiểm tra) it. (We’ll go over what branches are and how to use them in much more detail in Git Branching.)

Fetching and Pulling from Your Remotes

As you just saw, to get data from your remote projects, you can run:

 
$ git fetch <remote>
The command goes out (đi ra ngoài) to that remote project and pulls down (kéo xuống) all the data from that remote project that you don’t have yet (bạn chưa có). After you do this, you should have references to all the branches from that remote, which you can merge in or inspect(kiểm tra) at any time.

 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 (đã được đẩy) to that server since you cloned (or last fetched from) it. It’s important to note (điểu quan trọng cần lưu ý là) that the git fetch command only downloads 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 (thay đổi những gì bạn đang làm). You have to merge it manually (bạn phải hợp nhất nó theo cách thủ công) into your work when you’re ready.

 If your current branch is set up to track(theo dõi) a remote branch (see the next section and Git Branching for more information), you can use the git pull command to automatically fetch(nạp) and then merge that remote branch into your current branch. This may be an easier or more comfortable(thoải mái) 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 (bất kì nhánh nào) is called) on the server you cloned from. Running git pull generally(nói chung là) fetches(nạp) data from the server you originally cloned (sao chép ban đầu) from and automatically tries to merge (tự động cố gắng hợp nhất nó) it into the code you’re currently working on.

Pushing to Your Remotes

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> <branch>. If you want to push your master branch to your  origin server (again, cloning generally sets up both of those names (cả hai tên đó) for you automatically), then you can run this to push any commits you’ve done back up to the server:

 
$ git push origin master
This command works only if you cloned from a server to which you have write access (có quyền truy cập) and if nobody has pushed in the meantime (không có ai đẩy lên trong thời gian chờ đợi). If you and someone else clone at the same time (nhân bản cùng một lục) and they push upstream (đẩy ngược lên) and then you push upstream (sau đó bạn đẩy ngược lên), your push will rightly be rejected (Cú đẩy của bạn sẻ bị từ chối một cách chính xác). You’ll have to fetch their work (tìm nạp sản phẩm của họ trước) first and incorporate it into yours (và kết hợp nó vào sản phẩm của bạn) before you’ll be allowed to push (được phép đẩy). See Git Branching for more detailed information on how to push to remote servers.

Inspecting a Remote

If you want to see more information (xem thông tin thêm) about a particular(cụ thể) remote, you can use the git remote show <remote> command. If you run this command with a particular shortname, such as origin, you get something like this:

 
$ git remote show origin
* remote origin
  Fetch URL: https://github.com/schacon/ticgit
  Push  URL: https://github.com/schacon/ticgit
  HEAD branch: master
  Remote branches:
    master                               tracked
    dev-branch                           tracked
  Local branch configured for 'git pull':
    master merges with remote master
  Local ref configured for 'git push':
    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(kéo) all the remote references. It also lists all the remote references it has pulled(đã kéo) down.

 That is a simple example you’re likely to encounter(gặp phải). When you’re using Git more heavily (khi bạn sử dụng git nhiều hơn), however, you may see much more information from git remote show:

 
$ git remote show origin
* remote origin
  URL: https://github.com/my-org/complex-project
  Fetch URL: https://github.com/my-org/complex-project
  Push  URL: https://github.com/my-org/complex-project
  HEAD branch: master
  Remote branches:
    master                           tracked
    dev-branch                       tracked
    markdown-strip                   tracked
    issue-43                         new (next fetch will store in remotes/origin)
    issue-45                         new (next fetch will store in remotes/origin)
    refs/remotes/origin/issue-11     stale (use 'git remote prune' to remove)
  Local branches configured for 'git pull':
    dev-branch merges with remote dev-branch
    master     merges with remote master
  Local refs configured for 'git push':
    dev-branch                     pushes to dev-branch                     (up to date)
    markdown-strip                 pushes to markdown-strip                 (up to date)
    master                         pushes to master                         (up to date)
This command shows which branch is automatically pushed(bị đẩy) to when you run git push while on certain branches (một số nhánh nhất định). It also shows you which remote branches on the server you don’t yet have (bạn chưa có), which remote branches you have that have been removed (đã xóa) from the server, and multiple local branches that are able to merge automatically (có thể hợp nhất tự động) with their remote-tracking branch when you run git pull.

Renaming and Removing Remotes

You can run git remote rename to change a remote’s shortname. For instance, if you want to rename pb to paul, you can do so with git remote rename:

 
$ git remote rename pb paul
$ git remote
origin
paul
It’s worth mentioning that this (Điều đáng nói là điều này) changes all your remote-tracking branch names, too. What used to be referenced at pb/master is now at paul/master.

 If you want to remove a remote for some reason — you’ve moved the server (đã di chuyển máy chủ) or are no longer using a particular mirror (không còn sử dụng một máy nhân bản cụ thể), or perhaps a contributor isn’t contributing anymore (có thể một người đóng góp không còn đóng góp nữa)— you can either use git remote remove or git remote rm:

 
$ git remote remove paul
$ git remote
origin
Once you delete the reference to a remote this way, all remote-tracking branches and configuration settings associated with that remote are also deleted.
Để đáp ứng nhu cầu phát triển của Công ty, Chúng tôi cần tuyển 30 Học viên xử lý ảnh cụ thể như bên dưới. Anh/Chị nào có người thân, bạn bè...xin vui lòng giới thiệu giúp!
Vị trí:                 Học viên xử lý ảnh
Nơi làm việc:     Quy Nhơn
Số lượng:           30
Mô tả công việc:
     -   Thực hiện công việc thiết kế theo yêu cầu khách hàng
     -   Sử dụng các phần mềm đồ họa chuyên dùng Cad, Sketchup, Indd, Ai, Psd…
     -   Thiết kế ấn phẩm : Tạp chí, Catalogue, sách, bản đồ map, chỉnh sửa ảnh
Yêu cầu:
     -   Sử dụng thành thạo máy tính
     -   Ko đòi hỏi về chuyên môn đồ họa
     -   Có tinh thần hợp tác, chịu được áp lực công việc
     -   Sẵn sàng làm thêm ngoài giờ khi có yêu cầu
Quyền lợi:
     -   Được đào tạo thành thạo các phần mềm thiết kế chuyên dụng Cad, Sketchup, Indd, Ai, Psd…
     -   Được ký HĐ chính thức sau khi đào tạo dựa trên kết quả đánh giá hàng tháng.
     -   Mức lương cạnh tranh tương xứng với năng lực làm việc
     -   Cơ hội làm việc thăng tiến trong môi trường hiện đại,năng động,đa văn hóa
     -   Chế độ chăm sóc sức khỏe đặc biệt dành cho nhân viên và người thân (FPT care)
     -   Và rất nhiều quyền lợi hấp dẫn khác....
Hạn nộp hồ sơ:       05/07/2018
Gửi hồ sơ đính kèm qua email: tuyendung@fsoft.com.vn
Địa chỉ: Tòa nhà FPT Complex, Đường Nam Kỳ Khởi Nghĩa, Phường Hòa Hải, Quận Ngũ Hành Sơn, TP Đà Nẵng.
Điện thoại: +84 236 3958 777 hoặc +84 236 3952 332, Fax: +84 236 3 958 776.




































Không có nhận xét nào:

Đăng nhận xét

Đăng ký: Đăng Nhận xét (Atom)