Y Tech Blog search

GitHub 사용법 - 08. Conflict

|

주의: 이 글을 읽는 여러분이, 만약 git을 많이 써 봐서 익숙한 것이 아니라면, 반드시 손으로 직접 따라 칠 것을 권한다. 눈으로만 보면 100% 잊어버린다.

저번 글에서 작업하던 것을 이어서 한다. 저번 글에서는 diff, add, commit, .gitignore에 대해서 알아보았다.


Conflict

Conflict는 이름 그대로 충돌인데, 다음의 경우일 때 conflict가 생긴다.

같은 파일의 같은 부분을 동시에 두 곳(이상)에서 수정했을 때

이런 경우는 보통 여러 사람의 분업이 명확하게 이루어지지 않아 코드의 같은 부분을 수정할 때 일어난다.
물론 1인 팀에서도 코드 관리를 잘못하여, 혹은 여러 컴퓨터에서 작업하게 될 때 이러한 실수가 일어나기도 한다.

Conflict의 발생 및 해결 순서는 다음과 같다.

  1. 동시에 같은 파일의 같은 부분을 수정하고, merge 혹은 push를 할 때 일어난다. 이는 같은 파일을 수정했다 하더라도 명확히 다른 부분이 수정되었다면 git이 알아서 병합 과정을 처리해준다는 뜻이다.
    • 충돌이 일어났다면, git은 병합 과정을 진행하지 않고 충돌 상태를 그대로 둔다. 알아서 처리하는 대신 사용자가 충돌을 살펴보고 원하는 코드만 남길 때까지 기다린다.
  2. 사용자가 편집기에서 코드를 원하는 부분만 남긴다. 충돌이 일어난 부분은 git이 명확하게 표시를 해 준다.
    • 표시를 한다는 것은, 실제로 코드 파일을 git이 수정한다는 뜻이다. 물론 알아서 충돌을 해결한다는 뜻이 아니라, “여기 충돌 생겼어”하고 강력하게 표시를 한다는 뜻이다. 만약 코드 테스트를 한다면 틀림없이 이 부분에서 syntax error가 뜬다.
  3. 사용자가 직접 수정을 끝냈으면, commit을 한 다음 merge 혹은 push 작업을 완료한다.
    • 이때 따로 새로운 commit이 생기는 대신 원래 있어야 할 merge commit만 생성된다.

하나씩 살펴보자.


1. Conflict 발생시키기

일부러는 절대 해서는 안 되지만, 예시를 보여주어야 하기 때문에 고의로 conflict를 발생시켜 보겠다.

일단은 git_tutorial repo의 3rd-branch로 이동한 다음, git rebase master 명령을 실행한다.
2nd-branch부터 시작한 수정사항이 반영되어있지 않기 때문이다.

git checkout 3rd-branch
git rebase master

second.py의 마지막에 다음을 추가한다.

git_tutorial repo의 2nd-branch로 이동한 다음, first.py의 마지막에 다음을 추가한다.

git checkout 2nd-branch

print("Desired sentence in 2nd-branch")

commit을 한 뒤, master branch에서 2nd-branch의 내용을 merge한다.

git add first.py
git commit -m “Desired commit from 2nd-branch”
git checkout master
git merge 2nd-branch

그리고 3rd-branch로 이동하여 비슷하게 반복한다. 수정하는 파일은 당연히 first.py이다.

git checkout 3rd-branch

print("Unwanted sentence in 3nd-branch")

git add first.py
git commit -m “Unwanted commit from 2nd-branch”
git checkout master
git merge 3rd-branch

01_conflict

예상대로 conflict가 뜬다.


2. Conflict 해결하기

이제 편집기로 가서 first.py를 살펴보라. 메모장 코딩을 하는 것이 아니라면, 에러 표시줄이 여럿 보일 것이다.

02_file

파일을 살펴보면 확실히 어느 부분에서 conflict가 일어났는지 바로 확인이 가능하다.
참고로 필자와 빈 줄의 개수가 달라도 별 상관은 없다.

git이 수정해놓은 부분을 보면 다음과 갈은 구조로 되어 있다.

<<<<<<< HEAD
(현재 브랜치의 HEAD의 내용)
=======
(merge한 브랜치의 내용)
>>>>>>> (merge한 브랜치 내용)

여기서 각 브랜치의 내용 중 사용자가 원하는 부분만 남기고 모두 지우면 된다. 한쪽 브랜치의 내용만 남길 수도 있고, 양쪽 모두의 내용의 일부 혹은 전체를 남길 수도 있다.

수정을 마쳤으면 필요 없는 부분인 <<<<<<< HEAD, =======, >>>>>>> <branch> 등은 모두 제거하면 된다.

04_resolve

예상대로 남길 부분은 “Desired sentence”이므로 이 문장만 남기고 나머지 부분은 모두 삭제하면 된다.

IDE에 따라서는 다음과 같이 표시될 수도 있다. 이때는 조금 더 편하게 진행할 수 있다.
아래 예시는 Visual Studio Code의 경우이다.

03_vscode

수정하기 전 ‘변경 사항 비교’를 누르면 어떤 부분이 다른지를 양쪽에 나누어 보여준다.
내용을 확인한 뒤 ‘현재 변경 사항 수락’을 누르면 원하는 부분만 남겨지고 나머지는 알아서 삭제될 것이다. 물론 다른 부분을 남겨도 상관없다.


3. commit(merge) & push하기

