1. 개념

1.1 버전관리 시스템 Git

Git은 코드 변경 이력을 저장하고 관리하는 버전 관리 시스템이다. 우리가 일반적으로 텍스트 에이터에서 사용하는 undo-ing 개념을 떠올리면 쉽다.

• 코드 변경 이력을 저장하고 관리한다.
  • 이전 버전으로 돌아갈 수 있다.
  • 변경 사항을 쉽게 확인하고 비교할 수 있다.
• 파일을 백업한다.
• 다른 개발자와 협업이 가능하다.

1.2 Github와 Git의 관계성

Github는 Git으로 관리되는 파일들을 위한 저장소를 제공하는 클라우드 기반 서비스다.

• 코드 리뷰, 다양한 협업이 가능하다.
• 소스코드가 공개된 오픈 소스 기여가 가능하다.

1.3 Git Repository

Git Repository는 Git으로 관리되는 파일이나 폴더를 저장하는 저장소다.

Git에는 두 가지 종류의 저장소가 있다. Local Repository는 내 컴퓨터에 있는 개인 전용 저장소이고, Remote Repository는 여러 사람이 함께 공유 가능한 온라인 서버 상의 저장소다.

1.4 우분투에 Git 설치하기

환경설정

사용자 정보

• 사용자 이름과 메일주소 초기 설정하기
• --global 옵션 설정을 사용하면 사용자 홈에 저장되어 한 번만 입력해도 된다.

nano 에디터 설정

• merge commit 확인 메시지를 위한 에디터를 nano로 변경하자. vim은 다소 어려울 수 있다.

* Git 초기 설정을 위한 가이드

CLI로 Git 설치하기

• sudo apt install git
• git --version : 터미널에서 git이 설치되었는지 확인할 수 있다.

1.5 CLI 환경에서 git 명령어 사용하기

• Fork : 다른 유저의 원격 저장소를 나의 원격 저장소로 복제해오는 Github의 기능이다. 코드를 수정하고 PR(Pull Request)를 보내서 변경사항이 있음을 알릴 수 있다.
• git clone <주소> : 로컬 저장소로 복사해온다.
• git status : 로컬의 staging area, untracked files 목록을 확인한다. 다음 명령어가 모호하면 이 명령어를 통해 파일의 상태를 파악하고 참고할 수 있다.
• git restore --staged <파일이름> : staged 상태를 잃어버린다.
• git restore <파일이름> : 수정을 잃어버린다. 둘 다 모두 한 단계식 잃어버린다.
• git add <파일이름> : staging area로 올린다.
• git commit -m 'message' : 로컬 저장소로 commit해서 원격 저장소로 올릴 준비가 된 상태다.
• git reset HEAD^ : 바로 전에 commit한 파일을 되돌린다.
• git log : 원격 저장소에 commit한 내역을 확인할 수 있다.
• git pull <pair> <main>
• git push <origin> <branch> : 원격 저장소로 commit 사항을 업로드한다.
• git init : 내가 만든 디렉토리를 git의 관리하에 두기 위한 초기명령어다.
• git remote add
• git reset HEAD <file>
• git checkout -- <file>

1.6 Git의 세 가지 영역 및 상태

• committed : 커밋이 된 상태.
• modified : commit 이후에 수정이 일어난 상태. unmodified는 그 반대다. modified이면서 not staged일 수도 있고 staged일 수도 있겠다. unmodified도 결국은 tracked area다.
• staged : untracked file을 git add 명령어를 통해서 git의 관리 하에 두어서, commit이 가능한 상태다.

1.7 페어와 Git으로 협업하기

0. 코스 원격 저장소를 나의 원격 저장소로 포크한다.
1. git clone <주소> 포크해온 원격 저장소를 나의 로컬 저장소로 클론한다. 이 때, 터미널 창의 경로를 기억한다.
2. git remote add <nickname> <주소> pair의 원격 저장소와 연결한다. * 연결 확인 git remote -v
3. 페어가 코드를 수정해서 커밋한다.
   git add <파일이름> git add .
