힘내 푸시 오류 '[원격 거부 됨] 마스터-> 마스터 (현재 분기가 체크 아웃 됨)'

IT박스

힘내 푸시 오류 '[원격 거부 됨] 마스터-> 마스터 (현재 분기가 체크 아웃 됨)'

itboxs 2020. 9. 28. 08:32

힘내 푸시 오류 '[원격 거부 됨] 마스터-> 마스터 (현재 분기가 체크 아웃 됨)'

어제 내 컴퓨터 중 하나에서 다른 컴퓨터로 Git 저장소 를 복제하는 방법에 대한 질문을 게시했습니다. 다른 컴퓨터에서 'git clone'을 사용하려면 어떻게해야합니까? .

이제 소스 (192.168.1.2)에서 대상 (192.168.1.1)으로 Git 저장소를 성공적으로 복제 할 수 있습니다.

그러나 파일 a git commit -a -m "test"및 a를 편집 할 때 git push대상 (192.168.1.1)에서이 오류가 발생합니다.

git push                                                
hap@192.168.1.2's password: 
Counting objects: 21, done.
Compressing objects: 100% (11/11), done.
Writing objects: 100% (11/11), 1010 bytes, done.
Total 11 (delta 9), reused 0 (delta 0)
error: refusing to update checked out branch: refs/heads/master
error: By default, updating the current branch in a non-bare repository
error: is denied, because it will make the index and work tree inconsistent
error: with what you pushed, and will require 'git reset --hard' to match
error: the work tree to HEAD.
error: 
error: You can set 'receive.denyCurrentBranch' configuration variable to
error: 'ignore' or 'warn' in the remote repository to allow pushing into
error: its current branch; however, this is not recommended unless you
error: arranged to update its work tree to match what you pushed in some
error: other way.
error: 
error: To squelch this message and still keep the default behaviour, set
error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To git+ssh://hap@192.168.1.2/media/LINUXDATA/working
! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to 'git+ssh://hap@192.168.1.2/media/LINUXDATA/working'

두 가지 버전의 Git (원격에서는 1.7, 로컬 컴퓨터에서는 1.5)을 사용하고 있습니다. 그게 가능한 이유인가요?

원격 리포지토리를 베어 리포지토리로 간단히 변환 할 수 있습니다 (베어 리포지토리에는 작업 복사본이 없으며 폴더에는 실제 리포지토리 데이터 만 포함됨).

원격 저장소 폴더에서 다음 명령을 실행하십시오.

git config --bool core.bare true

그런 다음 .git해당 폴더를 제외한 모든 파일을 삭제하십시오 . 그런 다음 git push오류없이 원격 저장소 에서 수행 할 수 있습니다.

Git 학습을 시작하는 동안 동일한 오류가 발생했습니다 . 다른 답변 중 일부는 Git을 처음 접하는 사람을위한 것이 아닙니다!

(나는 비전문 용어를 사용하여 아이디어를 전달할 것입니다.) 어쨌든, 일어나고있는 것은 두 개의 저장소가 있다는 것입니다. 하나는 처음 만든 원본이고 다른 하나는 방금 만든 작업입니다.

지금은 작업 저장소에 있으며 "마스터"분기를 사용하고 있습니다. 하지만 원래 저장소에서 동일한 "마스터"브랜치에 "로그인"된 경우도 있습니다. 이제 원본에 "로그인"했으므로 Git은 원본을 작업하고 작업을 망칠 수 있기 때문에 엉망이 될 수 있다고 우려합니다. 따라서 원래 저장소로 돌아가서 "git checkout someotherbranch"를 수행해야합니다. 이제 문제없이 푸시 할 수 있습니다.

이게 도움이 되길 바란다.

오류 메시지는 발생한 상황을 설명합니다. 최신 버전의 Git은 브랜치가 체크 아웃 된 경우 푸시를 통해 브랜치를 업데이트하지 않습니다.

베어가 아닌 두 저장소 사이에서 작업하는 가장 쉬운 방법은 다음 중 하나입니다.

항상 풀 (또는 가져 오기 및 병합)을 통해 리포지토리를 업데이트하거나 필요한 경우
별도의 분기 (가져 오기 분기)로 푸시 한 다음 해당 분기를 원격 컴퓨터의 마스터 분기로 병합합니다.

이 제한의 이유는 푸시 작업이 원격 Git 저장소에서만 작동하고 인덱스 및 작업 트리에 대한 액세스 권한이 없기 때문입니다. 따라서 허용되는 경우 체크 아웃 된 분기에 대한 푸시 는 원격 저장소의 인덱스 및 작업 트리와 일치하지 않도록를 변경 HEAD 합니다.

이렇게하면 푸시 된 모든 변경 사항을 취소하는 변경 사항을 실수로 커밋하기가 매우 쉽고 커밋 되지 않은 로컬 변경 사항과 새 HEAD, 인덱스 및 작업 트리 간의 차이점을 구분하기가 매우 어렵습니다. 푸시 이동으로 인한 HEAD.

