여기에 동의합니다. 특히 커밋 대화 상자가 GUI에서 "git 상태"로 효과적으로 기능하기 때문에.

다음 시나리오에 대해 어떻게 예상하십니까?

0단계:

1. 기본(찾아보기) 양식에서 "Commit" 버튼을 클릭하면 커밋 대화 상자가 열립니다.
2. 커밋 대화 상자를 최소화하고 포커스를 다시 기본 창으로 전환합니다.
3. "Commit" 버튼을 다시 클릭합니다.
   Q: 기존 대화 상자를 팝업해야 합니까 아니면 새 대화 상자 사본을 만들어야 합니까?

1단계:

1. 기본(찾아보기) 양식에서 "Commit" 버튼을 클릭하면 커밋 대화 상자가 열립니다.
2. 포커스를 다시 기본 창으로 전환하고 닫습니다.
   Q: 커밋 대화 상자도 닫아야 합니까?

2단계:

1. 기본(찾아보기) 양식에서 "Commit" 버튼을 클릭하면 커밋 대화 상자가 열립니다.
2. 포커스를 다시 기본 창으로 전환하고 새 커밋이 아직 존재하지 않음을 확인합니다.
3. 커밋 대화 상자로 포커스를 전환하고 파일의 일부(또는 변경된 줄의 일부)를 커밋하면 새 커밋이 생성되었지만 커밋 대화 상자는 여전히 열려 있습니다.
4. 메인 창으로 돌아갑니다.
   Q: 커밋 히스토리 그래프에 새 커밋이 이미 포함되어 있어야 합니까?

1. 기존 대화 상자
2. 대화상자 닫기
3. 커밋 후 커밋 대화 상자가 닫히고 기록에 새 커밋이 표시되어야 합니다.

이것은 어디까지나 제 생각입니다.

0: 기존 대화 상자

1: 대화 상자 닫기

2: 그래프에 새 커밋이 포함되어야 하고, 선택한 옵션에 따라 커밋 대화 상자가 닫혀 있어야 합니다(현재 상태 그대로).

저도 이 요청을 지지하고 싶습니다. 예를 들어 커밋 메시지를 복사한 기록을 보려면 커밋 대화 상자를 닫아야 하는 것이 부자연스럽습니다.

높이 평가합니다.

또 다른 문제가 있습니다. 커밋 대화 상자가 열려 있고 사용자가 작업 디렉토리를 변경할 때 GitExtensions는 무엇을 해야 합니까?
a) 커밋 대화 상자 닫기
b) 대화 상자를 열어 두고 내용을 새로 고칩니다.
c) 대화 상자를 열어 두고 이전 저장소로 작업합니다.
d) 열린 대화 상자가 있을 때 작업 디렉토리 변경을 허용하지 마십시오.
e) 다른 아이디어.

"c"를 예상하지만 "Commit" 버튼을 반복해서 클릭하면 새 대화 상자 인스턴스가 열려야 합니다. 리포지토리당 하나의 대화 상자 인스턴스(따라서 작업 디렉토리를 다시 변경하면 세 번째 인스턴스를 여는 대신 첫 번째 인스턴스가 다시 사용됨).

c) 대화 상자를 열어 두고 이전 저장소로 작업합니다.

그리고 왼쪽의 변경 사항 파일 트리에 표시되는 "로컬 변경 사항 업데이트"를 제공합니다(단계화되지 않음). 이 상황은 현재 상태에서 이미 가능하며 대화 형식의 영향을 받지 않습니다. 그러나 GitExt에서 로컬 변경을 하면 안 된다는 점을 분명히 해야 합니다.
분기 또는 현재 커밋(즉, 인덱스)을 변경하는 것은 "하드"는 허용되지 않을 것이라고 생각합니다. 작업 디렉토리는 그대로 유지되어야 합니다. 이 시점에서 사용이 제한되지만 이것이 가능하지 않아야 할 이유가 없습니다.

또는 "...(분기|커밋)에 커밋".

최근에 ViewPullRequestForm을 모덜리스로 만들었습니다. FormBrowse를 클릭하면 응답하지만 ViewPullRequestForm 뒤에 남습니다. FormBrowse가 활성화된 후 ViewPullRequestForm 앞에 FormBrowse를 표시하는 설정을 아는 사람이 있습니까?

ViewPullRequestForm에 대한 Show()/ShowDialog() 호출에서 상위 매개변수를 제거할 수 있습니다.

