안경잡이개발자

728x90
반응형

  깃(Git)을 활용하다 보면 자신이 수행한 다양한 작업(Commit)을 되돌리고 싶을 때가 있습니다.



  기본적으로 특정한 Git Hub의 저장소와 동일한 프로젝트를 가지도록 git pull 명령어를 수행해 봅시다. git pull 명령어는 원격지에 있는 소스코드를 우리 컴퓨터에 그대로 가져오고, 자동으로 merge까지 수행해주는 명령어입니다. 저는 이미 Git Hub의 소스코드와 제 컴퓨터의 소스코드가 정확히 일치하기 때문에 별도로 바뀐 사항이 없다는 메시지가 출력됩니다.


※ 특정 지점으로 프로젝트 자체를 되돌리기 ※


  특정한 지점으로 프로젝트 자체를 되돌리는 방법을 소개해드리겠습니다. 일단 기존에 있는 특정한 소스코드를 수정해보세요. 저는 하나의 함수를 추가해보았습니다. 제가 추가한 함수는 mul() 함수에요.



  이후에 다음과 같이 수정된 내역을 반영해보도록 하겠습니다.



  결과적으로 푸시까지 한 번 진행해 보았습니다. 커밋 및 푸시 내역은 git log 명령어를 통해서 확인할 수 있어요.



  저는 예전에 커밋(Commit)이 진행되었던 위치로 돌아가고자 합니다. 이 때 사용할 수 있는 명령어는 git reset 명령어입니다. 특정한 지점의 해시 값을 그대로 복사하여 git reset --hard 명령어로 돌아가도록 하겠습니다. 이 경우 돌아간 지점의 이후 내역은 증발해버리게 됩니다.


  이처럼 돌아간 지점의 이후 내역들은 완전히 지워버리고자 한다면 hard 옵션을 사용할 수 있습니다. 또한 만약에 돌아간 이후의 내역들을 남겨놓고자 한다면 soft 옵션을 사용할 수 있습니다. 기본 옵션은 mixed 옵션으로, mixed 옵션을 사용하면 돌아간 이후의 변경 내역들은 남아있지만 인덱스 값들이 모두 초기화됩니다.



  실제로 특정한 지점으로 돌아가보았습니다.



  정말 그 당시 커밋했던 것과 동일한 프로젝트 구성으로 돌아가게 되었습니다. 이 경우, 우리 로컬 컴퓨터에서의 프로젝트 구성이 Git Hub 저장소의 구성과 다르게 됩니다. 그래서 푸시(Push)를 진행하려고 해도 오류가 발생합니다. 이 때는 -f 옵션으로 강제로 푸시를 할 수 있습니다.



  이처럼 강제로 푸시를 하게 되면 Git Hub 저장소에서도 완전히 특정한 지점으로 프로젝트가 되돌아간 것을 확인할 수 있습니다.


  이제 한 번 커밋 메시지를 변경하는 방법에 대해서 알아보도록 하겠습니다. 다음과 같이 저는 하나의 함수를 추가해서 커밋을 해보았습니다.




  이후에 하나의 함수를 추가적으로 더 만든 상황이 되어 커밋 메시지를 변경하고자 한다고 가정해봅시다. 저는 sub() 함수를 추가했어요.



  이 때는 git commit --amend 명령어를 사용할 수 있습니다.



  그러면 자동으로 에디터가 열려서 커밋 메시지를 수정할 수 있어요. 저는 첫 번째 줄의 커밋 메시지를 바꾼 뒤에 저장했습니다.



  이후에 다시 git push을 진행하여 변경된 커밋 메시지가 반영된 것을 확인할 수 있습니다.



728x90
반응형

728x90
반응형

  이번 시간에는 소스코드를 수정해서 Git 저장소에 반영하는 방법에 대해서 알아보도록 하겠습니다. 이전 강좌에서는 깃 허브(Git Hub)에서 하나의 저장소를 생성하여, 초기 프로젝트 구성을 올리는 방법에 대해서 알아보았습니다.


  소스코드를 수정해서 Git 저장소에 반영하는 방법도 이전 시간에 배웠던 내용과 거의 동일하다고 보시면 됩니다. 일반적으로 소스코드를 수정하는 것은 두 가지 사례로 나뉘게 됩니다.