그리고 수정한 파일을 git add 명령으로 추가한 뒤 commit한다. 정상적으로 처리되었는지 보기 위해 로그도 한번 출력해 보자.

git add first.py
git commit

05_commit

ESC 입력 후 :wq
git log –oneline

06_merge

이러면 conflict가 해결된 것이다. remote repo에 push하자.

git push

그리고 3rd-branch로 이동하여 rebase를 한다.

git checkout 3rd-branch
git rebase master


4. Conflict가 발생하지 않는 경우

조금 전 처음에 했던 것처럼 2nd-branch로 이동해 업데이트한다.

git checkout 2nd-branch
git rebase master

이번엔 first.py 파일 끝에 다음을 추가한다.

print("This is the 2nd sentence written in 2nd-branch.")

그리고 second.py의 내용은 다음 문장 빼고 모두 지운다.

print("This is the 1st sentence written in 2nd-branch.")

다시 비슷한 과정을 반복한다.

git add *.py
git commit -m “No-collision commit from 2nd-branch”
git checkout master
git merge 2nd-branch

git checkout 3rd-branch

다음으로는 3rd-branch로 이동하여, first.py 파일의 내용을 다음 문장 빼고는 모두 지운다.
지우기 전에, print("This is the 1st sentence written in 2nd-branch.") 문장은 없어야 정상이다. 있다면, checkout을 제대로 했는지 살펴보라.

print("Desired sentence in 2nd-branch")

git add first.py
git commit -m “No-collision commit from 3rd-branch”
git checkout master
git merge 3rd-branch

07_no_conflict

문제없이 잘 병합된 것을 확인할 수 있다. 다른 파일, 혹은 같은 파일을 수정했더라도 수정한 부분이 다르면 conflict가 일어나지 않는다.
위 예시의 경우 first.py를 2nd-branch에서는 파일의 끝 부분을, 3rd-branch에서는 파일의 시작 부분을 수정했기 때문에 문제가 일어나지 않았다.


5. 이유없이 conflict가 생기는 것 같은 경우

사실 이유가 없는 경우는 없지만, 간혹 두 branch 간 차이가 전혀 없어 보이고 파일 수정까지 끝마쳤는데도 conflict가 계속해서 발생하는 경우가 있다.

다른 원인일 수도 있지만, 정말로 아무 차이도 없어 보인다면 운영체제의 line-feed 문자의 차이로 인한 문제일 수 있다.
즉 Windows는 '\r\n'을, Linux나 Mac은 '\n'을 개행 문자로 사용하기 때문인데, 이 차이를 제대로 인식하지 못해 실패하는 경우가 있으니 참고하면 되겠다.

해결법은 다음과 갈다.

git config merge.renormalize true

그리고 merge를 시도하면 된다.


다음 글에서는 Git 전체 명령어 사용법을 다룬다.


Git 명령어

GitHub 사용법 - 00. Command List에서 원하는 명령어를 찾아 볼 수 있다.

Comment  Read more

BOJ 01000(A+B), 01001(A-B), 01002(터렛) 문제 풀이

|

참조

분류 URL
문제 A+B, A-B, 터렛
이 글에서 설명하는 코드 01000~01002

BOJ 1000(A+B)

개요

시간복잡도: $ O(1) $

공간복잡도: $ O(1) $

문제 풀이

단순 구현 문제이다. 이 문제는 여러분이 어떤 식으로 이 사이트에 제출해야 하는지를 시험할 수 있는 문제이다. 아래 구현과 같이 하면 된다.

구현

다음과 같다. 이 문제는 C 스타일로 구현하였다.

#include <stdio.h>

int main(){
    int a, b;
    scanf("%d%d", &a, &b);
    printf("%d", a+b);

    return 0;
}

BOJ 1001(A-B)

개요

시간복잡도: $ O(1) $

공간복잡도: $ O(1) $

문제 풀이

이 문제 역시 단순 구현 문제이다. 이 문제도 여러분이 어떤 식으로 이 사이트에 제출해야 하는지를 시험할 수 있는 문제이다. 아래 구현과 같이 하면 된다.
사실 바로 위 문제에서 딱 한 글자만 바꿔도 된다.

구현

다음과 같다. 이 문제는 C++ 스타일로 구현하였다.

#include <iostream>

using namespace std;

int main(){
    ios::sync_with_stdio(false);    cin.tie(0);
    int a,b;
    cin >> a >> b;
    cout << a-b;
}

참고로, cin, cout 함수는 scanfprintf에 비해 느리기 때문에, main 함수 첫 줄과 같은 구문을 써 주어야 한다.
ios::sync_with_stdio(false);를 썼을 때는 cincoutscanfprintf를 같이 쓰면 안 된다.


BOJ 1002(터렛)

개요

시간복잡도: $ O(1) $

공간복잡도: $ O(1) $

문제 풀이

이 문제도 구현 문제지만, 알고리즘 문제를 풀어본 경험이 별로 없으면 충분히 헷갈릴 수 있는 문제이다.

이 문제의 답의 종류는 4종류이다. 먼저 종이에 원 2개를 그려보고 답의 개수가 될 수 있는 가지수를 생각하면 답을 얻을 수 있다.

  1. 위치의 개수가 무한대인 경우는 터렛 2개가 같은 위치에 있는 경우이다. 사실은 문제 데이터가 잘못되지 않았다면 거리 r1과 r2도 같아야 한다. 답은 -1이다. 두 원이 완전히 일치하는 경우이다.
  2. 만약에 두 사람이 구한 거리의 합이 두 터렛의 거리보다 멀면 불가능하다. 비슷하게 거리의 차가 터렛의 거리보다 짧아도 불가능하다. 답은 0이다. 두 원이 만나지 않는 경우이다.
  3. 만약 터렛1, 터렛2, 마린이 일직선상에 있고 거리의 합 또는 차가 일치하면 답은 1이다. 두 원이 접하는 경우이다.
  4. 그 이외의 경우라면 답은 2이다. 두 원이 두 점에서 만나는 경우이다.