요약

리포지토리의 사용자 가 데이터와 히스토리의 손실로 끝날 수있는 방식으로 엉망이되기 때문에 리포지토리의 체크 아웃 된 브랜치로 푸시 할 수 없습니다 . 그러나 동일한 저장소의 다른 분기로 푸시 할 수 있습니다.

베어 리포지토리에는 체크 아웃 된 브랜치가 없으므로 항상 베어 리포지토리의 모든 브랜치로 푸시 할 수 있습니다.

필요에 따라 여러 솔루션이 있습니다.

해결 방법 1 : Bare Repostiory 사용

제안 된대로 한 시스템에서 작업 디렉토리가 필요하지 않은 경우 베어 저장소로 이동할 수 있습니다. 저장소를 엉망으로 만들지 않으려면 복제 할 수 있습니다.

machine1$ cd ..
machine1$ mv repo repo.old
machine1$ git clone --bare repo.old repo

이제 이전과 동일한 주소로 원하는 모든 것을 푸시 할 수 있습니다.

해결 방법 2 : 체크 아웃되지 않은 분기로 푸시

하지만 리모컨에서 코드를 확인해야하는 경우 <remote>특수 분기를 사용하여 푸시 할 수 있습니다. 로컬 저장소에서 원격을 호출 origin했고 브랜치 마스터에 있다고 가정 해 봅시다 . 그럼 당신은 할 수 있습니다

machine2$ git push origin master:master+machine2

그런 다음 origin원격 저장소 에있을 때 병합해야합니다 .

machine1$ git merge master+machine2

문제의 부검

브랜치가 체크 아웃되면 커밋은 현재 브랜치의 헤드를 부모로하는 새 커밋을 추가하고 브랜치의 헤드를 새 커밋으로 이동합니다.

그래서

A ← B
    ↑
[HEAD,branch1]

된다

A ← B ← C
        ↑
    [HEAD,branch1]

그러나 누군가가 그 분기에 중간에 푸시 할 수 있다면 사용자는 git이 분리 된 헤드 모드를 호출하는 방식으로 전환됩니다.

A ← B ← X
    ↑   ↑
[HEAD] [branch1]

이제 사용자는 다른 브랜치를 확인하도록 명시 적으로 요청하지 않고 더 이상 branch1에 있지 않습니다. 더 나쁜 것은 사용자가 이제 분기 외부 에 있으며 새 커밋이 매달려 있다는 것입니다 .

      [HEAD]
        ↓
        C
      ↙
A ← B ← X
        ↑
       [branch1]

가정적으로이 시점에서 사용자가 다른 브랜치를 체크 아웃하면이 매달린 커밋이 Git의 가비지 수집기에 공정한 게임이됩니다 .

.git/config대상 서버에서 를 편집하여이 "제한"을 피할 수 있습니다 . 다음을 추가하여 git 저장소가 "체크 아웃"된 경우에도 푸시되도록합니다.

[receive]
denyCurrentBranch = warn

또는

[receive]
denyCurrentBranch = false

첫 번째는 가지를 엉망으로 만들 가능성을 경고하면서 푸시를 허용하는 반면, 두 번째는 조용히 허용합니다.

이것은 편집 용이 아닌 서버에 코드를 "배포"하는 데 사용할 수 있습니다. 이것이 최선의 방법은 아니지만 코드 배포를위한 빠른 방법입니다.

원격 상자에 여전히 사용 가능한 저장소가 있다는 생각이 마음에 들지만 더미 브랜치 대신 다음을 사용하고 싶습니다.

git checkout --detach

이것은 Git 의 매우 새로운 기능인 것 같습니다 . 저는 git 버전 1.7.7.4를 사용하고 있습니다.

git config --local receive.denyCurrentBranch updateInstead

https://github.com/git/git/blob/v2.3.0/Documentation/config.txt#L2155

서버 저장소에서 사용하고 추적되지 않은 덮어 쓰기가 발생하지 않으면 작업 트리도 업데이트합니다.

그것은에서 추가되었다 힘내 2.3 로 VonC 언급 코멘트에.

나는 Git 2.3을 컴파일하고 그것을 시도했다. 샘플 사용법 :

git init server
cd server
touch a
git add .
git commit -m 0
git config --local receive.denyCurrentBranch updateInstead

cd ..
git clone server local
cd local
touch b
git add .
git commit -m 1
git push origin master:master

cd ../server
ls

산출:

a
b

예이, b밀렸다!

나는 같은 문제가 있었다. 저에게는 Git 푸시를 사용하여 코드를 서버로 이동합니다. 나는 서버 측에서 코드를 변경하지 않으므로 안전합니다.

저장소에서 다음을 입력하도록 푸시합니다.

git config receive.denyCurrentBranch ignore

