01. Git 설치와 Git Bash 명령어 정리

01. Git 설치와 Git Bash 명령어 정리

2020. 7. 8. 23:55ㆍGit

f이번 포스트는 생활코딩 이고잉님의 지옥에서 온 Git을 정리한 내용을 담았습니다. 개인의 공부 목적으로 Git을 처음 접하는 이들이 이해할 수 있는 수준으로 설명하고자 작성하였으며 포스트의 모든 그림과 코드의 저작권은 지옥에서 온 Git에 있습니다.

안녕하세요. 이번 포스트부터는 생활코딩 이고잉님의 지옥에서 온 Git을 보고 공부 목적으로 내용을 재해석하여 포스팅하게 되었습니다. 포스트의 코드는 window환경에서 Git Bash를 이용해 작성했wef습니다.

Git 설치
먼저 window에서 Git을 설치하는 방법입니다. 아래 링크의 Git 다운로드 홈페이지에서 Windows를 선택해 설치해주시면 됩니다. 이후 설치하실 때 모두 Next >를 눌러 설치를 진행해주시면 됩니다.

이제 윈도우창에서 Git > Git Bash를 눌러 기본적인 명령어에 대해 알아보겠습니다.

Git Bash 명령어 정리

이제 Git Bash에서 Git 명령어에 대해 알아보겠습니다. 본 포스트는 6. 지옥에서 온 Git : git init에서 10. 지옥에서 온 Git : 변경 사항 확인하기 (log & diff)사이의 코드입니다.

pwd, cd, mkdir, ls -al

· pwd : 현재 작업중인 디렉터리의 위치, print working directory

pwd : 현 디렉터리 위치: /c/Users/childult-programmer

· cd : 디렉터리 이동, (i.e. cd gitDocuments, gitDocuments는 테스트를 위해 직접 만든 폴더입니다.)

cd gitDocuments으로 현 디렉터리 위치가 이동했음을 알 수 있습니다.

c:/Users/childult-programmer, cd 명령어를 이용해 작업하는 디렉터리 위치를 gitDocuments로 이동했습니다.

· mkdir : 새 디렉터리(폴더) 생성 (i.e. mkdir helloGit), make directory

· ls -al : 현재 디렉터리에 있는 파일 목록

mkdir명령어를 이용해 helloGit이라는 파일 폴더를 만들었습니다.

위 명령어들은 git에서만 사용되는 명령어는 아니지만 앞으로 많이 사용되기 때문에 알아두시면 좋을 것입니다. 이제 git의 명령어를 살펴보겠습니다. 시작 전 먼저 git에는 어떤 명령어들이 있는지 살펴보겠습니다.

· git : git에서 사용할 수 있는 명령어 리스트

git init

· git init : 시작, 현재 디렉터리에 git 생성
> create an empty Git repository or reinitialize an existing one

$ git init : Initialized empty Git repository

vim editor, git status, git add

· vim file: vim editor로 file 파일을 생성합니다. 위에서 Git 설치 시 vim editor를 Git의 default editor로 정했습니다.
> 파일 생성 후 에디터 모드에서 i(Insert 모드), 텍스트 입력, ESC + :wq(write, quit), Enter로 파일 작성

cat file : vim editor로 생성한 file의 내용을 출력합니다.

i를 눌러 Insert모드 진입, 텍스트 입력(source : 1) 후 ESC + :wq(write, quit) + Enter로 파일 작성

f1.txt 텍스트 파일이 생성되고 source : 1이 작성된 것을 볼 수 있습니다.

ls -al 명령어로 f1.txt파일이 생성된 것을 확인할 수 있습니다.

· git status : git에 의해 버전 관리되는 파일들의 상태를 확인합니다.

· git add file : git에게 file을 버전 관리하라고 명령합니다. 주로 다음의 상황에서 git add를 사용합니다.
> 새로운 파일을 만들어서 버전 관리를 시작하고 싶을 때
> 이미 버전 관리하는 파일을 수정했을 때

git에 의해 관리되는 파일들의 상태는 크게 Tracked(관리 대상)와 Untracked(관리 대상이 아님)로 나뉩니다. 자세히 설명하자면, 위에서 vim에디터로 만든 텍스트 파일 f1.txt는 현재 생성만 되었을뿐, git에 의해 관리되고 있지 않습니다. 버전 관리에서 버전은 어느정도의 작업이 완료된 상태로, 실시간 변화와는 구분지어 이해해야 합니다. 예를 들어 계산기 프로그램을 만들 때 기존의 덧셈과 뺄셈 연산이 있는 프로그램에서 곱셈을 추가하는 것은 어느정도 유미의한 작업이 완료된 상태로, 우리는 git에 프로그램의 버전 관리를 위해 프로그램이 어떤 변화를 담고 있는지, 왜 변경되었는지 등의 정보를 작성해야합니다. 이러한 작업을 커밋이라고 하며 커밋된 결과들은 git의 repository에 저장됩니다. 다시 말해 파일을 만든 후(Untracked) git init명령어로 git에게 파일을 관리하라고 명령하는데, 이 때 git init와 커밋 이전까지 파일들이 머무는 곳을 staging area라고 합니다. Tracked파일은 staging area 외에도 파일의 수정에 따라 Unmodified와 Modified 상태로 바뀌기도 합니다. 이러한 git입장에서의 파일 변화를 우리는 파일의 라이프사이클이라고 부르며, git status로 현재 파일이 라이프사이클에서 어느 위치에 있는지를 확인할 수 있습니다.

