변경 사항이 업스트림에 존재할 때 git status show branch가 최신 상태 인 이유는 무엇입니까?

변경 사항은 추적 된 분기에서 업스트림에 존재하지만 입력 git status하면 로컬 분기가 최신 상태임을 나타냅니다. 이 새로운 동작입니까, 구성 설정을 변경 했습니까? 아니면 잘못된 것입니까?

도와 주셔서 감사합니다.

ubuntu@host:/my/repo# git status
On branch master
Your branch is up-to-date with 'origin/master'.

nothing to commit, working directory clean


ubuntu@host:/my/repo# git pull
remote: Counting objects: 11, done.
remote: Compressing objects: 100% (11/11), done.
remote: Total 11 (delta 6), reused 0 (delta 0)
Unpacking objects: 100% (11/11), done.
From bitbucket.org:my/repo
   1234567..abcdefg  master     -> origin/master
Updating 1234567..abcdefg
Fast-forward
 file1        |  1 -
 file2        | 43 +++++++++++++++++++++++++++++++++++++++++++
 file3        | 21 ++++++++++++---------
 file4        | 21 ++++++++++++---------
 4 files changed, 67 insertions(+), 19 deletions(-)
 create mode 100644 file5

상태가 말한 것은 origin/master 로컬 repo의 로컬 참조 인 ref 뒤에 있다는 것 입니다. 이 경우 심판은이라는 일부 리모콘의 지점을 추적 origin하지만 리모콘의 지점에 대한 상태는 알려주지 않습니다. 로컬 파일 시스템에 저장된 커밋 ID 인 ref에 대해 알려줍니다 (이 경우 일반적으로 .git/refs/remotes/origin/master로컬 리포지토리에서 호출 된 파일에 있음 ).

git pull두 가지 작업을 수행합니다. 먼저 git fetch원격 리포지토리의 커밋 ( origin/master로컬 리포지토리 의 참조 를 업데이트)으로 최신 상태를 유지 한 다음 git merge커밋을 현재 분기로 병합합니다.

fetch단계 를 수행 할 때까지 (자체 git pull또는를 통해 ) 로컬 리포지토리는 추가 커밋이 업스트림에 있다는 것을 알 수 없으며 git status로컬 origin/master참조 만 볼 수 있습니다 .

git status최신이라고 하면 "현재 분기가 추적하는 분기의 최신"을 의미하며,이 경우 "로컬 참조가 origin/master" 인 최신 "을 의미 합니다. 그것은 "마지막 검색했을 때 검색된 업스트림 상태 fetch로 최신 상태 인 것과 같습니다.

왜 이런 식으로 작동합니까? 이 fetch단계는 잠재적으로 느리고 비용이 많이 드는 네트워크 작업입니다. Git (및 기타 분산 버전 제어 시스템 ) 의 설계는 불필요 할 때 네트워크 작동을 피하기위한 것이며, 많은 사람들이 익숙한 일반적인 클라이언트-서버 시스템과는 완전히 다른 모델입니다 (아래 의견에서 지적했지만 Git의 개념 여기에서 혼동을 일으키는 "원격 추적 지점"은 모든 DVCS에 의해 공유되지는 않습니다). 중앙 집중식 서버에 연결하지 않고 Git을 오프라인으로 사용할 수 있으며 출력에 git status반영됩니다.

Git에서 브랜치를 만들고 스위칭하고 상태를 확인하는 것은 중앙 집중식 시스템에 느린 네트워크 작동을 수행하는 것이 아니라 경량이어야합니다. Git 및 git status출력을 설계 할 때의 가정 은 사용자가이를 이해한다는 것입니다 (Git의 작동 방식을 이미 알고있는 경우 너무 많은 Git 기능 만 의미가 있습니다). DVCS에 익숙하지 않은 많은 사용자가 Git을 채택하면이 가정이 항상 유효한 것은 아닙니다.