이렇게하면 작업 복사 본인 동안 저장소를 변경할 수 있습니다.

Git 푸시를 실행 한 후 원격 머신으로 이동하여 다음을 입력합니다.

git checkout -f

이렇게하면 푸시 한 변경 사항이 원격 컴퓨터의 작업 복사본에 반영됩니다.

푸시하려는 작업 복사본을 변경하는 경우 항상 안전하지는 않습니다.

서버 리포지토리를 다시 만들고 로컬 브랜치 마스터에서 서버 마스터로 푸시 할 수 있습니다.

원격 서버에서 :

mkdir myrepo.git
cd myrepo.git
git init --bare

좋습니다. 현지 지점에서 :

git push origin master:master

이 문제를 일으키기 위해 수행 한 작업 :

이런 종류의 일은 작은 프로그램을 만들 때 발생합니다. 이미 작동하던 것을 변경하려고하므로 레벨 3의 영구 실행 취소 주문을 시전합니다.

machine1:~/proj1> git init

추가 / 커밋을 시작합니다. 그러나 다음 프로젝트의 시작은 더 관여하고 같은 일을 할 수 있도록 당신이 (당신의 가정의 PC 또는 노트북과 같은) 다른 컴퓨터에서 작업 할

machine2:~> git clone ssh://machine1/~/proj1

복제되고 모든 것이 좋아 보이므로 machine2에서 코드로 작업합니다.

그런 다음 ... machine2에서 커밋을 푸시하려고하면 제목에 경고 메시지가 표시됩니다.

이 메시지의 이유는 가져온 git 저장소가 machine1의 해당 폴더에만 사용되도록 의도 되었기 때문입니다. 잘 복제 할 수 있지만 푸시하면 문제가 발생할 수 있습니다. 두 개의 다른 위치에서 코드를 관리하는 "적절한"방법은 제안 된 것처럼 "베어"저장소를 사용하는 것입니다. 베어 REPO는 모든 작업이 수행되는 것으로 설계되지 않았습니다 에서 그것, 여러 소스에서 커밋을 조정하기위한 것입니다. 이것이 최고 등급의 답변 이 .git 폴더를 제외한 모든 파일 / 폴더 삭제를 제안 하는 이유 git config --bool core.bare true입니다.

최고 등급의 답변을 명확히하기 : 해당 답변에 대한 많은 의견은 "나는 machine1에서 .git이 아닌 파일을 삭제하지 않았고 여전히 machine2에서 커밋 할 수있었습니다"와 같이 말합니다. 맞습니다. 그러나 다른 파일은 이제 git repo에서 완전히 "이혼"합니다. 가서 시도해 git status보면 "치명적 :이 작업은 작업 트리에서 실행되어야합니다"와 같은 내용이 표시됩니다. 따라서 파일을 삭제하라는 제안은 machine2의 커밋이 작동 하도록하는 것이 아닙니다 . 혼란스럽지 않고 git이 여전히 해당 파일을 추적하고 있다고 생각하기 때문입니다. 그러나 machine1에서 파일 작업을 계속하려면 파일을 삭제하는 것이 문제가되지 않습니까?

그래서 당신은 정말로 무엇을해야합니까?

machine1 및 machine2에서 계속 작업 할 계획에 따라 다릅니다.

machine1에서 개발을 완료하고 모든 개발을 machine2로 옮긴 경우 ... 최고 등급의 답변이 제안하는대로 수행 git config --bool core.bare true한 다음 선택적으로 해당 폴더에서 .git 이외의 모든 파일 / 폴더를 삭제합니다. 추적되지 않으며 혼란을 일으킬 가능성이 있습니다.

machine2에 대한 작업이 한 번에 불과하고 거기에서 개발을 계속할 필요가 없다면 ... 베어 리포지토리를 만드는 데 신경 쓰지 마십시오. ftp / rsync / scp / etc. machine * 1 *의 파일 위에 machine * 2 *의 파일, machine * 1 *에서 커밋 / 푸시 한 다음 machine * 2 *에서 파일을 삭제합니다. 다른 사람들은 브랜치 생성을 제안했지만, 다른 머신에서 한 번에 수행 한 일부 개발을 병합하려는 경우 약간 지저분하다고 생각합니다.

machine1과 machine2 모두에서 개발을 계속해야한다면 제대로 설정해야합니다. 리포지토리를 베어로 변환 한 다음 작업 할 machine1에서 복제본을 만들어야합니다 . 아마도이 작업 을 수행하는 가장 빠른 방법은 다음과 같습니다.

machine1:~/proj1> git config --bool core.bare true
machine1:~/proj1> mv .git/ ../proj1.git
machine1:~/proj1> cd ..
machine1:~> rm -rf proj1
machine1:~> git clone proj1.git
machine1:~> cd proj1

