"git pull"이 자동으로 숨겨지고 보류중인 변경 사항을 팝 할 수 있습니까?

"git pull"이 자동으로 숨겨지고 보류중인 변경 사항을 팝 할 수 있습니까?

---

나는 이것을 해결하는 방법을 안다.

user@host$ git pull
Updating 9386059..6e3ffde
error: Your local changes to the following files would be overwritten by merge:
    foo.bar
Please, commit your changes or stash them before you can merge.
Aborting

그러나 할 수있는 방법이 없다 git pull할 일 stash및 pop나를 위해 춤은?

이 명령의 이름이 다른 경우 괜찮습니다.

에 대한 셸 별칭을 만드는 것이 git stash; git pull; git stash pop해결책이지만 더 나은 해결책을 찾고 있습니다.

---

Git 2.6 이상 (2015 년 9 월 28 일 출시)

git config관심있는 유일한 설정은 다음과 같습니다.

rebase.autoStash

true로 설정하면 작업이 시작되기 전에 자동으로 임시 숨김을 만들고 작업이 끝난 후에 적용합니다.
이는 더티 워크 트리에서 rebase를 실행할 수 있음을 의미합니다.

그러나주의해서 사용하십시오. 성공적인 리베이스 후 최종 숨김 애플리케이션은 사소한 충돌을 초래할 수 있습니다. 기본값은 false입니다.

그것을 다음과 결합하십시오.

pull.rebase

true이면 "git pull"이 실행될 때 기본 원격의 기본 브랜치를 병합하는 대신 가져온 브랜치 위에있는 브랜치를 리베이스합니다.

git config pull.rebase true
git config rebase.autoStash true

git pull더러운 나무에서도 간단 하게 작업 하기에 충분합니다 .
이 경우 별칭이 필요하지 않습니다.

---

Kevin Daudt ( )의 commit 53c76dc (2015 년 7 월 4 일)를 참조하십시오 . ^{(Merged by Junio ​​C Hamano -- in commit e69b408 , 17 Aug 2015)}Ikke
gitster

pull: rebase.autostash활성화 되면 더티 트리 허용

rebase는 더러운 작업 트리를 만날 때 변경 사항을 숨기는 법을 배웠지 만 git pull --rebase그렇지 않습니다.

rebase.autostash활성화되지 않은 경우 작업 트리가 더러워 졌는지 확인하십시오 .

---

참고 : autostash 없이 가져 오려면 ( rebase.autoStash true이 설정되어 있어도 ) git 2.9 (2016 년 6 월)부터 다음이 필요합니다.

 pull --rebase --no-autostash

참조 450dd1d 커밋 , 1,662,297 커밋 , 44a59ff 커밋 , 5c82bcd 커밋 , 6ddc97c 커밋 , eff960b 커밋 , efa195d 커밋 (2016 4월 2일을), 및 f66398e 커밋 , c48d73b을 투입 하여 (2016년 3월 21일) Mehul 자이나교 ( mehul2029) .
^{(Merged by Junio ​​C gitsterHamano -- in commit 7c137bb , 13 Apr 2016)}

특히 f66398e 커밋 에는 다음이 포함됩니다.

pull --rebase: --[no-]autostash플래그 추가

경우 rebase.autoStash구성 변수가 설정 "에 대한 재정의 할 수있는 방법이 없습니다 git pull --rebase명령 줄은".

설정된 경우 의 현재 값을 재정의 git pull --rebase하는 --[no-]autostash명령 줄 플래그를 " "에 알려줍니다 rebase.autoStash. " git rebase"이 --[no-]autostash옵션을 이해하므로 git rebase" git pull --rebase"이 호출 될 때 기본 " "에 옵션을 전달하는 문제입니다 .

---

경고 : Git 2.14 (2017 년 3 분기) 이전 git pull --rebase --autostash에는 로컬 기록이 업스트림으로 빠르게 이동할 때 " "가 자동으로 숨겨지지 않았습니다.