시도했지만 도움이되지 않습니다.

메인 창을 닫을 때 응용 프로그램이 종료되기 때문에 현재의 모덜리스 양식 동작은 사용자 관점에서 직관적이지 않다고 생각합니다.

몇 가지 옵션이 있다고 생각합니다.

• 현재 구현에서 문제를 수정하십시오.
• 새 애플리케이션 인스턴스를 실행할 때마다
• 모든 모덜리스 창 FormBorderStyle을 FixedToolWindow/SizableToolWindow로 변경하여 사용자가 최소한 이 동작을 예상할 수 있도록 합니다.

나는 종종 이것에 걸려 넘어진다. 나는 정기적으로 작은 커밋을 수행하므로 커밋 창을 유지합니다.

이것은 계속 발생합니다:

1) 무언가를 커밋하다
2) 창 최소화
3) 계속하다
4) Git Extensions 메인 창으로 돌아와서 클릭을 시도합니다.
5) 깜박거리고 오류음만 나면 답답함
6) 내 화면의 맨 왼쪽에 아주 작은 최소화된 모달 창이 있음을 깨닫습니다.

비모달로 만들거나 최소화 기능을 제거하십시오. 나는 전자의 옵션에 투표합니다.

스테이징 및 스테이징 해제한 다음 커밋 대화 상자를 닫고 가져올 수 있습니다.
언제든지 백업하십시오.

2013년 7월 18일 목요일 오전 11시 14분에 Drew Noakes [email protected] 이 작성했습니다.

나는 종종 이것에 걸려 넘어진다. 나는 정기적으로 작은 커밋을 수행하므로
에 대한 커밋 창.

이것은 계속 발생합니다:

1) 무언가를 커밋하다
2) 창 최소화
3) 계속하다
4) Git Extensions 메인 창으로 돌아와서 클릭을 시도합니다.
5) 깜박거리고 오류음만 나면 답답함
6) 맨 왼쪽에 작은 최소화된 모달 창이 있음을 깨닫습니다.
내 화면

비모달로 만들거나 최소화 기능을 제거하십시오. 나는 투표한다
이전 옵션의 경우.

—
이 이메일에 직접 답장하거나 Gi tHubhttps://github.com/gitextensions/gitextensions/issues/564#issuecomment -21190625에서 확인하세요.
.

_제이 애즈버리_
PC 수리 및 맞춤형 프로그램 $30/시간 1시간
내 자전거 블로그 http://vbjaybiking.blogspot.com

@vbjay , 그건 제가 커밋 창으로 작업하는 데 익숙하지 않다는 것을 압니다. :) 저는 Linux에서 예상대로 작동하는 다른 도구를 사용하여 대부분의 시간을 보냅니다. 작가가 최선을 결정하는 것을 기쁘게 생각합니다. 변경에 대한 내 +1입니다.

모달 커밋 대화 상자의 또 다른 성가신 것은 포커스가 있을 때 기본 창을 앞으로 가져오는 것입니다.

예를 들어 기본 창을 왼쪽에 도킹한 다음 커밋 대화 상자를 열고 오른쪽에 도킹한 다음 왼쪽에 도킹된 IDE를 열고 커밋 대화 상자에 초점을 맞추면 기본 창이 IDE를 가립니다. 결국 원하는 방식으로 창을 얻으려면 약간의 저글링을 해야 합니다.

저는 최근에 기본적으로 커밋 창만 사용한다는 것을 깨달았고 독립 실행형으로 실행하게 되어 기쁩니다. 나는 (콘솔에서 대화식으로 하는 것보다) 마우스로 패치를 커밋하는 기능을 정말 좋아하지만 다른 모든 git 항목은 명령줄에서 더 편안하게 느껴집니다.

이를 염두에 두고 @vcpp 가 제기한 세 가지 질문에 대한 답변은 다음과 같습니다.

1. 리포지토리 기반으로 커밋 창을 재사용합니다(다른 프로젝트에 대해 여러 커밋 창을 열고 싶습니다).
2. 커밋 창을 열어 둡니다.
3. 자식 창에서 커밋하면 메인 창에 새 커밋을 알리므로 즉시 업데이트됩니다.

@NJAldwin , @jbialobr 및 나(3명의 응답자) 사이에 두 번째 요점을 제외한 모든 것에 대해 동의한 것으로 보이며, 이는 이 기존 드롭다운의 옵션으로 제어할 수 있습니다.

