Giit 명령 입문: restore 동작 설명 중!"제7회"

9703 단어 GitGitHubLinux환경 구조tech

대본의 3이 맞다면.


안녕하세요~ 저번에 이렇게 흐리멍덩하게 멘탈 붕괴됐는데 다들 괜찮으세요?글쎄, 옵션을 동시에 설정할 때, 두 가지 결과가 예측될 때는 의심스러운 수수께끼지~ (쓴웃음) 결국, 내가 git 개발 입장에 서면 옵션의 우선순위를 명확히 할 수 있을 것 같아.예를 들어 -working-staged가 기재되어 있으면 시나리오 1, 앞뒤를 바꾸고, Staged-working을 쓴 후 시나리오 2를 이렇게 구분하여 사용하는 규격을 사용하지 않으면 git 도구의 경우라도 처리 절차가 모순되는 상태가 남는다~[1]<

겸사겸사 지난번 보도를 말씀드리자면, 여기 있습니다!


https://zenn.dev/shiozumi/articles/081244e7fb9256
내가 예측하고 싶은 동작은 다음과 같은 두 가지가 있는데, 결과는 3번이다.

README.md의 초기 상태


각 영역
Working Tree
Staging Area
Git Repository
파일 이름
README.md
README.md
README.md
컨텐트
test add (^^)
test add
test
  • git restore --worktree --staged README.첫 번째 결과로 이동
  • git restore --staged --worktree README.두 번째 결과로 이동

    • 1번 결과:worktree-staged 순서대로 처리


    각 영역
    Working Tree
    Staging Area
    Git Repository
    파일 이름
    README.md
    README.md
    README.md
    컨텐트
    test add
    test
    test

    2번 결과:staged-worktree 순서대로 처리


    각 영역
    Working Tree
    Staging Area
    Git Repository
    파일 이름
    README.md
    README.md
    README.md
    컨텐트
    test
    test
    test
    원래는 이렇게 동작을 구분할 수 있는 방법을 만들어야 한다.[2]

    실제로는 세 번째 대본! - - -Staged 무시!


    각 영역
    Working Tree
    Staging Area
    Git Repository
    파일 이름
    README.md
    README.md
    README.md
    컨텐트
    test add
    test add
    test
    결과 -- Staged가 무시되어 유효하지 않습니다.
    다른 사이트도 몇 개 찾아봤지만 잘못된 사이트를 이해하는 정보도 있을 수 있으니 조금만 주의해 주세요.지금부터 조사를 시작하겠습니다. 제가 잘못 알았나 봐요. 하지만 지금 어떻게 하든 무시하고 있습니다. 작업tree와 Staged를 동시에 지정합니다.[3]

    여기까지 돌아본 소감!


    급하신 분들은 넘어가셔도 돼요!
    Git2.나는 23에서 도입된 restore 지령을 여기까지 조사했지만, 나 자신은git의 숙련자가 아니기 때문에 그 방법과 조사 방법도 독특해졌다.이런 결과는 아마도 독자 여러분에게 폐를 끼칠 것이다.만약 그렇다면 떳떳하지 못하다.나의 목표는 가능한 한 간단명료하고 알기 쉽게 조금씩 깊이 이해하고 초보자가 넘어질 수 있는 곳, 의문이 생길 수 있는 곳을 상상해 보는 것이다. 지금까지 진행된 실제 상황은 어떠한가?응, 어쨌든 내 경험은 게임 프로그래머가 된 거야. 아마 지금의 일반 프로그래머와는 많이 다르겠지?!그렇게 생각해요.(쓴웃음), 관심 있는 분들께 감사하고 제 방향성을 조금이나마 이해해 주시고 도움이 되셨으면 좋겠습니다.그럼, 계속하세요!

    git diff로 재확인!


    그럼~Working/Stageng/Repogitory가 각자의 영역에서 인식하고 파일의 차이를 간단하게 조사하는 명령, diff, 앞으로도 사용하세요!git status일 뿐이라면 가끔 머리가 혼란스러울 때가 있어요~
    지난번에 제가 status의 내용을 완전히 잘못 읽었고 반성의 뜻을 담았기 때문에 diff를 사용하지 않을 수 없습니다.(쓴웃음)[4]

    그럼 이 초기 상태에서git diff를 실행하세요!


    각 영역
    Working Tree
    Staging Area
    Git Repository
    파일 이름
    README.md
    README.md
    README.md
    컨텐트
    test add (^^)
    test add
    test
    [shiozumi@ovs-009 mygit]$ git diff
diff --git a/README.md b/README.md
index fd66901..0811606 100644
--- a/README.md
+++ b/README.md
@@ -1,3 +1,4 @@
 # test
 # add
+# (^^)
    Working Tree 및 Stage Area에서 알게 된 README입니다.md의 차이를 표시합니다.git diff 이것도 생략계이기 때문에 원래 의식해야 한다git diff [Working] [Staging][5].
    보충: 맨 아래 줄, 옅은 녹색의 그물칸[6]의 부분은 차이점이다.실제 데이터는 (^^)입니다.다른 부분은 여기서, 설명하지 않지만, 잠시 후에!

    다음은 git diff HEAD[7]를 실행하십시오!


    [shiozumi@ovs-009 mygit]$ git diff HEAD