① 해당 프로젝트에 소속된 사람이 아닌 경우


  만약 우리가 특정한 커뮤니티(Community)의 구성원이 아니라서 스스로 커밋을 하여 저장소에 적용할 권한이 없다면, 소스코드를 수정하는 것에 제약이 있습니다. 이런 경우 PR(Pull Request)를 작성하여 오픈소스에 기여할 수 있습니다.


  이 경우는 우리가 큰 오픈소스 프로젝트의 구성원으로 참여하고 싶을 때 사용하는 방법입니다. PR에 수정 사항 등을 담아서 전송하면, 해당 오픈소스의 관리자가 이를 허용했을 때 실제로 오픈소스에 반영이 될 수 있습니다.


② 해당 프로젝트에 소속된 사람인 경우


  자신이 해당 프로젝트에 대한 권한을 가지고 있으므로 그냥 커밋(Commit)하고 푸시(Push)해서 저장소에 수정 내역을 반영하면 됩니다.


※ 소스코드 수정하여 Git 저장소에 반영하기 ※


  우리는 초보자이므로, ②번 케이스를 따라서 우리가 만든 깃 저장소에 수정된 내역을 반영하는 방법에 대해서 알아보도록 하겠습니다.


  


  저는 위와 같이 이전에 실습을 위해 만들었던 깃 허브 저장소를 확인해보겠습니다.


  


  깃 허브 주소가 https://github.com/ndb796/Git-Study입니다.


  


  실습을 위해 특정한 폴더를 생성하여 그 폴더로 클론(Clone)을 받아보겠습니다. 말 그대로 프로젝트 폴더를 다운로드 받겠다는 소리입니다.



  그러면 위와 같이 다운로드가 완료됩니다.



  이제 소스코드를 수정해보겠습니다. 위와 같이 하나의 파일을 만들어서 add() 함수를 작성해 볼게요.



  이후에 git add 명령어를 이용해 우리가 수정한 파일을 Staging Area에 올릴 수 있습니다. git status 명령어를 입력하면 현재 프로젝트의 상태를 확인할 수 있습니다. 새로운 파일(New File)로 하나의 소스코드가 등록된 것을 확인할 수 있습니다.



  Staging Area에 올린 파일을 다시 내리고자 한다면 git reset 명령어를 이용할 수 있습니다. 이후에 git status로 상태를 확인해 보면 my_module.py 파일이 제외된 것을 확인할 수 있습니다. 더불어 커밋할 파일은 없다는 메시지가 출력됩니다.



  아무튼 실습을 위해 일단 작성된 파일을 커밋해보도록 합시다. 커밋 이후에는 성공적으로 하나의 커밋이 완료되었다는 메시지가 출력됩니다. 이제 이를 git push 명령어로 깃 허브의 저장소로 변경된 내역을 반영할 수 있습니다.



  성공적으로 반영이 완료되었습니다. Git Hub 주소로 가보시면 이를 확인할 수 있어요.



  이제 한 번 하나의 함수를 더 추가해 보겠습니다.



  단순히 함수를 추가한 이후에 git status 명령어를 입력해 보시면 수정만 이루어진 파일이 존재한다는 메시지가 출력됩니다.



  특정 파일에 대해서 수정한 내역을 무시하고, 다시 저장소에 기록된 내용으로 되돌리고자 할 때는 git checkout -- 명령어를 이용할 수 있습니다.



  git checkout 명령어를 이용한 이후에 다시 파일을 확인해 보시면 위와 같이 소스코드가 원래 상태로 돌아온 것을 확인할 수 있습니다.



  저는 다시 sub() 함수를 추가하여 커밋을 진행해보도록 하겠습니다.



  git add . 명령어로 프로젝트에서 변경된 모든 소스코드를 Staging Area에 올렸습니다. 이후에 git push 명령어로 소스코드를 실제 Git Hub 저장소에 반영한 것을 확인할 수 있습니다.