UX Stack Exchange 사이트에는 다음과 같은 흥미로운 토론이 있습니다.

http://ux.stackexchange.com/questions/39778/benefits-and-drawbacks-of-modal-windows

커밋 창을 짧은 주문에 사용할지 아니면 열어둔 상태로 두는지에 따라 결정되는 것 같습니다. Git Extensions와 같은 도구는 다양한 워크플로 개발자에게 적합합니다. 이 문제 하나만으로 나와 다른 워크플로를 가진 누군가를 위해 설계된 것처럼 느껴집니다. 일화적으로, 이 보기는 우리 팀의 다른 개발자들과 공유하고 있습니다.

최근에 메인 창의 하단 창에 있는 탭 컨트롤에 콘솔이 추가되었습니다. 커밋 창을 탭으로 추가할 수 없는 이유는 무엇입니까?

이것은 나에게 훌륭한 솔루션인 것 같습니다.

여기 모형이 있습니다. 탭 제목을 변경해야 합니다. 두 번째 "Commit" 탭이 "Changes"가 될 수 있습니다.

그렇게 성장한 사용자를 위해 기존 커밋 창을 계속 유지할 수 있습니다. 최소한 시각적인 관점에서 컨트롤을 재사용할 수 있습니다(커밋 시 대화 상자 닫기에 대한 옵션 제외).

이것은 나에게 훌륭한 솔루션인 것 같습니다.

참으로 좋은 생각입니다! 대부분의 경우 커밋 대화 상자를 열기 위해서만 찾아보기 대화 상자로 전환합니다.

내가 볼 수있는 유일한 문제는 UI 속도 저하입니다. 그것은 많은
기능이 하나의 형태로 통합되었습니다. 제어를 업데이트하지 않을 수도 있습니다.
탭이 활성화되어 있습니다.

2017년 3월 20일 월요일 오후 1:36 Janusz Białobrzewski <
[email protected]>은 다음과 같이 썼습니다.

이것은 나에게 훌륭한 솔루션인 것 같습니다.

참으로 좋은 생각입니다! 대부분의 경우 찾아보기 대화 상자로 전환합니다.
커밋 대화 상자를 열기 위해서만.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/gitextensions/gitextensions/issues/564#issuecomment-287837834 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ADdhsWU1-9kllO-8sYbi61lIS_owCqH0ks5rnrkcgaJpZM4AdCWc
.

UI를 느리게 로드하는 것이 합리적으로 보입니다(코드에 익숙하지 않지만).

FormCommit을 기본 폼에 통합하려면 전체 창에서 "Console", "Commit..." 탭을 이동해야 한다고 생각합니다.

둘 다 그래프에서 선택한 커밋에 의존하지 않기 때문에 논리적으로 일관된 @KindDragon .

단점은 더 많은 수직 공간을 잃고 UI를 탐색하는 데 필요한 마우스 이동 및 클릭의 양이 증가한다는 것입니다. 종종 UI는 프로그래머에게 덜 논리적인 경우에도 사용자에게 더 친숙하고 자연스럽습니다.

상단에 탭을 도입하려는 경우 하나의 창에서 여러 리포지토리를 추적할 수 있도록 리포지토리용 탭을 개인적으로 선호합니다. 이것이 이 문제의 초점은 아니지만 그렇게 하기 전에 최상위 탭 컨트롤에 대한 대체 사용법을 고려해 볼 가치가 있습니다.

커밋 양식이 그래프 아래에 있으면 더 좋을 워크플로 중 하나는 수정 커밋을 만드는 것입니다. 필요한 모든 것이 화면에 표시됩니다. 가장 주목받는 두 가지 UI 요소는 그래프와 커밋 창입니다. 커밋 모달을 만들면 이 두 가지를 함께 사용하기 어렵습니다. 탭에 넣으면 더 쉬워지지만 두 가지를 동시에 볼 수 있게 하는 것이 (내 생각에는) 궁극입니다.

상단에 탭을 도입하려는 경우 하나의 창에서 여러 리포지토리를 추적할 수 있도록 리포지토리용 탭을 개인적으로 선호합니다.

하단의 탭을 생각하고 있습니다.

하단의 탭 표시줄, 중간의 탭, 상단의 도구 모음/메뉴 사이를 이동하는 것은 이동해야 하는 곳을 탐색하기 위한 많은 마우스 활동입니다. 상단에 하나의 막대와 중간에 하나의 막대가 있는 것이 IMO 세 개의 막대를 갖는 것보다 낫습니다. 창 아래에 배치된 탭은 UI에서 그렇게 일반적이지 않습니다.