그러면 실제로 git status를 실행해 확인해보겠습니다. No commits yet, Untracked files: f1.txt를 보아 git은 아직 f1.txt파일을 버전 관리하지 않고 있습니다. but untracked files present (use "git add" to track)는 f1.txt파일이 아직 untracked상태이므로 git add를 실행해 파일을 staging area에 커밋 대기 상태로 둘 수 있다고 말합니다. 실제로 바로 git add f1.txt를 실행하여 git에 f1.txt를 track상태로 만든 후 git status로 다시 확인해보면, new file: f1.txt를 확인할 수 있습니다. git add f1.txt시 발생하는 warning은 리눅스와 윈도우 사이 발생하는 경고문으로, 당장은 신경쓰지 않으셔도 되지만 자세한 설명을 알고 싶으시다면 다음의 블로그에서 확인하실 수 있습니다. 재윤 블로그 : Git 에러 CRLF will be replaced by LF (혹은 반대)

Git 에러 CRLF will be replaced by LF (혹은 반대) 핸들링하는 방법

맥/리눅스 이용 개발자와 윈도우 개발자가 협업할 때 왜 발생할까? 터미널에 git 명령어를 입력했는데 다음과 같은 에러가 뜨는 경우가 있다: ```bash warning: CRLF will be replaced by LF in some/file

blog.jaeyoon.io

git config --global user.name, git config --global user.email

· git config --global user.name name : git에서 작업한 사람의 이름이나 닉네임 등을 명시

· git config --global user.email email : git에서 작업한 사람의 이메일을 명시

해당 버전을 커밋한 작성자 정보를 명시하는 것은 협업 시 매우 중요한 문제로, 처음 한번만 실행되며 git의 최초 설정으로 분류됩니다. --global 옵션으로 설정하면 Git은 커밋할 때 마다 이 정보를 사용하며 한 번 커밋한 이후에는 변경할 수 없습니다.

git config --global user.name / user.email

git commit, git log, git diff

· git commit : 커밋, 버전별 관리를 위해 git에 파일이 어떤 변화를 담고 있는지, 왜 변경되었는지 등의 정보들을 작성

vim editor, i(Insert모드)를 눌러 커밋할 내용을 작성합니다.

작성 후 ESC + :wq(write, quit), Enter로 커밋을 마칩니다.

1 file changed, 1 insertion(+), create mode 100644 f1.txt를 보아 커밋이 성공했음을 확인합니다.

· git log : 파일의 커밋 히스토리를 조회

git log, 작성자 정보와 커밋 시점, 커밋 내용을 담은 히스토리를 조회합니다.

실습 차원에서 f1.txt로 버전을 몇개 더 만들어 보겠습니다.

git status로 확인해보면, f1.txt가 modified 상태임을 알 수 있습니다.

이 때 staging area에는 파일이 없기 때문에 바로 git commit 명령어를 입력하면 실행되지 않습니다. 다시 git add f1.txt로 파일을 커밋 대기 상태에 올려놓은 뒤, git commit을 입력해야합니다.

git commit 입력 시, not staged for commit으로 staging area에 파일이 없음을 알 수 있습니다.

git log -p : 각각의 커밋과 커밋 사이의 소스 상의 차이점을 확인

git log -p를 이용해 각각의 커밋과 커밋 사이 소스 코드 상의 차이점을 확인할 수 있습니다. 예를 들어 위의 git log -p를 실행한 창에서 change : 3과 change : 2을 버전 3, 2로 놓은 채 커밋 메시지 사이의 메시지를 보겠습니다. 먼저 +++ b/f2.txt는 버전 3에서 파일 f2.txt를 관리했다는 의미이며, --- /dev/null은 버전 2에서는 f2.txt파일이 존재하지 않았음을 의미합니다. 즉 사용자는 버전 3에서 f2.txt파일을 커밋했음을 알 수 있습니다. 아래의 source : 2는 f2.txt파일의 내용입니다. 이어서 아래의 change : 2와 change : 1 사이의 메시지를 보면, 버전 2와 1에서는 모두 f1.txt파일을 관리하고 있습니다. 다만 f1.txt파일의 내용이 버전 1에서는 source : 1인 반면 버전 2에서는 source : 2로 변경되었음을 알 수 있습니다.