구현

다음과 같다. R과 r은 각각 거리의 합의 제곱 또는 차의 제곱이다.

#include <stdio.h>

using namespace std;

int TC;
int x1, y1, x2, y2;
int r1, r2;
int main(){
    scanf("%d",&TC);
    while(TC--){
        scanf("%d%d%d%d%d%d", &x1, &y1, &r1, &x2, &y2, &r2);
        int d_square = (x1-x2) * (x1-x2) + (y1-y2) * (y1-y2);
        int R_square = (r1+r2) * (r1+r2);
        int r_square = (r1-r2) * (r1-r2);
        if(x1==x2 && y1==y2 && r1==r2)
            puts("-1");
        else if(d_square > R_square || d_square < r_square)
            puts("0");
        else if(d_square==R_square || d_square==r_square)
            puts("1");
        else 
            puts("2");
    }
    return 0;
}
Comment  Read more

GitHub 사용법 - 07. diff, add, commit, .gitignore 중급

|

주의: 이 글을 읽는 여러분이, 만약 git을 많이 써 봐서 익숙한 것이 아니라면, 반드시 손으로 직접 따라 칠 것을 권한다. 눈으로만 보면 100% 잊어버린다.

저번 글에서 작업하던 것을 이어서 한다. 저번 글에서는 다른 local repo의 branch update까지 살펴보았다.


git add, git diff

다시 git_tutorial_clone 디렉토리 밖으로 빠져 나와서, 원래 git_tutorial repository로 돌아가자. 그리고 업데이트를 한다.

cd ../../git_tutorial
git pull

여기에서 git add 명령의 다양한 옵션을 설명했었다.
페이지를 옮겨다니기 귀찮을 것이므로 다시 한번 가져왔다.

명령어 Description
git add first.py first.py 파일 하나를 staging area에 추가한다.
git add my_directory/                               my_directory라는 이름의 디렉토리와 그 디렉토리 안의 모든 파일과 디렉토리를 staging area에 추가한다.
git add . 현재 폴더의 모든 파일과 디렉토리, 하위 디렉토리에 든 전부를 staging area에 추가한다. 규모가 큰 프로젝트라면 써서는 안 된다.
git add -p [<파일>] 파일의 일부를 staging하기
git add -i Git 대화 모드를 사용하여 파일 추가하기
git add -u [<경로>] 수정되고 추적되는 파일의 변경 사항 staging하기

사실은 위의 것 말고도 조금 다른 방법이 있다. 바로 와일드카드이다.

파일을 추가할 때 .py 파일을 전부 추가하고 싶다고 하자. 그러면 다음과 같이 쓸 수 있다.

git add first.py
git add second.py

그러나 이는 귀찮을 뿐더러 빠트리는 경우도 얼마든지 있을 수 있다. 이럴 땐 * 를 사용한다.

git add *.py

이를 사용하면 .py로 끝나는 모든 파일이 staging area에 추가된다.

표에서 위쪽 세 종류의 명령은 어려운 부분이 아니므로, 다른 옵션을 설명하겠다.

git diff

2nd-branch로 이동한다. master에는 직접 수정을 가하지 않는다.

git checkout 2nd-branch

그리고 second.py를 수정한다. 최종 결과물은 다음과 같다.

print('1st')
print("Why don't you answer me, git?")

print('2nd')
print("This is the 1st sentence written in 2nd-branch.")

print('3rd')
print('4th')

참고로 모든 파일의 마지막 줄에는 빈 줄은 추가해 두는 것이 commit log를 볼 때 편하다. 이유는 마지막에 빈 줄만 추가하고 staging시켜 보면, 마지막 줄의 내용을 삭제한 후 마지막 줄의 내용 그리고 빈 줄을 추가한 것처럼 나오기 때문이다.

07_diff

별로 깔끔하지 않기 때문에 빈 줄을 추가하라. commit log 볼 때뿐만 아니라 나중에 편집할 때에도 조금 더 편하다.
IDE에 따라서는 빈 줄이 없으면 경고를 띄워 주기도 한다.

여기서 다음 명령을 입력하면 지금까지 어떤 수정사항이 있었는지 볼 수 있다.

git diff

07_diff_2

git diff는 아무 옵션 없이 입력하면 staging area에 반영되지 않은 수정사항을 보여준다.
git diff HEAD와 기능이 같다.

diff 역시 많은 옵션이 있는데, 간략히 살펴보도록 하겠다.

local branch 간 비교는 git diff [<branch1>] <branch2>와 같이 한다. 브랜치명을 하나만 쓰면 현재 local branch와 비교한다.
물론 remote branch와의 비교도 가능하다.

git diff 3rd-branch
git diff 2nd-branch origin/2nd-branch

커밋간 비교도 가능하다. git diff [<commit1>] <commit2>
역시 첫번째를 생략하면 현재 상태와 비교한다.

git diff 317200f

다른 옵션들은 나중에 설명하도록 하겠다. 일단은 여기까지만 하자.

git add -p [<파일>]

