"git add, git commit"전후에 언제 "git pull"을 수행해야합니까?


95

올바른 방법은 무엇입니까?

git add foo.js
git commit foo.js -m "commit"
git pull
git push

또는

git pull
git add foo.js
git commit foo.js -m "commit"
git push

또는

git add foo.js
git pull
git commit foo.js -m "commit"
git push

UPD :

이 경우 추적수정 된 파일 git add을 준비하는 데 사용한다는 것을 언급하는 것을 잊었습니다 . 저장소에 새 파일을 포함하지 않습니다. 이것은 명령의 순서를 변경합니까?


답변:


98

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

로컬 변경 사항을 숨 깁니다.

git stash

분기를 최신 코드로 업데이트

git pull

로컬 변경 사항을 최신 코드에 병합하십시오.

git stash apply

변경 사항 추가, 커밋 및 푸시

git add
git commit
git push

내 경험상 이것은 Git (어쨌든 명령 줄에서)에 대한 저항을 최소화하는 경로입니다.


4
이것이 더 나은 이유 를 설명 할 수 있습니까 ? 이것은 어떤 문제를 피합니까? 특히 이것이 왜 단순한 커밋> 풀> 푸시보다 낫습니까? (필자는 가장 좋은 대답이 될 수있는이 같은 느낌,하지만 지금에도 좋은 답변을 고려해야 할 충분한 정보를 가지고 있지 않습니다.)
댈린

8
아마도 이것은 너무 일화 적이었지만 항상이 접근 방식 (sourcetree와 같은 것보다 명령 줄에서)이 훨씬 쉽다는 것을 알았습니다. 커밋을 한 다음 당겨서 큰 팀에서 작업하는 동안 git이 파일에 대한 변경 사항을 들어오는 파일에 병합하는 데별로 좋지 않았기 때문에 항상 큰 병합 충돌이 발생합니다. 숨김으로써 새로운 변경 사항을 가져온 다음 업데이트 된 코드를 기반으로 변경 사항을 추가 할 수 있습니다. 갈등을 다루는 것이 나에게 더 명확했기 때문에 더 쉬웠습니다 (이제 변경 사항이 갈등 이었으므로). 돌이켜 보면 내 상황이 더 쉬웠을 수도 있습니다.
johnjo

1
그래서 "코끼리를 어떻게 먹나요? 한 번에 한 입씩"같은 소리처럼 들립니다. 즉, 프로세스를 몇 단계로 나누어 병합을 단순화하여 변경 사항을 줄이고 명확하게합니다. 말이된다.
dallin

여기에 git add가 필요합니까? 모든 파일이 이미 스테이징에 추가 된 경우!
Sharp Edge

사용하지 않으면 git stash어떨까요?
Aaron Franke 1911

77

pull = 가져 오기 + 병합.

병합하기 전에 수행 한 작업을 커밋해야합니다.

그러니 커밋 후 당기십시오.


8
이것은 당신이 만든 각 커밋에 대해 추가 커밋을 만들고 리포지토리를 조잡하게 만드는 것을 의미합니까? 또한 초기 커밋 메시지는 매번 병합 주석이 이어집니다. 그렇다면 @johnjo가 아래에 언급 한 숨김 방법을 사용하는 경향이 있습니다.
MondayPaper 2016 년

3
@DanielM 예, 병합에 대한 추가 커밋이 있습니다 (명시적인 기본 커밋 메시지 포함). 마지막 커밋이나 동료의 마지막 커밋 또는 병합 커밋을 확인할 수 있기 때문에 이것은 꽤 좋은 일입니다. 그것을 피하고 싶고 동료의 커밋 뒤에 커밋을 배치하려면 rebase대신 merge. git commit && git rebase또는을 사용하여 수행 할 수 있습니다 git pull --rebase.
Arnaud Denoyelle

팁 주셔서 감사합니다, @Arnaud. 많은 다른 질문을 읽은 후이 의견이 작성되었습니다. 동료들이 다른 파일에 대해 작업 할 때 선호하는 옵션은 git pull변경 사항을 스테이징 한 후 가장 자연스러운 것입니다. 여러 가지 워크 플로가 작동한다는 것을 알고 있지만 (숨겨진 것도 좋습니다), 아마도 취향의 문제 일 것입니다.
nephewtom

52

큰 병합과 가능한 충돌을 최소화하기 위해 가능한 한 자주 원격 지점에서 가져 오는 것이 좋습니다.

그렇게 말 했으니 첫 번째 옵션을 선택하겠습니다.

git add foo.js
git commit foo.js -m "commit"
git pull
git push

가져 오기 전에 변경 사항을 커밋하여 가져 오기 중에 커밋이 원격 변경 사항과 병합되도록합니다. 이로 인해 문제가 발생하고 어떤 이유로 든 병합을 중단해야하는 경우 코드가 이미 커밋되었음을 알 수있는 충돌이 발생할 수 있습니다.

나는 누군가가 나에게 동의하지 않을 것이라고 확신합니다. 나는 이 병합 흐름을 수행 하는 올바른 방법 이 없다고 생각 합니다.


1
질문에 대한 내 업데이트를 볼 수 있습니까? git add내 예에서 정확히 무엇을 사용 하는지 설명하는 것을 잊었습니다 .
Green

1
새 파일이든 추적 / 수정 된 파일이든 아무런 차이가 없어야합니다. 여전히 커밋하고 당기십시오.
Jasarien 2013-08-30

7

git pull --rebase특정 지점에서 가지고 있지 않은 원격 커밋 위에 로컬 최근 커밋을 설정하는 가장 깨끗한 방법 이라고 생각 합니다.

따라서 변경을 시작할 때마다 당길 필요가 없습니다.


이것이 제가하는 일이기도하지만, 병합 캠프에서 Linus 자신과 함께 (개별 커밋에서 충돌을 해결하는 것이 가장 좋은지 병합 커밋에서 한 번 해결하는 것이 가장 좋은지 중심으로) 이것에 대한 두 가지 주요 생각 학교가 있음을 지적합니다. . 다행히 도구 자체가 의견을 고집하지 않는, 그래서 그러나 당신 및 프로젝트의 요구 :-) 위해 최선을 작동 사용
누가 복음 Usherwood

3

변경 사항이 원격 분기의 현재 상태 위에 놓이기를 원합니다. 그래서 아마도 당신은 자신을 저지하기 직전에 당길을 원할 것입니다. 그 후 변경 사항을 다시 푸시하십시오.

"더러운"로컬 파일은 원격 브랜치와 충돌하지 않는 한 문제가되지 않습니다. 그래도 충돌이 발생하면 병합이 실패하므로 로컬 변경을 커밋하기 전에 가져올 위험이나 위험이 없습니다.


1
Arnaud가 언급했듯이 작동하지 않습니다. 당기려면 먼저 변경 사항을 커밋해야합니다.
Jasarien

내 자식은 많은 로컬 변경 사항을 가져 오는 데 행복해 보입니다. 물론 동일한 파일이 원격 브랜치에서 변경되면 풀의 병합 부분이 실패합니다. 적절한 병합 충돌을 만들려면 먼저 커밋해야합니다. 따라서 로컬 및 원격으로 변경된 파일 집합이 분리되어있는 경우 가져 와서 커밋하는 것이 좋습니다. 그렇지 않으면 git이 당기지 않습니다. 시도해도 손상되지 않습니다.
AlexE

사람들이 다른 파일에서 작업 할 때 선호하는 옵션이며 가장 자연스러운 방법입니다.
nephewtom
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.