매우 중요합니다 : repo의 위치를 proj1에서 proj1.git로 옮겼 기 때문에 machine2의 .git / config 파일에서이를 업데이트해야합니다 . 그 후 machine2에서 변경 사항을 커밋 할 수 있습니다. 마지막으로, 작업 트리에서 멀리 떨어진 중앙 위치에 내 저장소를 유지하려고합니다 (예 : 'proj1'과 동일한 상위 폴더에 'proj1.git'을 넣지 마십시오). 나는 당신에게도 그렇게하도록 조언하지만 위의 단계를 가능한 한 간단하게 유지하고 싶었습니다.

몇 가지 설정 단계를 통해 다음과 같은 한 줄짜리를 사용하여 웹 사이트에 변경 사항을 쉽게 배포 할 수 있습니다.

git push production

멋지고 간단하며 원격 서버에 로그인하여 가져 오기 등을 수행 할 필요가 없습니다. 프로덕션 체크 아웃을 작업 브랜치로 사용하지 않는 경우이 방법이 가장 잘 작동합니다. (OP는 약간 다른 맥락에서 작동하고 있었고 @Robert Gould의 솔루션이 문제를 잘 해결했다고 생각합니다.이 솔루션은 원격 서버에 배포하는 데 더 적합합니다.)

먼저 웹 루트 외부의 서버 어딘가에 베어 저장소를 설정해야합니다.

mkdir mywebsite.git
cd mywebsite.git
git init --bare

그런 다음 파일을 만듭니다 hooks/post-receive.

#!/bin/sh
GIT_WORK_TREE=/path/to/webroot/of/mywebsite git checkout -f

그리고 파일을 실행 가능하게 만드십시오.

chmod +x hooks/post-receive

로컬 컴퓨터에서

git remote add production git@myserver.com:mywebsite.git
git push production +master:refs/heads/master

모든 설정! 이제 앞으로 git push production변경 사항을 배포 하는 데 사용할 수 있습니다 !

이 솔루션에 대한 크레딧은 http://sebduggan.com/blog/deploy-your-website-changes-using-git/ 로 이동합니다 . 무슨 일이 일어나고 있는지에 대한 자세한 설명을 보려면 거기를 찾으십시오.

베어 저장소로만 푸시해야합니다. 베어 저장소는 체크 아웃 된 분기가없는 저장소입니다. 베어 저장소 디렉토리로 cd하면 .git 디렉토리의 내용 만 볼 수 있습니다.

3 가지 옵션이 있습니다

다시 당기고 밀기 :
```
git pull; git push
```
다른 지점으로 푸시 :
```
git push origin master:foo
```
원격에서 병합합니다 ( git또는 pull-request )
```
git merge foo
```
강제 실행 (을 통해 의도적으로 커밋을 변경하지 않는 한 권장되지 않음 rebase) :
```
git push origin master -f
```
경우 여전히 비활성화, 거부 denyCurrentBranch 에 원격 저장소 :
```
git config receive.denyCurrentBranch ignore
```

실제로 원격을 체크 아웃되지 않은 분기로 설정하는 것으로 충분합니다. 다른 지점에서 리모컨을 체크 아웃 한 후 푸시 할 수 있습니다.

Git을 사용하여 Android 휴대폰과 랩톱에서 저장소를 동기화하는 데 동일한 문제가 발생했습니다. 나를위한 해결책은 @CharlesBailey가 제안한 것처럼 푸시 대신 당기는 것이 었습니다.

git push origin master Android 저장소에서 @ hap497이 저장소 + 작업 복사본의 맨손으로 체크 아웃하기 때문에 얻은 것과 동일한 오류 메시지로 실패합니다.

git pull droid master랩톱 저장소 및 작업 복사본이 나를 위해 작동합니다. 물론 이전에 git remote add droid /media/KINGSTON4GB/notes_repo/.

.git/config대상 프로젝트에서 확인하십시오 .

$ cat .git/config 
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
[receive]
    denyCurrentBranch = updateInstead

(가) 경우 core. bare거짓 true로 설정할 수 있습니다 :

$ git config core.bare true

그런 다음 로컬에서 원격으로 푸시합니다.

git push remote_repo   // suppose the destination repo is remote_repo

성공할 것입니다. remote_repo에서 git 버전을 확인할 수 있습니다.

$ git log -1
commit 0623b1b900ef7331b9184722a5381bbdd2d935ba
Author: aircraft < aircraft_xxx@126.com>
Date:   Thu May 17 21:54:37 2018 +0800

이제 "작업 공간"에서 git을 사용할 수 없습니다.

$ git status
fatal: This operation must be run in a work tree

bare.bare다시 false로 설정해야합니다 .

$ git config core.bare false

이전 버전의 Git은 베어가 아닌 저장소의 현재 체크 아웃 된 분기로 푸시를 허용하는 데 사용되었습니다.

이것은 허용하기에 매우 혼란스러운 일이었습니다. 그래서 그들은 당신이 보는 경고 메시지를 추가했습니다. 이것은 또한 매우 혼란 스럽습니다.

