바로 우리가 게으른 사람이기 때문에'정확하고 부정확하며 약간 정확한git의 사용법'

이 보도는 졸저 큐타 기사에서 옮겨온 것이다
오늘 기사는 여기 있습니다.

이 글의 독자 대상

commiit 메시지 중 wipfix가 9할 이상'우주인'을 써서'진지한 사람'으로 읽기9/1 이전에 여름방학 숙제를 마친 사람은 미래인"하루에 1분만 노력한다"고 말할 수 있는 초능력자가 있다.
나는 일반인에게만 흥미를 느낀다.
우주인, 미래인, 이세계인, 초능력자가 있다면 가볍게'좋아요'기사를 끄세요.이상!

위원의 올바른 운용은?

세계선 사람들이 참고할 만한 기사가 많이 쓰여 있다.
http://qiita.com/kozyty@github/items/87fa95a236b6142f7c10
http://qiita.com/itosho/items/9565c6ad2ffc24c09364
http://qiita.com/risacan/items/f4cbabc62b684ab9296d
http://qiita.com/crifff/items/1abf08bca4ce51db4775
잠깐만요.
정확한 세상인 분들은 이 기사들을 참고하세요.

자신의 약속이 옳다는 것을 자주 깨닫는 것은 정말 번거롭다.그럼 어떡하지?

게으른 제출 정보, 적당한 제출 요청, File Changes(243)이 싫어진다.
팀원들의 MP를 줄여도 좋은 것은 아니다.

그러니 아래의 일에 주의하세요.

모두가 함께 일하는 지점은 더럽히지 않는다

자신의 지점 업무로 완성하고 홍보하세요!PR!!PR!!!

통합 시 GiitHub 사용Squash and Merge

남이 보는 것(≈pull 요구)을 깨끗이 하다

요청한 description의 목적이 무엇인지 명확히 설명한다

는 시가로 설정하지 않습니다.

적어도 새로운 기능의 추가인지, 오류 수정인지, 팩스인지는 적어야 한다.

원하는 부분을 소단위로 설명

물론'작은 변경·작은 PR'도 좋지만, 번거로운 여러 가지 일로 커진 경우도 있다.

"'●'이 문서의 메뚜기 100092; 제 △행을 위해 이렇게 했는데 □□ □일 수도 있어요. 한번 봐주세요."

● 파일의 시도 10009 & 오류; 3단계"...더 좋은 게 있겠죠!

네.이 단계에 이르러서야 비로소'약속을 줄이고 정보는 적당해야 한다'는 말을 진정으로 체득하게 되었다.요즘 실감이 난다.
그렇긴 하지만 보통 사람들은'그걸 하고 있을 때 여기를 신경 쓰고 여기도 고쳤다'는 경우가 많다.
설치하는 과정에서 귀찮았어요. "아, 이건 아니야. 다른 지점을 잘라. 그때로 돌아가서 여기서 지점을 잘라..."이런 건 너무 귀찮아요.너무 귀찮아요.
예를 들어 슬랙에 보내기 전에 잘못이 있는지 없는지를 엄격하게 다듬나요?설마.
아무튼 일단 Enter 키를 돌려!그럼 나중에 Edit하면 되겠네요.앞으로 안 봤으면 좋겠어요.

나중에 깨끗이 하면 돼.

Version 관리가 난폭하다면'이후 무슨 일이 일어났는지 뒤돌아보기 위해서','이후 과거의 편집을 바꾸기 위해서'다.
그래서 최초의 커미션은 적당했다.
실장 과정에서 고치고 싶은 부분을 고치고 마음껏 노력해 주세요.
그러나 자신의 업무 지점으로남에게 폐만 끼치지 마라.

이렇게 할 수 있었으면 좋겠어요.

● 기능 추가를 위해...

● 설치: 9xd4941

● 테스트: 0979xd2

하는 김에 한 가지 일을 했습니다.

자동 생성 코드 부분: 337xab7

보기 쉽다.더 예쁘게 할 수 있겠지...
6exd364

'나중에 예뻐질 거야'를 위한 다양한 일들.

모든 용례가 편리한git 명령

그러면 실제로 한 번 제출한 내용을 예쁘게 하기 위해 약간의 다른 용례의git 명령을 사용했다.

과거의 커미션을 정리하고 싶어요.

그렇다면, 귀사는 현재 업무 중에 대량의 wip 약속을 하고 있습니다.

$ git branch

  master
* wip-branch

$ git log

commit 035a324a7e9e03822be202536a89d3bd27451c95
Author: kyoh86 <[email protected]>
Date:   Tue Nov 22 08:15:42 2016 +0900

    wip まだゴミあった

