Main Topic: Git & GitHub

---

한 주간 느낀 점

새로운 마음으로 시작한 첫 주이며 8월에 졸업을 한 뒤 무너진 생활 습관을 바로잡는 시작이었다. 이틀 연속으로 새벽 6시에 일어나 교육장으로 향하는 것은 생각했던 대로 힘든 일이었다. 다만 이제는 미룰 수 없고 타인의 도움을 받는 것이기에 고작 이틀이지만 열심히 나가 수업을 들었다. 이전에 배웠던 내용이고 적용도 해 보았던 내용이지만 체계적으로 다시 학습하니 그 중에서도 애매했던 개념들이 확실히 정립되었다.

정리

---

Git 기본 명령어

git add : 파일을 staging area에 추가
git commit -m : staging area의 변경 사항을 커밋
git log : 커밋 히스토리 확인
git log --oneline : 로그를 한 줄로 깔끔하게 보여줌
git switch : 브랜치 전환
git merge : 다른 브랜치를 현재 브랜치에 병함
git push : 로컬 변경 사항을 원격 저장소에 업로드
git clone : 원격 저장소를 복제해 로컬에 다운로드
git diff : 변경 내용을 비교
git reset : staging area 또는 commit 되돌림
git rm --cached 파일명 : 추적 중인 파일을 Git에서 추적 해제
git stash : 변경 사항을 임시로 저장

---

Linux 명령어

touch 파일명 : 파일 생성
mkdir 폴더명 : 폴더 생성
rm 파일명 : 파일 삭제
rm -r 폴더명 : 폴더 삭제
ls -a : 숨겨진 모든 내용까지 확인
ls -al : 숨겨진 모든 내용까지 세부정보 확인

---

Git log

git log --oneline --graph --decorate

--oneline : 세부사항 없이 깔끔하게 한 줄로 표현
--graph : 브랜치를 아스키 코드를 이용하여 일렬로 표현
--decorate : 색상 부여

---

Branch

Master 브랜치와 Main 브랜치

• 터미널에서 기본 값을 바꿔주어야 기본 브랜치의 이름이 master에서 main으로 변경
• 하지만 기존에 master로 생성한 기본 브랜치가 자동으로 main으로 변경되는 것은 아님
• 기존 master 브랜치를 명시적으로 main으로 바꾼다고 명령어를 입력해 주어야 함

브랜치 이름을 정하는 규칙

• feature/login : login 기능을 개발하는 브랜치
• fixed/login : login 기능을 수정하는 브랜치

---

Merge

master 브랜치에 병합하는 경우

• master 브랜치가 보통 배포되는 브랜치이기 때문에 가장 마지막으로 병합을 진행
• 이러한 이유로 보통은 dev(develop) 브랜치에 병합을 진행 후 테스트
• dev 브랜치에서 기능 별 브랜치를 뻗어 작업 후 dev에 병합하는 것

merge 후 브랜치의 취급

• 병합이 정상적으로 이루어졌다면 해당 브랜치는 필요없기에 삭제하는 것이 보통

Fast-Forward Merge

• master 브랜치에서 새로운 브랜치를 뻗었을 때
• 브랜치를 뻗은 시점 이후 master 브랜치에는 변함이 없고 이후 브랜치에만 수정이 있을 경우에 적용되는 merge 방법
• 단순 포인터만 이동해 브랜치 병합 진행

3-way Merge

• 두 브랜치가 서로 다른 변경이 있거나 충돌이 생길 경우에 적용되는 방법
• 충돌 없이 병합될 경우
  • 서로 다른 변경 사항들이 통합
• 충돌 발생 시
  • vim 또는 타 도구를 통해 충돌 해결
• 고려해야 할 것
  • 충돌 해결 후 반드시 add, commit을 진행해 변경사항을 저장해 주어야 함

---

GitHub

흐름

1. Workspace → Staging Area
   • git add
2. Staging Area → Local Repository
   • git commit
3. Local Repository → Remote Repository
   • git push
4. Remote Repository → Workspace
   • git fetch : 변경사항만 가져오기
   • git clone/pull : 변경사항을 commit해 가져오기
     • git clone 시의 폴더 이름은 레포지토리 이름을 따라감

---

Fork

• 타인의 GitHub 레포지토리를 복사해 내 레포지토리로 가져오는 것
• 내 레포지토리가 생성되면 clone이나 pull을 사용해 원하는 장소에 파일 다운로드
• 코드 수정 후 add, commit, push
• pull을 할 때 오류가 발생하는 경우

  1. 사용자가 원격 저장소의 dev 브랜치 pull

  2. 다른 사용자가 원격 저장소의 dev 브랜치에 수정 사항 반영

  3. 사용자가 파일 수정 후 원격 저장소 dev 브랜치에 push 요청

     → 오류 발생

  • 사용자가 pull한 사항과 이미 dev 브랜치의 상태가 다르기 때문에 오류 발생

    → 해결방법

  • git pull —rebase 사용

    • —rebase를 하면 원격 저장소 브랜치의 변경 사항 선 반영 후 사용자의 변경 사항 적용
    • 덮어씌우는 느낌

중요한 것!! 내가 수정한 부분은 나만이 수정했어야 함
그렇지 않으면 원본과 나의 복사본이 다른 부분이 수정되어 있기 때문에 오류 발생, git rebase를 통한 오류 해결 필요

---

Keep

시간표 자체에는 그래도 적응한 것 같다. 몸이 안 따라주거나 하지는 않아 다행이다.

Problem

문제사항은 아직까지 없다.

Try

아직까지는 소화하기 쉬운 내용들이기 때문에 틈틈이 이론 공부를 추가적으로 할 생각이다.

다음주 다짐

열심히 하자. 작심삼일이라면 3일마다 계획을 세우자.