728x90
반응형

728x90
반응형

  기본적으로 깃(Git) 프로젝트에 담겨 있는 데이터들은 파일 시스템 상에서의 스냅샷(Snapshot)이라고 볼 수 있습니다. 실제로 프로젝트를 커밋(Commit)하여 적용할 때의 순간을 중요시한다는 특징이 있습니다. 파일 자체를 저장하기보다 수정 내역 자체를 저장합니다.


  Git의 동작 원리를 바르게 이해하기 위해서는 Git 프로젝트의 세 가지 구성요소에 대해서 이해할 필요가 있습니다.


  - Working Directory: 작업할 파일이 있는 디렉토리입니다.

  - Staging Area: 커밋(Commit)을 수행할 파일들이 올라가는 영역입니다.

  - Git Directory: Git 프로젝트의 메타 데이터와 데이터 정보가 저장되는 디렉토리입니다.


  깃 프로젝트는 위와 같은 구성요소를 통해 동작하게 됩니다. 그렇다면 실제로 소스코드를 수정하는 등의 작업을 해서 커밋(Commit)하고, 다시 저장소에 있는 수정 내역을 자신의 컴퓨터로 옮기는 과정들은 어떻게 이루어지게 되는 걸까요?


  아래 첨부 파일은 제가 간단히 그려 본 Git의 기본적인 동작 과정입니다.


Git 동작 과정.xml



  이전 시간에 실습을 통해서 간단히 다루어 본 내용입니다. 원격지에 있는 저장소(Remote Repository)에서 맨 처음에 클론(Clone)을 받으면, 자신의 컴퓨터에 해당 프로젝트가 통째로 다운로드가 된다고 말씀 드렸습니다.


  이후에 자신이 수정한 내역을 다시 원격지 저장소까지 반영하려면 git add, git commit, git push의 과정을 거쳐야 합니다. 이후에 다시 저장소로부터 수정된 내역을 받을 때에는 git fetch를 수행합니다. 다만, 이러한 과정에서 내가 수정한 내역이 원격지 저장소에 있는 내역과 다를 수 있기 때문에 git merge를 수행하여 자신의 컴퓨터에 있는 소스코드를 원격지 저장소와 맞추는 것입니다.


  더불어 git fetch와 git merge를 한 번에 사용하는 명령어인 git pull를 사용할 수도 있습니다.


※ 저장소(Repository)에 대해서 ※


  저장소(Repo)실제 소스코드가 담겨 있으면서 커밋(Commit) 내역 등의 모든 작업 이력이 담겨 있는 공간을 의미합니다. 실제로 프로젝트의 메타 데이터를 포함해 각종 데이터는 .git 폴더에 담기게 됩니다. 실제로 이 폴더를 열어 보면 각종 데이터와 해시 값 등이 담겨 있습니다.


  어떠한 파일을 Commit 하게 되면 각 작업들을 분류하기 위해 내부적으로 해당 작업에 대한 해시(Hash) 값을 이용하는 것입니다. 일반적으로 해시 값은 충돌이 발생하지 않기 때문에 정확히 커밋 내역들을 관리할 수 있습니다.

728x90
반응형

728x90
반응형

  깃(Git)을 이용하면 하나의 프로젝트를 여러 사람들과 함께 효과적으로 관리하여 협업할 수 있습니다. 실제로 오픈소스를 효과적으로 관리하기 위한 목적으로 깃이 만들어 졌으므로 깃은 실제 프로젝트에 적용하기에 매우 적합합니다.


  여러분이 하나의 프로젝트를 여러 사람과 함께 작업한다고 해봅시다. '동시에' 프로젝트를 작업해야 한다는 점에서 매우 큰 난항을 겪을 수 있습니다. 소스코드를 여러 명이 동시에 보면서, 소스코드를 수정해야 하는데 이러한 작업은 깃(GIt)과 같은 협업 관리 도구가 없으면 쉽지 않습니다.


  깃(Git)은 여러 명이 병렬적으로 개발을 할 수 있게 해준다는 점에서 프로젝트 개발 속도를 매우 빠르게 해줍니다. 실제로 리눅스를 포함해서 다양한 오픈소스 프로젝트들은 수천 명이 넘는 개발자가 포함되어 있는데, 이들의 작업 내역을 어떻게 효과적으로 관리할 수 있는지를 깃(Git)을 제대로 배웠을 때 바르게 이해할 수 있습니다.


  무엇보다 깃(Git)을 사용할 때 얻을 수 있는, 개발자의 현실적인 장점포트폴리오 관리에도 용이하다는 겁니다. 깃 허브(Git Hub)에 자신이 작업한 프로젝트를 나열하여 얼마나 주기적으로 프로젝트를 관리하고 있는지 모두 드러나기 때문입니다.


