첫번째: 오픈 소스 소프트웨어 개발을 위한 기본 개념과 도구 특히 소스 코드 버전 컨트롤과 패키지 관리, 프로젝트 빌드를 중점으로 배운다.
두번째: 애자일 기반 소프트웨어 개발 방법인 짝수 프로그래밍, 테스트 주도 개발, 행위 주도 개발, 클라우드 기반 데브옵스를 공부한다.
애자일 기반 소프트웨어는 애자일 방법론(Agile Methodology)을 적용하여 개발된 소프트웨어를 말합니다. 여기서 '애자일(Agile)'은 '민첩한', '기민한'이라는 뜻으로, 변화하는 요구사항에 유연하게 대처하고 빠르게 결과물을 제공하는 것을 목표로 합니다.
세번째: 새로운/낯선 소프트웨어 개발 환겨 및 도구를 스스로 배우는 태도를 배운는 것을 목적으로 한다.
오픈 소스 소프트웨어(Open Source Software, OSS)는 소스 코드가 공개되어 누구나 자유롭게 접근, 사용, 수정, 재배포할 수 있도록 허용된 소프트웨어를 말합니다.
이는 소프트웨어의 개발 과정과 사용에 있어 개방성, 투명성, 협업이라는 가치를 핵심으로 합니다.
완전히 자유롭게 오픈소스를 사용해도 되는가?(NO!!!)
OSS 라이센스를 지키며 사용할 수 있다.
지켜야 할 사항
- MIT 라이선스 코드를 포함하여 배포하는 모든 사본 또는 주요 부분에 원저작자의 저작권 고지(Copyright notice)와 MIT 라이선스 전문을 그대로 포함해야 합니다.
- 라이선스 전문에는 소프트웨어가 "있는 그대로(AS IS)" 제공된다는 조항이 포함되어 있습니다.
요약: MIT 라이선스는 "가져다 마음껏 써라. 단, 내 이름은 밝히고, 네가 쓸 때 발생하는 문제는 네 책임이다"라고 요약할 수 있습니다. 이러한 유연성 덕분에 React, jQuery, Node.js 등 수많은 인기 프로젝트에서 MIT 라이선스를 채택하고 있습니다.
'Octoverse' at Github 을 통해 확인 할 수 있습니다.
주요주장
- FREE SOFTWARE: 사용자가 소프트웨어를 통제하고, 소프트웨어가 사용자를 통제하지 못하도록 보장하는 것이 최우선입니다. 따라서 소프트웨어를 수정하고, 재배포할 때도 자유가 유지되도록 소스 코드 공개를 의무화하는 GPL(GNU General Public License) 같은 라이선스를 선호합니다.
- OPEN SOURCE SOFTWARE: 소프트웨어 개발 모델로서의 효율성을 강조하며, 기업들이 오픈 소스를 사용하는 것이 비즈니스적으로 더 합리적임을 설득합니다.
주의사항
- 여기서의 OPEN SOURCE SOFTWARE는 앞서 개념에 대해 설명한 OSS와는 다른 용어이다.
- FREE SOFTWARE의 free는 '공짜'가 아닌 '자유'이다
VCS
파일이나 파일 집합의 변경 사항 이력을 추적하고 기록하여, 필요할 때 이전 상태로 되돌리거나 변경 내용을 비교할 수 있도록 관리하는 체계적인 시스템입니다.
VCS software
- CVS (Concurrent Version System)
- SVN (Subversion)
- Mercurial
- Darcs
- Git (가장 대중적으로 사용되는 버전관리 소프트웨어)
Repository or repo(저장소):여러가지 버전들에 대한 파일이 저장되어있는 곳
- Checkin: 버전 관리하는 저장소로 내가 작업한 내용을 보내는 기능(Git에서는 commit이라는 명령어를 사용)
- Checkout: 버전 관리하는 저장소에서 내가 작업하는 곳으로 가져오는 기능
- Diffs: 내가 작업한 내용과 현재 버전과의 차이점을 보는 기능
- Branching: 프로젝트의 주요 코드 흐름을 분리하여 독립적인 환경에서 작업할 수 있게 해주는 기능
- Merging: 버전 관리 시스템(VCS)에서 브랜치(Branch)의 변경 사항들을 다른 브랜치로 통합하는 기능
- Conlifcts: 두 명(또는 그 이상)의 사용자나 두 개의 브랜치가 같은 파일의 같은 부분을 동시에 다르게 수정했을 때 일어난다.
- Taggings: 특정 커밋(Commit)에 영구적이고 의미 있는 이름표를 붙여서 특별한 시점을 기록하는 기능
GIT
"컴퓨터 파일의 변경 사항을 추적하고 여러 사용자 간에 해당 파일들의 작업을 조율하기 위한 분산 버전 관리 시스템(Distributed Version Control System, DVCS)입니다."
Git의 4가지 관리 영역
- Workspace: 개인의 작업공간
- Index: 버전 관리를 할 목록들
- Local repository: commit을 통한 로컬 저장소
- Remote repository: push를 통한 원격 저장소(ex.github사이트)
Git의 흐름과 명령어 정리
Git의흐름
명령어
- git add: 워킹 디렉토리(Working Directory)에서 수정한 파일을 스테이징 영역(Staging Area)에 추가합니다.
- git commit: 스테이징 영역에 있는 파일들의 변경 사항을 로컬 저장소에 버전으로 기록(커밋)합니다.
- git commit -a: 파일을 스테이징하는 (git add) 과정을 생략하고, Git이 이미 추적하고 있는 모든 수정된 파일을 즉시 커밋합니다.
- git push: 로컬 저장소의 커밋들을 원격 저장소(Remote Repository)로 전송하여 반영합니다.
- git fetch: 원격 저장소의 최신 변경 이력을 가져오지만, 로컬 작업 내용에는 자동으로 병합하지 않습니다.
- git merge <브렌치>: 지정한 <브랜치>의 변경 이력을 현재 브랜치로 통합(Merge)합니다.
- git pull: git fetch 와 git merge 를 합친 명령어입니다. 원격 저장소의 최신 이력을 가져와서 (fetch), 현재 로컬 브랜치에 자동으로 병합(Merge)합니다.
- git diff HEAD: 현재 워킹 디렉토리의 내용과 가장 최근에 커밋된 버전(HEAD) 사이의 모든 변경 사항(수정되었지만 커밋되지 않은 모든 내용)을 비교하여 보여줍니다.
- git diff: 현재 워킹 디렉토리의 수정 내용과 스테이징 영역에 준비된 내용 사이의 차이만 보여줍니다. (아직 git add 하지 않은 변경 사항)
Github이란
GitHub는 Git을 기반으로 하는 웹 기반 호스팅 서비스 및 협업 플랫폼입니다.
가장 쉽게 비유하자면, "Git이 내 컴퓨터에서 파일의 버전을 관리하는 '도구'라면, GitHub는 그 Git 저장소(Repository)를 인터넷에 올려놓고 여러 사람과 공유하며 협업할 수 있도록 하는 '온라인 공간(클라우드 서비스)'입니다."
Fork는 GitHub, GitLab과 같은 원격 저장소 호스팅 서비스에서 사용되는 기능으로, 다른 사용자의 원격 저장소(Repository)를 통째로 자신의 계정으로 복사해 오는 것을 의미합니다.
"쉽게 말해, 기존 프로젝트에 영향을 주지 않으면서 독립적으로 프로젝트를 수정하거나 기여할 준비를 하는 과정입니다."
Pull Request, 즉 풀 리퀘스트는 Git을 기반으로 하는 협업 플랫폼(GitHub, GitLab 등)에서 사용되는 핵심 기능으로, 자신의 변경 사항을 다른 사람의(주로 메인) 저장소에 통합(병합)해 달라고 공식적으로 요청하는 행위입니다.
"쉽게 말해, '당겨주세요(Pull) + 요청(Request)'으로, 원본 저장소의 관리자에게 '내 브랜치에 있는 최신 코드를 당신의 저장소로 가져가서 병합해 주세요.'라고 부탁하는 의미를 담고 있습니다."
Git Advanced Topics(Git 고급 주제)는 기본적인 커밋, 브랜치, 병합, 푸시, 풀 등의 명령어를 넘어선, 복잡한 상황을 해결하고, 깔끔한 커밋 이력을 관리하며, 효율적인 협업 워크플로우를 구축하는 데 사용되는 심화 기능과 개념들을 통칭합니다.
- Rebase(리베이스): 한 브랜치의 커밋들을 떼어내 다른 브랜치의 맨 뒤에 순차적으로 적용합니다.
목적: 불필요한 병합 커밋(Merge Commit) 없이 이력이 마치 하나의 선처럼 깨끗하게 이어지게 합니다.
- Interactive Rebase (대화형 리베이스): 특정 범위의 커밋들을 다음과 같이 수정할 수 있습니다.
- Squash: 여러 커밋을 하나로 합치기.
- Fixup: 커밋을 합치고 메시지를 버리기.
- Edit: 특정 커밋에서 멈춰서 수정 작업을 추가하기.
- Reorder: 커밋들의 순서를 변경하기.
목적: 지저분하거나 불필요한 커밋들을 정리하여, 의미 있는 하나의 작업 단위로 커밋 이력을 최적화합니다.
- Reflog (레프로그): 로컬 저장소에서 HEAD가 이동했던 모든 기록을 남깁니다. (브랜치 이동, 리베이스, 리셋 등의 모든 이력)
목적: 실수로 커밋을 잃어버렸을 때, Reflog의 기록을 통해 잃어버린 커밋 상태로 되돌아갈 수 있습니다.
- Cherry-pick (체리 픽): 다른 브랜치에 있는 특정 커밋 하나만을 선택하여 현재 작업 중인 브랜치에 복사해 적용합니다.
목적: 아직 병합할 수 없는 브랜치에서 긴급한 버그 수정 커밋 하나만 먼저 가져와 적용해야 할 때 유용합니다.
- Git Hook (깃 훅): 디렉토리에 스크립트를 넣어두면, Git 작업 과정 중 특정 시점에 해당 스크립트가 실행됩니다.
목적: 커밋 전에 코딩 스타일 검사(Lint), 테스트 코드가 통과했는지 확인 등의 작업을 자동화하여 품질 관리를 강화합니다.
- Submodule (서브모듈): 하나의 Git 저장소 안에 다른 Git 저장소를 포함하는 기능입니다.
목적: 외부 라이브러리나 다른 프로젝트를 메인 프로젝트의 종속성(Dependency)으로 정확히 특정 버전을 고정하여 포함시킬 때 사용합니다.
Markdown
일반 텍스트 편집기를 사용하여 서식이 지정된 텍스트를 만들기 위한 경량 마크업 언어이다.
"메모장 같은 단순한 프로그램에서 간단한 문법(예: #, *, **)을 사용하여, 나중에 웹페이지나 문서처럼 예쁘게 서식이 적용된 문서를 만들 수 있게 해주는 언어"라고 할 수 있다.
- 텍스트 기능
- 제목(Heading)
- #뒤에 한칸 스페이스바 후에 제목으로 만들고자 하는 텍스트를 입력하면 된다.
- #의 개수가 많아 질 수록 헤더의 크기는 작아진다.
예시: # header, ## header
- 굵기(bold)
- 강조한고 싶은 텍스트의 앞뒤에 **을 입력한다.
예시: **bold** -> bold
- 기울림체(italic)
- 기울리고 싶은 텍스트의 앞뒤에 _을 입력한다.
예시: _italic_ -> italic
- 제목(Heading)
- 구조 기능
- 인용문(Backquotes)
- >뒤에 다른 텍스트와 구별되는 인용블록을 입력하면 된다.
예시: >인용문
- 목록(List)
- 정렬 목록을 만들고 싶은 경우에는 1.,2.,3. ... 뒤에 스페이스 후 목록의 내용을 입력하면 된다.
예시: 1. 내용1
2. 내용2- 비정렬 목록의 경우에는 * 뒤에 스페이스후 목록의 내용을 입력하면 된다.
예시: * 내용1
* 내용2- 목록안에 목록을 만들고 싶은 경우에는 tab간격을 두어 목록을 만들면 생성된다
예시: * 내용1
* 내용1-1
- 인용문(Backquotes)
- 링크 및 미디어
- 하이퍼링크
- 클릭 가능한 텍스트 링크를 만들기 위해 [텍스트](url) 혹은 [텍스트1](텍스트2)후에 [텍스트2]:url로 url을 나중에 명시 할 수 있다.
예시: [Google](https://www.google.com) -> Google
- 이미지
- 문서에 이미지를 넣고 싶은 경우에 을 입력하여 사용한다.
- [이미지 설명](이미지 주소)의 경우에는 클릭시에 이미지를 보여준다.
- 하이퍼링크