Tyler Brazier ( )의 commit f15e7cf (2017 년 6 월 1 일)를 참조하십시오 . ^{(Merged by Junio ​​C Hamano -- in commit 35898ea , 05 Jun 2017)}tylerbrazier
gitster

pull: ff --rebase --autostash는 더러운 저장소에서 작동합니다.

git pull --rebase --autostash더티 저장소에서 빨리 감기가 발생 했을 때 아무것도 자동 저장되지 않았고 가져 오기가 실패했습니다.
이것은 빨리 감을 수있을 때 rebase 실행을 피하는 지름길 때문이지만 해당 코드 경로에서 autostash는 무시됩니다.

---

업데이트 : Mariusz Pawelski 는 댓글 에서 흥미로운 질문을합니다.

그래서 모두가 autostash당신이 rebase (또는 pull --rebase) 를 할 때에 대해 쓰고 있습니다 .

그러나 병합을 사용 하여 정상적인 끌어 오기를 수행 할 때 아무도 자동 보관하지 않습니다 .
자동 스위치가 없나요? 아니면 뭔가 빠졌나요? 나는하는 것을 선호 git pull --rebase하지만 OP는 " 표준 "git pull에 대해 물었다.

대답:

The original thread discussing this autostash feature, it was implemented originally both for git pull (merge) and git pull --rebase.

But... Junio C Hamano (Git maintainer) noted that:

If the pull-merge were something that would induce the "annoyance" that triggered this topic, by definition, the local change overlaps with the merge, and this internal "stash pop" will touch the paths the merge touched and it is likely not result in "Dropped" but leave further conflicts to be resolved.

I suspect that pull.autostash configuration is not a good addition because it encourages a bad, pain-inducing workflow.
In simple cases it may not hurt, but when local changes are complex, it would actively hurt than not having it, and the configuration robs the incentive to choose.

The equation is somewhat different for "pull-rebase", as "rebase" insists you to start from a clean working tree, so "download and then stop" annoyance feels bigger. I have a suspicion that loosening that may be a more productive fix to the real problem.

So, regarding a classic pull-merge, it is better to:

encourage the user to think about the nature of WIP he has in the working tree before running "git pull".
Is it a too complex beast that may interfere with what others are doing, or is it a trivial change that he can stash away and pop it back?

If the former, he will be far better off doing "checkout -b", keep working until the local change gets into somewhat a better shape and "commit", before pulling into the original branch.

If the latter, he is better off doing:

• "git pull",
• after finding it conflicts, run
  • git stash,
  • git merge FETCH_HEAD and
  • git stash pop

---

To save few seconds for oncoming explorers, here is a summary (thanks to @VonC):

git pull --rebase --autostash

---

As the comment above stated, setting the two config values doesn't currently work with git pull, as the autostash config only applies to actual rebases. These git commands do what you want:

git fetch
git rebase --autostash FETCH_HEAD

Or set it as an alias:

git config alias.pullr '!git fetch; git rebase --autostash FETCH_HEAD'

Then do:

git pullr

Of course, this alias can be renamed as desired.

---

With Git 2.6+ you can use the following:

alias gup='git -c rebase.autoStash=true pull --rebase'

This --rebase makes git-pull use rebase instead of merge, so settings/options like --ff-only won't apply.

I am using an alias to pull with --ff-only by default (git pull --ff-only), and can then use gup (from above) in case a fast-forward merge is not possible or there are stashed changes.

---

As you already mentioned this is the way to do it. You can use it in alias to save you typing and to use shortcut or you can use it in a single line (can be an alias as well)

git stash && git pull --rebase && git stash pop

It will do the same thing as you done but in a single line (&&) and is you set as alias it will even be shorter.

The following lines will display the incoming/outgoing changes before you pull/push

git log ^master origin/master
git log master ^origin/master

참고URL : https://stackoverflow.com/questions/30208928/can-git-pull-automatically-stash-and-pop-pending-changes