창의 왼쪽에 있는 탭 열(그래프, 커밋, 콘솔)이 위쪽에 정렬되어 있을 수 있습니다. 그렇게 하면 모든 것이 밀접하게 유지됩니다.

사용자가 레이아웃을 자신에게 맞게 구성할 수 있도록 도킹 프레임워크를 사용하는 것이 좋습니다. 하나의 레이아웃으로 모든 사람을 만족시킬 수는 없다고 생각합니다. 다시 말하지만, 나는 커밋하는 동안 그래프를 보는 것을 좋아합니다.

나는 실제로 그 제안이 마음에 들지 않습니다... 저에게 그것은 패널(스플리터)의 크기를 지속적으로 조정하는 것을 의미합니다.

VS와 같은 도킹된 창을 사용하면 더 나은 UX를 얻을 수 있습니다(https://github.com/gitextensions/gitextensions/issues/3679 참조).
그러나 (항상 하나 있어야 함) Windows가 아닌 사용자에게는 작동하지 않습니다....

사용자가 미리 정의된 도킹 또는 도킹 해제 레이아웃 집합에서 레이아웃을 선택할 수 있는 "가난한 사람" 도킹 솔루션이 가능할 수 있습니까? 모든 사람이 도킹을 지원하는 프레임워크를 찾는 것이 어려울 수 있습니까?

몇 가지 관련 문제를 추가했습니다.

4033

4031

@drewnoakes의 모형과 유사한 "모덜리스 커밋"과 관련되어야 하는 #4031의 제안
@RussKie 에 어느 정도 동의하고 기본 커밋은 모덜리스여야 한다고 생각하지만 팝업에서 "전체" 커밋을 수행할 수 있습니다.

• 커밋 탭이 현재 숨겨져 있습니다. 커밋 해시가 없고 해당 커밋 메시지가 "현재 WIP"(예비 추가된 것)라는 점을 제외하고 HEAD의 커밋 탭과 유사한 정보가 있어야 합니다.

• 개선 사항: 편집 가능한 커밋 텍스트. 팝업 대화 상자에서만 커밋이 가능하더라도 커밋 메시지 작성을 단순화합니다.

• 개선 사항: 커밋 팝업과 유사한 커밋 버튼

• Diff 탭, 파일 보기 상황에 맞는 메뉴로 파일 준비/언스테이징 및 재설정

  • 파일을 두 번 클릭하면 찾아보기(파일 히스토리)에서처럼 작동하거나 커밋에서처럼 스테이지/언스테이징해야 합니까?

• 개선 사항: Commit/Diff를 동시에 볼 수 있도록 별도의 탭

  • 커밋 창을 이동하는 것으로 충분합니까?

커밋 그래프( @drewnoakes mockup) 하단에 커밋 대화 상자를 "도킹 가능"하게 하고 도킹/도킹 해제 키보드 단축키는 처음에 대화 상자를 여는 것과 동일(또는 구성 가능)할 ​​수 있다는 아이디어에 대해 어떻게 생각하십니까?
따라서 ctrl+space를 사용하여 본격적인 대화 상자를 열었지만 더 작게 만들고 Ctrl+space를 다시 누르면 도킹됩니다. 마지막 대화 상태가 도킹된 경우 반대입니다.

@drewnoakes 작동하는 프로토타입이 있습니까? 나는 이것을 오늘 사용하기 시작하고 싶습니다 :D

연초부터 CommitInfo 탭을 이용하여 구현하기 시작했는데 기본적으로 FormCommit의 모든 코드를 복제해서 유지관리 관점에서 솔루션이 재미없게 되어 포기했습니다.

이 대화 상자를 모달로 남겨두고 도킹/도킹 해제할 수 있는 옵션이 있습니까?

사용하지 않았습니다. MIT 라이센스입니다. https://github.com/dockpanelsuite/dockpanelsuite

#5535를 위해 이것을 닫습니다.

내 개인적인 의견으로는 이것을 구현하는 것이 더 좋았을 것입니다. 어쨌든 적어도 Windows에서는 파일 탐색기에서 폴더를 열고 마우스 오른쪽 버튼을 클릭하고 "GitExt Commit..."를 선택하는 해결 방법이 있습니다. 열려 있는 다른 Git Extensions 창과 독립적으로 커밋 대화 상자.