지금까지 기릿 조작은 모두 SourceTree를 사용했기 때문에 지령으로도 기릿을 조작할 수 있다고 생각했고, 조사를 많이 해서 기사로 쓰려고 했다.

Giit 창고 만들기

Git로 관리하려는 디렉토리에서git init 명령을 사용합니다.

$cd Gitで管理したいディレクトリへのパス  // ディレクトリに移動
$git init  　　　　　　　　　　　　　　 // 移動したらgit initコマンドでリポジトリを作成

이렇게 해서 이 디렉터리는 Giit에서 관리한다.

Giit 웨어하우스 상태 확인

Git 창고가 완성되었으니 서류를 제작하고 편집합시다.
디렉터리에test가 있습니다.txt라는 파일을 만듭니다.

$echo 'Hello, Git!' > test.txt
$cat test.txt
Hello, Git!

디렉터리 내의 상태가 계속 변경되며git status 명령을 통해 상태를 확인할 수 있습니다.

$git status

커밋

로컬 환경에서 파일을 관리하는 데는 다음과 같은 세 가지가 있다. (그림1)

작업 디렉토리
현재 편집된 파일 또는 디렉토리의 위치 저장

제본 구역
파일을 제출하기 전에 수정된 위치를 잠시 등록합니다
여기에 추가된 파일은 다음 제출 시 창고에 로그인됩니다

.

로컬 웨어하우스
원격 웨어하우스에 등록

그림 1 로컬 환경에서의 파일 관리
이 그림에서 알 수 있듯이 작업 목록의 수정 내용을 창고에 등록하려면 다음과 같은 절차가 필요하다.
[제출 전 단계]
1.dd 명령으로 제본 구역에 변경 내용을 잠시 등록(제본)
2.commiit 명령을 통해 창고 제출

$git add test.txt  // ファイルを指定してステージング
$git commit

뮤지컬이 필요한가요?

실제로 우리는 위의 절차에 따라 제출한 것이니 한꺼번에 제출하면 되지 않겠습니까?그렇게 생각할 거야.
하지만 보람은 있다.
<예>
예를 들어 "사용자가 로그인한 기능을 수정할 때 로그인 화면의 디자인까지 수정했다."
이 경우 디버깅을 하지 않으면 모든 변경 사항이 창고에 제출되어 저장됩니다. (그림 2 왼쪽)
이 예와 같이 한 번의 수정 기능과 디자인의 제출은 이후 변경점의 차이를 재평가할 때 기능의 수정과 디자인의 수정 등 여러 의미를 포함하는 변경점이 혼합되어 나타난다.제출 메시지는'로그인 기능의 변경'처럼 한쪽의 변경만 언급해 이후의 혼란을 초래할 수 있다.
호치키스를 사용하면 연관성이 강한 변경점을 종합하여 각 변경 내용을 디버깅할 수 있다
그림2에서 보듯이 한 번의 제출은 관련성이 강한 제출만 한데 모아 축소하고 가능한 한 다른 곳에 미치는 영향을 억제하며 고장의 원인이나 변경을 쉽게 확정하거나 취소할 수 있다.

그림2 장정시 여부의 차이
다시 공부해 보니 좋은 이유가 있어서 이렇게 만든 것 같아요.

참고 문헌

서적: "엔지니어의Git교과서 실천에서 사용! 버전 관리와 팀 개발 기법"
이번 기사는 여기까지입니다. Giit에 관해서는 기사 쓰는 것을 계속 배우고 싶습니다.
잘못된 점과 이해가 부족한 점을 지적해 주시면 다행입니다.