다른 작업을 수행하는 동안 커밋되지 않은 변경 사항을 제쳐두고 어떻게해야합니까?

다른 작업을 수행하는 동안 커밋되지 않은 변경 사항을 제쳐두고 어떻게해야합니까?

---

커밋되지 않은 변경 사항이 많고 대신 다른 작업을 수행하는 동안 제쳐두고 싶다면 나중에 (몇 일 후) 다시 돌아와 작업을 계속하십시오. 이를 수행하는 가장 쉬운 워크 플로는 무엇입니까? (지금까지 Mercurial의 기본 기능에 대한 경험 만 있습니다). 내 일반적인 방법은 복제를 사용하여 새 분기를 만드는 것이었지만 더 좋은 방법이있을 수 있습니다.

---

몇 가지 옵션이 있습니다.

1. 선반 항목을. 이렇게하면 변경 사항이 저장되고 작업 디렉토리에서 제거되므로 분기를 계속할 수 있습니다. 변경 세트를 생성하지 않습니다.

   hg shelve --all --name "UnfinishedChanges"
   
   hg unshelve --name "UnfinishedChanges"
   

   업데이트 / 편집 : 최신 버전의 수은을 사용해야 할 수 있습니다.

   hg shelve -n "UnfinishedChanges"
   hg unshelve "UnfinishedChanges"
   

   여전히을 --name대신 사용할 수 -n있지만 수은은 --name더 이상 좋아하지 않는 것 같습니다 . 또한 --all더 이상 필요하지 않으며 실제로 수은이 그 이상을 두려워 할 것입니다.

2. 패치 는 mq. 이것은 어떤 측면에서 선반에 비해 너무 다르지 않지만 다르게 작동합니다. 최종 결과는 동일하며 변경 사항이 제거되며 나중에 선택적으로 다시 적용 할 수 있습니다. 푸시되면 패치는 논리적 변경 세트이며, 팝되면 다른 곳에 저장되며 변경 세트 기록의 일부가 아닙니다.

   hg qnew "UnfinishedWork"
   hg qrefresh
   hg qpop
   
   hg qpush "UnfinishedWork"
   

3. 로컬로 커밋하고 이전 변경 세트로 업데이트하고 계속 작업하고 익명 분기 (또는 여러 헤드)를 사용합니다. 그런 다음 변경하려면 헤드를 병합 할 수 있습니다. 변경을 원하지 않는 경우 변경 세트를 제거 할 수 있습니다 .

   hg commit -m"Commiting unfinished work in-line."
   hg update -r<previous revision>
   
   hg strip -r<revision of temporary commit>
   

4. 명명 된 분기에 커밋합니다. 그러면 워크 플로가 옵션 3 (준비되면 병합 또는 제거)과 동일하게됩니다.

   hg branch "NewBranch"
   hg commit -m"Commiting unfinished work to temporary named branch."
   hg update <previous branch name>
   

개인적으로 저는 변경 세트를 제거하거나 부분 코드를 체크인하는 것을 신경 쓰지 않기 때문에 옵션 3 또는 4를 사용합니다 (결국 푸시되지 않는 한). 필요한 경우 다른 사용자로부터 로컬 변경 세트를 숨기기 위해 새로운 단계 항목 과 함께 사용할 수 있습니다.

또한 rebase병합으로 코드 기록에 아무것도 추가하지 않는 병합을 피하기 위해 명령을 사용하여 변경 집합을 이동합니다. 병합은 중요한 분기 (예 : 릴리스 분기) 간의 활동이나 수명이 더 긴 기능 분기의 활동을 위해 저장하는 경향이 있습니다. histedit변경 세트를 압축하는 데 사용 하는 명령 도 있습니다. 여기서 "수다 스러움"이 값을 감소시킵니다.

패치 대기열도이를 수행하는 일반적인 메커니즘이지만 스택 의미 체계가 있습니다. 패치를 푸시하고 팝하지만 스택의 다른 패치 "아래"에있는 패치는 그 위에있는 패치도 푸시해야합니다.

경고 , 이러한 모든 옵션과 마찬가지로 보류 / 대기 / 분기 한 임시 변경 사항 이후 파일에 더 많은 변경 사항이있는 경우 보류 해제 / 밀기 / 병합시 병합 해결이 필요합니다.

---

개인적으로 지금까지 게시 된 답변이 마음에 들지 않습니다.

1. 나는 단지이 각 프로젝트를 좋아하기 때문에 분기 클론처럼하지 않는 한 디렉토리를. 동시에 다른 디렉토리에서 작업하면 편집자의 최근 파일 기록이 완전히 엉망이됩니다. 나는 항상 잘못된 파일을 변경합니다. 그래서 더 이상 그렇게하지 않습니다.
2. 나는 shelve빠른 수정을 위해 사용 합니다 (내가 잘못된 지점에 있다는 것을 알게되면 커밋되지 않은 변경 사항을 다른 지점으로 옮기기 위해). 당신은 며칠에 대해 이야기하고 있습니다.
3. mq이런 평범한 상황에는 너무 복잡 하다고 생각합니다

가장 좋은 방법은 변경 사항을 시작하고 거기에서 작업하기 전에 변경 세트로 돌아가서 변경 사항을 커밋하는 것입니다. 몇 가지 사소한 문제가 있습니다. 설명하겠습니다.

변경 세트 A가 있다고 가정합니다. 변경을 시작하는 것보다. 이 시점에서 잠시 따로 보관 해 두십시오. 먼저 작업을 수행하십시오.

hg ci -m "Working on new stuff"

원하는 경우 나중에 쉽게 돌아올 수 있도록 책갈피를 추가 할 수 있습니다. 저는 항상 익명의 지점에 대한 책갈피를 만듭니다.

hg bookmark new-stuff

이러한 수정 이전의 변경 집합으로 돌아 가기

hg update A

여기에서 작업하고 변경 세트 C를 생성합니다. 이제 2 개의 헤드 (B 및 C)가 있으므로 푸시하려고 할 때 경고가 표시됩니다. 해당 분기의 헤드를 지정하여 하나의 분기 만 푸시 할 수 있습니다.

hg push -r C

Or you can change the phase of the new-stuff branch to secret. Secret changesets won't be pushed.

hg phase -r new-stuff --secret --force

---

To keep local uncommited changes, easiest way for me is just to save them as a patch file.

hg diff > /tmp/`hg id -i`.patch

and when you need to return to previous state:

hg up <REV_WHERE_SAVED>
hg patch --no-commit /tmp/<REV_WHERE_SAVED>.patch

---

You can just clone your repo multiple times. I tend to have a root clone, then multiple childs from there. Example:

• MyProject.Root
• MyProject.BugFix1
• MyProject.BugFix2
• MyProject.FeatureChange1
• MyProject.FeatureChange2

The 4 childs are all cloned from the root and push/pull to/from the root. The root then push/pulls from the master repo on the network/internet somewhere. The root acts as your sort of personal staging area.

So in your case, you'd just clone up a new repo and start working. Leave your 'shelved' work alone in the other repo. It's that simple.

The only downside is disk space usage, but if that were a concern you'd not be using DVCS at all anyway ;) Oh and it does kind of pollute your Visual Studio "recent projects" list, but what the hey.

[Edit following comments] :-

To conclude then... what you're doing is completely fine and normal. I would argue it is the best possible way to work when the following are true: 1) it is short-lived 2) you don't need to collaborate with other developers 3) the changes don't need to leave your PC until commit/push time.

참고URL : https://stackoverflow.com/questions/11520047/how-do-i-put-a-bunch-of-uncommitted-changes-aside-while-working-on-something-els