2020/06/21 - [🗂️git] - [Git / Git Hub] 탄생배경 및 간단한 소개
2020/06/21 - [🗂️git] - [Git / Git Hub] Git의 기본
들어가기 전, Git과 Github계정이 이미 설치되어 있고 가입되어 있다는 가정하에 시작하겠습니다.
설치방법이나 가입방법은 유튜브나 네이버에 친절하게 설명된 컬럼이 많으니 참고하세요.
1. git init
git으로 버전을 관리하고 싶은 프로젝트에 git 저장소를 만든다.
$git init
2. git status
git이 버전관리 대상 파일들의 상태를 파악한다.
$git status
처음 git init 을 하게되면 master branch 로 첫번째 커밋을 가르키게 된다. 브랜치는 포인터다. 브랜치는 커밋을 가르킨다.
on branch master 는 현재 브랜치가 master 라는 뜻이며 untracked files 깃이 track 하고 있지 않은 파일들 이라는 뜻이다.
당연히 처음 init 하게 되면 그 프로젝트 안에 즉 workind directory (WD) 안에 있는 파일들을 트랙킹 하고 있지 않다.
브랜치(branch) : 브랜치는 커밋 사이를 가볍게 이동할 수 있는 어떤 포인터 같은 것이다. 기본적으로 Git은 master 브랜치를 만든다. 처음 커밋하면 이 master 브랜치가 생성된 커밋을 가리킨다. 이후 커밋을 만들면 master 브랜치는 자동으로 가장 마지막 커밋을 가리킨다.
git의 파일 상태
- untracked : git 이 file 을 추적하고 있지 않은 상태이다. git status 를 했을때 적색으로 나타난다.
- modified : git이 추적하고 있고(즉, 한 번 이상 커밋당한 상태의 파일), commit되었을 때 비교해서 수정되어 있는 상태. git status 했을 때 적색이며, git diff했을 때 고쳐진 부분을 볼 수 있다.
- unmodified : git 이 추적하고 있고(즉 한번 이상 커밋 당한 상태의 파일), 수정되지 않은 파일이다. git status 했을때 보여지지 않는다.
- staged : git 이 추적하고 있고, modified 당했으며, git add 로 commit 될 준비가 되어있는 상태이다.git status 했을때 초록색이다.
3. git add
파일을 staging area(index)로 추가시킨다. modified, untracked상태의 파일을 staged상태로 만들어준다. 즉 commit이 가능한 상태, commit이 되기 전 상태로 만들어준다.
$git add <파일이름>
$git add .
필자는 해당 WD 중 DI01_test 폴더를 add하겠다.
$git add DI01_test
$git status
다시 git status를 해보면 staging된 file들을 볼 수 있다.
4. git commit -m "message"
수정한 것을 커밋하기 위해 Staging Area에 파일을 정리했다. Unstaged 상태의 파일은 커밋되지 않는다는 것을 기억해야 한다.
Git은 생성하거나 수정하고 나서 git add 명령으로 추가하지 않은 파일은 커밋하지 않는다. 그 파일은 여전히 Modified 상태로 남아 있을 것이다. 커밋하기 전에 git status 명령으로 모든 것이 Staged 상태인지 확인할 수 있다. 그리고 git commit을 실행하여 커밋하도록 하자.
=>-staging area의 내용을 local repository에 확정 짓는다.
$git commit -m "변경된 메세지 내용을 입력"
git에서 커밋은 변경사항을 내 컴퓨터에 저장한다는 의미이다. git status 했을때 녹색인 파일들 즉 staged 상태의 파일들을 스냅샷을 찍어 저장한다. 즉 언제든지 돌아갈수 있는 상태로 만든다. 웬만하면 commit 된 상태는 복구가 가능하다.
또한 git add 명령을 실행했을 지라도 git add 명령을 실행한 후에 또 파일을 수정하면 파일의 상태는 Ustaged 상태로 나온다.
$git commit -am "변경된 메세지 내용을 입력"
git commit 명령을 실행할 때 -a 옵션을 추가하면 Git은 Tracked 상태의 파일을 자동으로 Staging Area에 넣는다. 그래서 git add 명령을 실행하는 수고를 덜 수 있을 것이다.
git log 명령어로 지난 commit이력을 확인 할 수 있다.
5. git remote / git push
push는 마지막으로 커밋한 사항을 git repository 에 올리겠다는 뜻이다. push가 안되면 원격 서버에 변경사항이 저장되지 않습니다. 다시말해, 프로젝트를 공유하고 싶을 때 remote 저장소에 Push할 수 있다.
git remote 명령어를 사용하면 현재 사용중인 Git 프로젝트에 연결된 원격 저장소를 확인할 수 있다. 연결된 원격 저장소의 단축이름(별칭) 을 보여준다. 원격 저장소를 clone한 경우 원격 저장소의 별칭은 자동으로 origin이 된다.
만약 원격 저장소 없이 개인의 PC에서 Git저장소를 만들어 작업하다가 다른 팀원들이 프로젝트에 참여하게 된 경우 협업을 위해 원격 저장소가 필요하게 될 것이고 작업중이던 Git 저장소를 원격 저장소로 추가해야 할 것이다. 원격 저장소에 연결하는 명령어는 git remote add [별칭] [원격 저장소 URL] 이다.
$git remote add [별칭] [원격 저장소 URL]
원격 저장소는 이미 만들어져 있어야 하며 해당 저장소의 URL이 필요하다.
필자는 github에 별도의 저장소를 추가했다.
다음과 같이 미리 HTTPS 를 복사해둔다.
필자는 origin이라는 별칭으로 remote했다.(git bash에서의 붙여넣기는 shift+insert이다.)
commit 한 내용을 remote repository에 push( 업로드 ) 해보자.
$git push [별칭][branch]
처음 push를 했다면, 계정 정보 확인을 위해 Github 이메일과 비밀번호를 입력하라고 한다.
비밀번호를 타이핑할 때는 출력이 되지 않으므로 그냥 입력하면 된다.
master는 브랜치( branch )의 이름이며, remote repository를 생성하면 기본적으로 master 브랜치가 생성된다.
이러한 방법으로
웹에 접근해서 자신의 작업 내용을 올리거나( push ) 동료의 최신 코드를 받아와서( pull ) 작업한 내용을 합칠 수( merge )가 있다.
반대로 원격저장소에 올라온 소스를 local로 가져오려면 어떻게 해야 할까.
clone, pull 두 가지 방법이 있다.
6. git clone
$git clone {원격 저장소 URL}
$git clone -b {브랜치명}{원격 저장소 URL}
clone 명령어는 처음 프로젝트에 투입되거나, 책에서 제공하는 예제 소스를 가져올 때, 중간에 git이 꼬였을 때 사용할 수 있다.
저장소 통째로 가져오는 것이다.
다음 경로에 clone을 해보자
clone할 저장소의 https를 복사한다.
git clone과 git pull을 비교해보자.
pull 명령어 역시 remote repository에 있는 파일들을 local로 가져오는 명령어 이며, 차이점은 다음과 같다.
git clone | git pull |
Github의 모든 파일들을 가져오기만 함 | = git fetch + git merge local repository와 비교하여 병합하고, local repository에 add까지 수행. -git fetch는 local에 연결된 remote repository의 브랜치 목록과 그 파일 내용을 최신으로 업데이트 하는 명령어. local과 remote의 싱크를 맞추는 새로고침 역할. -git merge는 두 개의 branch를 병합하는 명령어. |
git pull은 협업 과정에서 프로젝트의 최신 코드를 local로 가져오는 역할로 많이 사용한다.
예를 들어, 팀 프로젝트를 진행하다가 동료가 기능 구현을 완료해서 push를 했다고 가정해보자.
이제 필자는 새로운 작업 내용을 반영하기 위해, Github에 있는 코드를 가져와야 하는데 어떤 방식으로 가져와야 할까?
git clone을 하면 제가 그동안 작업했던 내용들과 동료가 작업한 최신 버전은 독립된 존재가 되어버린다.
즉, clone을 해서 받은 폴더에 제가 작업했던 내용들을 일일이 수작업으로 적용시켜야 한다.
이는 좋은 방법이 아니다.
git pull을 하면 어떨까?
현재 필자가 작업 중인 local repository와 최신 코드가 비교및 병합되어, 최신 버전 파일들이 저의 local repository에 적용된다.
따라서 제가 작업하고 있던 코드들과 최신 버전 파일의 코드는 함께 존재하게 된다.
즉, 제가 작업한 코드와 동료의 작업 코드가 자동으로 합쳐지게 되니까 매우 바람직하다.
그런데 만약 저와 동료가 동일한 파일 내역을 수정했다면 어떻게 될까?
이 경우 충돌( conflicts )이 발생하며 일일이 수작업으로 충돌된 부분을 수정해야 한다.
7. git reset / git revert
이제 이전 버전으로 돌아가보자.
git reset은 특정 커밋으로 되돌아 갈 수 있으며, 되돌린 버전 이후의 버전들은 히스토리에서 삭제된다.
git revert는 reset처럼 특정 버전으로 되돌아갈 수 있지만, 되돌린 버전 이후의 이력들은 남아있다.
git reset | . | 현재 버전으로 되돌리기(add 무효화) |
{commit 번호} | 특정 버전으로 되돌리지만, 커밋 이력 삭제 파일내용 유지 |
|
-- hard {commit 번호} | 파일내용까지 되돌림 | |
-- soft {commit 번호} | 파일내용은 그대로 유지하면서 staging area에 올림 | |
git revert | {commit 번호} | 특정 버전으로 되돌리는데, 파일 내용은 그대로 유지하고 되돌린 버전 이휴의 모든 commit이력은 보존 |
출처:
https://victorydntmd.tistory.com/79?category=682764
https://dololak.tistory.com/346
https://webclub.tistory.com/317 [Web Club]
'🗂️git' 카테고리의 다른 글
[Git] 자주쓰는 command (0) | 2020.11.29 |
---|---|
[Git / Git Hub] Git 용어 재 정리 (0) | 2020.06.23 |
[Git / Git Hub] Branch (0) | 2020.06.21 |
[Git / Git Hub] Git의 기본 (0) | 2020.06.21 |
[Git / Git Hub] 탄생배경 및 간단한 소개 (0) | 2020.06.21 |