git commit -m 'message'
git push origin main
git log
4. 페어가 수정한 코드를 pull 해온다.
   git pull <nickname> main
5. 번갈아 가면서 해본다.
6. 연결 해제하기
   git remote remove <nickname>

충돌 발생 상황

페어가 나와 동일한 라인을 수정한 경우 auto-merging이 되지 않고 충돌이 생긴다. 충돌이 생기면 선택 가능한 4가지 옵션이 있다. 그 옵션을 선택해 충돌을 바로 해결하고 다시 커밋을 올린다.

• 페어와 내가 동일한 라인을 수정했다.
• 나는 로컬에 commit 올린 상태이고, 상대는 원격에 push를 한 상태다.
• 내가 페어의 코드를 pull 해오면 충돌이 발생한다.
• 이 때, 충돌을 해결하고 다시 commit - push를 올린다.
• 그럼 나의 충돌 전 커밋과 페어의 커밋과 merge 커밋이 모두 올라가게 될 것이다.

branch & merge

origin vs upstream

1.8 commit 메세지 작성법

2. 에러로그

나의 디렉토리를 만들어 원격 저장소에 연결하기

1. 먼저 Github에 새로운 Repository를 만든다.
2. 터미널 창을 열어 연결하고자 하는 디렉토리로 경로 변경을 한다.
3. 다음과 같은 명령어를 입력한다.

echo "# test3" >> README.md
git init
git add README.md
git commit -m "first commit"
git branch -M main
git remote add origin git@github.com:Leekyeongmi/test3.git
git push -u origin main

• 먼저 README 파일을 만들어 주고, git init 명령어를 사용하고, branch 관련 명령어를 사용하고, 그 다음 원격 저장소와 연결하고, README 파일을 commit 해 주었다.
• error : src refspec main does not match any : 왜 이런 오류가 떴을까? 브랜치 이름이 맞지 않았던 것 같다. master에 연결되어 있는데 main으로 push를 해주었던가, 하는 그런 이유였을 것이다.

3. 질문

Q1. git remote add로 다른 사람의 원격 저장소와 연결할 때.. 같은 저장소를 포크했을 때만 가능한가?

Q3. 로컬 저장소로 commit을 한 상태든 아닌 상태든 같은 라인을 수정한 페어의 코드를 당겨오면 충돌이 일어나나?

main과 master 기본 브랜치라고 생각해 주면 된다. 왜 이름이 다른가? master는 신분제도에서 따온 구시대적인 말이므로 main으로 바꿔 쓰는 추세이지만 여전히 예전 언어가 혼용되어 쓰이고 있다.

다운받는 프로토콜의 종류가 3가지가 있다고 생각하면 된다.

origin을 써야 하는 이유 : upstream 으로 할지 origin으로 할지...
다음 명령이 모호하면 git status라는 걸 써서 힌트를 얻을 수도 있겠구나?

manage access 서로 서로 권한을 가질 수 있다. pull/push가 될 수 있도록?

git kraken, smartgit, github desktop (gui로 볼 수 있는?)

서로 다른 부분이 있으면 충돌이 일어나므로 브랜치를 나눠서 다른 파일을 작업을 하는 것!

충돌이 일어나면 어떻게 잘 해결하느냐가 포인트가 될 거 같다.

명령어에서 master와 branch를 바꿔 쓰는데.. git pull shortname branch 여기에서도 master로.. 예시에서도? 이건 무슨 차이?

포크 하지 않은 코드도 clone 해 올 수 있는 걸까? 어떤 차이점이 있을까?

내 로컬 저장소에서 다른 사람의 저장소로 바로 push/pull 할 수도 있는건가? 그림에 보면 그렇다. 페어의 remote 저장소로 pull만 했었는데, push도 할 수 있는 거구나.