FIX 

가장 자주 사용되는 커밋 로그 중 하나로 'Fix'가 있습니다. 보통 올바르지 않은 동작을 고친 경우에 사용합니다.


Fix A  - A를 수정합니다
  • Fix stat cache
  • Fix changelog entry

Fix A in B - B의 A를 수정합니다.

가장 자주 사용되는 패턴입니다.

  • Fix calculation in process.uptime()
    • process.uptime()에 calculation을 수정합니다.
  • Fix build warning in node_report.cc
    • node_report.cc에 빌드 경고를 수정합니다.

Fix A which B , Fix A that B - B절인 A를 수정합니다.

'Fix A'로 끝낼 수 있으나 무엇을 수정한 것인지 상세하게 설명할 때 주로 사용합니다.

  • Fix incorrect type which makes animated gifs not loop forever on device
    • 디바이스에서 애니메이션 gif가 반복되지 않는 잘못된 타입을 수정합니다
  • Fix crash that happens when a component throws an exception that contains a null message
    • 컴포넌트가 null 메세지를 포함하는 예외를 발생시키는 경우 발생하는 충돌을 수정합니다

Fix A to B , Fix A to be B - B를 위해 A를 수정합니다

왜 수정하는지를 추가로 설명합니다

  • Fix inability to remove 'Disabled' state from AccessibilityStates
    • 'Disabled' 상태를 AccessibilityState에서 제거할 수 없는걸 수정합니다
  • Fix HTTP connection timeout callback to be appropriately called
    • 적당한 호출을 위해 HTTP 연결 시간 초과 콜백을 수정합니다

Fix A so that B - A를 수정해서 B가 되었습니다

'Fix A to B'와 의미는 비슷하나, 어감이 조금 다릅니다. 고쳐진 B의 상태가 강조됩니다.

  • Fix react-native init --help so that it doesn't return undefined
    • react-native init --help를 수정해서 정의되지 않은 상태로 반한되지 않습니다

Fix A where B - B처럼 발생하는 A를 수정했습니다

여기서 A는 보통 'issue', 'error', 'crash' 등이 들어가고 B는 문제가 발생한 모습을 적어줍니다.

  • Fix case where content of inline views didn't get relaid out
    • 인라인 뷰의 내용이 전달되지 않는 케이스 수정했습니다.

Fix A when B - B일 때 발생하는 A를 수정했습니다

A는 보통 'issue', 'error', 'crash' 등이 들어가고 B는 문제가 발생한 모습을 적어줍니다.

  • Fix crash when removing root nodes
    • 루트 노드를 제거할 때 발생하는 충돌을 수정했습니다
Reference

 

 

'Git' 카테고리의 다른 글

초간단 Git 사용법  (0) 2017.09.08
1.Git 시작하기  (0) 2017.08.30

이번에는 Git에 대한 사용법을 먼저 익히고 싶은 사람들을 위한 글입니다. 그래서 명령어를 중심으로 글을 작성하겠습니다.