※ 깃을 사용하지 않는 경우 ※


  깃을 사용하지 않으면 소스코드를 USB에 담아서 다른 사람의 컴퓨터로 옮기는 방식 등으로 프로젝트를 공유해야 합니다. 그러면, A라는 사람이 수정한 내역이 B라는 사람에게 즉각적으로 전달이 안 되기 때문에 A와 B가 동시에 프로젝트를 작업하기는 어렵습니다. 실제로 저는 깃을 사용하는 방법을 모르는 2년 전에 해커톤에 나간 적이 있었는데요. 카카오톡으로 프로젝트를 주고 받으면서 개발한 기억이 납니다. (그럼에도 불구하고 당시 최우수상 수상)


  혹은 깃 대신에 서브버전(Subversion)을 사용할 수 있습니다. 줄여서 SVN이라고도 부르는 이것은 Git이 활발하게 이용되기 이전에 많이 사용되었던 협업 관리 도구입니다. SVN은 기본적으로 중앙 서버가 존재한다는 점에서 Git과는 차이점이 존재합니다. 서브버전 자체도 오픈소스라는 특징이 있으며, 저는 Git 세대라서 서브버전을 사용해 본 적은 없습니다.


※ 깃을 사용하는 경우 ※


  앞서 다루어 본 SVN은 각 컴퓨터가 중앙 서버처럼 사용하는 컴퓨터로부터 파일을 다운로드 받아 이용하는 방식입니다. 깃(Git)은 중앙 서버의 개념이 없으며 중앙 서버처럼 사용하는 컴퓨터가 있다고 하더라도, 그 서버가 망가졌을 때 다른 컴퓨터로부터 소스코드를 복구할 수 있다는 특징이 있습니다.


※ 깃의 장점 ※


- 분산적인 개발: 깃(Git)을 사용하는 전체 개발 내역을 각 개발자의 로컬 컴퓨터로 복사할 수 있습니다. 나중에 서로 수정된 내역을 합치기(Merge)할 수도 있으며 이 때 Git의 고유한 프로토콜을 이용하게 됩니다.


- 효율적인 개발: 깃(Git)은 일반적인 다른 버전 관리 시스템보다 성능이 뛰어나며, 변경 이력이 많더라도 변경된 내용만 처리한다는 점에서 메모리적인 효율성 또한 뛰어납니다.


- 비선형적인 개발: 깃(Git)은 브랜치(Branch)라는 개념이 사용됩니다. 다시 말해서 프로젝트의 가지치기가 가능합니다. 이는 트리 구조, 다시 말해서 비선형적인 구조라고 볼 수 있습니다.


- 변경 이력 보장: 작업된 모든 내역(Commit 내역)들은 모두 별도의 영역에서 관리되어 안전하게 프로젝트를 운영할 수 있습니다.


※ 깃을 쓰지 않았을 때 다루기 어려운 문제들 ※


  우리가 유명한 안드로이드 어플리케이션을 개발하고 있는 개발자라고 가정합시다.


  현재 사용자들이 이용하고 있는 배포 버전이 있는 상태에서, 우리는 새로운 기능을 개발하고 있습니다. 이 때 갑자기 배포 버전에 오류가 있다는 사실이 드러나서, 빠르게 배포 버전을 수정해야 하는 상황이 왔다고 해봅시다. 이 때 우리는 어떻게 효과적으로 프로젝트 수정을 처리할 수 있을까요?


  이러한 내용은 깃에 대해서 자세히 공부하면서 익힐 수 있게 됩니다.

