일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- Xcode
- IOS
- Swift
- enum
- 코딩테스트
- property
- Method
- initializer
- UIKit
- type
- Unicode
- Git
- Class
- 디자인패턴
- 이니셜라이저
- delegate
- Terminal
- tuist
- optional
- url
- struct
- 스위프트
- Foundation
- Protocol
- extension
- init
- instance
- String
- interpace
- initalizer
- Today
- Total
아리의 iOS 탐구생활
[Git] Basics, commit 본문
VSC(Version Control System) 이란?
서버에만 히스토리 정보가 있는 것이 아니라 모든 개발자들이 히스토리 정보를 가지고 있는 것을 말한다.
working directory
프로젝트의 파일들을 수정하는, 작업하고 있는 곳
staging area
어느 정도 작업하다가 버전 히스토리에 저장할 준비가 되어있는, 파일들을 옮겨놓는 곳
git directory
버전의 히스토리를 가지고 있는 곳
git init
Git을 초기화한다. 깃을 초기화하게되면 기본적으로 master branch로 설정된다.
rm -rf .git
숨겨진 깃 폴더를 삭제할 수 있다. 삭제하면 더이상 git 프로젝트가 아님을 확인할 수 있다.
git config --global alias.st status
명령어를 짧게 커스텀할 수 있다. 이제 git st만 작성해도 git status 명령어가 실행된다.
echo hello world! > a.txt
a.txt라는 파일안에 hello world! 라는 문자열이 적힌 파일을 만듬
git add 파일이름
commit
git add *.txt
확장자 .txt 모든 파일을 staging area로 올리겠다는 명령어
git rm --cached *
모든 파일을 staging area에서 내리겠다는 명령어
git add *
디렉토리에 있는 모든 파일을 staging area로 옮기겠다는 명령어
rm a.txt
a.txt라는 파일을 삭제한다는 명령어
git add .
모든 파일을 포함해서 staging area에 추가하겠다는 명령어
echo *.log > .gitignore
트레킹 하고 싶지 않은 파일들 깃과 깃허브에 올리고싶지 않은 파일들은 .gitignore에 모아둘 수 있다.
✍🏻 꿀팁들
CMD + K 를 누르면 터미널이 깨끗하게 청소된다.
간편하게 볼 수 있는 git stauts -s
git diff : 깃이 변경된 상세한 내용을 확인할 수 있다.
git diff —staged : 깃이 수정된 모든 내용을 상세하게 표시.
git config --global -e 열면 다음과 같이 나오는데
diff tool을 직접 정의해줄 수도 있다.
위 사진에서는 diff 툴을 vscode로 열고 이전내용과 수정된 내용을 열어준다는 설정이다.
수정된 사항을 메세지와 함께 커밋. git commit -m "메세지"
모든 수정된 파일을 메세지와 함께 커밋 git commit -am "메세지"
🔍 commit 참고사항
히스토리에는 어플리케이션을 조금더 세분화해서 기능별로, 작은 단위로 만들어 나가는 것이 중요하다. 커다란 코끼리를 히스토리에 한번에 넣기보다는 작은단위로 나누어서 히스토리에 저장하는 것이 좋다. 그렇다고 히스토리에 너무 의미가 없는 커밋1, 커밋2, 커밋2… 이런 식으로 작성하기 보다는 조금 더 의미있는 이름을 지정해서 저장하는 것이 중요하다. 프로젝트를 초기화하는 커밋하나, 로그인 서비스 모듈을 하나 만들어서 커밋, 그 다음에 UserRepository Module을 만들었다면 그것도 하나, 그다음에 웰컴페이지 커밋하나, 어바웃페이지 커밋하나, 이런식으로 작은 단위로 의미있는 이름을 지정해서 히스토리를 바라봤을 때 작업한 내용도 빠르게 확인해볼 수 있다. 그리고 내가 원하는 변경 사항을 빠르게 찾아서 자세히 확인해볼 수도 있다. 또 원하지 않는 커밋을 취소하기도 편리해진다. 보통 커밋의 메세지는 현재형으로, 그리고 동사로 만들어진다. init, add fix 이런 단어가 쓰여진다. 그리고 커밋을 할때 한가지 주의해야 되는 점은 커밋을 할때 내가 크레싱을 고쳤다고 하면 정말 그 고친 내용만 포함한 커밋을 만들어야지, 이왕 하는김에 다른 버그도 고치고 리팩토링도 하고 새로운 기능도 한번 넣어볼까? 하고 커밋을 하게되면 코드리뷰할때도 혼동이 오지만 히스토리를 바라볼 때도 너무 혼동이 오기 쉽다. 그래서 커밋 메세지에 맞게 해당하는 그 내용만 포함해서 커밋하는 것이 중요하다. 커밋은 너무 커도 문제지만 또 너무 작은 단위로 해나가도 좋지가 않다. 어느정도 의미있는 단위로 나누는 것은 실제로 프로젝트를 하면서 커밋을 해나가면서 조금씩 감을 쌓을 수 있다.
'GitHub > Git' 카테고리의 다른 글
[Git] Rebase를 활용하여 이전 커밋 수정하기 (0) | 2021.11.23 |
---|