diff --git a/README.md b/README.md
index fd7407f..0811606 100644
--- a/README.md
+++ b/README.md
@@ -1,3 +1,4 @@
 # test
-
+# add
+# (^^)
    Working Tree 및 Git Repogitory에서 인식하는 README입니다.md의 차이를 표시합니다.
    HEAD는 commiit의 현재 분기입니다.git diff HEAD예git diff Working[省略] Repository[HEAD]이런 의식을 가져야 한다.
    보충: 아래 세 줄, 연한 색, 빨간색[8]과 녹색 음영 부분은 차이.아마, Repogitory로 알고, README.md에서 #test 밑에 줄을 바꾸는 줄이 있겠지!

    마지막으로git diff--staged를 실행하십시오!


    [shiozumi@ovs-009 mygit]$ git diff --staged
diff --git a/README.md b/README.md
index fd7407f..fd66901 100644
--- a/README.md
+++ b/README.md
@@ -1,3 +1,3 @@
 # test
-
+# add
    Stage Area 및 Git Repogitory에서 알게 된 README입니다.md의 차이를 표시합니다.이쪽도 헤드가 생략됐습니다.자세히 쓰면 git diff --staged HEADgit diff --staged HEAD예git diff Staging Repository[HEAD]이런 의식을 가져야 한다.
    보충: 아래 두 줄, 옅은 빨간색과 녹색 망가 부분은 차이.아까의 설명과 같다.

    git diff를 사용하면 status보다 더 쉽게 알 수 있습니다!


    각 분야에서 실제 문서의 내용과 차이를 식별할 수 있기 때문에 앞으로도 이쪽 지령을 잘 사용하겠습니다!(웃음) 아니면 좀 더 일찍 기억해야 되나?

    그림을 그렸다.더욱 확고한 이미지!



    총결산

  • git diff와 [working][staging]의 비교, 차이
  • git diff--staged와 [staging][Repogitory]의 비교, 표시 차이
  • git diff HEAD와 [working] [Repogitory]를 비교한 결과 차이점이 있음

    • 생략 형식 재인식

  • git diff가 git diff-working [생략] - staged [생략]임을 깨달았습니다!
  • git diff--staged HEAD 의식 [생략]!
  • git diff HEAD를 git diff-working [생략] HEAD임을 인식합니다!
    • 생략된 부분을 다시 한 번 인식하면 이해도가 깊어진다!

    그럼, 거의 본론으로 돌아가야 한다!


    우선 동시에 진행할 수 없다는 것을 깨달았다git restore --worktree --staged.
    그리고--staged는 무시됩니다.물론git restore --staged --worktree 이렇게 앞뒤로 바꿔도 결과는 같고--staged는 실행하지 않습니다.
    그렇다면 왜 help에 동시에 설정할 수 있다고 표시됩니까?
    [shiozumi@ovs-009 mygit]$ git restore --help
// 中略 ～
git restore [<options>] [--source=<tree>] [--staged] [--worktree] <pathspec>...

    발견!--소스=<tree>란?


    이거 분명히 설정부터 해야 된다는 거야?!새로운 옵션을 찾았어요~ 아뇨, 그래도 이번엔 완전히 무시했네요.꼭, 추가 지정--source=하면 정상적으로 일하세요···새로운 미래, 또 하나를 볼 수 있어요!
    - 소스 파일은 정보 소스입니다.tree: 트리.그런데 그 나무는 어디에 있을까요?
    그나저나 나무는 도대체 뭐야?!(웃음)
    다음에 restore 명령에 지정된 HEAD,tree를 자세히 살펴보자!

    이번'제7회'는 여기까지!수고하셨습니다!


    https://zenn.dev/shiozumi/articles/86b348786f1038
    각주
    --staged-worktree와 동시에 지정은 --source==를 통해 할 수 있습니다.↩︎
    방향성으로는 탈선이 컸지만 솔직한 마음이었다.(웃음) ↩︎
    다른 매개 변수를 추가하면 동시에 처리할 수 있습니다.단, 시나리오 1, 2와는 다른 동작이니 주의하세요.↩︎
    사용하기 시작한 방법은 조금이라도 사용법을 기억해야 한다!↩︎
    실제로 Working을 지정할 수 없습니다.↩︎
    + 기호는 파일과 비교할 때 추가됩니다.↩︎
    HEAD에 대해서는 다음에 설명하겠습니다.현재 상황에서 최신 Repository라고 생각하면 문제없습니다.↩︎
    - 기호가 파일과 비교할 때 부족합니다.↩︎
    [HDU] 4734 F(x) 디지털 DP
    C# - Cosmos DB를 사용하는 EF 5: 단일 컬렉션의 여러 엔터티 형식

    좋은 웹페이지 즐겨찾기

    개발자 우수 사이트 수집

    개발자가 알아야 할 필수 사이트 100선 추천 우리는 당신을 위해 100개의 자주 사용하는 개발자 학습 사이트를 정리했습니다
    best100-homepage