첫 번째 저장소가 서버 역할 만하는 경우 다른 답변이 권장하는대로 베어 저장소로 변환하고 수행하십시오.

그러나 둘 다 사용중인 두 저장소간에 공유 분기가 필요한 경우 다음 설정을 사용하여 수행 할 수 있습니다.

Repo1-서버 역할을하며 개발에도 사용됩니다.

Repo2-개발 전용입니다.

Repo1을 다음과 같이 설정하십시오.

작업을 공유 할 분기를 만듭니다.

git branch shared_branch

안전을 위해, shared_branch 이외의 모든 변경 사항을 거부하는 $ (REPO) .git / hooks / update도 만들어야합니다. 왜냐하면 사람들이 개인 브랜치를 망쳐 놓는 것을 원하지 않기 때문입니다.

repo1/.git/hooks  (GIT_DIR!)$ cat update
#!/bin/sh
refname="$1"
oldrev="$2"
newrev="$3"

if [ "${refname}" != "refs/heads/shared_branch" ]
then
   echo "You can only push changes to shared_branch, you cannot push to ${refname}"
   exit 1
fi

이제 실제 작업을 수행 할 repo1에 로컬 브랜치를 만듭니다.

git checkout -b my_work --track shared_branch
Branch my_work set up to track local branch shared_branch.
Switched to a new branch 'my_work'

(일 git config --global push.default upstream하기 위해 필요할 수 있음 git push)

이제 다음을 사용하여 repo2를 만들 수 있습니다.

git clone path/to/repo1 repo2 
git checkout shared_branch

이 시점에서 repo1과 repo2가 모두 repo1에서 푸시 및 풀하는 로컬 브랜치에서 작동하도록 설정 shared_branch되어 있으며, 해당 오류 메시지에 대해 걱정하거나 repo1에서 작업 디렉토리가 동기화되지 않도록 할 필요가 없습니다. 사용하는 일반적인 워크 플로가 무엇이든 작동합니다.

다음은 bare서버의 작동 방식을 확인하기 위해 수행 할 수있는 테스트입니다 .

라이브 사이트가 호스팅되는 워크 스테이션과 서버가 있고이 사이트를 수시로 업데이트하려고한다고 가정 해보십시오 (이는 두 명의 개발자가 베어 중개자를 통해 작업을주고받는 상황에도 적용됩니다).

초기화

로컬 컴퓨터에 일부 디렉토리를 생성 cd한 후 다음 명령을 실행합니다.

# initialization
git init --bare server/.git
git clone server content
git clone server local

먼저 베어 server디렉토리 를 만듭니다 (마지막에 .git 참고). 이 디렉토리는 저장소 파일의 컨테이너 역할 만합니다.
그런 다음 서버 저장소를 새로 만든 content디렉토리에 복제합니다 . 이것은 서버 소프트웨어에서 제공 할 라이브 / 프로덕션 디렉토리입니다.
처음 두 디렉토리는 서버에 있고 세 번째 디렉토리는 워크 스테이션의 로컬 디렉토리입니다.

워크 플로우

이제 기본 워크 플로는 다음과 같습니다.

local디렉토리를 입력하고 일부 파일을 만든 다음 커밋합니다. 마지막으로 서버로 푸시합니다.
```
# create crazy stuff
git commit -av
git push origin master
```
이제 content디렉토리를 입력하고 서버의 컨텐츠를 업데이트하십시오.
```
git pull
```
1-2를 반복합니다. 여기 content에 서버에 푸시 할 수있는 또 다른 개발자가있을 수 있습니다 local.

좋습니다. 일반적인 원격 저장소를 원한다면 추가 브랜치를 만들고 체크 아웃하세요. 하나의 브랜치 (체크 아웃되지 않음)로 푸시하고 로컬에서 푸시 한 후 나중에 현재 활성화 된 브랜치와 병합합니다.

예를 들어, 원격 서버에서 :

git branch dev
git checkout dev

로컬 설정에서 :

git push

원격 서버에서 :

git merge dev

나는 git --init기존의 베어 리포지토리에서 다시 실행 해야했고 이것은 .git베어 리포지토리 트리 내에 디렉토리를 생성했습니다 git status. 거기에 입력 한 후에 깨달았 습니다. 나는 그것을 삭제했고 모든 것이 다시 정상이었습니다. :)

(이 모든 답변은 훌륭하지만 제 경우에는 설명한대로 완전히 다른 것입니다 (내가 볼 수있는 한).)

이 질문을 보는 대부분의 사람들은 처음 두 개의 큰 답변에서 멈출 것이라고 확신하지만 여전히 내 솔루션을 제공하고 싶습니다.

