개발자라면 누구나 깃은 할줄 알아야 하는 거 아니야?
라는 말을 거의 모든 커뮤니티나.. 책에서 봐왔던 지난 2년... 근데 나는 항상 생각했다.
난 아직 혼자서 배우는 단계인데 굳이 깃을 할 줄 알아야 하나?
근데 해야할 것 같다. 이제 슬슬 다른 사람들과 코드를 공유하고 내 생각을 비교하기 위해서 코드를 업로드 해놓고 관리할 곳이 필요해졌기 때문이다. 코드를 카카오톡으로 주고 받을 순 없잖아 '0'...
GIT
Git은 코드 버전관리 프로그램이다.
그렇다면 버전관리란?
우리가 대학교 과제를 하면서 진짜 진짜 진짜 최종본.pdf 이런거 많이 해봤잖아... 하지만 이렇게 코드를 관리하게 되면
파일의 어떤 내용이 업데이트 됐는지 알 수 없다.
따라서 Git으로 버전관리를 함으로서 파일의 변화를 시간별로 나누어서 버전 별로 정리해 놓을 수 있게 됐다!
Git으로 할 수 있는 것들
1. 코드의 수정 내역 확인
2. 문제 발생시 이전 내역으로 돌아갈 수 있음
3. 코드를 공유함으로써 협업을 할 수 있음
4. 다른 컴퓨터에 작업물을 보낼 수 있음
Git의 역사
깃을 만든 사람은 바로 리누스 토발즈(Linus Torvalds)라는 사람이다.
리누스 토발즈는 리눅스(Linux)라고 하는 운영 체제를 만든 사람인데, 리누스 토발즈는 리눅스를 만든 이후에 BitKeeper라고 하는 툴(Tool)로 리눅스의 각 버전들(ver1, ver2, ver3 ...)을 관리하고 있었다.
그런데!! 리눅스 커뮤니티의 개발자 한 명이 BitKeeper의 내부 동작 원리를 분석하려고 했던 일을 계기로 리눅스 커뮤니티와 BitKeeper 측의 사이가 틀어지게 되었다 ㅠ... 이때문에 리눅스 커뮤니티 측에 대해서 BitKeeper는
유료화되었고, 리누스 토발즈는 BitKeeper를 대신할 다른 버전 관리 시스템을 찾아보게 됐다.
하지만 자신의 마음에 드는 버전 관리 툴을 찾지 못했고, 그래서 리누스 토발즈는 본인이 직접 버전 관리 프로그램을 만들어버렸다. 지린다... 이렇게 만들어진 버전 관리 프로그램이 바로 깃!!
깃은 설계 및 제작될 당시에 여러 목표를 가지고 제작됐다.
1. 빠른 속도 단순한 디자인 비선형적 개발 지원
2. 완전 분산형 시스템 리눅스와 같은 거대한 프로젝트도 속도 저하의 문제없이 관리할 수 있는 시스템
깃은 버전 관리(Version Control), 협업(Cooperation)에 필요한 여러 요소들이 고려되었기 때문에, 사용성이 굉장히 좋은 프로그램이 될 수 있었다.
Git의 의미
"""
깃은 당신의 마음에 따라 그 어떤 것으로도 해석될 수 있습니다.
1. 유닉스 커맨드에서 사용되는 명령어 이름을 제외한 랜덤한 알파벳 3글자의 조합
2. 멍청하고 단순한(이런 특성을 지닌 아무 단어로 해석되어도 좋다는 의미)
3. global information tracker의 약자
4. goddamn idiotic truckload of sh*t 이라는 욕설의 약자
"""
출처 : https://ko.wikipedia.org/wiki/%EA%B9%83_(%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4)
가공자 : hwany
GIT 개념
1. Repository (저장소) : 프로젝트 디렉토리의 버전을 관리하는 공간이다.
프로젝트 디렉토리 내부에 ~~~.git 디렉토리가 Repository이다. (평소엔 숨겨져있다.)
2. Commit (커밋) : 프로젝트 디렉토리의 모습을 하나의 버전으로 남기는 과정 및 그 결과물
*** 커밋이 저장되는 곳이 레포지토리이다!
Repository 만들기
mkdir directoryName # 프로젝트 디렉토리 생성
cd directoryName #프로젝트 디렉토리로 이동
git init # 경로에 비어있는 Repository 생성
Commit 하기
- directoryName 폴더 내부에 커밋을 할 파일을 올려놔야 한다. (License, calculator.py 파일을 올린다 가정)
1. 깃에게 커밋한 사람을 알려주기
### 깃에게 커밋한 사람을 알려주기
git config user.name "hawny" # 이름설정
git config user.email "lopahn2@gmail.com" # 이메일 설정
### >>> 커멋시 이름과 이메일주소도 함께 저장됨2. 커밋 메시지 남기기
# commit 메시지 남기기
git commit -m "commit 관련 메시지입니다."
그런데! 이렇게 하면 파일의 상태가 tracked 이 아닌 untracked 상태일 것이다. 우리가 어떤 파일을 커밋할 것인지 깃에게 알려주지 않았기 때문이다!!
3. add 해주기
# staging place에 올려주기
git add calculator.py
git add License4. 다시 커밋해주기
git commit -m "commit 관련 메시지입니다."이렇게 하면, root-commit이란 메시지와 함께 결과창이 뜰 것이다.
***root-commit : 첫 번째 커밋
정리!
1. 처음으로 커밋하기전 사용자이름과 이메일주소 설정해줘야함
2. 커밋메세지를 남기기 (옵션 -m)
3. 커밋할 파일을 git add로 지정해주기
Git의 작업영역
Git은 사실 하나의 작업공간에서 파일을 업로드 하지 않는다. add를 해주고 커밋을 해주어야 repository에 업로드 되는 이유가 이때문이다..! 차근차근 알아보자.
1. Working Directory : 작업을 하는 프로젝트 디렉토리.. 위의 예시에선 directoryName이 되겠지?
2. Staging Area : git add를 한 파일들이 존재하는 영역이다. 커밋을 하게되면 이 영역의 파일들만 커밋된다!
3. Repository : Working Directory의 변경 이력들이 저장되있는 영역, 즉 커밋들이 저장되는 영역
정리!
working directory에서 뭔가 작업을 하고, 작업한 파일들을 git add 해주고,
커밋을 하면 staging area에 있던 파일들의 모습이 스냅샷(snapshot)처럼 이 repository에 저장됨
working directory에서 A.txt 파일과 B.txt 파일을 작성하고
git add A.txt와 git add B.txt를 실행해서 A.txt, B.txt 둘다 staging area에 올렸다.
그 다음 git commit -m "Ver_1"를 실행해서 staging area에 있는 파일들을 가져와 커밋으로 남기면 위와 같은 상태가 된다.
그렇다면, 원하는 파일만 commit 하고싶다면 어떻게 해야할까?
이전 그림에서 작업을 좀더 하고 나서의 모습이다.
working directory에서 A.txt 파일 내용에 Python~이라는 단어를 추가, B.txt 파일 내용에 Morning!이라는 단어를 추가함.
그런데 이번에는 git add B.txt만 실행해서 B.txt 파일만 staging area에 업로드 했다.
그 다음 git commit -m "Ver_2"로 두 번째 커밋을 했다.
이전 그림과 다른 점은 A.txt는 staging area에 올리지 않고, B.txt만 staging area에 올렸다는 것.
그랬더니 지금 repository에서 Ver_2 를 보면
A.txt는 staging area에 있던 모습, 그러니까 수정하기 이전의 모습이 Ver_2 커밋에 반영되었고
B.txt도 staging area에 있던 모습, 하지만 A.txt와는 달리 수정한 이후의 모습이 Ver_2 커밋에 반영되었다!
A.txt, B.txt 둘다 working directory에서 수정했다는 사실은 같지만, staging area에 올렸는지 여부에 따라 그 최신 모습이 커밋에 반영되는지가 달라지는 것!
즉 원하는 파일만을 repository에 올리기 위해 staging area가 존재하는 것이다!
참고: working directory는 working tree라고 하기도 하고, staging area는 index라고 할 때도 있다.
GIT Add
**git status : 깃이 인식하고 있는 프로젝트 디렉토리의 현재 상태를 보여줌
1. 폴더 업로드하기
mkdir metting-log
cd meeting-log/
touch day1
touch day2
cd ..
get add meeting-log/ # staging area에 폴더자체를 올리기
2. 모든 파일 업로드하기
git add .
3. add 취소하기
git reset을 통해 staging area에 올렸던 파일을 내려줄 수 있다. (working directory에는 살아있다.)
git reset calculator.py***clean : 이전 커밋 이후 변경사항이 없다는 뜻!
GIT STATUS
Git에서 파일들은 크게 두가지 상태를 가진다.
- Untracked
- Tracked
그리고 Tracked 상태는 다시 3가지 상태로 나눌 수 있다.
- Staged
- Unmodifed
- Modifed
Untracked
파일이 Git에 의해서 변동사항이 전혀 추적되고 있지 않는 상태라는 뜻이다.
파일을 한번도 git add 해주지 않았다면 Untracked 상태이다.
Tracked
파일이 Git에 의해 변동사항이 추적되고 있는 상태라는 뜻이다.
1) Staged : 파일이 수정되고, staging area에 있는 상태. git add를 해준 후라면 이 상태.
2) Unmodifed : 현재 파일이 최신 커밋의 파일과 전혀 차이점이 없는 상태. 커밋을 한 직후에 working directory의 모든 파일이 이 상태이다.
3) Modifed : 최신 커밋의 모습과 비교했을 때 조금이라도 바뀐 내용이 있는 상태
Add the file : Untracked 상태의 파일을 처음으로 git add 해주면 Staged 상태.
Edit the file : 최신 커밋과 비교했을 때 차이가 없는 Unmodified 상태의 파일의 내용을 수정하면 Modified 상태.
Stage the file : Modified 상태의 파일을 git add 해주면 Staged 상태
Remove the file : 파일을 삭제하면 당연히 Git에서 인식하지 못한다.
Commit : 커밋을 하면 staging area에 있던 파일들이 커밋에 반영되고, 이제 모든 파일들은 최신 커밋과 차이가 없게 되니까 Unmodified 상태.
커맨드 정리
git init : 현재 디렉토리를 Git이 관리하는 프로젝트 디렉토리(=working directory)로 설정하고 그 안에 레포지토리(.git 디렉토리) 생성
git config user.name 'codeit' : 현재 사용자의 아이디를 'codeit'으로 설정(커밋할 때 필요한 정보)
git config user.email 'teacher@codeit.kr' : 현재 사용자의 이메일 주소를 'teacher@codeit.kr'로 설정(커밋할 때 필요한 정보)
git add [파일 이름] : 수정사항이 있는 특정 파일을 staging area에 올리기
git add [디렉토리명] : 해당 디렉토리 내에서 수정사항이 있는 모든 파일들을 staging area에 올리기
git add . : working directory 내의 수정사항이 있는 모든 파일들을 staging area에 올리기
git reset [파일 이름] : staging area에 올렸던 파일 다시 내리기
git status : Git이 현재 인식하고 있는 프로젝트 관련 내용들 출력(문제 상황이 발생했을 때 현재 상태를 파악하기 위해 활용하면 좋음)
git commit -m "커밋 메시지" : 현재 staging area에 있는 것들 커밋으로 남기기
git help [커맨드 이름] : 사용법이 궁금한 Git 커맨드의 공식 메뉴얼 내용 출력
GIT_HUB
Git hub란 간단히 말해 백업 컴퓨터를 지원해주는 서비스이다.
git vs github
git은 버전관리를 해주는 프로그램
github는 git으로 만든 프로그램을 올려둘 수 있는 서비스(원격 저장소)
remote vs local
깃허브의 repository : remote repository
내 컴퓨터의 repository : local repository
1. Local을 Remote에 업로드
git remote add origin (githubAddress)
git push -u origin master
# username과 비밀번호 입력2. Local에서 바뀐 내용을 Remote에도 반영하기
cd directoryName
git add .
git commit -m "~~"
# directoryName 위치에 있는 staging area에 있는 파일 커밋
git push
# local repository의 내용을 remote repository에 그대로 커밋
3. Remote에서 바뀐 내용을 Local에도 반영하기
git pull
# remote repository의 내용 그대로 local에 커밋
Remote Repository를 만드는 이유!!
1. 안전성. 백업파일을 만드는 것이라 생각하면 됨
2. 다른 개발자들과의 협업이 get push와 get pull을 이용해서 가능해짐
그러면,,, 아무나 push를 해서 내 깃헙을 망칠 수 있는 거 아닐까?
그건 아니다! git push는 remote repository의 주인만 할 수 있다.
그러면,,, 협업을 못하는 거 아닐까?
그것 또한 아니다!
PUSH 권한 주기
GitHub 페이지에서 자신(codeitTeacher)의 리모트 레포지토리인 MathBox의 설정을 살펴보자.
상단의 여러 탭 중에서 Settings 탭을 클릭하면, 그 다음 화면 왼쪽의 Manage access 탭을 클릭하면!
화면에 PUBLIC REPOSITORY라는 표현이 보일 것이다! 이 말은 지금 누구나 제 리모트 레포지토리의 주소만 알면, 그 내용을 살펴볼 수 있다는 뜻! 그리고 누구든지 제 레포지토리를 자기 컴퓨터로 가져갈 수도 있다는 뜻이기도 하다. 그리고 자기 컴퓨터에서 추가 작업을 할 수도 있겠지?
하지만 그래도 본인이 아닌 이상 그 내용을 git push할 수 없기 때문에 리모트 레포지토리에 반영할 수는 없다.
자 이제 설정을 바꾸어 보자
화면 하단에서 Invite a collaborator 버튼을 누르면 collaborator를 초대한다.
다른 사용자를 collaborator로 초대하면, 그 사용자는 제 리모트 레포지토리에 git push할 수 있는 권한을 가질 수 있다!
그 다음 뜨는 창에서 위 그림과 같이 GitHub의 codeitDeveloper라고 하는 사용자를 검색해서 클릭 !
(codeitDeveloper는 초대하고자 하는 사용자이다!)
그리고 codeitDeveloper에게 “내 레포지토리의 collaborator가 되어달라”는 초대장을 보내면.. !
그럼 이제 codeitDeveloper에 대해서 Pending invite 상태가 된다.
그럼 이제 상대방은 초대장을 받게 된다.
여기서 View Invitation 버튼을 클릭해서 초대장을 살펴보면
그럼 이렇게 내가 codeitDeveloper를 초대한 내용을 확인할 수 있다.
codeitDeveloper가 Accept invitation 버튼을 클릭하면 codeitDeveloper는 codeitTeacher가 소유한 MathBox 레포지토리의 collaborator가 된다.
그리고 다시 원래 codeitTeacher 계정에서 확인해보면 codeitDeveloper가 정말 collaborator가 된 것을 확인할 수 있는다..!
이제 codeitDeveloper는 MathBox 레포지토리를 자신의 컴퓨터로 가져가서 수정한 후 git push를 해서 저의 리모트 레포지토리를 수정할 수 있다.
정리!!
원칙적으로 자신의 리모트 레포지토리에는 자신만 git push를 할 수 있다.
만약 다른 사용자도 git push를 할 수 있게 해주려면 그 사용자를 해당 리모트 레포지토리의 collaborator로
지정하면 된다.
다른 프로젝트 가져오기
1. 메인화면 -> explore에서 찾아보거나 검색창에서 프로젝트 검색
2. 우측에 clone or download 눌러서 주소 복사
3. 터미널로 이동
4. 프로젝트 디렉토리 변경
5. git clone (복사한 주소) .
이런식으로 하면 된다. 참 쉽죠잉?
참고
.을 붙이는 이유 : 폴더에 클론이 생성됨
clone : 깃허브 프로젝트의 레포지토리를 그대로 복제
깃헙 사용법 정리를 하려니.. 아는 것들을 최대한 정리해보려 했는데 역시 글로 쓰려니 어렵다.. 양이 매우 많아서 오늘 하루에 다 못끝낸 것이 조금 아쉽구만...! 내일도 일요일이니 내일도 열심히 해야겠다! 파이팅!
2021-09-11
'DevOps > Git' 카테고리의 다른 글
| 4. 커맨드 모음 (0) | 2021.10.01 |
|---|---|
| 2. 브랜치 다루기 (0) | 2021.09.26 |
| 1. Commit 다루기 (0) | 2021.09.21 |
| GIT 오픈소스 (0) | 2021.09.11 |
| 마크다운 사용법 (4) | 2021.09.05 |