[Git] iOS앱스쿨3기 Git 특강

Boogios·2023년 6월 26일
0

[Git]

목록 보기
3/3
post-thumbnail

iOS 앱스쿨 3기 Git 특강 내용 정리


시작하기전에!

이번 요약은 본 특강 내용의 모든 내용을 정리해둔것이 아닌 내가 처음알게된것들, 잘 쓸거같은 명령어들, 헷갈렸던 부분들을 정리해두기 위해 쓰는 글이다!

git restore --staged <"file">

Staging Area에 있는 파일들의 변경 히스토리를 다시 내려줄 수 있음!

git commit --amend

커밋 내용, 메시지 수정 가능한 메시지, push 전에만 가능하다!
만약, 푸쉬를 했다면 git push -f로 강제 push 해야됨

Commit 템플릿 생성하기

commit convention을 정해서 터미널창에서 보여줄 수 있음!
vi .gitmessage.txt // 템플릿 파일 생성
파일 내용 작성 후 저장
git config --global commit.templete ~/.gitmessage.txt // 모든 프로젝트에 적용
git config --list를 통해 템플릿이 잘 등록되었는지 확인 가능함
커밋 템플릿 제거하는 명령어는? git config --unset -global commit.templete

Commit 메시지 규칙

Karma 방식 참고 (http://karma-runner.github.io/6.4/dev/git-commit-msg.html)

보안 관련 중요한 파일

Xcode에서 새 파일 생성 - Configuration Settings File 생성한다
관리해야할 키 값들을 정의해준다!
~~.xcconfig 이런 양식들을 안올라가도록 한다
다음과 같이 gitignore에 추가한다*.xcconfig

.gitignore에 추가했는데도 변경사항으로 잡힐 경우

git rm -f --cached (파일명)
Working Directory에서 파일을 유지한 채 Git에 올라간 파일을 제거하기 위한 명령어

이전 커밋으로 돌아가기!

git reset {해시값}
하면 이전에 커밋한것들이 다시 Working Directory로 돌아감

git reset --hard 변경사항을 아예 날려버림

git reflog 지금까지 사용한 Git 명령어들의 History를 보는법

Reset을 되돌리기!
git reset --hard {커밋 명령에 대한 해시값}
리셋하기 전 상태로 돌아갈 수 있음
git reflog를 해서 reset했던 명령에 대한 해시값을 가져온다!

reset했던것도 기록하고 싶다? git revert

reset하는것과 동일하지만 기록이 남냐 안남냐 차이일뿐!

브랜치 병합하기

GitHub를 통한 Merge
3가지의 방식의 Merge를 제공함
1. Create a merge commit - 커밋했던 것들이 쌓이고 마지막에 머지했다는 커밋이 남게됨

  1. Squash and merge - 커밋했던 것들을 하나의 커밋으로 정리해서 Merge됨

  2. Rebase and merge - 커밋했던 것들을 그대로 Merge됨

가장 많이 쓰는 방식이 있다기보단 필요에 따라 팀원들과 상의해서 정해야함

가장 중요하다고 생각하는 명령어 git rebase!!!

Conflict가 날 경우!
C가 작업한 애용도 유지하면서 내가 작업한 것을 뒤에 붙여야 하는 경우
git rebase {베이스를 맞춰야하는 브랜치}

rebase를 하면 커밋들의 해시값이 변경된다.
Remote에 올린 커밋 로그와 해시값이 다르면 강제 푸쉬가 필요함

Conflict

동일한 파일을 수정하면 깃이 어떤걸로 합쳐야할지 몰라서 Conflict가 난다
git status를 통해 어디서 Conflict가 났는지 확인 가능

open -a Xcode {Conflict가 발생한 파일 경로} 로 파일을 열 수 있다.
코드 수정을 한 다음에 git add .를 통해 수정사항들을 Staging Area로 이동하고
git rebae --continue를 쳐서 리베이스를 계속 진행시킴!
계속 처리해주면된다!

브랜치 이동 git switch {브랜치명}

브랜치 이동한다!

커밋을 하지 않고 변경 사항을 저장하고 싶다면? git stash

작업도중에 다른 브랜치로 이동해서 코드를 봐줘야할 경우
git stash
변경사항을 저장을 해줌
git stash list 를 치면 스택구조로 보여준다
가장 최근에 저장한 내용을 다시 불러오려면

git stash pop - 가장 최근 저장 내용을 제거하면서 불러옴
git stash apply - 저장 내용을 그대로 냅두고 가장 최근 내용을 가져옴

git stash drop - 가장 최근 저장 내용을 제거
git stash clear - stash list 모두 제거

git stash apply stash@{0} - 특정 저장 내용으로 돌아가고 싶을 경우

브랜치 전략 - GitFlow

이것도 커밋처럼 일관되게 하는것이 좋다! 미리 정하는 것이 필요함!!
브랜치들을 미리 정해주면 코드 품질을 보장하고 버그를 조기에 제거하는데 도움이 된다!
코드 스타일들을 일정하게 해준다!

하지만, 개발 속도가 늦어질 수 있다! 리뷰 과정에서 특정 개발자의 Micro Managing이 발생함
어느정도 프로젝트가 있고 주니어 개발자가 많은 경우에 유용하다!

브랜치 전략 - Trunk-based

하나의 브랜치를 잘 관리하자!
하나의 기능을 개발하고 바로 main에 머지시키는 방식
빠르게 개발할 수 있음, Feature 브랜치에서 많은 테스트가 필요함
숙련된 시니어 개발자가 주로 작업을 하거나 빠른 작업이 필요할 때 유용하다!

Git 명령어 단축키

open ~/.gitconfig를 통해 파일을 열어서 명령어를 작성하여 사용가능함!

Github에 있는 내용을 로컬로 가져오기 fetch vs pull

git fetch
로컬에 있는 HEAD는 그대로 두고 서버에 있는 히스토리를 가져옴

git pull
모두 가져옴!

Pull Request

변경된 소스코드는 적게!! 변경 사항에 대한 설명은 자세하게!!!

만약, 막 1,000줄짜리 코드의 변경사항들을 PR 요청하면 너무 오바다..!
리뷰의 퀄리티도 낮아지도 시간도 너무 오래걸림

그래서!
PR은 최대한 하나의 기능만 들어가도록 쪼개서 보내는 것이 좋다!
브랜치에서 작업을 하다가 너무 길어질거같으면 브랜치를 하나 더 쪼갠다!

이슈 관리

꿀팁! PR Description에 close #{이슈번호}를 적어놓는다면 PR과 이슈가 자동 연동됨
close #960 이런식으로!

profile
iOS Developer

0개의 댓글