VCS( version control system )
버전 관리 시스템 : 파일 변화를 시간에 따라 기록했다가 나중에 특정 시점의 버전을 다시 꺼내올 수 있는 시스템
GIT Document에서 발췌
DVCS(분산 버전 관리 시스템)에서의 클라이언트는 단순히 파일의 마지막 스냅샷을 Checkout 하지 않는다. 그냥 저장소를 히스토리와 ****더불어 전부 복제한다. 서버에 문제가 생기면 이 복제물로 다시 작업할 수 있다. 클라이언트 중에서 아무거나 골라도 서버를 복원할 수 있다. Clone은 모든 데이터를 가진 진정한 백업이다.
간단히 설명하자면 Git은 프로젝트를 버전 별로 관리가 가능하기에 보다 효율적이며 팀 단위로 하는 협업에 최적화 되어 있기 때문에 개발자라면 팀원들과의 원활한 협업을 위해 필수적으로 배워두면 좋다고 생각한다. 물론 실제 회사에서도 많이 사용한다.
Git Flow
Working Directory → Staging Area→ .git Directory→ Remote Repository
1. Git의 설치
GitHub를 통해 간단하게 사용을 할 수도 있겠지만 Git을 제대로 사용하기 위해서는 Git을 다운로드 받아야 한다.
Git 명령어를 사용하기 위해서는 "리눅스" 또는 "MAC의 터미널" 또는 "Intelli J command" 와 같은 환경에서 운용하는 것이 가장 좋다.
Ubuntu에서 테스트
설치 후 Command를 이용해 테스트 위치 만들기
- 폴더 생성
mkdir test
- test 폴더로 이동
cd test
2. 처음부터 직접 쳐보며 Git Command 명령어 알아보자 -1 (Local)
git init : 해당 폴더에서 git을 시작하겠으니 .git을 만들어라
git init
친절하게도 생성되었다고 아래와 같이 알려준다
git status : git의 현재 상태를 보여줘라
// 현재 상태를 보면 아무것도 없는것을 표현해준다.
git status
// git의 현재 상태를 변화를 보기 위해 파일을 생성해보겠다.
vi README.md
git status
- Git은 친절하게도 설명이 상세히 적혀져 있다.
- 현재 브랜치는 master로 되어있다.
- 아직 커밋들이 없다
- untracked file들의 목록은 아래 빨간색으로 되어있다.
- 이 파일을 commit 하기 위해서는 git add 을 해라
git add : Git Flow의 Staging 영역에 추가한다.
git add 기본적인 방법은 아래와 같다
- git add README.md
- README.md 파일이름을 적음으로써 한 개의 파일만 Staging으로 add 한다.
- git add .
- . 을 적음으로써 Local Directory에 있는 모든 파일을 Staging으로 add 한다.
git add README
위와 같이 확장자까지 붙이지 않을 경우 staging에 추가되지 않고 에러가 발생한다.
fatal: pathspec 'README' did not match any files
git add README.md
git status
git rm --cached : Commit 파일 목록에서 제외하고자 Staging에서 내리고 싶을 경우 사용한다.
git rm --cached README.md
git status
다시 git add . 후 테스트 진행하겠다.
git commit -m : Staging → .git 즉, Local Repository에 올린다.
git commit -m "feature/1/#GitTest1 -commitTest"
// git status 명령어를 사용해보면 모두 없어졌다.
git status
git log : Commit된 HEAD(Branch) + Hash코드 + Author(누가 올렸는지) + 날짜 + commit 내용이 나온다
git log
// 아래와 같이 한줄로 나타낼수도 있다.
git log --oneline
// 계속 따라 치다보면 보겠지만 아래 명령어를 사용하면
// 모든 Branch의 Log를 한 라인씩 짧게 Graph 형태로 추가해서 보여준다
git log --oneline --all --graph
git branch : Branch를 생성한다.
git branch develop
git branch
초록색 표시에 왼쪽의 별표로 현재 Branch가 무엇인지 체크해준다.
다음 테스트 진행을 위해 삭제하겠다.
git branch -d develop
git switch : 사용할 Branch로 이동한다
git switch -c : Branch를 생성하면서 해당 브랜치로 이동한다.
git version이 오래되었을 경우 switch가 없다! checkout을 사용해야 한다
git switch -c develop
// git branch가 이동되었음을 확인할 수 있다.
git branch
// on branch develop이 적혀있듯이 사용하고 있는 브랜치를 알려준다
git status
// master branch에서 git switch를 통해 develop을 생성하였으니
// master에서 만들었던 파일, 폴더, commit 내역 등등 모든 정보를 복제하여
// develop branch를 생성하였기 때문에 log를 보면 HEAD는 동일하게 develop을 가리키고 있다.
git log
git merge : 다른 branch와 파일, 폴더 등등을 병합한다.
git merge
→ 다음과 같이 가정하자
- 현재 master branch 위치에 있다.
- develop의 최신화 된 commit 내역을 master branch에 병합하려 한다.
→ git merge develop
*"master에 develop을 병합 한다"라는 뜻이라고 해석하자*
다음 테스트를 하기 위해 다음과 같이 파일을 만들고 커밋했다.
vi Test.java
// 아래 내용은 중요하지 않다.
-> public class Test{
public static void main(String[] args){
System.out.println("test class");
}
}
javac Test.java
git status
git add .
git commit -m "feature/2/develop merge test commit"
// 아래와 같이 commit이 추가 된 것을 볼 수 있다.
git log
이제 많이 사용했던 명령어에 대한 이미지는 제외하겠다 힘듦...
git switch master
// log를 살펴보면 develop과 달리 master branch는 처음 커밋했을 때와 같다는 것을 알 수 있다.
git log
// 아래 이미지와 같이 update 된 것을 확인할 수 있다.
git merge develop
// git log를 사용해서 확인하면 merge된 파일도 HEAD에 master가 추가 되었음을 알 수 있다
git log --oneline
다음 테스트를 위해 commit을 하나 더 하겠다.
vi file.txt
git add .
git commit -m "feature/3/reset Test File add"
git log --oneline
git reset<Commit Id 7자 또는 HEAD~숫자>: 무언가 잘못 commit || push 하였을 경우 commit 했던 위치로 reset 즉, 지정한 commit 이후로의 기억은 하고 싶지 않아! 삭제하겠어!다
위와 같이 되돌리기 위해 데이터 저장의 분기점인 Commit Id(Hash)를 사용하는데 reset을 사용하는 문제가 아니어도 본인이 기능을 만들면서 잦은 Commit을 해서 다양한 분기점을 기록하여 작성하는 버릇을 들이길 추천한다.
- reset 방법은 3가지가 있다.
- --soft : 지정한 commit으로 되돌아 가고, 이후의 내용이 지워지지 않고 스테이지도 그대로 남아있다
- --mixed : default 옵션이다. 지정한 commit으로 되돌아 가고, 이후의 내용이 지워지지 않고 스테이지의 변경되었던 내역은 삭제된다.
- --hard : 지정한 commit 위치로 되돌아 가고, 이후의 모든 내용을 지워버린다.
테스트는 hard와 soft만 해보겠다!
Hard Test
git reset --hard 4a56419
// log를 확인해보면 4a56419 commit Id로 돌아가고 이후 데이터가 모두 사라진 것을 알 수 있다.
git log --oneline
Soft Test
git reset --soft HEAD~2
// 아래와 같이 스테이징에 파일이 올라가 있다
git status
// commit Id log는 사라졌다.
git log --oneline
다음 테스트를 위해 추가하겠다
vi text.txt
git add .
git commit -m "feature/4/분기테스트"
// master에도 commit Id 분기가 만들어지니 develop과 갈라져서 그래프가 표현된다.
git log --oneline --all --graph
git rebase : 두 개의 Branch의 Commit 분기를 하나로 합쳐서 보다 가시성 있고 협업 하기에 좋도록 만들어 준다.
우선 만약 merge를 하면 어떻게 되는지 보자
git switch develop
// develop에서 master branch 파일을 가져와 병합한다.
git merge master
// branch가 나뉘어 졌고 각자의 commit Id가 생긴 상태에서 병합하니
// 아래와 같이 나뉜것이 보인다
git log --oneline --graph --all
생각을 해보자, 위와 같이 계속해서 Branch가 많아지고 Commit이 많아지면 팀원들이 병합 할 때마다. 이 많은 선이 생길 것이다. 감당이 되겠는가? 우선 develop을 master와 rebase 하겠다.
git rebase master
// 위의 merge와 달리 아래 이미지와 같이 한 줄로 합쳐진 것을 볼 수 있다.
git log --all --oneline --graph
여기서 유심히 들여다 보다 보면 한 가지 더 하고 싶어진다. Commit Id가 너무 많다!??!?
나는 1개의 Commit만을 두고 싶다 하면 git rebase -i <Commit Id || HEAD~숫자>
를 사용해서 squash를 하기 바란다. Squash는 Commit을 하나로 압축해주는 기능이다.
// 아래와 같이 명령어를 작성시 아래 이미지가 나온다
// --root는 Commit Id가 2개밖에 없을때 사용하는 명령어로 첫 번째 커밋을 변경한다는 뜻이다
// --root 말고는 위에서 언급한 대로 Commit Id 또는 HEAD~숫자를 입력하면 되겠다.
git rebase -i --root
앞에 문자를 아래와 같이 바꿔보자
pick한 Commit Id에 아래 있는 파일들을 (s) squash 하겠다는 것이다.
// 아래 명령어를 입력하면 아래 이미지와 같이 커밋 메시지를 어떻게 할 것인지 나온다
:wq
아래와 같이 커밋 메시지를 바꿔보자
:wq
저장을 하고 Log를 확인해보면 아래와 같이 커밋 메시지가 저장되는 위치를 알 수 있고
Commit Id가 하나만 남았다는 것을 알 수 있다.
Git을 그림으로 보며 이해하는데 도움이 될만한 블로그 : https://velog.io/@godori/Git-Rebase
3. 처음부터 직접 쳐보며 Git Command 명령어 알아보자 -2 (Remote)
GITHUB Repository 생성해서 push & pull 해보기
https://github.com/ 깃허브에 로그인해서 Repositories에 New를 클릭한다.
아래와 같이 입력 또는 클릭하고 create repository를 클릭한다.
_Add a README file_은 프로젝트를 진행하는 거라면 만들어서 깃 페이지를 예쁘게 꾸미자
아래와 같이 나왔다면 표시한 복사 버튼을 누른다
git remote add origin : github에서 만든 remote repository에 연결한다
git remote add origin https://github.com/kschoi93/git_test.git
이후에 git push로 올릴 파일을 추가해야 한다면 위에서 사용한 add와 commit을 이용해 추가한다
git pull : remote에서 파일을 내려받는다.
git clone은 만들어져 있는 repository를 아예 복제해오는 것이지만 우리는 처음부터 로컬에서 만들고 시작했기 때문에 remote로 연결하고 git pull로 최신 데이터를 병합해서 최신화를 유지시킨 상태에서 push를 시작할 것이다.
// name ( 브런치 )를 정하지 않고 처음이니까 전부 받아줬다
git pull
git push origin master : remote의 origin master 브랜치로 commit 내역을 전송한다
// 현재 switch가 develop으로 되어있어 develop으로 올렸다.
// branch는 보통 현재 위치한 branch와 remote branch 가 일치하게 push한다.
git push origin develop
아마 아래와 같이 나올 것이다. git config를 지정 안해서 그렇다 추후 git config 지정을 꼭 하길 바란다
즉, git에 데이터를 보내는데 유저네임은 뭐고 비밀번호는 뭐냐?고 묻는다
그런데, 으잉? 이런 에러가 발생한다.
8월 13일부로 비밀번호 대신 토큰을 이용하게 변경되었다고 한다.
remote: Support for password authentication was removed on August 13, 2021. Please use a personal access token instead.
remote: Please see https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ for more information.
fatal: unable to access 'https://github.com/kschoi93/git_test.git/': The requested URL returned error: 403
- github에서 프로필을 눌러보면 setting에 들어갈 수 있다.
- 왼쪽 사이드바에 개발자 설정을 클릭
3. 왼쪽 사이드바에서 personal access tokens 클릭
4. Generate new token 클릭
5. 아래와 같이 설정하고 Generate token을 누른다
6. 아래와 같이 git token이 나올 것이다. 앞으로도 사용할 것이기 때문에 잘 저장해 놓자
Git에서 설명하는 git hub token 생성 방법이다.
// 다시 push하면 잘 올라간 것을 볼 수 있다.
git push origin develop
깃허브에서 보면 아래와 같이 최근에 올라온 push는 몇분 전에 올라왔는지 표시해준다.
아래와 같이 셀렉트 박스를 클릭해서 develop으로 이동하면 push된 파일이 보인다.
끝!
여기까지 Git 명령어를 직접 쳐보며 어떻게 하는지 간단하게 알아봤다.
작성하고 보니 완전 초보들을 위한 글이 된듯하다.
더 많은 것은 직접 경험을 통해 익히는 것을 추천한다.
추가적으로 git을 사용함으로써 issue, milestone, branch를 잘 사용함으로써 진정한 협업이 이뤄진다고 생각한다.
데이터가 없어지는 것을 무서워 하면 더이상의 발전은 없다 !
초보일때 실수를 많이 하자! 화이팅!
'Infrastructure > Git' 카테고리의 다른 글
install gitlab (0) | 2023.03.18 |
---|---|
Git Commit 메시지 수정 방법, --amend (0) | 2021.10.09 |
에러, git push 후 rejected (0) | 2021.04.03 |
에러, github GH007 해결 방법 (0) | 2021.03.13 |
github 서버에서 파일 수정할 경우 이클립스에서 full 또는 push 모두 충돌 발생하는 경우 해결 방법 (0) | 2021.03.13 |