설명 된 오류가 발생하면 Eclipse + EGit 웹 프로젝트를 설정했습니다. 저에게 도움이 된 것은 단순히 GitHub 앱을 사용하는 것이 었는데 마법처럼 문제를 해결하는 것 같았습니다. EGit은 항상 푸시를 거부하지만 GitHub 데스크톱 앱은 어깨를 으쓱하고 변경 사항을 푸시합니다. 멀티 로그인 상황을보다 우아하게 처리 할 수 있습니다.

다른 사람들에게 유용 할 수있는 기사 는 5 분 안에 Git입니다 .

DC에있는 VDE ( Virtual Distributed Ethernet) 로 푸시하려는 Git 버전 제어하에 Xcode 프로젝트 가있었습니다 . VDE는 Centos 5를 실행 합니다.

내가 읽은 Git 기사 중 베어 리포지토리에 대해 언급하지 않았습니다. 내가 SVN 배경 에서 쉽게 나올 것이라고 생각한 것을 시도하기 전까지는 모든 것이 너무 간단하게 들렸습니다 .

원격 저장소를 맨손으로 만들기위한 제안 사항입니다. 내 요구 사항보다 더 나은 것은 Xcode 프로젝트를 projectname.git에 복제하고 원격 서버에 복사하는 것입니다. 그런 다음 마법처럼 작동합니다. 다음 단계는 커밋에 대한 오류없이 Xcode를 푸시하도록하는 것이지만 지금은 터미널에서 수행해도 괜찮습니다.

그래서:

cd /tmp (or another other directory on your system)<br/>
git clone --bare /xcode-project-directory projectname.git<br/>
scp -r projectname.git sshusername@remotehost.com:repos/<br/>

Xcode에서 커밋 한 후 Xcode 프로젝트에서 변경 사항을 푸시하려면 :

cd /xcode-project-directory<br/>
git push sshusername@remotehost.com:repos/projectname.git<br/>

위의 작업을 수행하는 더 부드럽고 정교한 방법이 있다고 확신하지만 최소한 작동합니다. 모든 것이 명확합니다. 여기에 몇 가지 설명 /xcode-project-directory이 있습니다. xcode 프로젝트가 저장된 디렉토리입니다 /Users/Your_Name/Documents/Project_Name. 아마도 . projectname은 말 그대로 프로젝트의 이름이지만 원하는 이름으로 부를 수 있습니다. Git은 상관하지 않습니다.

scp를 사용하려면 SSH 액세스 가 허용 된 원격 서버에 사용자 계정이 있어야합니다 . 자신의 서버를 실행하는 사람은 누구나 이것을 갖게됩니다. 공유 호스팅 등을 사용하는 경우 운이 좋지 않을 수 있습니다.

remotehost.com원격 호스트의 이름입니다. IP 주소를 쉽게 사용할 수 있습니다. 더 명확하게하기 위해 SSH 키로 원격 호스트에서 Gitosis 를 사용 하고 있으므로 푸시 할 때 암호를 입력하라는 메시지가 표시되지 않습니다. Git Repositories 호스팅, 간편하고 안전한 방법 기사에서는이 모든 것을 설정하는 방법을 알려줍니다.

이를 수행하는 가장 좋은 방법은 다음과 같습니다.

mkdir ..../remote
cd ..../remote
git clone --bare .../currentrepo/

이것은 저장소를 복제하지만 .../remote. 리모컨을 보면라는 하나의 디렉토리가 생성 된 currentrepo.git것을 볼 수 있습니다. 이는 아마도 원하는 것입니다.

그런 다음 로컬 Git 저장소에서 :

git remote add remoterepo ..../remote/currentrepo.git

변경 한 후 다음을 수행 할 수 있습니다.

git push remoterepo master

Heroku 의 배포 git 저장소 에서이 문제가 발생했습니다 .

Heroku에 베어 리포지토리가없는 이유는 모르겠지만 해결 방법으로 원격 리포지토리를 재설정하고 다시 업로드 할 수있었습니다.

공동 작업을위한 유일한 git 저장소로 Heroku의 저장소 사본을 사용해서는 안되지만, 만약을 대비하여 명확하게 말할 것 입니다. 저장소의 전체 사본이 다른 곳에 안전하게 저장되어 있다고 확신하지 않는 한 이렇게하지 마십시오 . Heroku. 재설정을 수행하면 저장소 컨텐츠가 삭제됩니다.

재설정하려면 :

아직 설치하지 않은 경우 Heroku 도구 벨트 (명령 줄 클라이언트 포함)를 설치합니다 .
아직 설치 하지 않았다면 heroku-repo 플러그인을 설치하십시오 .
```
heroku plugins:install https://github.com/heroku/heroku-repo.git
```
재설정을 수행하면 저장소가 삭제되고 비어있는 새 저장소가 생성됩니다.
```
heroku repo:reset
```
평소처럼 Heroku 리모컨으로 푸시합니다. 모든 것을 다시 업로드합니다.

비어있는 (베어) 저장소를 만든 후에는 원격 서버의 구성 파일을 변경해야합니다.

root@development:/home/git/repository/my-project# cat config

