1. Git과 Github의 차이를 알고, 기본 개념에 대해 이해 할 수 있어야 한다.
2. Git의 영역과 기본 명령어에 대해 설명할 수 있다.
3. 페어와 Simple Git Workflow 실습을 통해 협업을 할 수 있다.
- Git 기본
✔︎ 버전 관리
✔︎ 백업
✔︎ 협업
$git config --global user.name "사용자 이름"
$git config --global user.email "이메일 주소"
✔︎ 온라인 : Remote repository (원격 저장소)
✔︎ 로컬 : Work space (작업 공간), Staging area (스테이징 영역), Local repository (지역 저장소)
- Git Workflow
git init
: Git으로 파일 관리를 시작하는 명령어git config --global init.defaultBranch 변경할_브랜치_이름
: 기본 브랜치 이름 변경git branch -m 변경할_브랜치_이름
: 현재 위치하는 브랜치 이름 변경git init
입력을 통해 .git
디렉토리가 생성되었음.ls -al
명령어를 통해 .git 파일 존재 유무 확인git status
: 파일 상태를 확인하는 명령어Commit
과정을 거쳐 Tracked상태로 변환git add 파일_이름
: Staging area로 파일을 이동시키는 명령어git add .
: 현재 디렉토리 내 모든 파일이 Staging area로 이동시키는 명령어git rm --cashed 파일_이름
: Staging area에서 다시 workspace로 내리는 명령어git commit
: 파일을 Local repository 🌟 에 저장하고 버전을 기록하는 명령어git commit -m 커밋_메세지
: 커밋 메세지를 짧게 요약하여 한 줄만 작성git log
: Commit 내역 확인q
를 입력하여 빠져 나올 수 있음git push
: 작업물을 Remote repository 🌟 로 업로드하는 명령어git remote
: Remote repository와 Local repository 연결하는 명령어git remote --v
: Local repository와 연결된 Remote repository를 확인하는 명령어git remote add 원격_저장소_별칭 원격_저장소_URL
: 해당 URL Remote repository에 연결하는 명령어git remote rm 원격_저장소_별칭
: 연결한 Remote repository과 연결을 해제하는 명령어git push 원격_저장소_별칭 브랜치_이름
: 작업물을 업로드하는 명령어git clone 복사한_URL
: Remote Repository의 코드를 로컬로 복사해오는 명령어git pull 페어_원격_저장소_별칭 브랜치_이름
도 사용 가능
- Simple Git Workflow : Pair Programming
✔︎ get restore 파일_이름
: 변경 내용을 다시 되돌릴 수 있음
✔︎ get restore --staged 파일_이름
: 스테이징 취소
✔︎ git reset
: 커밋 취소 명령어
✔︎ git reset HEAD^
: 가장 최신 커밋 취소
※ HEAD3 = HEAD^^^, HEAD^ = HEAD~1 로 표현 가능
✔︎ git reset --hard
:
✔︎ git reset --soft
:
✔︎ git commit -a
: commit과 a를 동시 활용, 단 1번이라도 커밋된 적이 있었을 때 사용
ex) git commit -am "~"
✔︎ HEAD → main
의 의미
✓ main
: 해당 commit내역이 main브랜치 내에서 최신 commit임을 나타냄
✓ HEAD
: 여러 브랜치들 중 현재 작업 중인 브랜치
✔︎ fetch
: 가져올 때, push
: 내보낼 때
✔︎ Situation
: 서로 같은 이름의 파일을 수정하고 수정한 부분이 겹침 → 병합 과정 오류 발생 🔥
✔︎ hint에 있는 # merge, # rebase, # fast-forward only 3가지 방법으로 시도
① git config pull.rebase false
# merge
② git config pull.rebase true
# rebase
③ git config pull.ff only
# fast-forward only
✔︎ Conclusion
: git에서 제공하는 자동 병합(auto-merging)은 안되는 걸로.. 😹 일일히 수동 병합을 시켜줘야만 했다! 하지만 여기서 멈추지 않고 😎 왜 안되는지 이유를 구글링해서 결국 찾아냈다 🥹
✔︎ merge 두 가지 상황
✔︎ 서로 다른 파일
을 수정할 때 : 이상 없음!
✔︎ 서로 같은 파일
을 수정할 때 : 다시 두 가지 상황으로 나뉜다.
① 서로 같은 이름의 파일을 수정했으나 수정 부분이 다를 때
: 이상 없음!
② 서로 같은 이름의 파일을 수정했으나 수정 부분이 겹칠 때
: 충돌 발생!
따라서, 개발자가 직접 해당 부분의 소스 코드를 고쳐줘야 한다! 👨⚖️(땅!) 🧑⚖️(땅!)! 👩⚖️(땅!)!
☞ Git을 접하고 느낀 바는 어제 배웠던 Linux만큼 명령어들이 많지는 않지만, 개념적으로 확실한 이해를 바탕으로 상황들을 이해하가며 알맞는 명령어들을 적용시켜 활용해나가야 하는 프로그램이라고 느꼈다.
Work space, staging area, Local Repository, Remote Repository 등의 개념을 이해하고, add
를 통해 staging area에 넣고, commit
을 통해 Local Repository에 보내고, push
를 통해 Remote Repository에 보내고, pull
또는 clone
을 통해 Remote Repository에서 꺼내오는 등 전반적인 흐름에 관해서는 개념학습과 개인 및 페어와의 실습, 실시간 라이브세션을 통해 어느정도 숙지가 되었으나,
Untracked, Tracked, Unmodified, Modified, Staged 등 파일의 상태와 연계하여 이해하는 부분은 아직 미흡하다 느껴졌다. 여러 번 반복 학습을 통해, 프로그램 내에서 어떤 명령어를 쳤을 때 git이 대답하는 의미가 무엇인지 알아내고 오류가 발생했을 때 해결해나가는 등의 학습은 나름 흥미로울 것 같다.
무엇보다도 오늘 페어와 함께 Git Workflow에 임하며 정말 큰 도움이 됐다. 서로의 Local Repository와 Remote Repository를 통해 번갈아 파일을 수정하며 주고 받았고 특히, 일부러 충돌 상황(Conflict)을 발생시켜서 오류가 나타났을 때 오류 메세지를 해석해 방법을 구상하고 구글링을 통해 문제를 해결해나가는 과정은 쉽게 얻지 못하는 갚진 경험이라 생각됐다. 나중 취업 이후에도 일을 하다가 충분히 발생할 수 있는 상황이기에 더 그렇다. 🌟
오늘로 워밍업 단계는 끝났다. 🔥 다음주부터 Java의 세계가 시작되는데 마음 단단히 먹고 주말동안 잘 충전하여 달릴 준비를 마칠 수 있도록 하겠다! 😤
・ JAVA
・ 변수, 타입, 문자열
・ 연산자 & 콘솔 입출력