Hunky Git 퀵 가이드

커버 이미지: Two People Holding Macbook Pro x Christina Morillo
git에 대해 이야기할 때, 많은 개발자들은 한 개 이상의 파일에 변경을 하고, 이 파일들을 임시 저장하고, 제출을 만드는 것에 만족한다.
일반적으로 이 작업 흐름은 운행이 양호하다.그러나 간혹 파일의 측면에서git를 고려하면 제출이 원자가 아닐 수도 있습니다.
한 파일에서 여러 개의 변경 사항을 다른 커밋으로 분할해야 하는 경우도 있습니다.예를 들어, 클래스에 기능을 추가하고 있지만, 작업 중에 다른 방법을 재구성하기로 결정한다면, 이 두 가지 변경 사항을 두 개의 제출로 나누는 것은 의미가 있을 수 있습니다.
변경 사항을 취소하고 다시 놓으면 쉽게 할 수 있지만, 몇 줄보다 더 중요하거나 여러 파일에서 이렇게 하면git를 사용하는 것이 더 편리합니다.
이것은 git add --patch의 용례다.대부분git를 사용하는 개발자들이 알고 있는 바와 같이 git add은 미래에 임시 저장 파일을 제출하기 위한 명령이다.나는git를 사용하는 많은 개발자들이 --patch 로고에 대해 잘 알지 못하는 것을 발견했기 때문에 나는 여기서 이것에 대해 설명할 것이다.
새 git 명령이나 로고를 만났을 때, 먼저 git에게 물어봐야 합니다.

git add --help

--help 로고는 대량의 유용한 문서를 제공할 것입니다. (탐색이 아니라 읽어야 합니다.) 주어진git 명령의 기능을 정확하게 설명합니다.
주로, 우리는 git add 명령을 볼 수 있습니다. "작업 트리의 현재 내용을 사용하여 색인을 업데이트하고, 다음 제출을 위해 임시로 저장할 내용을 준비합니다."
이것은 우리가 이미 알고 있는 것을 거의 증명하였지만, --patch은?
아래로 스크롤하면 --patch에 대한 설명이 표시됩니다.

-p, --patch
Interactively choose hunks of patch between the index and the work tree and add them 
to the index. This gives the user a chance to review the difference before adding 
modified contents to the index.

이 설명은 -p 로고 사용에 관한 중요한 사항 중 하나 또는 두 가지를 설명한다.우선, 사용자가'상호작용 방식으로 연출할 멋쟁이'를 선택할 수 있도록 한다.그 다음으로 "색인에 수정 내용을 추가하기 전에 차이를 볼 수 있는 기회가 있습니다."--patch의 첫 번째 장점은 매우 유용하지만, 저도 제출하기 전에 변경 사항을 검사하는 실천에서 많은 가치가 있음을 발견했습니다.git add --patch 로고를 사용하면 매우 간단합니다.
이 예에 대해 Solidusgemspec 파일의 일부 내용을 변경하고 싶다고 가정하십시오.나는 gm 설명을 업데이트할 것이며, --patch에 대한 의존도 포함할 것이다.
이러한 변경을 한 후에 solidus_graphql_api을 실행하여 무대에 오르는 UI를 만났습니다.

solidus master % git add solidus.gemspec --patch
diff --git a/solidus.gemspec b/solidus.gemspec
index 3d8d40ed4..d585334e1 100644
-------- a/solidus.gemspec
+++ b/solidus.gemspec
@@ -7,7 +7,7 @@ Gem::Specification.new do |s|
   s.name        = 'solidus'
   s.version     = Spree.solidus_version
   s.summary     = 'Full-stack e-commerce framework for Ruby on Rails.'
-  s.description = 'Solidus is an open source e-commerce framework for Ruby on Rails.'
+  s.description = 'Solidus is a neat open source e-commerce framework for Ruby on Rails.'

   s.files        = Dir['README.md', 'lib/**/*']
   s.require_path = 'lib'
Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]?

나는 지금이 잘생긴 남자를 정의할 때라고 생각한다.
GNU diffutils manual은 이런 언어를 사용하는 잘생긴 남자를 묘사했다.

When comparing two files, diff finds sequences of lines common to both files, interspersed with groups of differing lines called hunks.

쉽게 말하면 한 줄 혹은 여러 줄에 변화가 생겼다.파일이 아닌 큰 블록을 옮기는 것은 옮기는 내용과 시간을 세밀하게 제어할 수 있다는 장점이 있다.무대에 오를 때 코드를 검사하고 제출 구조를 더욱 원자화할 수 있습니다.
만약 이 인터페이스에 있다면, 알림이 매우 불투명하다는 것을 알 수 있습니다.

Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]?