우선 Git을 먼저 다운받도록 하겠습니다. Git(https://git-scm.com/) Git 홈페이지를 들어가서 Git을 다운 받으시면 됩니다.

 

 

그럼 Git이 설치 되었다는 가정하에 진행하도록 하겠습니다.

 

Git을 이용해서 GitHub와 연동되어 사용을 하고 싶은 분들이 많을 것이라고 생각됩니다.

그럼 우선 GitHub에 가서 로그인을 하고 난 다음에 Start a project 버튼을 눌러주도록 합니다.

 

 

그러면 아래와 같은 페이지가 나타나게 됩니다.

 

그러면 Repository name에 저장할 이름을 설정해 주고 Description 에 이 저장소에 대한 설명을 작성해주고 생성해 주면 됩니다.

그리고 나면 아래와 같은 페이지가 나오는데 첫번째 칸(빨간 네모칸)에 쓰여있는 명령어대로 실행을 해주시면 됩니다.

아니면 이미 저장소가 있다면 두번째 칸(파란 네모칸)에 쓰여있는 명령어를 이용하면 됩니다.

일일이 쓰기 귀찮으면 옆에 복사버튼이 있으니 누르고 CMD창에서 붙여넣기만 해주면 됩니다.

 

GitHub에서의 준비는 이것으로 끝입니다. 저장소만 만들어 주면 됩니다. 간단하죠?

그럼 이제 D드라이브로 이동해서 작업할 폴더하나를 만들겠습니다. GitHub와 연동해보도록 하겠습니다.

먼저 CMD창을 열어 명령어를 순서대로 작성을 하면됩니다.

 

 

1
2
3
4
5
6
7
8
9
d:                //D드라이브로 이동합니다
mkdir Git_test    //mkdir은 폴더를 생성하는 명령어 입니다. Git_test 라는 이름의 폴더를 생성합니다.
cd Git_test        //cd는 디렉토리를 이동할 수 있는 명령어입니다. Git_test 폴더로 이동합니다.
echo "#Git_test" >> README.md    //내용이 #Git_test인 README.md라는 파일을 생성합니다.
git init        //현재 폴더에 git저장소를 생성합니다.
git config user.name "YOUR NAME" //사용자명을 등록하는데 꼭 작성해줘야합니다.
git config user.email "YOUR EMAIL" //사용자의 이메일을 등록하는데 꼭 작성해줘야합니다.
git add README.md  //git이 README.md라는 파일을 추적하도록 스테이징 영역에 올려줍니다. 쉽게말하면 git은 add된 것만 관심을 가집니다.
git commit -"first commit" // -m 옵셥을 이용해서 커밋할 때 변경사항에 대한 메시지를 작성할 수 있습니다.
cs

 

 

remote add origin " 깃허브 저장소 " 를 적어주면 되는데요 빨간 네모칸에 쓰여있는 내용그대로인데 길어서 쓰기 귀찮다면 위쪽에 https|SSH 로 되어있는 이곳의 오른쪽에 복사할수 있는 버튼이 있습니다. 그 버튼 눌러다 붙여넣기를 해도 됩니다.

 

1
2
git remote add origin https://github.com/SeungHyunBaek/Git_test.git    //원격저장소를 추가합니다. github에 저장할 저장소입니다.

                                                                      //origin은 추가하는 원격저장소의 이름입니다.

git push -u origin master    //작업한 내용들을 github에 저장합니다.

cs

    

그러면 아래처럼 github에 commit했던 부분까지 원격저장소에 저장된 것을 볼 수 있습니다. 간단하죠?

 

 

초간단 Git 사용방법이었습니다.

'Git' 카테고리의 다른 글

Commit 메세지 작성 : Fix 편  (0) 2020.02.18
1.Git 시작하기  (0) 2017.08.30

오늘은 분산 버전 관리 시스템인 Git 에 대해서 알아보도록 하겠습니다.

Git을 통한 프로젝트 관리는 유용하고 많은 도움이 될 것이라 생각됩니다. 저는 Windows환경에서 진행했음을 알려드립니다.

먼저 간단히 진행 순서를 알려드리겠습니다.

 

1. 저장소 생성하기

2. 파일 추가하고 변경하기

3. 새 브랜치 만들기

4. 릴리스에 태그 붙이고 저장소 관리하기

5. 저장소 복제하기

 

위의 과정을 진행하도록 하겠습니다. ( Git 이 다운받아져 있다는 전제하에 진행하겠습니다. )

 

1. 저장소 생성하기

Git 에서 저장소를 생성하는 방법은 간단하지만 서브버전이나 CVS를 사용해왔다면 조금 이상해 보일 수 있습니다. 대부분의 버전 관리 시스템에서 저장소는 자신이 가지고 있는 복사본과 떨어져 존재하지만 Git에서는 작업 트리와 함께 .git 디렉토리에 저장됩니다.

 

그럼 먼저 Git bash를 열고 프로젝트 코드를 저장할 위치를 정할건데요. 프로젝트 이름은 mysite 라고 정하겠습니다. 프로젝트 이름과 같은 디렉토리를 생성하고 디렉토리 안으로 이동한 다음 git init 이라는 명령어를 입력해주면 됩니다.

 

이것으로 끝입니다. 이제 프로젝트를 추적할 수 있는 Git 저장소가 생겼습니다.

이게 전부일리 없다고 생각할지 모르지만 정말로 더 이상 없습니다. Git 저장소를 설정하는 작업은 정말로 간단합니다.

git init 명령어는 .git 디렉토리를 생성하고 여기에 저장소 메타데이터를 모두 저장합니다. 그리고 현재 비어있는 mysite 디렉토리는 저장소에서 체크아웃 할 코드의 작업 트리가 됩니다.

 

2. 파일 추가하기

이제 빈 저장소에 파일을 추가하겠습니다. index.html 파일을 생성하고 헤더와 'Hello World!'란 텍스트를 추가합니다.

index.html

1
2
3
4
5
<html>
<body>
 <h1>Hello World!</h1>
</body>
</html>
cs

추적을 시작할 간단한 HTML 페이지다. 계속해서 이 파일에 내용을 추가합니다.

이제 추적할 파일이 생겼으니 Git에게 이 파일을 추적하겠다는 사실으르 알립니다.

Git에게 알리는 작업은 두 단계에 걸쳐서 진행됩니다. 먼저 git add 명령어로 HTML 파일을 Git의 관리 목록에 추가합니다. 그러고 나서 git commit으로 커밋합니다.

 

 

 

 추적 하려는 파일이나 파일의 목록을 git add에 매개변수로 전달합니다. 그리고 git commit은 커밋을 생성합니다.

커밋은 저장소에 저장된 개별적인 이력으로, 각 커밋은 코드의 진행 상태를 기록합니다. Git은 앞에서 설정한 내용을 참조해서 사용자의 이름과 이메일 주소를 기록하고 각 커밋에 메시지를 추가합니다.

 앞의 명령어에서 -m 다음의 문자열이 커밋에 추가되는 메시지입니다. 잘 작성한 로그 메시지는 모든 버전 관리 시스템의 핵심 요소로, 로그 메시지에 커밋하는 이유를 설명합니다. 새 파일이 무엇을 하는지? 코드에서 무엇을 변경했는지? 를 알 수 있습니다.

 git log 를 실행하면 지금까지의 커밋 내용을 볼 수 있습니다.

 

 

 

첫 줄에서 커밋명을 보여줍니다. 커밋명은 커밋을 추적할 수 있도록 Git이 생성한 SHA-1 해시(hash) 값입니다. Git은 각 커밋의 식별자가 완벽히 고유하도록 SHA-1 해시를 이용합니다. 분산 환경에서는 완벽히 고유하다는 점이 중요합니다.

git log 출력의 둘째 줄은 커밋한 사람의 정보입니다. 셋째 줄은 커밋한 날짜고, 마지막 줄은 커밋 로그 메시지입니다.

 

3. 프로젝트를 이용한 작업 시작하기

이제 저장소를 준비했으며 이미 첫 번째 파일을 추적하고 있습니다. 이제부터 변경 사항을 다뤄보겠습니다.

지금까지 HTML에 <head>와 <title> 엘리먼트가 빠져 있었습니다. 엘리먼트를 추가한 index.html 파일은 다음과 같습니다.

index.html

1
2
3
4
5
6
7
8
<html>
<head>
 <title>Hello World in Git</title>
</head>
<body>
 <h1>Hello World!</h1>
</body>
</html>
cs

 

방금 파일을 변경했음을 Git도 알고 있습니다. git status 명령어는 저장소의 현재시점인 작업 트리의 상태를 보여줍니다.

서브버전이나 CVS 사용자는 작업 트리를 작업 복사본이라고 알고 있습니다.

 

 

출력 결과를 통해 변경된 파일을 Git이 알고 있지만 이를 어떻게 처리할지는 아직 모른다는 사실을 알 수 있습니다.

변경한 파일은 수정된 파일(modified)로 표시되지만, 갱신 전(Changed but not updated) 헤더에 있습니다. 이 파일을 커밋하려면 변경 사항을 스테이징(stage)해야 합니다. 변경 사항을 스테이징하면 커밋할 수 있도록 준비합니다. Git에서는 사용자의 코드를 세 곳에 저장합니다.

첫째 위치는 파일을 편집할 때 직접 이용하는 작업트리다.

둘째 위치는 인덱스이며 이후에는 스테이징 영역(staging area)이라 부릅니다. 스테이징 영역은 작업 트리와 저장소 사이의 버퍼(buffer)공간입니다.

마지막 위치는 Git이 코드를 저장하는 저장소입니다. 스테이징 영역은 저장소에 커밋하려는 대상만 올려두는 용도로 사용합니다.

이제 git add 명령어를 다시 이용하면 index.html 파일의 변경 내용을 스테이징할 수 있습니다. 이전에 새 파일을 추가하기 위해서 사용한 명령어와 동일합니다. 다만 새로운 파일임을 알리는 용도가 아니라 추적할 새로운 변경 내용이 있음을 Git에게 알립니다.

 

 

수정된 index.html 파일을 추가한 다음 git status 명령어를 실행하면 헤더 영역이 갱신 전에서 커밋 예정(Changes to be commit-ted)로 바뀐 것을 확인할 수 있습니다. 색상 출력을 켜놨다면 index.html을 가리키는 줄의 색이 빨간색에서 녹색으로 바뀐 것도 볼 수 있습니다.

그럼 git commit 명령어를 실행해보겠습니다. 이때, -m 매개변수를 이용해서 변경한 이유를 설명한 것도 잊지 말아야합니다.

 

 

두 개의 -m 매개변수를 사용했습니다. Git에서는 원하는 대로 -m 매개변수를 사용할 수 있고, 매개변수마다 하나의 문단으로 취급합니다.

git log로 메시지가 두 개의 문단으로 구성됨을 확인할 수 있습니다.

 

 

git log 명령어에 새로운 매개변수 -1을 이용했습니다. 숫자를 변경하면 보고 싶은 커밋 개수만큼 git log의 출력을 제한할 수 있습니다.

 

4.브랜치 사용하고 이해하기

브랜치를 이용하면 작업 중인 프로젝트의 분기 이력을 관리할 수 있습니다. 분기 이력이 훌륭하긴 하지만 실제 프로젝트에서는 어떻게 사용해야 할까요? 실제 유용한 형태의 브랜치는 두 가지가 있습니다. 바로 프로젝트의 여러 버전을 브랜치 별로 관리하기 위해 생성한 브랜치와 특정 기능을 다루는 주제 브랜치입니다. 저는 첫번째 형태의 브랜치를 다루도록 하겠습니다.

mysite코드는 릴리스 준비가 거의 끝났지만 그래도 관련된 사람들에게 승인을 받아야 합니다. 승인을 기다리는 중에도 다음 버전의 새로운 기능을 추가할 수 있습니다.

브랜치를 이용하면 릴리스 준비가 된 코드의 복사본을 보관해둘 수 있으므로 개발을 멈출 필요가 없습니다. 브랜치를 생성하는 명령어는 git branch이며 매개변수를 두 개 받습니다. 첫번째는 생성하려는 브랜치명이고 두번째는 분기해 나올브랜치명입니다.

 

 

이 명령어는 master 브랜치에서 RB_1.0이라는 브랜치를 생성합니다. Git에서 master는 기본 브랜치명입니다. CVS나 서브버전에서는 Git의 master 브랜치와 같은 역할을 트렁크(trunk)라고 부릅니다. 브랜치명에서 사용한 RB는 릴리스 브랜치(release branch)의 약어입니다. RB라는 접두어를 붙이면 릴리스 브랜치를 파악하기 쉬워집니다.

이제 릴리스 준비 중인 코드에 영향을 주지 않고도 내용을 변경할 수 있습니다. index.html 파일에 약력(Biography) 페이지로 가는 링크를 추가합니다.

</body> 태그 앞에 다음 내용을 추가합니다.

 

index.html

1
2
3
4
5
6
7
8
9
10
11
<html>
<head>
 <title>Hello World in Git</title>
</head>
<body>
 <h1>Hello World!</h1>
 <ul>
  <li><a href="bio.html">Biography</a></li>
 </ul>
</body>
</html>
cs

 

이제 변경사항을 커밋하겠습니다. 이전과는 조금 다른 형태의 명령어를 사용합니다.

 

 

 

출처 : Git, 분산버전관리시스템

 

 

 

'Git' 카테고리의 다른 글

Commit 메세지 작성 : Fix 편  (0) 2020.02.18
초간단 Git 사용법  (0) 2017.09.08

+ Recent posts