그리고 다음 명령을 입력한다. 지금은 second.py만 수정했기 때문에 해당 파일만 추가한다.
조금 위의 표에서 봤듯이 -p 옵션은 파일의 일부만을 staging(staging area에 올리는 것)하는 과정이다.
-p--patch의 단축 옵션이다.

git add -p second.py

그러면 다음과 같이 뜬다.

08_patch

  • 초록색 줄은 추가된 줄, 빨간색 줄은 삭제된 줄이다.
  • 파일의 일부분만을 추가하는데, 모든 한 줄마다 따로 추가하는 것이 아니라 hunk라는 덩어리로 한 번에 staging area에 추가할지 말지를 결정한다. 만약에 git이 나눠준 hunk가 너무 크다면, s를 입력하여 더 잘게 쪼갠다. 위의 경우는 너무 크기 때문에, 잘게 쪼갤 것이다.
  • 만약에 무슨 옵션이 있는지 궁금하다면 ?를 입력하라. 도움말이 표시된다.
명령 설명
y stage this hunk
n do not stage this hunk
q quit; do not stage this hunk or any of the remaining ones
a stage this hunk and all later hunks in the file
d do not stage this hunk or any of the later hunks in the file
g select a hunk to go to
/ search for a hunk matching the given regex
j leave this hunk undecided, see next undecided hunk
J leave this hunk undecided, see next hunk
k leave this hunk undecided, see previous undecided hunk
K leave this hunk undecided, see previous hunk
s split the current hunk into smaller hunks
e manually edit the current hunk
? print help

s, y, n, y를 차례대로 입력한다. s를 입력하면 3개의 hunk로 분리되었다고 알려 준다.

09_hunk

참고:

  1. untracked files는 -p를 할 때 나오지 않는다. 새로 추가된 파일이라면 먼저 staging area에 올린 후, 수정한 파일만을 p 옵션으로 처리하라.
  2. 디버깅을 위해 넣어 놓은 print문 등을 제거하고 push할 때 유용하다.
  3. 파일명으로 추가하는 대신 *.를 쓰는 것도 가능하다.

git add -i [<파일>]

대화형으로 파일 수정사항을 staging area에 추가하는 방법이다. first.py를 수정하자.

print("Hello, git!") # instead of "Hello, World!"
print("Hi, git!!")

print('1st')

print("This is the 1st sentence written in 1st-branch.")
print("This is the 1st sentence written in 3rd-branch.")

print('2nd')

그리고 git add -i first.py를 입력한 다음, 다음 그림대로 따라 해 보자.
중간쯤에 아무것도 안하고 Enter만 입력한 곳이 있는데, 이렇게 하면 선택한 파일들이 staging area에 추가된다.

10_i

파란색으로 강조된 부분을 잘 따라가면 이해하기 어렵진 않을 것이다.

위와 같이 하면 first.py 파일이 staging area에 추가된다.

git add -u [<경로>]

git add .git add -u는 하는 일이 비슷하지만, 차이점은 다음과 같다.

  • git add .는 현재 디렉토리의 모든 변경사항을 staging area에 추가한다. untracked files를 포함한다.
  • git add -u는 업데이트(‘u’)된 파일, 즉 untracked files는 제외하고 staging area에 추가한다.

뒤에 경로를 추가하면 해당 디렉토리 혹은 파일들에 대해서만 위의 작업을 수행한다.

아무 파일이나 하나 추가한 다음 차이를 확인하자. first.py 파일 끝에 다음을 추가하고, dummy1.txt 파일을 생성만 하자.

print('test git add .')

11_short

-s 옵션을 줄 때 ‘??’는 untracked files를 의미한다.

이제 git add .로 staging area에 추가해 보자.

12_add

모두 추가되었다.

이제 조금 전과 비슷하게 second.py 파일의 끝에 다음을 추가하고 dummy2.txt 파일을 생성만 하자.

print('test git add -u')

13_u

untracked files 상태인 dummy2.txt는 여전히 추가되지 않은 상태로 남아 있는 것을 볼 수 있다.


git commit: 중급

git commit에도 옵션은 굉장히 많으나, 여기서는 -v 옵션과 tag 두 가지만 설명한다.

-v 옵션

-v 옵션은 git add-p와 비슷하다. 즉 수정사항을 미리 볼 수 있는데, git diff를 밑에 보여주는 것과 비슷하다.

git commit -v

15_v

i 입력 후, 커밋 메시지는 적당히 입력하고 ESC, :wq 를 입력하라. 무엇인지 까먹지 않았기를 바란다.

tag

commit에는 태그를 붙일 수 있다. 여러분이 블로그에서 볼 수 있는 그 태그와 같은 기능이다.

태그에는 두 종류가 있는데, 단순 태그 기능만 하는 Lightweight 태그와 태그를 만든 사람, 시간, 메시지, 서명 정보 등을 저장하는 Annotated 태그가 있다.

먼저 Lightweight 태그는 다음과 같이 붙일 수 있다. 뒤에 commit 코드를 명시하지 않으면 현재 commit에 붙는다.

git tag v0.7

버전 정보를 저장할 때 태그로 하면 편하다.

현 repo의 태그 목록을 확인하려면 다음을 입력한다.

git tag

태그의 정보를 자세히 확인하고 싶다면 다음과 같이 입력한다.

git show v0.7

14_tag

태그를 삭제하려면 -d 옵션을 붙인다.

git tag -d v0.7