누가 머리가 정상적인 상황에서 우리가 옳고 그름에 대답할 수 있는 11가지 옵션이 필요하다고 결정했습니다!?고맙습니다. 우리는 물음표로 git의 질문에 대답할 수 있습니다. git가 왜 이러는지 알려주십시오.

Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]? ?
y - stage this hunk
n - do not stage this hunk
q - quit; do not stage this hunk or any of the remaining ones
a - stage this hunk and all later hunks in the file
d - do not stage this hunk or any of the later hunks in the file
g - select a hunk to go to
/ - search for a hunk matching the given regex
j - leave this hunk undecided, see next undecided hunk
J - leave this hunk undecided, see next hunk
e - manually edit the current hunk
? - print help

고맙습니다git!
이러한 옵션의 대부분은 편리한 기능입니다.나는 오류를 보고 그것을 상연하기 전에 복구할 수 있도록 하기 때문에 git add solidus.gemspec --patch을 특히 좋아한다.이 도구를 이용하면 공백 복구나 맞춤법 오류 삭제 등 미래의 제출을 없애는 데 도움이 될 것이다. 왜냐하면 이런 일은 내가 변경을 준비할 때 처리할 수 있기 때문이다.
이것은 보기에 매우 좋아 보이기 때문에 나는 계속해서 e으로 이것을 보여 줄 것이다.
그리고 나는 다음 잘생긴 남자로 들어갔다.

@@ -26,4 +26,5 @@ Gem::Specification.new do |s|
   s.add_dependency 'solidus_core', s.version
   s.add_dependency 'solidus_frontend', s.version
   s.add_dependency 'solidus_sample', s.version
+  s.add_dependency 'solidus_graphql', s.version
 end
Stage this hunk [y,n,q,a,d,K,g,/,e,?]?

나는 이것에 대해 임시 저장을 하고 싶지 않다. 왜냐하면 나는 새로운 의존항을 추가하기 위해 다른 제출을 하고 싶기 때문에, 나는 y으로 알림을 응답하여 종료하고 다른 내용을 임시 저장하지 않는다.
이제 설명 변경 사항을 제출합니다.

git commit -m "Update gem description."

나는 다음 제출 때 다시 잘생긴 남자를 주목할 수 있다.

git add solidus.gemspec --patch

@@ -26,4 +26,5 @@ Gem::Specification.new do |s|
   s.add_dependency 'solidus_core', s.version
   s.add_dependency 'solidus_frontend', s.version
   s.add_dependency 'solidus_sample', s.version
+  s.add_dependency 'solidus_graphql', s.version
 end
Stage this hunk [y,n,q,a,d,K,g,/,e,?]?

나는 여기에 잘못이 있는 것을 보았다.이 보석은 실제로 q이라고 하기 때문에 빨리 편집해야 합니다.solidus_graphql_api으로 힌트에 대답하면 Vim에 들어갈 수 있습니다. 이렇게 하면 제가 빠르게 변경할 수 있습니다.

# Manual hunk edit mode -- see bottom for a quick guide.
  @@ -26,4 +26,5 @@ Gem::Specification.new do |s|
   s.add_dependency 'solidus_core', s.version
   s.add_dependency 'solidus_frontend', s.version
   s.add_dependency 'solidus_sample', s.version
+  s.add_dependency 'solidus_graphql_api', s.version
  end
# ---
# To remove '-' lines, make them ' ' lines (context).
# To remove '+' lines, delete them.
# Lines starting with # will be removed.
#·
# If the patch applies cleanly, the edited hunk will immediately be
# marked for staging.
# If it does not apply cleanly, you will be given an opportunity to
# edit again.  If all lines of the hunk are removed, then the edit is
# aborted and the hunk is left unchanged.
~

변경 사항을 작성하고 저장하면 터미널로 다시 보내져 커밋을 만들 수 있습니다.

git commit -m "Add solidus_graphql_api dependency"

지금 우리가 일지를 원한다면:

commit 2eff835db6807163f395529cfb89643a17b9b817 (HEAD -> test-git-patch)
Author: jacobherrington <[email protected]>
Date:   Tue Aug 13 10:39:56 2019 -0500

    Add solidus_graphql_api dependency

commit 70c9aab9d7a829042a35ebc9153b1b85c4e35292
Author: jacobherrington <[email protected]>
Date:   Tue Aug 13 09:30:09 2019 -0500

    Update gem description

e 로고는 항상 정확한 도구가 아니다. 때로는 임시 저장 파일을 제출하기 위해서만 충분하지만, 특히 더욱 실질적이고 복잡한 변경 상황에서 --patch 로고를 사용하는 것은 자신의 현명한 검사라고 생각한다.
한 걸음 더 해서 당신이 정확한 결정을 했는지 검증하는 것은 항상 현명하다.

A good programmer is someone who always looks both ways before crossing a one-way street. - Doug Linder

상관없어. 도그 린드가 누구인지, 그리고 이 말이 처음 어디서 왔는지 알려줄 사람이 있다면 너무 멋있어.🤠