당신은 볼 것이다

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true

당신은 이것을 진실로 거짓으로 만들 것이고 나는 logallrefupdates = true를 제거했습니다 (그 사용이 확실하지 않습니다!)

...에

[core]
repositoryformatversion = 0
filemode = true
bare = true

다음을 테스트 할 수 있습니다.

$ git remote show origin
* remote origin
Fetch URL: my-portal@development:/home/XYZ/repository/XYZ
Push  URL: my-portal@development:/home/XYZ/repository/XYZ
HEAD branch: (unknown)

이 HEAD 분기 : (알 수 없음)은 PUSH 할 수없는 경우 표시됩니다. 따라서 HEAD 브랜치가 알 수없는 경우 베어를 true로 변경해야하며 푸시가 성공한 후 재사용 할 수 있습니다.

git remote show origin

그리고 당신은 볼 것입니다

 HEAD branch: master

이것을 사용하여 원격 업스트림 브랜치로 푸시하면이 문제가 해결되었습니다.

git push <remote> master:origin/master

리모컨은 업스트림 저장소에 대한 액세스 권한이 없으므로 해당 리모컨에 대한 최신 변경 사항을 가져 오는 좋은 방법이었습니다.

나를 위해 작업 솔루션은 다음과 같습니다.

원격에서 :

git checkout -b some_tmp_name

현지 :

git push

원격에서 :

git checkout master
git branch -d some_tmp_name

그러나 이것은 실제 해결책이 아닙니다.

누군가가 유용하다고 생각하는 경우를 대비하여. 저에게는 git 서버 권한 문제였습니다. 처음부터 프로젝트를 체크 아웃하고 간단한 파일을 푸시 한 다음 "푸시 거부 됨 : 원본 / 마스터로 푸시가 거부되었습니다"라는 메시지가 표시됩니다.

Git을 사용하면 두 개의 일반 (베어가 아닌) 리포지토리가 파일을 직접 앞뒤로 밀거나 가져올 수 없습니다. 중개 베어 저장소가 있어야합니다. 분명히, 그것은 일종의 결혼 한 부부처럼 아이가 있고 그 부부는 이혼하고 있습니다. 부모는 서로 이야기하지 않지만 아이를 통해 의사 소통을합니다.

따라서 저장소가 하나 있고이 저장소를 베어 저장소에 복제 한 다음이를 세 번째 저장소에 복제합니다. 첫 번째와 세 번째는 두 번째 저장소 인 베어 저장소를 통해 정보를 교환 할 수 있습니다. 나는 이것이 합리적이라고 생각하는데, 그것은 병합 충돌 등을 일으킬 수 있기 때문에 누군가가 당신의 동의없이 당신의 저장소에 물건을 체크인하는 것을 원하지 않기 때문입니다.

예를 들면 다음과 같습니다.

PC에서 ~ / workspace

git init
echo "line 1" > afile.txt
git add .
git commit -m ‘initial import’
git clone --bare . ../remote-repository.git
git remote add origin ../remote-repository.git
git push --set-upstream origin master

랩톱에서 ~ / workspace (git init 등을 수행하지 마십시오)

git clone //LJZ-DELLPC/remote-repository.git/ .

// 그런 다음 다양한 커밋을 수행하고 푸시합니다.

echo "line 2" > afile.txt
git add afile.txt
git commit -m 'added line 2'
git push

그런 다음 ~ / workspace에서 PC로 돌아갑니다.

git pull

// 그런 다음 다양한 커밋을 수행하고 푸시합니다.

git push

노트북에서 git pull

기타 등등..

다음은 명령 창에서 직접 복사 한 하나의 컴퓨터에있는 절대적인 구체적인 예입니다. 따라서 단계가 누락되지 않았는지, 실제로 작동했는지 등을 알 수 있습니다.

lylez@LJZ-DELLPC ~
$ cd gitdir
/home/lylez/gitdir

lylez@LJZ-DELLPC ~/gitdir
$ ls

lylez@LJZ-DELLPC ~/gitdir
$ mkdir repo1

lylez@LJZ-DELLPC ~/gitdir
$ cd repo1
/home/lylez/gitdir/repo1

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git init
Initialized empty Git repository in /home/lylez/gitdir/repo1/.git/

lylez@LJZ-DELLPC ~/gitdir/repo1
$ echo "line 1" > afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git add afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git commit -m 'initial import'
[master (root-commit) f407e12] initial import
 1 file changed, 1 insertion(+)
 create mode 100644 afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git clone --bar . ../repo1-bare-clone
Cloning into bare repository '../repo1-bare-clone'...
done.

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git remote add origin ../repo1-bare-clone

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git push --set-upstream origin master
Branch master set up to track remote branch master from origin.
Everything up-to-date

lylez@LJZ-DELLPC ~/gitdir/repo1
$ cd ..

lylez@LJZ-DELLPC ~/gitdir
$ ls
repo1  repo1-bare-clone