commit d387cf8dd21b297d9b8c427db8b7007fe9dee108
Author: kyoh86 <[email protected]>
Date:   Tue Nov 22 07:57:33 2016 +0900

    wip バグ直し

commit 101f652a9dd51a29269fa818b91d2fac8a2e3d0c
Author: kyoh86 <[email protected]>
Date:   Tue Nov 22 07:51:02 2016 +0900

    wip できた？

commit 59be7f5930f6d3fe7d3cda89ddb1dd252d170b77
Author: kyoh86 <[email protected]>
Date:   Tue Nov 22 06:53:42 2016 +0900

    wop ごみ掃除

commit df735e2e2b31df94d73ad134fa02692996e3ad9d
Author: kyoh86 <[email protected]>
Date:   Tue Nov 22 05:09:27 2016 +0900

    functions 再整理 (#42)

df735e2(functions 재정리(#42) 이후 제출은 모두 wip입니다.
그렇게 복잡한 상황은 아니야.다만,'쓰레기 청소'위원 2명은 "다 했느냐?"오류 수정과 마찬가지로 작업 과정을 제출했습니다.
원래'쓰레기 청소'는 하나의 약속이고'청소 기능의 실현'은 하나의 약속이다. 이것이 가장 좋다.
그래서 git rebase -i 제출품을 다시 배열하여 몇 개로 정리했다.

$ git rebase -i df735e2e2b31df94d73ad134fa02692996e3ad9d # ← "functions 再整理 (#42)" のコミットハッシュ

pick 59be7f5 wop ごみ掃除
pick 101f652 wip できた？
pick d387cf8 wip バグ直し
pick 035a324 wip まだゴミあった

# Rebase 326fc9f..0d4a808 onto d286baa
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

편집기(기본값vim)가 열리면 설명에 따라 편집

재배열

총 1개

제출 메시지 변경

수정 제출 내용

에 대한 커밋 작업을 수행합니다.
여기, 아래처럼 이렇게 만져보세요.

reword 59be7f5 wop ごみ掃除
squash 035a324 wip まだゴミあった
reword 101f652 wip できた？
squash d387cf8 wip バグ直し

결과git log는 다음과 같습니다.

commit 4641774bde2c85eaa3ce905e1e6d9b4e1cebf60a
Author: kyoh86 <[email protected]>
Date:   Tue Nov 22 07:51:02 2016 +0900

    ◯◯の実装

commit 398acba7019ca7f7d915b55711c9ac53d7b22d3e
Author: kyoh86 <[email protected]>
Date:   Tue Nov 22 06:53:42 2016 +0900

    リファクタリング：使用していない✕✕パッケージを削除

commit df735e2e2b31df94d73ad134fa02692996e3ad9d
Author: kyoh86 <[email protected]>
Date:   Tue Nov 22 05:09:27 2016 +0900

    functions 再整理 (#42)

기쁘고 축하할 만하다.git rebase -i의 편집 상세 정보는 많은 사람들이 다른 문장에서 총결하였다.
http://qiita.com/umanoda/items/93aec41213f8e3ce14c8

과거의 약속을 다시 시작하고 싶어요.

그럼, 귀사는 현재 또 대량의 와이프 커미션을 가지고 있습니다.

$ git log

commit eb8b87a08098fc2fd7df9805970dd197ab850447
Author: Kyoichiro Yamada <[email protected]>
Date:   Tue Sep 27 21:52:57 2016 +0900

    fix

commit 61a476ba015556e167a46c3e29fcada60c510e9b
Author: Kyoichiro Yamada <[email protected]>
Date:   Tue Sep 27 21:48:03 2016 +0900

    fix

commit c2df90e8bc50446b736249ecaaac89f2c4c4dc9e
Author: Kyoichiro Yamada <[email protected]>
Date:   Tue Sep 27 21:44:01 2016 +0900

    fix

commit 37d070c710f4df384686a27a99b9a2e9dcf84610
Author: Kyoichiro Yamada <[email protected]>
Date:   Tue Sep 27 21:41:06 2016 +0900

    fix

commit b3293ccd4420938941843aa70d4b85d5ac4f3acc
Author: Kyoichiro Yamada <[email protected]>
Date:   Tue Sep 27 21:40:45 2016 +0900

    fix

commit 490e1c0c46b67594aee31e38fcb28076ed6c1fdb
Author: Kyoichiro Yamada <[email protected]>
Date:   Sun Sep 25 16:35:56 2016 +0900

    fix

commit df735e2e2b31df94d73ad134fa02692996e3ad9d
Author: kyoh86 <[email protected]>
Date:   Tue Nov 22 05:09:27 2016 +0900

    ◯◯機能の実装 (#43)

그럼, 답장할까요? 그렇게 생각하지만 이번에 어떤 위원이 무슨 짓을 했는지 아무 말도 하지 않았어요.
때리고 싶은 거예요?내가 때려줄게.git reset에서 되돌려받을 과거 제출을 지정합니다.
이 목적에 있어서 틀린 것을 사용하지 않도록 주의하십시오--hard.

$ git reset df735e2e2b31df94d73ad134fa02692996e3ad9d # ← "◯◯機能の実装 (#43)" のコミットハッシュ

이것은 과거에 자신의 어리석은 약속이 없었다는 것을 의미한다.
그러나 --hard 옵션을 사용하지 않았기 때문에 파일의 변경은 보류되었다.
나머지는 정확한 commiit를 생산하는 것이다.

$ git add foo.go
$ git add foo_test.go
$ git commit -m '△△機能の実装'
$
$ git rm bar.go
$ git rm -r baz/
$ git commit -m '□□機能の廃止'

같은 서류에 다른 목적의 변경이 섞여 있다!

상기 git reset가 필요한 상황에서 엄마입니다.
만약 단일한 서류에 서로 다른 목적의 변경이 섞여 있다면 어떻게 해야 좋을까.git add에는 -p 옵션이 있습니다.partial의p죠.
실행 후 대상 파일의 diff를 표시하고 필요한 변경 사항만 선택합니다 add.
자세한 내용은 여기를 참고하세요.
http://qiita.com/takke/items/3400b55becfd72769214

지점 이름에 wip이 있지...

누군가가 자신의 업무 지점에서 지점을 다시 자르는 비극을 최대한 피하기 위해
업무 지점 등에도 wip-xxxxx처럼 명확한 이름을 지어준다.(혹은 덧붙이는 것이 좋다)
그러나 일단 홍보를 제기하는 단계에 이르면 지점명wip-xxxxx은 통제하지 않는다.
"이미 특정 새로운 조건을 충족하는 브런치"라며 이름을 바꿔달라.

$ git branch -M feature-xxx
$ git push -u origin feature-xxx

# 作業ブランチを既にリモートにプッシュしていた場合、リモートのゴミも残さずキレイにしましょう。
$ git push origin :wip-xxxxx 

이 명령을 능숙하게 사용할 수 있다면 업무 중에 즐겁게 제출할 수 있다
끝나고'예뻐질 때'도 실수가 적어 쉽게 도전할 수 있다.

더 잘 일하기 위해서.

tig

git log와 git add -p는 편리하지만 가려운 데가 곳곳에 닿지 않는다.
http://qiita.com/crifff/items/1abf08bca4ce51db4775를 사용하면 그 근처가 편해요.
상세한 상황은 이곳의 보도를 참고하시오.
tig
또한 이 글에는 언급되지 않았지만'tig 화면에서 선택한 제출한 해시 복사'키bind를 설정하면
특정한 제출이나 리베이스로 거슬러 올라가면 수월해진다.
~/.tigrc

# main viewの左端にコミットIDを表示する
set main-view = id:width=12 date author commit-title:graph=yes,refs=yes
# デフォルト
# set main-view = date author commit-title:graph=yes,refs=yes

# 水平分割したウィンドウの下画面サイズを % で指定（行数指定も可）
set split-view-height = 80%

# Shift-Cで、選択行のコミットのハッシュをクリップボードにコピー（macOS用）
bind main C !@git pbcopy %(commit)

작업용 분기 전환

자기가 쓰는 일의 가닥을 용도에 맞게 짜다.
그래서 무엇을 위해 준비한 지점인지 잊기 쉽다.fzf하고 peco 사용하세요.참조 가능http://qiita.com/suino/items/b0dae7e00bd7165f79ea
이것만을 위한 졸작인 분기 명세서를 쓴 당신https://fithub.com/junegunn/fzf/wiki/examples#git을 사용할 수도 있습니다.
function/checkout-git-branch.zsh

function checkout-git-branch() {
  git-branches --color --exclude-current \
    | fzf \
    | awk '{print $2}' \
    | xargs -r git checkout
}
autoload -Uz checkout-git-branch
bindkey '^xgb' checkout-git-branch
bindkey '^xg^b' checkout-git-branch
bindkey '^x^gb' checkout-git-branch
bindkey '^x^g^b' checkout-git-branch

끝맺다

어때?
진지한 사람, 진지한 사람이 읽으면 쓰러지거나 욕하는 소리가 나는 기사다.
끊임없이 메일에 매진하고 정중하게 메시지를 쓸 순 없어... 나 같은 사람을 도울 수 있다면 좋겠다.
디버깅을 정확하게 활용하는 것이 가장 좋다고 확신할 수 있다.
팀원 중 엄격한 사람이 있고 진지한 사람이 있다면 고의로 잘못된 길을 걷지 말고 모두가 보조를 맞추어'올바르게 운용'하도록 주의해야 한다.