Annotated 태그를 붙일 때에는 -a 옵션을 사용한다. 메시지를 입력하려면 -m 옵션을 붙인다.
메시지를 입력하지 않으면 일반적인 커밋 메시지를 쓰지 않았을 때처럼 vim 편집기가 열린다.

git tag -a v0.7 -m “git tutorial ver 0.7”

뒤에 commit 코드를 명시할 경우 이전 커밋에도 태그를 붙일 수 있다.

git tag v0.5 90ce4f2

당연하게도 여러분이 직접 커밋을 만들었다면 커밋 코드는 다를 것이다. git log로 먼저 확인 후 원하는 커밋에 태깅하도록 한다.

16_tag

그림에서 커밋 로그에 ‘tag: v0.5’ 등이 생겼음을 확인하라.

이제 push를 하자.

git push

그러나 태그는 git push명령에 자동으로 remote repo에 올라가지 않는다.
태그는 따로 올리면 된다.

git push origin v0.5
git push origin –tags

--tags 옵션은 모든 태그를 remote repo에 올린다.


.gitignore 중급

사실 .gitignore 사용법은 어렵지 않다. 파일을 제외하거나, 디렉토리를 제외하거나, 와일드카드를 사용하여 여러 파일을 staging area에 올라가는 것을 막는 것뿐이다. 각각은 다음과 같이 사용한다.
.gitignore 파일의 각각 다른 줄에 추가하면 된다.
이 내용은 .gitignore 파일에 추가하지 않아도 된다.