728x90
반응형

728x90
반응형

  이번 시간에는 Git을 설치한 뒤에 기본적인 사용법에 대해서 알아보도록 하겠습니다. 정말 필요한 내용만 빠르게 다루어 보도록 하겠습니다. 일단 Git을 사용하기 위해서는 Git 저장소를 하나 만들어야 하는데요. 일반적으로 Git Hub에서 무료 저장소를 만들어서, 여기에다가 각종 소스코드를 올리곤 합니다. 소스 코드를 오픈 소스로 누구에게나 공개(Public) 설정을 한다면 Git Hub를 무료로 사용할 수 있습니다.


  ▶ 깃 허브(Git Hub): https://github.com/


  위 깃 허브 웹 사이트에 가입한 이후에 로그인을 해줍니다.


※ 깃 저장소 만들기 ※


  저장소는 말 그대로 소스코드가 저장되는 공간을 의미합니다. 쉽게 말해 하나의 '프로젝트(Project)'를 의미합니다.



  New Repository 버튼을 눌러서 새로운 저장소를 만들 수 있어요.



  일단 깃의 사용법을 연습하는 목적이므로 간단히 아무 이름이나 넣어서 저장소를 만들어 보도록 하겠습니다.



  결과적으로 Git Hub에 하나의 오픈 소스 프로젝트가 생성이 되었습니다. 그리고 이 저장소에 접근할 수 있는 공인 URL 주소가 생성됩니다. 이제 언제 어디에서나 이 프로젝트를 다운로드 받을 수 있게 된 거예요. 물론 지금 프로젝트는 텅텅 비어있지만요.


  그렇다면 이렇게 만들어진 저장소에 접근하여 프로젝트를 업로드하거나, 다운로드 하는 방법은 무엇일까요? 바로 Git 소프트웨어를 설치하는 겁니다. 말 그대로 Git이라는 것을 사용하도록 해주는 프로그램입니다.


  ▶ 깃 다운로드: https://git-scm.com/downloads


  깃을 다운로드 받아서 적절히 설치해줍니다.


  


  설치 이후에는 명령 프롬프트(CMD)에서 git이라고 입력을 해보면, 설치가 완료되어 각종 세부적인 명령어를 사용 여부를 확인할 수 있습니다.


  


  설치된 깃의 버전을 확인할 때는 git --version이라고 입력하시면 됩니다.


  


  이제 자신의 깃 허브 가입 내용과 동일하도록 이름 및 이메일을 입력하여 환경 설정을 진행합니다.


  ▶ git config --global user.name 유저명

  ▶ git config --global user.email 이메일



  이후에 테스트를 위해 간단히 특정한 경로에 폴더를 생성해주도록 합니다.



  명령 프롬프트에서 해당 경로로 이동하여 자신이 만든 원격지 저장소에서 다운로드할 수 있도록 합니다. 깃에서는 다운로드의 개념과 동일한 단어로 클론(Clone)이라는 단어를 사용합니다. 엄밀히 말하면 클론 이후에는 자신의 컴퓨터도 고유한 저장소가 되는 겁니다.


  ▶ git clone {클론 하고자 할 깃 URL}



  그러면 다음과 같이 저장소로부터 클론이 완료됩니다.



  실제로 클론된 폴더에 들어가 보면 다양한 환경 설정 정보가 담겨 있는 .git 폴더를 확인할 수 있습니다.



  기본적으로 윈도우에서는 이러한 환경 설정 폴더를 '숨김' 처리 해놓으므로, 만약 보이지 않으시는 분들은 '보기' 에서 '옵션'에 들어가 숨김 해제를 해주셔야 합니다.



  다음과 같이 확장명 숨기기를 체크 해제 해주시면 됩니다.



  이제 한 번 우리의 깃 프로젝트에 하나의 문서를 추가해봅시다. 소스 코드 등을 추가했다고 가정하는 거예요.



  이제 수정된 내역을 git add 명령어로 추가하고, 저장소에 반영하기 위해서 git commit 명령어를 사용합니다. 이후에 원격지 저장소인 Git Hub 저장소에 반영하기 위해서 git push 명령어를 사용하면 됩니다.


  ▶ git add {파일 이름}: 수정된 파일을 수정 내역에 추가합니다.

  ▶ git commit -m {커밋 메시지}: 수정된 내역을 저장소에 반영합니다. 반영이 되면 스냅샷(Snapshot)이 찍히게 되어 저장됩니다.

  ▶ git push: 원격지 저장소에도 수정 내역을 반영합니다.



  이제 다시 깃 허브로 이동해보시면 다음과 같이 파일이 추가된 것을 확인할 수 있습니다.