로컬 리포지토리가 업스트림 리모컨으로 체크인하지 않았기 때문입니다. 예상대로이 작업을 수행하려면 사용 git fetch하고 git status다시 실행 하십시오.

이것들은 모두 가능한 답변이지만 로컬 리포지토리가 원격지와 일치하는지 확인하는 방법을 제공하기로 결정했습니다. 내 지점이 어디 있는지 보려면 간단히 사용하십시오.

git remote show origin

그것이 수행하는 것은 현재 추적 된 모든 분기와 가장 중요한 것-최신, 앞 또는 원격 원점 뒤에있는 정보를 반환하는 것입니다. 위의 명령 다음에 반환되는 내용의 예입니다.

  * remote origin
  Fetch URL: https://github.com/xxxx/xxxx.git
  Push  URL: https://github.com/xxxx/xxxx.git
  HEAD branch: master
  Remote branches:
    master      tracked
    no-payments tracked
  Local branches configured for 'git pull':
    master      merges with remote master
    no-payments merges with remote no-payments
  Local refs configured for 'git push':
    master      pushes to master      (local out of date)
    no-payments pushes to no-payments (local out of date)

이것이 누군가를 돕기를 바랍니다.

"origin / master"는 "origin / master"브랜치의 HEAD 커밋에 대한 참조 poiting을 나타냅니다. 참조는 일반적으로 커밋 객체 인 Git 객체에 대한 사람에게 친숙한 별칭 이름입니다. "origin / master"참조는 git push원격지 ( http://git-scm.com/book/en/v2/Git-Internals-Git-References#Remotes )에 있을 때만 업데이트됩니다 .

프로젝트 루트 내에서 다음을 실행하십시오.

cat .git/refs/remotes/origin/master

표시된 커밋 ID를 다음과 비교하십시오.

cat .git/refs/heads/master

그것들은 동일해야하며, 이것이 Git master이 최신 버전입니다 origin/master.

달릴 때

git fetch origin master

.git / objects 폴더에서 로컬로 새 Git 객체를 검색합니다. 그리고 Git은 .git / FETCH_HEAD를 업데이트하여 페치 된 브랜치의 최신 커밋을 가리 킵니다.

따라서 현재 로컬 브랜치와 업스트림에서 가져온 브랜치의 차이점을 확인하려면

git diff HEAD FETCH_HEAD

샘플 자식의 repo에 모습 경우 확인하자 your branch (master)입니다 up to date함께 origin/master.

로컬 마스터가 출발지 / 마스터를 추적하고 있는지 확인하십시오.

$ git branch -vv
* master a357df1eb [origin/master] This is a commit message

로컬 마스터 브랜치에 대한 추가 정보 :

$ git show --summary
commit a357df1eb941beb5cac3601153f063dae7faf5a8 (HEAD -> master, tag: 2.8.0, origin/master, origin/HEAD)
Author: ...
Date:   Tue Dec 11 14:25:52 2018 +0100

    Another commit message

출발지 / 마스터가 동일한 커밋에 있는지 확인하십시오.

$ cat .git/packed-refs | grep origin/master
a357df1eb941beb5cac3601153f063dae7faf5a8 refs/remotes/origin/master

우리는 동일한 해시를 볼 수 있으며 지점이 적어도 현재 git repo에서 원격과 일관성이 있다고해도 안전합니다.

git add .전에 시도git commit

나를 여기로 데려 간 것과 같은 사소한 대답은 여전히 ​​정확합니다. 나는 새로운 리포지토리에서 일하고 있었고 상태에 따라 새로운 것으로 보이지 않는 파일을 추가했습니다.

파일이 .gitignore 파일의 패턴과 일치하는 것으로 끝납니다.

이 경우 git add를 사용하여 보류중인 모든 파일을 통합 한 다음 git commit을 사용하고 git push를 사용하십시오.

자식 추가-모든 pedent 파일을 통합

자식 커밋-커밋 저장

자식 푸시-저장소에 저장