현재git의 GUI 클라이언트 자체 제작이 매우 유행하고 있습니다!

3628 단어 GitSwingJava

권유하다


Git 클라이언트 애플리케이션을 제작하고 있습니다.

  • 자체 제작된 Giit 클라이언트 어플리케이션 제작 중@soramimi_jp선생님의 글

  • 현재git의 GUI 클라이언트 자체 제작이 매우 유행하고 있습니다!(이 글)
  • 내 꿈을 꾸며 창작하는 사람이 늘었으니 그런 곳에서 일어나면 즐거울 거야.

    진도



    모티프


    제 상황은요.
  • Windows 버전의 SourceTree는 갈수록 고통스러워지고 있다. 다른 것을 써야 할 때가 많지 않을 것 같다
  • 행위 단위의 Stage/unstage를 지원하는 응용 프로그램이 매우 적다
  • git를 좋아해서 언제 직접 GUI 앱을 만들고 싶은지
  • 무직최고!!!!!
  • 이것은 내가 자각한 동기다.다른 것도 있을지도 몰라요.
    (현재 자유 엔지니어로서 iOS와 안드로이드 프로그램을 개발하고 있다.)
    또 지난해'GUI의 Git 클라이언트 애플리케이션을 만들어 보았습니다.'를 읽은 덕분이다
    나는 내가 손찌검을 한 지 2~3년 정도 빠르다고 생각한다.

    커밋 또는 작업 커밋


    할 곳을 생각하고
    git의 GUI 클라이언트에서 무엇을 찾고 있는지 고려
    적어놓거나 우선도를 적으면 다음과 같은 생각이 든다.
    나는git를 사용하여 하는 일은 다음과 같은 두 단계로 나누어 고려해야 한다고 생각한다.
  • 제출git add,git reset,git commit등)
  • 운영제출git merge,git rebase,git reset등)
  • 이 두 단계는 반드시 같은 응용 프로그램을 사용해야 하는 것은 아니다.
    좋아하는 프로그램을 사용하면서 지령선을 직접 두드리기도 한다.
    물론 왔다 갔다 할 수 있기 때문에 같은 응용 프로그램은 비교적 가볍다
    둘 다 구분할 수 없는 기능이 있을 수도 있다.
    (예를 들어 git bisect 전용 물건을 준비하는 것이 가장 좋다.)
    하지만git 프로그램을 하려면 따로 생각해 보는 것이 좋다.
    그리고 어떻게 사용하든 커미션을 만들어야 해요.
    제가 가장 중요한 건 행위 단위의 스테이지/unstage를 구명조끼로 찾는 거예요.
    나 이거 먼저 하기로 했어.

    행위 단위의 스테이지/unstage 구현


    지금까지 큐타에 쓴 기사와 앞으로 쓸 기사다.

    [1]stage/unstage 기초지식편


    행단위 스테이지/unstage를 위해 해야 할 5가지1. 元になるpatchとしてdiffを出力する 2. stage/unstageしたい行を選ぶ 3. hunkのボディを編集する 4. hunkのヘッダーを再計算する 5. 最終的なpatchをapplyする

    [2]Stage/unstage 불완전 공략편


    JGTI를 사용해 보면 안 돼, git.직접 exe를 사용한다고 합니다.
    자세히 쓰진 않았지만 일렉트론은 역습을 당했다.
    언젠가는 복수할 거야.

    [3]stage/unstage 패치 편집편

    3. hunkのボディを編集する 4. hunkのヘッダーを再計算する

    [4] diff et al.

    1. 元になるpatchとしてdiffを出力する

    [5] 첫 번째 데스크톱 응용 프로그램


    디스플레이용2. stage/unstageしたい行を選ぶ

    [6] Stage/unstage의 완성(임시)

    2. stage/unstageしたい行を選ぶ의 계속5. 最終的なpatchをapplyする로컬 수정 취소(완료되지 않음)

    [7] 쓰기 시험(잠정)


    지령선에서 불가능한 일도 열심히 대처해야 하기 때문에 테스트를 쓰지 않으면 죽는다.
    테스트 부분만 잘라서 프로그램 라이브러리로 만들면 좋을 것 같아요.
    아마 그것은 가까운 시일 내에 매우 엄격할 것이다. 그래서 나는 어떻게 테스트하는지 쓸 계획이다.
    그리고 이것은 내가 처음으로 테스트 코드를 쓴 것이다.

    다음 개발 계획


    아무래도 제출하기 전에 다 한 것 같아서요.
    세밀한 과제와 문제가 있었지만 일단락됐다.
    그만뒀으니까 쓰는 시간이 줄었죠
    작업 중에 사용하려면 필요한 기능이 부족하고 전속력으로 실현해야 한다.
    이런 효과도 있고, 좋은 효과도 있다.
    다음은 큰 그림으로
  • 운영 커밋
  • 제출 이력을 표시하는 UI가 우선적으로 고려되기 때문이다.
    우선 복잡한 도표에 좋은 느낌을 주려고 노력하지 않겠습니다.
    그나저나 제가 GUI 고객에게 요구한 두 번째 탄은 git rebase -i입니다.
    나는 문턱이 매우 높다고 생각하지만, 틀림없이 방법이 있을 것이다.
    요즘 Windows 10 환경에서git rebase 창고가 넘쳐서 울고 있어요.

    나누어 주다


    Java라서 여기저기 이동할 수 있는데 어떻게 나눠드리면 좋을까요?
    나는 아직 아무것도 조사하지 않았는데, 단지 제멋대로 "강한 상점이 있었으면 좋겠다."라고 말했다.

    좋은 웹페이지 즐겨찾기