dummy_txt
data/
*.tar
data/raw/*
*dummy*

대신 한 가지 흔히 하는 실수를 다루도록 하겠다. 데이터 파일이나 설정 파일, IDE가 자동으로 생성한 파일 등은 git add .를 생각없이 사용하다 보면 어느새 remote repo에 올라가 있는 경우가 많은데, 이 파일은 나중에 .gitignore 파일에 추가해도 repo에서 자동으로 사라지지 않는다.

예제를 하나 갖고 왔다. 우선 git_tutorial 디렉토리를 PyCharm IDE로 열거나, 아니면 .idea/라는 디렉토리를 하나 만들어 보자.

PyCharm으로 열면 자동으로 .idea/라는 디렉토리가 생겨버린다.

18_status

이를 그냥 생각없이 추가하면 직접 생성하지도 않은 수많은 파일들이 추가된다.

19_add

그리고 한번 remote repo에 올려 보자.

git commit -m “Doong!”
git push

이건 그다지 좋은 상황이 아니기 때문에, remote repo에서 제거하려고 한다. 서둘러 .gitignore 파일에 다음을 추가한다.

.idea/
*dummy*

그리고 3종 세트를 입력하자.

git add .gitignore
git commit -m “edit .gitignore: remove .idea/ directory”
git push

20_browser

물론 앞서 말한 대로, 자동으로 지워지지 않는다.

이럴 때는 어디선가 본 듯한 명령을 사용한다.

git rm –cached .idea/ -r
git rm –cached *dummy*

디렉토리를 제거하려고 할 때는 -r 옵션을 사용한다.

21_rm

이제 push를 한다. git add 명령은 필요없다.

22_push

이와 같은 실수를 막기 위해서는, 아예 .gitignore 파일에 git에 올라가지 말아야 할 파일을 정리해 두는 것도 괜찮다.
추천하는 것은 데이터 파일, 설정 파일, 패키지, 압축 파일 등이다.

PyCharm 기준으로는 구글링을 하면 적당히 쓸 만한 설정 파일을 구할 수도 있다.


이제 master branch에 merge를 하자.

git checkout master
git merge 2nd-branch
git push


다음 글에서는 대망의 conflict에 대해서 알아본다. 여러 사람이 작업 분할을 충실하게 하지 않는다면 필히 만나게 될 것이다.
물론 혼자서도 만들 수도 있다.


Git 명령어

GitHub 사용법 - 00. Command List에서 원하는 명령어를 찾아 볼 수 있다.

Comment  Read more

GitHub 사용법 - 06. branch 관리

|

주의: 이 글을 읽는 여러분이, 만약 git을 많이 써 봐서 익숙한 것이 아니라면, 반드시 손으로 직접 따라 칠 것을 권한다. 눈으로만 보면 100% 잊어버린다.

저번 글에서 작업하던 것을 이어서 한다. 저번 글에서는 두 사람이 각각 브랜치를 만들어 자신의 브랜치에서 작업하는 상황을 가정하여 진행했었다.


Branch naming

Branch 관리는 사실 하기 나름이지만, 다음의 방법이 괜찮기에 추천한다.

  1. 기본적으로 master 브랜치에서 진행한다. 이건 아주 기본적인 사항이다. master branch는 곧 배포할 코드를 보관한다.
  2. 개발의 중심이 되는 브랜치는 develop 브랜치에서 진행한다. develop 브랜치에서는 지금까지 merge된 코드들이 오류 없이 안정적으로 동작하는지를 검사한다. 물론 develop 브랜치에 merge되기 전에도 다른 팀원들이 검사하는 것이 일반적이지만, 모든 것을 다 판별할 수는 없기 때문에 안정성을 검사하는 것이다.
  3. feature 브랜치는 새로운 기능을 추가할 때 사용된다. 기능을 새로이 개발해야 할 때 local에서 만든 다음, 개발이 끝나면 develop 브랜치로 merge된다. 일반적으로 local에서 진행되고 remote repo에 push되지 않으나, 여러 명이 한 기능을 동시에 개발하는 경우에는 push한다.
  4. release 브랜치는 실제 동작 환경과 유사한 곳에서 테스트를 한번 더 하는 브랜치인데, 서버 환경이거나 아주 큰 프로젝트같은 것이 아니라면 굳이 필요하지는 않다. develop 브랜치로부터 생성되고, 안정성 검사가 끝나면 master branch로 version number와 함께 merge된다. 일반적으로 release 관련 작업은 주기적(1주 등)으로 이루어진다.
  5. hotfix 브랜치는 배포 이후에 발견된 버그를 빠르게 고쳐 패치하기 위한 브랜치이다(hotfix 패치는 어디선가 많이 봤을 것이다). 대개 master 혹은 develop 브랜치에서 생성되며 버그를 고친 이후에는 둘 모두에 각각 merge된다.

위의 경우는 큰 프로젝트 혹은 서버의 경우이고, 규모가 작은 프로젝트라면 master 브랜치와 개인 브랜치(feature 브랜치와 비슷), 그리고 필요하다면 develop 브랜치 정도까지만 있어도 괜찮다.


Branch update

저번 글에서 master, 2nd-branch, 3rd-branch까지 만들어서 작업을 했었다. 그런데 이 모든 내용은 local repo에 절대 자동으로 업데이트되지 않는다.

git_tutorial_clone 폴더로 이동한다. 여기에서 했었는데, 아마 기억하고 있을 것이다.

그리고 브랜치 상태를 확인해 보자.

git status
git branch -a

01_clone

업데이트를 전혀 안 했기 때문에, git pull을 입력해 보자.

02_pull

remote repo는 업데이트되었다. 만약 잘 되지 않았다면 git fetch를 추가로 입력하라. 이 명령은 저번 글에서 설명하였다.
그러나 local branch 목록은 전혀 업데이트되지 않았다.

업데이트하기 전에, 우선 브라우저로 가서 2nd-branch로 이동한다. 그리고 second.py를 수정한다.

03_browser

마지막 줄에 다음을 추가한다. 이렇게 브라우저에서도 파일을 수정할 수 있다.
추천되는 방법은 아니지만, readme.md를 수정하는 용도로는 쓸 만하다.

print("Directly modified sentence")

04_browser

그리고 Commit changes 버튼을 누른다.

다시 git_tutorial_clone/git_tutorial 폴더로 돌아오자.

local branch 목록은 전혀 업데이트되지 않았다. 이는 git은 자동으로 모든 것을 복사해오지 않기 때문이다.

remote branch를 local branch로 가져오는 방법은 다음과 같다.

첫번째 방법:

git checkout -t origin/2nd-branch

-t 옵션은 --track과 같다.
만약 이전 버전의 git을 쓰고 있다면, -b 옵션을 추가로 붙인다.

두번째 방법:

git checkout 2nd-branch

그리고 다음을 입력한다. 이는 checkout 하기 전 master 브랜치에서 진행해도 상관없다.

git pull
type second.py

type은 윈도우 명령창에서 파일의 내용을 출력하는 명령어이다. Linux 환경에서는 cat이다.

05_local

위의 방법은 branch를 직접 가져오는 것이다. git pull을 하면 파일 내용이 업데이트된다.

그런데 remote branch를 가져오는 다른 방법이 있다. detached HEAD 상태로 가져오는 방법인데,

  1. 이는 branch의 내용을 갖고 오면서 직접 수정도 할 수 있지만,
  2. commit이나 push를 할 수는 없고,
  3. 다른 branch로 checkout하면 사라진다.

06_detached


지금까지 remote branch를 가져오는 법을 알아보았다. 다음 글에서는 git diff, git add, git commit, .gitignore의 더 자세한 사용 방법을 알아본다.


Git 명령어

GitHub 사용법 - 00. Command List에서 원하는 명령어를 찾아 볼 수 있다.

Comment  Read more

GitHub 사용법 - 05. branch 기본 2

|

주의: 이 글을 읽는 여러분이, 만약 git을 많이 써 봐서 익숙한 것이 아니라면, 반드시 손으로 직접 따라 칠 것을 권한다. 눈으로만 보면 100% 잊어버린다.

저번 글에서 작업하던 것을 이어서 한다. 저번 글에서 1st-branch를 만들고 master에 merge한 뒤 삭제하는 작업을 진행했었다.


Branch 생성, checkout, 강제 삭제

현재 작업 트리의 상황은 다음과 같다. 1st-branch가 삭제되어 있다.

01

이제 브랜치 2개를 더 만들어 보자. 다음 명령을 입력한다.
2nd-branch는 여러분이 사용하는 브랜치이고, 3rd-branch는 여러분 말고 다른 팀원이 사용하는 branch라 생각하자.
물론 사람을 데려오긴 어렵기 때문에, 여러분이 직접 두 개를 다 만들도록 한다.

git branch 2nd-branch
git checkout -b 3rd-branch

첫 번째 명령은 다 알 것이라고 생각하고, 두 번째 명령은 조금 다르다.
git checkout은 원래 다른 브랜치로 이동할 때 쓰는데, -b 옵션을 주면 해당 브랜치를 만들면서 checkout하는 효과를 갖는다. 즉, 여러분은 현재 3rd-branch 브랜치에 위치해 있다.

02_create

물론 위와 같이 이미 있는 이름으로 만드려고 하면 이미 존재한다고 오류를 뱉어낸다.

이미 완전히 삭제해버린 브랜치 이름(1st-branch)로 만드는 것은 오류를 뱉어내지 않는다.
그러나 뭔가 확실하지 않은 부분이 있다면 똑같은 이름으로 재생성하는 것은 별로 추천되지 않는다.

옵션: Branch 재생성, 강제 삭제

하지만 예시를 보여주기 위해 만들어 보겠다.

git branch 1st-branch
git checkout 1st-branch

그리고 first.py 파일을 생성하고 마지막 줄에 다음을 입력한다. 곧 삭제할 것이기 때문에 아무거나 입력해도 괜찮다.

print('Dummy!')

다음으로 여러분은 이 수정 사항이 쓸모 있는 것이라고 생각하고 다음 명령까지 진행했다고 하자.

git add first.py
git commit -m “dummy!”

커밋 메시지가 너무 단순하다고 생각된다면, 다음 명령을 입력하라.

git commit –amend

그러면 (아마도 vim이라고 하는) 편집기가 뜬다. 이 편집기의 사용법은 나중에 좀 더 자세히 다룰 텐데, 지금은 다음 과정만 따른다.

  1. 처음 편집기에 들어왔을 때는 ‘명령 모드’이다. 여기서 i를 누르면 INSERT 모드(명령창의 맨 아래에 뜬다)가 되어, 커밋 메시지를 수정할 수 있다.
  2. 다음으로 커밋 메시지를 바꾼다. Dummy commit!
  3. 그리고 다음 키들을 차례로 입력한다. 하나도 틀려서는 안 된다.
    1. ESC
    2. : (콜론)
    3. wq (영문자 두 개이다)
    4. Enter

그러면 작성했던 커밋 메시지가 수정된다.

03_1st_branch

04_dummy_commit

여기까지는 문제가 없다. 그러나 추천되지 않는 행동이기에, 바로 삭제하려고 한다.
여러분도 프로젝트를 진행하다 보면 브랜치를 만들고 작업을 하다가 필요가 없어져서 삭제하려고 하는 상황이 올 것이다.

2nd-branch로 checkout을 하고 삭제 명령을 입력한다.

git checkout 2nd-branch
git branch -d 1st-branch

그러나 에러가 뜬다. 변경된 작업사항을 push하거나 merge하지 않았기 때문에, 수정사항을 잃어버릴 수도 있다고 경고하는 것이다.
물론 여러분은 이것이 쓸모없는 브랜치인 것을 알기 때문에, 강제로라도 삭제하면 된다.

친절하게도 강제 삭제 명령을 git에서 알려 주었다.

git branch -D 1st-branch

05_D

이제 2nd-branch에서 다시 시작하자.


Non fast-forward 병합

이번엔 두 개의 서브 브랜치(참고로 티켓 브랜치라고도 부른다)에서 모두 master에 변경사항을 만들어 볼 것이다.
두 명의 사람이 각각 자신의 브랜치를 만들어서 master에 적용하려는 상황을 생각하라.
참고: 같은 컴퓨터에서는 명령창을 두 개 놓고 다른 브랜치에서 작업하는 것은 불가능하다.

우선 2nd-branch에서, second.py 파일의 끝에 다음을 추가한다.

print("This is the 1st sentence written in 2nd-branch.")

그리고 다음 명령들을 차례로 입력한다. 이 부분은 fast-forward 병합이다.
참고: 명령창에서 second.py를 입력할 때 ‘s’ 정도만 타이핑한 후 Tab 키를 누르면 파일(또는 디렉토리) 이름이 자동완성된다.

git add second.py
git commit -m “This is the 1st commit written in 2nd-branch”
git checkout master
git merge 2nd-branch

파일 수정 시 빈 줄을 몇 개나 넣었느냐에 따라서 수정 사항(1 file changed, 3 insertions(+), 1 deletion(-)) 이 달라 보일 수 있으나, 여기선 별 상관 없다.
참고: 마지막 두 줄은 git merge master 2nd-branch로 가능하다. 그러나 해당 브랜치에서 추가 작업이 필요한 경우 별로 편리한 명령은 아니다.

06_fast

그리고 이제 커밋 코드를 확인해 보자.

07_log

16진수 코드가 같다. fast-forward 방식으로 병합되었기 때문임은 설명했다.

이제 3rd-branch로 이동한다.
그리고 3rd-branch에서는 first.py에 다음을 추가한다.

print("This is the 1st sentence written in 3rd-branch.")

그리고 다음 명령들을 입력한다. 조금 전과 매우 유사하다.

git add first.py
git commit -m “This is the 1st commit written in 3rd-branch”
git checkout master
git merge 3rd-branch

세 브랜치의 로그를 확인해 보면 위와는 조금 차이가 있다.

08_log

작업 트리를 그려보면 다음과 같다. master로 checkout했을 때를 기준으로 하였다(HEAD).
또한 fast-forward와 non fast-forward를 구분하여 그렸다.

09

명령창에서 그래프를 그릴 수도 있다. 다음 둘 중 하나를 입력한다.

git log –graph
git log –graph –oneline

10_graph

위의 그림들에서는 설명할 것이 많다.

  1. 2nd-branch merge 시: master에 새로운 수정사항이 없는 상태에서 다른 서브 브랜치의 커밋을 merge했을 때, fast-forward 방식으로 merge된다. 작업 트리에서 보듯이 master는 해당 브랜치의 커밋을 그대로 가져올 뿐이다.
  2. 3rd-branch merge 시: master에 수정사항이 있는 경우(2nd-branch로부터의 커밋 1개), non fast-forward 방식으로 merge된다. 이 때는 master가 3rd-branch의 커밋을 그대로 가져오기는 하지만, merge commit(90ce4f2)이라는 새로운 커밋이 생성된다.

보충 설명은 다음과 같다.

  1. 빨간색 글씨로 (origin/master)이라 되어 있는 부분이 있다. 이는 remote repo의 HEAD가 현재 local repo의 어떤 커밋까지 적용되어 있는지를 의미한다. 여러분은 ‘This is 1st commit written in 1st-branch’까지만 remote repo에 push했기 때문에, 현재 remote repo는 그 위치에 멈춰 있다. 이후에 push를 하면 위치가 바뀔 것이다.
  2. master의 로그를 보면,
    1. (origin/master) 이후에 (2nd-branch)가 있다. 이는 2nd-branch로부터 (merge하여) 가져온 커밋임을 의미한다. 바로 다음의 (3rd-branch)도 마찬가지이다.
    2. (HEAD -> master)는 이전에 잠깐 설명했었는데, 현재 위치(HEAD)를 나타내는 동시에 현재 브랜치의 이름을 나타낸다.
  3. 로그를 출력한 그림의 맨 윗부분을 보면, “Your branch is ahead of ‘origin/master’ by 3 commits”라는 문구가 있다. 이는 조금 전 설명과도 일치하는 부분인데, 여러분의 local repo의 master가 remote repo의 master보다 3개의 커밋만큼 수정사항이 더 많다는 뜻이다. 3개의 커밋은 각각 (origin/master) 커밋 이후의 커밋들 3개이다.
    1. (2nd-branch) This is the 1st commit written in 2nd-branch
    2. (3rd-branch) This is the 1st commit written in 3rd-branch
    3. (HEAD -> master) Merge branch ‘3rd-branch’
  4. 그럼 왜 2nd-branch와 3rd-branch로 checkout했을 때는 그런 메시지가 없는지 알 수 있을 것이다.
    1. 2nd-branch와 3rd-branch는 push한 적이 전혀 없다. 즉, remote repo에는 해당 브랜치들에 대한 정보가 전혀 없다. 브라우저를 켜서 확인해보라.

이제 local repo의 master의 변경사항을 remote repo에 업데이트하자.

git status
git push

11_push

master에서는 파일을 직접 수정하지 않고 merge만 했기 때문에, git addgit commit 명령이 따로 필요 없다.

12_browser


Ticket branch 업데이트

티켓 브랜치(서브 브랜치)의 로그는 master의 로그보다 조금씩 적었다. 그 이유는 master에는 모든 수정사항이 적용되었지만, 2nd-branch와 3rd-branch는 각각 상대 서브 브랜치의 수정사항이 적용되어있지 않기 때문이다.

물론 2nd-branch와 3rd-branch는 각각 서로 부모 자식 간의 관계가 아니기 때문에, 서로 직접 상호작용할 이유는 없다.
상호작용은 직접 연관된 master와만 하면 된다.

master에 적용된 수정사항(자신의 것이 아닌, 팀원이 만든 커밋을 가져온다)을 가져오고 싶으면 다음을 수행하라.
바로 push까지 수행한다.

git checkout 2nd-branch
git rebase master
git push –set-upstream origin 2nd-branch

13_2nd

위의 그림에서 “Fast-forwarded 2nd-branch to master.”라는 문구를 볼 수 있다. 2nd-branch에서 더 이상의 수정사항이 발생하지 않은 상태에서 master의 커밋을 가져왔기 때문에 fast-forward 조건이 성립하고, 이를 확인할 수 있다.

다음 명령들을 수행하여 master의 로그와 비교하면 2nd-branch의 로그와 커밋 코드가 완전히 같아졌음을 볼 수 있다.

git checkout master
git log –oneline

팀원의 브랜치도 업데이트해 주자.

git checkout 3rd-branch
git merge master
git push –set-upstream origin 3rd-branch

이 경우에는 merge나 rebase나 별다른 차이가 없다.

이제 브랜치의 기본적인 내용은 끝났다.


Merge vs Rebase

브랜치 간 병합을 수행할 수 있는 명령은 merge와 rebase가 있는데, 간략히 차이를 적어 보면 다음과 같다.

Merge: git merge <branch>로 사용. 해당 브랜치의 변경사항을 현재 브랜치로 (그대로) 가지고 온다. 이때 가져온 커밋들은 현재 HEAD의 위쪽에 그대로 쌓인다. 경우에 따라 Merge commit이 남을 수 있다.
Rebase: 이름 그대로 base를 바꾸는 것이다. base가 되는 커밋의 위치를 바꾼다.

base를 예시를 들어 설명하면,

  1. 3rd-branch는 master에서 생성되었다. 이때 생성 시점은 master가 “6df3479 This is 1st commit written in 1st-branch” 커밋까지 포함한 상태였다. 여기서 3rd-branch의 base는 바로 이 커밋이다.
  2. git rebase master 명령을 실행하면, master의 tip(HEAD) 으로 base를 재설정한다. 그러면 master의 커밋들로부터 시작한 셈이 되므로, master의 커밋들을 가져온 결과와 같다.

Merge와 rebase는 사용법이 조금 다르다. 이는 나중에 설명하도록 하겠다.
사람에 따라서는 별 구분 없이 사용하기도 한다.


이제 git의 branch에 대한 기본적인 설명을 알아보았으니, 다음 글에서는 브랜치를 관리하는 법에 대해서 알아본다.


Git 명령어

GitHub 사용법 - 00. Command List에서 원하는 명령어를 찾아 볼 수 있다.

Comment  Read more