728x90
반응형

728x90
반응형

  오픈 소스(Open Source)란 '공개된 소스코드'를 의미합니다. 특정한 소프트웨어를 개발한 개발자의 권리를 지키면서 누구나 소스코드를 확인할 수 있도록 합니다. 소스코드가 공개된다는 것은 어떤 의미일까요? 맞습니다. 공짜(Free)입니다.


  오픈 소스는 대학교 시절 온갖 컴퓨터 과제의 도우미와도 같은 존재였습니다. 정말 없는 오픈 소스가 없거든요. 가장 대표적인 오픈 소스로는 제가 강의에서 굉장히 자주 다루었던 부트스트랩(Bootstrap)이 있습니다.



  (부트스트랩: 가장 유명한 웹 디자인 프레임워크 중 하나) 부트스트랩은 세계적으로 가장 큰 오픈 소스 저장소인 Git Hub에서 확인할 수 있습니다.



  오픈 소스 활동은 특정한 프로젝트를 오픈 소스로 만들어서 관리하는 행위, 컨트리뷰션(Contribution)하는 행위 등을 지칭합니다.


  컨트리뷰션은 말 그대로 기여한다는 의미이며 기능 추가, 보안 취약점 수정 등 뿐만 아니라 오타 수정, 번역, 의견 제시 등도 컨트리뷰션이라고 할 수 있습니다. 그렇기 때문에 사실상 누구나 컨트리뷰션을 할 수 있습니다.


  어떠한 이익도 없을 것 같은 오픈 소스 활동. 다시 말해 컨트리뷰션은 왜 할까요? 다양한 이유가 있지만, ① 오픈 소스 활동 자체는 공개된 기록으로 남기 때문에 구직 활동을 할 때 이력서에 활동 이력을 담을 수 있습니다. 그리고 ② 내가 작업한 새로운 기능을 다른 개발자들도 사용해보고, 이를 평가하여 개선시킬 수 있습니다.


  커미터(Committer)는 실제로 누군가 컨트리뷰션을 하면, 해당 내용을 리뷰하고 실제 프로젝트에 반영할지를 결정하는 사람입니다. 다시 말해 특정한 프로젝트를 오픈 소스로 만들어서 관리하는 사람들을 의미합니다.


  그렇다면 왜 프로젝트를 오픈 소스로 공개하여 누구나 볼 수 있도록 하는 걸까요?


  ① 사회 공헌

  ② 소프트웨어의 품질 향상

  ③ 어쩔 수 없이


  맞습니다. 어쩔 수 없이 오픈 소스로 공개하는 경우도 있습니다. 이는 오픈소스 라이센스 때문인 경우가 많은데요. 오픈 소스 라이센스는 대체 무엇일까요? 실제로 오픈 소스를 활용하여 개발할 때는 저작권 및 라이센스를 명시해야 합니다.


※ 오픈소스 라이센스 ※


  대표적인 오픈소스 라이센스 몇 가지만 알아봅시다.


 ▶ MIT License: 무료, 배포 가능, 소스코드 수정 가능, 2차 저작물 공개 의무 없음

 ▶ Apache License: 무료, 배포 가능, 소스코드 수정 가능, 2차 저작물 공개 의무 없음

 ▶ GPL: 무료, 배포 가능, 소스코드 수정 가능, 2차 저작물 공개 의무 있음

 ▶ Beerware: 만나면 그냥 술이나 사주자

728x90
반응형