lylez@LJZ-DELLPC ~/gitdir
$ mkdir repo1-remote

lylez@LJZ-DELLPC ~/gitdir
$ cd repo1-remote
/home/lylez/gitdir/repo1-remote

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git clone ../repo1-bare-clone .
Cloning into '.'...
done.

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ ls
afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ cat afile.txt
line 1

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ echo "line 2" >> afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git add afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git commit -m 'added line 2'
[master 5ad31e0] added line 2
 1 file changed, 1 insertion(+)

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git push
Counting objects: 3, done.
Writing objects: 100% (3/3), 260 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To /home/lylez/gitdir/repo1-remote/../repo1-bare-clone
   f407e12..5ad31e0  master -> master

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ cd ../repo1

lylez@LJZ-DELLPC ~/gitdir/repo1
$ ls
afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ cat afile.txt
line 1

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git pull
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From ../repo1-bare-clone
   f407e12..5ad31e0  master     -> origin/master
Updating f407e12..5ad31e0
Fast-forward
 afile.txt | 1 +
 1 file changed, 1 insertion(+)

lylez@LJZ-DELLPC ~/gitdir/repo1
$ cat afile.txt
line 1
line 2

lylez@LJZ-DELLPC ~/gitdir/repo1
$ echo "line 3" >> afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git add afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git commit -m 'added line 3'
[master 3fa569e] added line 3
 1 file changed, 1 insertion(+)

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git push
Counting objects: 3, done.
Writing objects: 100% (3/3), 265 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To ../repo1-bare-clone
   5ad31e0..3fa569e  master -> master

lylez@LJZ-DELLPC ~/gitdir/repo1
$ cd ../repo1-remote/

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ ls
afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ cat afile.txt
line 1
line 2

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git pull
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From /home/lylez/gitdir/repo1-remote/../repo1-bare-clone
   5ad31e0..3fa569e  master     -> origin/master
Updating 5ad31e0..3fa569e
Fast-forward
 afile.txt | 1 +
 1 file changed, 1 insertion(+)

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ cat afile.txt
line 1
line 2
line 3

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git --version
git version 2.1.1

lylez@LJZ-DELLPC ~/gitdir/repo1-remote

내 솔루션 (사용 중)

원격 서버에서 "마스터"체크 아웃
"dev"브랜치에서 로컬로 작업
원격 개발자에 변경 사항 푸시
원격에서 개발자를 마스터로 병합

빙고

참고 URL : https://stackoverflow.com/questions/2816369/git-push-error-remote-rejected-master-master-branch-is-currently-checked

'IT박스' 카테고리의 다른 글

mysql_fetch_array () / mysql_fetch_assoc () / mysql_fetch_row () / mysql_num_rows 등… 매개 변수 1이 리소스 또는 결과 일 것으로 예상합니다. (0)	2020.09.28
Eclipse를 시작할 수 없음-Java가 시작되었지만 종료 코드 = 13을 반환했습니다. (0)	2020.09.28
로컬 git 브랜치를 원격 브랜치와 비교하는 방법은 무엇입니까? (0)	2020.09.28
'동기화 됨'은 무엇을 의미합니까? (0)	2020.09.28
Git 워크 플로 및 리베이스 및 병합 질문 (0)	2020.09.28

현재글힘내 푸시 오류 '[원격 거부 됨] 마스터-> 마스터 (현재 분기가 체크 아웃 됨)'

itboxs

힘내 푸시 오류 '[원격 거부 됨] 마스터-> 마스터 (현재 분기가 체크 아웃 됨)'

힘내 푸시 오류 '[원격 거부 됨] 마스터-> 마스터 (현재 분기가 체크 아웃 됨)'

요약

해결 방법 1 : Bare Repostiory 사용

해결 방법 2 : 체크 아웃되지 않은 분기로 푸시

문제의 부검

원격 서버에서 :

좋습니다. 현지 지점에서 :

3 가지 옵션이 있습니다

초기화

워크 플로우

'IT박스' 카테고리의 다른 글

'IT박스'의 다른글

티스토리툴바

힘내 푸시 오류 '[원격 거부 됨] 마스터-&gt; 마스터 (현재 분기가 체크 아웃 됨)'

힘내 푸시 오류 '[원격 거부 됨] 마스터-> 마스터 (현재 분기가 체크 아웃 됨)'

요약

해결 방법 1 : Bare Repostiory 사용

해결 방법 2 : 체크 아웃되지 않은 분기로 푸시

문제의 부검

원격 서버에서 :

좋습니다. 현지 지점에서 :

3 가지 옵션이 있습니다

초기화

워크 플로우

'IT박스' 카테고리의 다른 글

'IT박스'의 다른글

관련글

티스토리툴바

힘내 푸시 오류 '[원격 거부 됨] 마스터-> 마스터 (현재 분기가 체크 아웃 됨)'