oss 기말고사 범위.pdf

Software Engineering laboratory Yeungnam University 1 What is Open Source Software? Open Source Software (OSS) OSS is a type of computer software Source code is released under a license that allows users to study, change, and distribute the sof...

Software Engineering laboratory Yeungnam University 1 What is Open Source Software? Open Source Software (OSS) OSS is a type of computer software Source code is released under a license that allows users to study, change, and distribute the software to anyone for any purpose. This promotes collaborative and transparent development. It encourages innovation and knowledge sharing as the code is accessible to the public. This model has led to the development of a wide variety of software, from operating systems like Linux to web browsers like Mozilla Firefox. Closed source, Proprietary source 2 What is Open Source Software? 오픈 소스 소프트웨어(Open Source Software, 이하 OSS) 소스 코드가 공개되어 누구나 접근하고 사용할 수 있는 소프트웨어 이는 개발자 혹은 사용자가 해당 소프트웨어의 내부 코드를 열람하고 수정할 수 있게 함으로써 사용자 간의 협력과 소프트웨어의 발전을 촉진하는 개념을 포함 누구나 자유롭게 사용, 복제, 배포, 수정, 활용 가능 저작권자의 권익을 보호할 수 있도록 제도화된 소프트웨어 일반 대중의 공동 연구로 개발 , 시험 및 개선 동료 평가와 커뮤니티 기반 소프트웨어 개발 분산된 지역의 여러 개발자의 협업 방식으로 개발 3 What is Open Source Software? OSS의 특징 요약 소스 코드 공개 소프트웨어의 소스 코드가 공개되어 있어 누구든지 접근 가능 소프트웨어의 동작 방식을 이해하고 필요에 따라 수정 가능 자유로운 수정 및 배포 OSS는 사용자가 소스 코드를 자유롭게 수정하고, 해당 변경사항을 다시 공개할 수 있는 권리를 제공 수정된 소프트웨어를 누구든지 무료로 사용하거나 배포 가능 커뮤니티 협력 다수의 개발자가 참여하여 의견을 나누고 코드를 개선함으로써, 커뮤니티 기반의 협력 가능 다양한 라이선스 다양한 라이선스가 존재하며, 각 라이선스는 소프트웨어를 어떻게 사용하고 공유할 수 있는지 규정함. 4 오픈소스SW, 비공개SW, 상용SW 오픈소스SW와 비공개SW 공통점 저작권은 작성과 동시에 저작권자에게 귀속되므로 오픈소스SW와 비공개 소프트웨어 공통으로 저작권이 존재 차이점 오픈소스SW의 저작권자들은 일반적으로 소스코드를 공개하여 누구나 자유롭게 사용, 복제, 배포, 수정, 활용할 수 있는 권리를 사용자에게 부여하지만, 비공개SW의 저작권자들은 일반적으로 소스코드를 공개하지 않으면서 사용자가 자유롭게 사용, 복제, 배포, 수정, 활용 하는 것을 금지하고 사용에 대한 대가를 요구 5 오픈소스SW, 비공개SW, 상용SW 상용SW 상용 소프트웨어는 수익 창출을 목적으로 만들어진 소프트웨어 제품 일반적으로 유료로 소스코드를 공개하지 않고 제품 자체를 판매 때때로 소스코드를 공개하고 오픈소스SW 라이선스를 적용하여 듀얼 라이선스 정책을 가지고 사업을 하기도 함 출처: 과학기술정보통신부, 정보통신산업진흥원, 오픈소스SW 라이선스 가이드 6 OSI의 10가지 오픈소스SW 정의 출처: 과학기술정보통신부, 정보통신산업진흥원, 공개 소프트웨어 연구개발 수행 가이드라인 7 OSI의 10가지 오픈소스SW 정의 (1) 자유 배포 (Free redistribution) 특정한 소프트웨어의 라이선스에 배포나 판매상의 제한을 설정할 수 없음. 배포판에 대한 판매나 양도에 있어서 별도의 라이선스 비용을 징수할 수 없음. 즉, 오픈소스SW를 재배포하는 사용자에 대한 제한을 할 수 없으며, 재배포 소프트웨어에 별도 라이선스 비용을 징수할 수 없다. 8 OSI의 10가지 오픈소스SW 정의 (2) 소스코드 공개 (Source Code Open) 프로그램 저작물에는 반드시 소스코드가 포함되어야 함. 가장 바람직한 방법은 인터넷을 통해서 소스코드를 무료로 다운로드 받을 수 있도록 하는 것. 프로그래머들이 개작하기에 용이한 형태로 제공되어야 함. 고의로 복잡하고 혼란스럽게 만들어진 형태와 선행 처리기나 번역기에 의해서 생성된 중간 형태의 코드는 허용되지 않음. 즉, 오픈소스SW는 소스코드 형태로 배포되어야 한다. 9 OSI의 10가지 오픈소스SW 정의 (3) 2차적 저작물 (Derived works) 허용 프로그램 원저작물의 개작이나 이를 이용한 2차적 프로그램의 창작이 허용되어야 함. 이러한 파생적 프로그램들은 최초의 프로그램이 갖고 있던 라이선스의 규정과 동일한 조건 하에서 재배포될 수 있어야 함. 즉, 오픈소스SW를 사용하여 2차적 저작물을 만들 수 있고 이를 배포할 수 있다. 10 OSI의 10가지 오픈소스SW 정의 (4) 소스코드 수정 제한(Integrity of The Author's Source Code) 빌드 과정을 통해서 프로그램을 개작할 목적으로 소스 코드와 패치 파일을 함께 배포할 경우에는, 정상적인 빌드를 보장하기 위해서 라이선스 안에 소스코드의 수정을 제한하는 항목을 추가할 수 있음. 그러나 이러한 경우에도 수정된 소스 코드를 이용해서 만들어진 소프트웨어에 대한 자유로운 배포를 허용해야 함. 즉, 오픈소스SW의 정상적 빌드와 저작권자의 저작권을 보호하기 위해 수정을 제한하는 항목을 추가 할 수 있으나 자유로운 배포를 허용해야 함. 11 OSI의 10가지 오픈소스SW 정의 (5) 개인이나 단체에 대한 차별 금지 (No Discrimination Against Persons or Groups) 라이선스는 모든 개인과 단체에 대해서 동일한 기준으로 적용되어야 한다. 즉, 모든 라이선스는 구분 없이 동일하게 적용되어야 한다. 12 OSI의 10가지 오픈소스SW 정의 (6) 사용 분야에 대한 제한 금지 (No Discrimination Against Fields of Endeavor) 라이선스 안에 특정한 분야에 종사하는 사람에 대한 프로그램 사용상의 제한을 설정할 수 없음. 예를 들면, 유전연구나 상용 사업체에서는 해당 프로그램을 사용할 수 없다는 등과 같이 특정한 분야에 대한 사용을 금지하는 제한을 설정해서는 안됨. 즉, 사용 분야에 대한 제한을 해서는 안된다. 13 OSI의 10가지 오픈소스SW 정의 (7) 라이선스의 배포 (Distribution of License) 프로그램에 대한 권리는 반복되는 배포에 따른 별도의 라이선스 승인이나 양도 과정 없이도 프로그램을 배포 받은 모든 사람에게 동일하게 적용됨. 즉, 라이선스 준수를 하여 사용하는 경우 별도의 승인 혹은 양도가 없어도 사용 가능하다. 14 OSI의 10가지 오픈소스SW 정의 (8) 라이선스 적용상의 동일성 유지 (License must not be specific to a product) 프로그램에 대한 권리는 반복되는 배포 과정의 모든 단계에서 동일한 효력 발생. 만약, 특정한 배포판에 포함되어 있던 프로그램을 독립적으로 사용하거나 재배포한다면, 해당 프로그램을 배포 받는 사람은 프로그램이 포함되어 있던 최초의 배포판 상태에서 발생된 권리와 동일한 권리를 지님. 즉, 한번 적용된 라이선스는 몇 번이 재배포 되더라도 동일하게 권리와 의무를 갖는다. 15 OSI의 10가지 오픈소스SW 정의 (9) 다른 라이선스의 포괄적 수용 (License must not contaminate other software) 라이선스에 오픈소스SW와 함께 배포되는 소프트웨어에 대한 제한을 설정해서는 안됨. 예를 들면, 동일한 매체를 통해서 배포되는 소프트웨어는 모두 오픈소스SW이어야 한다는 제한으로 인해서 다른 라이선스 기준을 따르는 소프트웨어가 함께 배포될 수 있는 형태를 금지해서는 안 됨. 즉, 함께 배포되는 소프트웨어에 제한을 두지 말아야 한다. 16 OSI의 10가지 오픈소스SW 정의 (10) 라이선스의 기술적 중립성 (License must be Technology-Neutral) 라이선스의 어떠한 규정도 개별기술 또는 인터페이스 형태에 기초하여 규정하지 말아야 함. 즉, 라이선스의 조항은 모든 기술 혹은 형태 등에 동일하게 적용될 수 있어야 한다. 17 OSS Licenses 출처: 과학기술정보통신부, 정보통신산업진흥원, 오픈소스SW 라이선스 가이드 18 OSS Licenses 정의 (Lincense: 사용권, 사용허가) 오픈소스SW 저작권자가 사용자에게 자신의 저작물에 대한 사용을 허락하는 명문화된 문서 종류 좋은 라이센스나 나쁜 라이센스는 없으며 어떤 라이센스도 다른 라이센스보다 낫지 않음. 누구나 자신에게 맞는 오픈소스 라이선스를 만들 수 있음. 이것이 바로 오픈소스 라이선스가 너무 많은 이유. 이로 인해 오픈 소스 라이선스를 선택하는 것이 복잡한 비즈니스가 될 수 있음. OSI에서는 가장 일반적으로 사용되는 80개가 조금 넘는 오픈 소스 라이선스로 구성된 승인된 라이선스 목록을 제공함. 19 OSS Licenses Top open source licenses explained * All licenses in this chart permit commercial use and all require a copy of the license in distribution. https://www.mend.io/blog/top-open-source-licenses-explained/ 20 OSS Licenses 분류 개별 오픈소스SW 저작권자들의 저작 권리 주장 및 사용허가를 제공하는 라이선스라는 명문화된 형태로 반영되어 코드 공개여부 및 범위에 따라 분류 Permissive 계열 Copyleft 계열 - Weak copyleft 계열 - Strong copyleft 계열 * 오픈소스SW는 해당 라이선스 의무사항만 준수한다면 출처: 과학기술정보통신부, 정보통신산업진흥원, 오픈소스SW 라이선스 가이드 아무나 자유롭게 상업적으로 이용 가능함. 21 OSS Licenses 분류 (cont’d) Permissive 계열 사용함에 있어서 별다른 요구사항을 부여하지 않고 사용자에게 광범위한 사용권한을 부여하는 오픈소스SW 계열 기본적으로 저작권 고지 및 라이선스 사용 고지 정도만을 요구 BSD, MIT 등이 대표적 Copyleft 계열 소스코드 공개 및 원 저작물뿐만 아니라 원저작물을 기반으로 만들어지는 파생저작물에도 동일한 라이선스로 공개되어야 한다는 소스코드 공유 개념 계열 - Weak copyleft 계열 수정 부분을 포함하는 코드에 대한 공개를 요구하는 라이선스들로서 MPL, EPL, LGPL 등이 대표적. - Strong copyleft 계열 결합된 모든 코드에 대한 동일조건의 소스코드 공개를 요구하는 라이선스로서 GPL, AGPL 등이 해당. 22 OSS Licenses 오픈소스SW의 고지의 목적 저작권 고지 모든 오픈소스SW 라이선스에서 공통적으로 요구하고 있는 의무사항. 오픈소스SW의 저작자를 알림으로서 사용자에 대한 사용 권리를 인지시키는 동시에 질문이나 토론 사항이 있을 경우 저작권자를 특정하는 기능. - 협업 개발을 위한 채널로서 활용. 저작자 표시 문구는 해당 부분 소스코드의 라이선스 변경 요청을 할 경우에도 필요함. 라이선스 고지 오픈소스SW를 사용한 경우 사용자들의 사용 권리를 알리기 위해 오픈소스SW 라이선스를 고지해야 함. 대부분의 오픈소스SW 라이선스에서 의무사항으로 규정. 만일 이 라이선스 문구가 없는 코드의 경우에는 사용이 불가하다는 암묵적 정보를 포함함. 23 OSS Licenses 오픈소스SW의 고지 이행 방법 (1) File scope approach (파일 단위 고지) 파일에 여러 명의 기여자가 있을 경우 그 각 파일의 모두 부분에 저작권 표시를 하는 방식. (2) Centralized approach (종합 고지) 프로젝트 최상위에 AUTHORS or COPYRIGHT 파일을 만들고 저작권 정보를 모두 합쳐서 기재하는 방식. 24 OSS Licenses 오픈소스SW의 고지 이행 방법 (3) Hybrid approach (하이브리드 고지) 파일 단위 고지 방식과 종합 고지 방식을 적절히 혼합하여 사용하는 방식. * 세 가지 고지 방식 중 가장 권장할 고지방식은 하이브리드 방식이다. * 오픈소스SW 사용자들이 특정 프로젝트의 전체를 사용할 수도 있지만 일반적/부분적으로 특정 모듈이나 라이브러리 소스코드들 만을 취사 선택해서 사용할 경우, 또 개별 파일에 고지문이 없을 경우 해당 파일은 출처가 모호해지게 됨에 따라서 가급적 개별 파일의 헤드라인에 고지문을 넣고 전체 프로젝트에 종합 고지문을 함께 작성하여 배포하는 것을 권장함. 25 OSS Licenses 고지문 작성 방식 공통사항 원래의 소스코드에 있는 저작자 표시 내용을 그대로 표시 저작권 문구에는 통상 웹 주소가 동시에 표시되는데, 이는 저작권 표시가 그 오픈소스SW의 내용에 대한 문의처를 알리는 기능을 한다는 점에서 매우 중요함. Copyright 2030, Kevin Seo * Dual licensed under the MIT or GPL Version 2 licenses. * http://jquery.org/license [고지문 작성 예] 26 OSS Licenses 고지문 작성 방식 변경사항 고지 GPL-2.0 라이선스나 Apache-2.0 라이선스 같은 특정 라이선스에서는 소스코드 수정 시 변경사항에 대한 고지의무를 요구함. 변경사항에 대한 고지를 할 경우에는 원 저작권자의 고지문을 유지하고 수정한 저작권자의 고지를 추가하여 배포함으로써 저작권의 범위를 정확히 제공해야 함. Original Work Copyrightⓒ 2024, YU Company, Modified Work Copyrightⓒ 2030-12.31 ABC Company [변경사항 고지문 작성 예] 27 OSS Licenses 고지문 작성 (예) GPL-3.0 고지문 적용 방식 오픈소스SW 해당 파일 주석부분 or NOTICE.txt에 상기 영문 고지한다. 오픈소스SW를 변경 했을 경우 해당 파일 주석 부분에 저작권 고지한다. NOTICE.txt는 통상적으로 소스코드 최상위 수준에 위치하도록 고지한다. 파일을 수정할 때는 파일을 수정했다는 사실과 그 날짜를 파일에 명시해야 한다. Original Work Copyrightⓒ 2024, XXX Company, Modified Work Copyrightⓒ Year, Company Name 28 OSS Licenses 오픈소스SW 라이선스 양립성(Compatibility) 복수의 저작물에 적용된 상이한 라이선스가 새로운 저작물을 만들기 위하여 해당 저작물들의 소스코드나 내용물을 결합시키는 것을 불가능하게 만드는 조건을 포함할 때 발생하는 문제. 기본적으로 오픈소스SW를 사용함에 있어서 하나 이상의 오픈소스SW 라이선스를 사용할 경우에 검토해야 될 사항 ‘적어도 두 패키지 중의 하나의 저작자의 직접적인 허가가 없이는 두 패키지의 결합을 합법적으로 배포할 수 없는 경우’두 개의 라이선스는 호환되지 않는다 or 양립할 수 없다고 지칭함. 29 OSS Licenses 오픈소스SW 라이선스 양립성(Compatibility) 발생 예 ‘A+B’라는 프로그램을 만들어 배포하고자 하는 경우, MPL-1.1 조건의 A코드: MPL-1.1은 ‘A+B’의 A부분을 MPL로 배포할 것을 요구 배포 불가 GPL-2.0 조건의 B코드: GPL-2.0은 ‘A+B’ 전체를 GPL-2.0으로 배포할 것을 요구 'A+B' 프로그램의 배포를 강행하였다면, 적어도 GPL-2.0 혹은 MPL-1.1중 어느 한쪽 라이선스를 위반하는 결과를 초래. 따라서 해당 A 혹은 B 프로그램의 원 저작자로부터 별도의 허가를 받지 않는 한, 'A+B'를 배포한 자는 저작권법 내지 계약 위반에 따른 책임. * MPL-2.0에서는 Larger Work 배포 시에 부차적 라이선스로 GPL-2.0, LGPL-2.1, AGPL-3.0 혹은 이후 버전으로 배포할 수 있게 함으로써 라이선스 호환성 문제를 개선함. 30 OSS Licenses 오픈소스SW 라이선스 양립성(Compatibility) 해결방안 한쪽의 오픈소스SW를 제거 혹은 다른 라이선스로 대체 해당 라이선스에서 명시하고 있는 라이선스 적용의 예외에 해당하는 결합 형태 고려 라이선스 충돌이 방지하지 않도록 결합형태를 분리된 저작물로 변경을 검토 오픈소스SW 활용시 오픈소스SW 라이선스 검증 작업이 반드시 필요함. 31 Benefits of Open Source Software 출처: 과학기술정보통신부, 정보통신산업진흥원, 공개 소프트웨어 연구개발 수행 가이드라인 32 Examples of Popular Open Source Software Projects Linux One of the most well-known open source software projects, Linux is widely used in servers, embedded systems, and as an operating system for personal computers. Mozilla Firefox A popular, open source web browser known for its speed, privacy features, and extensive support for web standards. WordPress This content management system (CMS) is extensively used for creating websites and blogs due to its ease of use, flexibility, and extensive plugin and theme ecosystem. 33 Challenges and Limitations of Open Source Software Maintaining Quality Ensuring quality in a large, distributed development ecosystem, with diverse contributors and varying levels of expertise, can be a challenge for open source projects. Security Concerns Open source software may face security vulnerabilities if not rigorously maintained and reviewed, potentially leading to exploitation or data breaches. Complex Governance Establishing effective governance models and decision-making processes in open source projects can be complex, potentially leading to conflicts and disagreements among contributors. 34 History of OSS (cited from IBM) ~1970년대 1970년대 중반까지 컴퓨터 코드는 컴퓨터 하드웨어 운영에 포함되는 것으로 여겨졌으며, 저작권법의 보호 대상인 고유한 지적 재산이 아니라고 간주. 조직들은 자체 소프트웨어를 프로그래밍했으며, 코드 공유는 일반적인 관행. CONTU(Commission on New Technological Uses of Copyrighted Works)가 1974년에 제정되면서, 소프트웨어 코드는 저작권법의 보호를 받을 수 있는 창작물의 범주에 속한다고 결론 이로 인해 독점적 소스 코드를 주된 수입원으로 삼는 독립적 소프트웨어 게시가 하나의 산업으로 급성장 ! 개인용컴퓨팅으로모든기업과많은가정에서애플리케이션을사용하게되면서소프트웨어시장경쟁과열 35 History of OSS (cited from IBM) 1980년대 독점적 소프트웨어의 제한 및 한계에 대한 일종의 반항은 1983년에 시작 프로그래머인 Richard Stallman아 Free Software Foundation을 설립 자신의 작업을 수행하기 위해 적합한 형식으로 독점적 소프트웨어를 맞춤화할 수 없음 “소프트웨어는 맥주가 아니며 표현처럼 자유로워야 한다”고 생각 무료로 맞춤화에 사용할 수 있는 소프트웨어라는 개념을 지지 애플리케이션 중에서 무엇보다 AT&T가 소유한 Unix 운영 체제에 대한 오픈 소스 대안의 개발을 추진 그는 최초의 카피레프트 소프트웨어 라이센스인 GNU GPL(General Public License)을 혁신 - GPL 라이센스에 따라 소스 코드를 개선한 사람이면 누구나 그와 마찬가지로 모두에게 무료로 편집된 버전을 게시해야 함. 36 History of OSS (cited from IBM) 1990년대 1999년에 "오픈 소스"라는 용어가 채택 많은 사람들이 Stallman이 사용한 “Free software”라는 용어가 부적절하게 가격적으로 "무료"라는 개념을 강조한다고 느낌. The Open Source Initiative (OSI)가 이를 옹호하기 위해 설립 - 이 조직은 또한 오픈 소스 정의를 통해 이 산업을 위한 기본 규칙을 제정 - 호환되는 오픈 소스 라이센스를 호스팅 Every free software is open source. Every open-source software is not free software. 37 OpenUp (오픈소스 소프트웨어 통합지원센터) 개요 오픈소스SW를 개발, 공유, 활용하기를 원하는 개발자, 기업, 정부 등을 체계적으로 지원 수요(기업, 공공기관)및 공급(개발자, 기업)의 선순환 구조 구축 오픈소스SW 활성화의 허브 역할을 수행 정보통신산업진흥원(NIPA) 오픈소스SW사업 목적 오픈소스SW를 활용함에 있어 기술지원, 인력양성, 창업지원, 저변 확대 등 기업, 개발자, 커뮤니티 지원기능 통합을 통한 시너지 극대화 38 OpenUp (오픈소스 소프트웨어 통합지원센터) 39 OpenUp (오픈소스 소프트웨어 통합지원센터) 오픈소스SW 라이선스 자동 검증의 필요성 소프트웨어 개발시 활용한 오픈소스SW를 일일이 파악하는 것은 매우 힘든 작업. 소프트웨어를 개발이 진행되고 배포에 이르기까지 수많은 변경 작업이 발생. 수동으로 관리했다고 하더라도 미처 확인하지 못한 오픈소스SW의 소스코드가 포함될 수 있음. 오픈소스SW 라이선스 검증 지원 출처: 과학기술정보통신부, 정보통신산업진흥원, 오픈소스SW 라이선스 가이드 40 전세계의 오픈소스SW 유관단체 오픈소스SW 라이선스 자동 검증의 필요성 Linux Foundation(http://linuxfoundation.org) : 리눅스 표준 재정 등 오픈소스SW 선도 Software Freedom Law Center(http://www.softwarefreedom.org) : 법적 자문 기관 GPL-Violations(http://gpl-violations.org) : GPL 위반 모니터링 Open Source Initiative(http://opensource.org) : 오픈소스SW 라이선스 인증 관리 Open Invention Network(http://openinventionnetwork.com) : 리눅스 및 오픈소스SW 특허 관리 등 41 Software Engineering laboratory Yeungnam University 1 SW 개발시 git의 필요성 (1) 변경 내역을 확인하기 어려움 (1-1) 소스코드 수정시 하나의 파일에 저장하는 단순 방식 대개 파일을 단순히 저장하면 이전에 저장된 내용에서 현재 내용으로 덮어씀. 즉, 저장된 파일은 항상 최신 상태만 갖게 됨. 이런 방식으로는 현재 저장된 내용이 이전에 비해 무엇이 어떻게 달라졌는지 알기 어려움. 다시 말해, 변경 내역을 추적하기가 어려움. 2 SW 개발시 git의 필요성 (1) 변경 내역을 확인하기 어려움 (1-2) 소스코드 수정시 다른 이름으로 여러 개의 파일에 저장하는 방식 매번 다른 이름으로 따로 파일을 저장하여 관리하는 방법도 있지만, 이는 SW 개발 과정에서만큼은 권장할 만한 방법이 아님. 매번 파일을 다른 이름으로 새롭게 저장하여 변경 내역을 관리하는 것은 저장 공간을 낭비하는 일일 뿐 아니라 쉽게 실수할 수도 있기 때문. 3 SW 개발시 git의 필요성 (2) 버전(version)을 되돌리기 어려움 SW 개발시에는 반드시 과거 버전으로 쉽게 회귀할 수 있도록 개발 환경을 갖추어야 함. SW변경(디자인 변경 or 버그 수정 등) 수정한 코드에 문제가 생겼거나 사용자 반응이 영 좋지 않은 등 여러 문제로 이전의 모습으로 되돌려야 하는 상황이 생길 수 있음. 만일 파일을 단순히 덮어썼거나 다른 이름으로 저장하는 방식으로 변경 내역을 관리했다면 파일의 어느 부분이 삭제됐고, 어느 부분을 어떻게 되돌려야 할지 파악하기 어려울 것. 다시 말해, 이전으로 되돌리기가 어려워짐. 수정 추가 삭제 < 소스코드 수정 전 > < 소스코드 수정 후 > 4 SW 개발시 git의 필요성 (3) 협력하기 어려움 대규모 SW는 대부분 여러 개발자가 협업하여 개발 예) 로그인 기능, 결제 기능, 게시판 등등 각자 개발할 업무를 맡고, 추후 각자 만든 내용들을 통합. 코드를 합치는 과정에서 서로가 작업한 내용을 일일이 비교해야 한다면 시간이 많이 걸릴뿐더러 실수도 매우 빈번하게 발생 만일 모두가 작업한 파일을 덮어쓰는 방식으로 저장했거나 다른 이름으로 파일을 저장하는 방식으로 파일을 관리했다면 서로의 작업 내역을 합칠 때 매우 어려워짐. 웹 사이트를 이루는 파일이 여러 개이고 코드 양이 방대하다면 누가 어떤 파일에서 어떻게 코드를 수정했는지 파악하기 힘들기 때문임. A 개발자: 1개 파일 삭제, 2개 파일 생성, 3개 파일 수정 B 개발자: 2개 파일 삭제, 1개 파일 생성, 10개 파일 수정 C 개발자: 0개 파일 삭제, 3개 파일 생성, 6개 파일 수정 … 5 형상관리 (Configuration management: CM or SCM) 형상 관리 개념의 등장 SW 개발 생명주기 전반에 걸쳐 생성되는 모든 산출물의 통합 및 변경 과정을 체계적으로 관리하고 유지하는 개발 관리 활동. 개발 중 발생하는 모든 산출물들이 변경됨으로써 점차 변해가는 SW형상을 체계적으로 관리하고 유지하는 기법. The task of tracking and controlling changes in the SW. Version management. 잘 동작하던 코드를 수정했는데 에러가 발생해.. 근데 그 잘 동작하던 코드를 저장을 안했어..” 필요하면 이전의 버전으로 언제든지 되돌림. “너가 A기능을 만들어 내가 B기능을 만들게! 근데 여러 사용자에 대한 버전 이력 추적관리. 우리 각각의 코드를 어떻게 합치지..?” “컴퓨터가 고장이나서 내가 짠 코드들을 찾을 소스코드 충돌 처리 및 파일 변경 사항 확인 가능. 수가 없어 ㅠㅠ;;;” “매번 코드를 공유할때마다 압축해서 메일로 보내고 받고.. 협업하기 너무 힘드네..” 6 git 개요 Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is released under the GNU General Public License version 2.0 (GPL 2.0) 2005년 리눅스의 아버지 Linus Torvalds가 전 세계 수많은 개발자와 함께 오픈 소스 프로젝트(리눅스 커널)를 진행하다가 버전 관리에 어려움을 느껴 만든 도구 7 git 특징 대표적인 버전 관리 시스템 파일 변화를 시간에 따라 기록했다가 나중에 특정 시점의 버전을 다시 꺼내올 수 있는 시스템. 소프트웨어 소스 코드만 보여주지만, 실제로 거의 모든 컴퓨터 파일의 버전을 관리할 수 있음. 각 파일을 이전 상태로 되돌릴 수 있음. 프로젝트를 통째로 이전 상태로 되돌릴 수 있음. 파일을 잃어버리거나 잘못 고쳤을 때도 쉽게 복구. 시간에 따라 수정 내용을 비교 가능 8 git 특징 Version을 만들고 되돌리며, 다른 개발자들과 협업할 수 있음. git은 모든 변경사항과 파일들을 모든 시점에서 추적(tracking). 무엇이, 어디에서, 언제, 누구에 의해 바뀌었는지 등을 알 수 있음. 파일 수정 중에 실수로 웹 사이트가 망가졌다면, 이전 시점으로 되돌아갈 수 있게 함. git은 0,1로 이루어진 binary code로 파일을 읽기 때문에 원하는 것이 무엇이든 읽을 수 있음. 오디오, 이미지, 엑셀파일, 텍스트파일 등도 가능 git 또한 오픈 소스 소프트웨어 프로젝트로, 모든 소스 코드가 공개되어 있음. https://github.com/git/git 명령어로 이용하는 소프트웨어 git 제대로 활용하려면 git 명령어와 옵션을 숙지 9 git 중요성 소스 코드 변경 이력 관리에 사용되는 사실상의 표준 (de facto standard) 출처: https://www.atlassian.com/git/tutorials/what-is-git 10 git 중요성 IT 채용 및 교육 회사 프로그래머스의 채용담당자 대상 설문조사 출처: https://programmers.co.kr/pages/2023- recruiting-survey 11 git 중요성 IT 채용 및 교육 회사 프로그래머스의 채용담당자 대상 설문조사 출처: https://programmers.co.kr/pages/2023- recruiting-survey 12 git 사용하기 Git Bash CLI (Command Line Interface) 명령 행 인터페이스 CLI를 사용할 줄 알면 GUI도 사용할 수 있지만, 반대는 성립하지 않음 Windows의 명령 프롬프트(cmd) Mac의 Terminal Git GUI GUI 프로그램의 대부분은 git 기능 중 일부만 구현하기 때문에 비교적 단순 SourceTree, GitHub Desktop 등 13 git 버전 관리 시스템(VCS: Version Control System)의 종류 비교 (1) Local VCS 간단한 DB에 파일의 변경정보를 담아 관리. 가장 쉽고 간편한 방법으로 파일을 각 시점마다 복사. 삭제 및 변경에 취약. - 작업하던 디렉토리를 지워버릴 수 있음. - 실수로 파일을 잘못 고칠수도 있고, 잘못 복사할수도 있음. 다른 컴퓨터에서는 해당 DB에 접근이 어려움. 14 Scott Chacon and Ben Straub, ProGit, 2nd edition. git 버전 관리 시스템(VCS: Version Control System)의 종류 비교 (2) 중앙 집중식 버전 관리 (CVCS: Centralized VCS) 파일 관리를 하는 중앙 서버에 DB가 있어 각 로컬에서 해당 서버에서 파일을 받아서 사용. DB를 각 로컬에서 관리하지 않고 중앙에서 관리하기에 관리가 쉬움. 서버 기록을 보면 모든 사용자 활동 내역 확인 가능. 중앙 서버가 작동하지 않으면 그동안 아무도 다른 사람과 협업할 수 없음. 중앙 서버 하드디스크에 문제가 생기면 프로젝트의 모든 history를 잃어버림. 15 Scott Chacon and Ben Straub, ProGit, 2nd edition. git 버전 관리 시스템(VCS: Version Control System)의 종류 비교 (3) 분산 버전 관리 (DVCS: Distributed VCS) 로컬에 중앙 DB 저장소를 히스토리와 더불어 전부 복제 (Clone). 로컬에서 버전 관리 DB를 만들어 서버에 올릴 수도 있고, 다른 컴퓨터 로컬에 복사해서 줄수도 있음. 서버에 문제가 생기면 이 복제물로 다시 작업 시작 가능. 로컬 클라이언트 중에서 아무 것이나 골라도 서버 복원 가능. 16 Scott Chacon and Ben Straub, ProGit, 2nd edition. git git은 DVCS에 해당 Local clone of repository https://www.geeksforgeeks.org/git-features/ 17 GitHub 개요 원격 저장소 호스팅 서비스 ‘원격 저장소’라는 말이 조금 생소하겠지만, 쉽게 ‘깃으로 버전을 관리하는 프로젝트들이 모여 있는 웹 사이트’ 정도로 생각해도 무방함. - git으로 버전 관리한 프로젝트를 GitHub에 업로드 가능. GitHub 업로드한 프로젝트에 새로운 버전을 추가 가능. - 반대로 GitHub에 업로드된 전 세계 개발자들의 프로젝트를 로컬 컴퓨터로 다운로드 가능. 텐서플로(tensorflow), 쿠버네티스(Kubernetes), 리액트(react) 등 이름만 들어도 알 만한 유명한 프로젝트들이 이미 GitHub에 업로드되어 있음 내 프로젝트 … Version 0.3 Version 0.2 upload Version 0.1 download 외부 프로젝트 … Version 0.3 Version 0.2 18 Version 0.1 GitHub 개요 전세계적으로 가장 대표적인 오픈소스 SW 프로젝트 플랫폼 소스코드 공유와 협업 플랫폼. - GitHub에 업로드된 프로젝트에 코드를 기여하고, 다른 개발자들과 협업할 수도 있음. 공개/비공개 저장소, 코드 리뷰, 문서화, 커뮤니티 등 제공. 무료 서비스 사용시 공개 저장소만 사용 가능. - 모두에게 소스코드 내용 오픈. - 비공개 저장소 사용시 유료 서비스 가입. 2018년 6월 4일, Microsoft사 75억 달러(약 10조원) 인수 발표 Git을 위한 웹 저장소(Repository) + 커뮤니티 협의 공간 + 개발자들 간에 소통, 협업, 통합 및 자동화 지원 (DVCS SW) 19 git and GitHub git과 GitHub의 개념 https://www.coursereport.com/blog/what-is-github 20 git and GitHub git과 GitHub의 비교 https://devmountain.com/blog/git-vs-github-whats-the-difference/ 21 git and GitHub git과 GitHub의 정리 git은 소스코드 버전 관리 등 작업 파일들을 효과적으로 관리할 수 있게 해주는 SW. GitHub는 나의 git 파일을 업로드하는 곳. git의 웹호스팅을 제공 (GitHub 외에 GitLab, Bitbucket 등이 있음) GitHub 변경사항을 회사, 친구와 공유할 수 있음. 나의 git 파일 업로드, 다른 사람의 git 파일 다운로드 가능. (git ≠ github) SourceTree (or Github Desktop)은 가독성이 좋지 않은 CLI(Command Line Interface)의 git을 위해 보기 좋게 GUI(Graphic User Interface)를 제공해주는 프로그램 22 git 사용 준비 git 설치하기 git 홈페이지 접속 https://git-scm.com/ 적절한 운영체제 선택 후 다운로드 및 실행하여 설치 Next 버튼 클릭하여 기본 설정대로 설치 - git에서 사용할 기본 문서 편집기(에디터)를 선택하는 창에서는 Use Vim (the ubiquitous text editor) as Git's default editor 선택 권장 - Use bundled OpenSSH 23 git 사용 준비 git 설치 확인 임의의 폴더(ex. test) 생성 후 그 안에서 마우스 우측 버튼 클릭 Open Git Bash here 클릭 24 git 사용 준비 git 명령어 입력해보기 git bash 확인 마이크로소프트 windows로 포팅한 GNU 소프트웨어 도구 모음 현재 작업공간 확인 (명령어를 입력하고 있는 작업공간) git 입력시 관련 명령어 목록 출력 git –v git --version 25 git 사용 준비 git 설정하기 사용자 컴퓨터에 사용자 이름과 이메일을 등록하는 간단한 초기 설정. git config --global user.name “InChan Kim" git config --global user.email “[email protected]" 앞으로 git을 이용해 만드는 모든 버전에는 ‘만든 사람’, ‘지은이’와 같은 개념으로 지금부터 설정할 이름과 이메일이 함께 명시될 것임. 영어를 사용할 것을 권장. 설정한 이름과 이메일 확인 git config user.name git config user.email git config로 설정한 값 확인 git config --list 26 Sourcetree 사용 준비 Sourcetree 설치하기 Sourcetree 홈페이지 접속 https://www.sourcetreeapp.com/ 적절한 운영체제 선택 후 다운로드 및 실행하여 설치 Bitbucket 계정 등록은 하지 않고 “건너뛰기” 선택. Mercurial 체크 해제 후 “다음” 선택. 이름과 이메일은 앞서 설정한 값으로 자동 기입됨. “SSH 키를 불러오시겠습니까?” -> “아니오” 선택. SSH(Secure SHell)는 SSH 키를 이용해 안전하게 원격 컴퓨터와 연결하는 통신 방법 27 Sourcetree 사용 준비 Sourcetree에서 저장소(Local repository) 만들어보기 Local repository: local 컴퓨터에서 버전들이 만들어지고 관리되는 공간. 상단의 Local – Create 클릭. 목적지 경로: 내 컴퓨터 어느 곳에 저장소를 만들 것인지 결정. - 원하는 폴더 경로 입력 or 탐색 버튼을 클릭하여 폴더 지정. - C:\hello-sourcetree C:\hello-sourcetree 에 그림과 같이.git 숨김 폴더가 잘 만들어졌는지 확인 (숨겨진 파일 보이도록 설정). 28 GitHub 사용 준비 GitHub 회원 가입하기 GitHub 홈페이지 접속. https://github.com/ Sign Up 클릭하여 다음 정보 입력. email password username 간단한 퍼즐 풀기 후 계정 생성 완료. 29 Markdown Markdown is… Lightweight markup language that you can use to add formatting elements to plaintext text documents. Markup language: 태그 등을 이용하여 문서나 데이터의 구조를 명기하는 언어의 한 가지 Markup language의 예: HTML, XML, json 등 Created by John Gruber in 2004, Markdown is now one of the world’s most popular markup languages. GitHub의 README.md 가 대표적인 Markdown 문서 https://www.markdownguide.org/ : 기본 문법 확인 30 Markdown 장점 문법이 쉽고 간결함 It doesn’t take long to learn the Markdown syntax 지원 가능한 플랫폼과 프로그램이 다양함 Most people use Markdown to create content for the web, but Markdown is good for formatting everything from email messages to grocery lists. Text로 저장되기 때문에 용량이 적어 보관이 용이 HTML 변환 가능 단점 표준이 없어 도구에 따라 변환방식이나 생성물이 조금씩 다를 수 있음 모든 HTML 마크업을 대체하지 못함 31 Software Engineering laboratory Yeungnam University 1 git을 사용한 버전 관리 버전 관리를 위한 기초 개념 git이 관리하는 세 개의 공간 작업 디렉터리(working directory) or 작업 트리 (working tree), -.git 숨김 폴더가 놓여 있는 곳이 버전 관리 대상이 위치하는 공간 스테이지(stage), 저장소(repository) Stage Repository Working directory 2 git을 사용한 버전 관리 Working directory 버전 관리의 대상이 위치하는 공간 프로젝트 진행을 위해 새로운 파일 또는 폴더 생성 이후 기존 파일 또는 폴더를 수정하거나 삭제 진행 - 즉, 작업이 진행되면 working directory에서 변경 발생.git 작업 작업.git 작업 작업 폴더 폴더 폴더 폴더 신규생성파일.txt 파일 수정 파일 … 삭제 … Working directory Working directory 3 git을 사용한 버전 관리 Stage (staging area, index) git으로 버전을 만들 때는 working directory 내에서 변경된 파일들 중에서 새로운 버전으로 만들려는 파일들을 선별해 특별한 공간으로 옮기는 작업을 거치게 되는데 이 특별한 공간이 바로 stage. Staging: 작업 디렉터리에 파일이 1,000개 있고 이 중 100개가 변경됐을 때, 100개 중 새로운 버전이 될 파일을 선별하는 작업. Stage: 변경 사항이 있는 파일 중 다음 버전이 될 후보가 올라가는 공간. Workging directory는 프로젝트가 위치한 공간이라 눈으로 직접 볼 수 있는 반면, stage는 명시적으로 보이지 않음. ‘버전을 만든다’는 말은 ‘특정 순간의 변경 사항을 기억한다’는 말과 같음. 작업 디렉터리에 있는 프로젝트에 변경 사항이 생기는 순간 새로운 버전을 만들 수 있게 됨. 4 git을 사용한 버전 관리 Stage (staging area, index).git 작업 작업.git 작업 작업 폴더 폴더 폴더 폴더 신규생성파일.txt 파일 신규생성파일.txt 파일 수정 수정 파일 … 삭제 Stage … 신규 버전으로 만들고 싶은 파일들 Working directory Working directory 신규 버전으로 만들고 싶지 않은 파일들 5 git을 사용한 버전 관리 Repository (저장소) Staging된 파일들을 바탕으로 만들어진 새로운 버전이 저장되는 공간. 작업 디렉터리에서부터 만들어진 모든 버전들의 내역이 저장소에 있음. 저장소는 버전이 만들어지고 관리되는 공간. 저장소는 스테이지와 마찬가지로 사용자에게는 명시적으로 보이지 않음. Stage에 올라온 파일을 토대로 새로운 버전을 만들면 새로운 버전이 될 후보가 더 존재하지 않으니 stage는 깨끗하게 비워짐. 6 git을 사용한 버전 관리 저장소.git 작업 작업.git 작업 작업 폴더 폴더 폴더 폴더 신규생성파일.txt 파일 수정 파일 수정 신규생성파일.txt Version 1.0 파일 … 삭제 Stage … Repository Working directory Working directory 신규 버전으로 만들고 싶지 않은 파일들 7 git을 사용한 버전 관리 새로운 버전을 만들기 위한 git에서 사용하는 명령어 절차 Working directory에서의 후보 파일을 stage로 옮기는 것: stage에 추가한다. Staged된 파일들을 바탕으로 저장소에 새로운 버전을 만드는 것: commit 한다. 저장소에 저장된 각각의 버전들을 commit이라 지칭함. 즉, git으로 만든 버전을 편의상 commit으로 지칭함. * Working directory의 파일은 1 | 변경 사항 생성 2 | add 3 | commit …의 과정을 통해 1 | 작업 디렉터리 2 | 스테이지 3 | 저장소 순으로 이동하며 새로운 version으로 생성됨. 8 Sourcetree를 활용한 첫 버전 만들기 (1) Local repository 만들기 Sourcetree 실행 후 Create 클릭 목적지 경로를 설정 예) c:\git-test 하단에 생성 버튼 클릭 : 저장소 생성 만들어진 Local repository 확인해보기 우측 상단 “탐색기” 클릭..git 숨김폴더가 보인다면 성공적으로 local repository 생성 완료. 생성한 목적지 경로가 working directory. git으로 버전 관리할 대상을 여기에 위치시키면 됨. 9 Sourcetree를 활용한 첫 버전 만들기 (2) 버전 관리할 파일 만들기 Working directory에 다음 처럼 예제 파일 생성해보기 a.txt, b.txt, c.txt 각각의 파일 안에 text file a, text file b, text file c를 적은 뒤 저장. : 지금은 간단한 텍스트 파일로 실습하지만, 이 텍스트 파일들이 여러분의 프로젝트 소스 코드 파일일 수 있다는 점을 염두에 두길 바람. * 줄 바꿈을 하고 저장 권장함. - 각 텍스트 파일에 내용을 적은 후 바로 저장하지 말고, 다음 그림처럼 줄 바꿈을 한 뒤 저장 커서 - 줄바꿈을 하지 않고 저장하면 스테이지에 올릴때 경고메시지 발생 가능. 10 Sourcetree를 활용한 첫 버전 만들기 (3) Sourcetree에서 생성된 파일 확인 텍스트 파일을 작성한 뒤 저장하면 Sourcetree의 파일 상태에서 “스테이지에 올라가지 않은 파일” 항목에 방금 생성한 파일들이 추가됨. 스테이지에 올라가지 않은 파일은 말 그대로 ‘작업 디렉터리 내 변경 사항이지만, 아직 버전이 될 후보로 선정되지는 않은 파일’을 말함. (4) Stage에 올리기 “모두 스테이지에 올리기” or 각 파일 옆에 + 클릭. 각 파일 클릭해보면 파일 변경 사항 확인 가능. 초록색 표시와 +표시는 각 파일에서 새롭게 추가된 내용을 의미함. 11 Sourcetree를 활용한 첫 버전 만들기 (5) commit 해보기 commit: 스테이지에 올라온 파일들을 새로운 버전으로 만드는 것. 일반적으로 commit 하기 전에 commit message 작성. Commit message: 버전을 설명하는 메시지 - ‘내가 지금 어떤 파일을 어떻게 변경했는지, 왜 이렇게 변경했는지’ 등의 내용을 담은 일종의 쪽지. - 커밋 메시지는 크게 제목과 본문으로 이루어져 있으며 본문은 생략 가능. git을 통해 새로운 버전을 만들 때 반드시 commit message를 적기를 권장 - 커밋 메시지를 적지 않는다면 프로젝트의 규모가 커지고 수많은 커밋이 쌓였을 때 다른 누군가가(또는 커밋했던 본인조차) 누가, 언제, 어떤 변경 사항을 만들었는지, 이 변경 사항이 의미하는 것은 무엇인지 파악하기 어렵기 때문. - 다른 개발자들이 잘 이해할 수 있도록 구체적으로 작성 필수 (에러 메시지나 링크 첨부 가능). 12 Sourcetree를 활용한 첫 버전 만들기 (5) commit 해보기 commit message 작성 후 커밋 버튼 클릭. 커밋 이후… 좌측 메뉴의 “History” 클릭 후, 하단부에서는 커밋들의 커밋 메시지, 만들어진 시간, 작성자 등을 확인 가능. 좌측 메뉴의 “파일 상태” 에는 커밋할 내용이 없다고 표시. 13 버전 쌓아 올리기 방금 만든 첫 번째 버전을 수정한, 또 다른 버전 생성해보기 파일 수정 하기 “탐색기”를 열어서 a.txt 파일 안에 새로운 줄로 changed를 추가한 뒤 저장. 또한, c.txt 파일은 삭제하기. History 확인 ‘커밋하지 않은 변경 사항’이 추가된 것을 확인할 수 있음 파일 상태 확인 “스테이지에 올라가지 않은 파일” 항목에서 a.txt 파일과 c.txt 파일 확인 가능. 14 버전 쌓아 올리기 방금 만든 첫 번째 버전을 수정한, 또 다른 버전 생성해보기 수정된 파일 스테이지에 올린 후 commit message 작성 커밋 하기 그래프 부분 확인해보기 - 동그라미 두 개가 연결되어 있는 것을 볼 수 있음. - 여기서 동그라미 하나는 커밋 하나, 즉 하나의 버전을 나타냄. - ‘두 번째 커밋’의 동그라미가 ‘첫 번째 커밋’의 동그라미와 연결되어 있는 것은 두 번째 커밋이 첫 번째 커밋에서부터 만들어진 버전임을 나타냄. 15 (실습) 버전 쌓아 올리기 새로운 버전 만들어보기 text file d라는 내용을 담은 텍스트 파일 d.txt를 만들기 이를 스테이지에 올린 뒤 커밋 커밋 메시지는 다음과 같이 작성 - 제목: 세 번째 커밋 - 본문: d.txt 파일 추가 16.gitignore로 무시하기.gitignore 활용해보기 Working directory 안에서 새로운 추가/수정/삭제가 이루어질 때마다 git이 언제나 해당 변경 사항을 자동적으로 식별함. git으로 변경사항을 추적하고 싶지 않은 파일이나 폴더를 무시할 수 있는 기능. 종종 버전 관리 대상에서 제외하고 싶은 파일이나 폴더, 즉 변경 사항이 생기더라도 앞으로도 쭉 버전에 포함하고 싶지 않은 파일이나 폴더가 있을 수 있음..gitignore 파일은 쉽게 말해 ‘무시할 파일/폴더 목록’을 적은 파일. git은.gitignore 파일에 적은 파일이나 폴더에 변경 사항이 생겨도 이를 무시함 17.gitignore로 무시하기 (1) 작업 디렉터리에.gitignore 파일을 만들기.gitignore 파일은 일반 텍스트 파일처럼 생성해도 좋음 git은 정확히.gitignore라는 파일명을 인식하기 때문에.txt와 같은 확장자는 지우기 주의 : 확장자가 안 보일 때 확장자를 지우기 위해서는 윈도우 탐색기에서 파일 확장명 보기에 체크해두어야 함. 18.gitignore로 무시하기 (2) 생성된.gitignore 안에 e.txt를 적은 뒤 저장해보기 git이 작업 디렉터리 내 앞으로 e.txt 파일을 무시하겠다는 의미 (3) e.txt 생성하기 내용 예: text file e 19.gitignore로 무시하기 (4) git이 e.txt 무시 확인 20.gitignore로 무시하기 (5) 파일 외에 폴더에도 적용해보기 ignore 폴더 생성하기 ignore 폴더 안에 임의의 파일들 생성해보기 (예) ignore1.txt, ignore2.txt, ignore3.txt.gitignore파일에 e.txt 다음 줄에 ignore/라고 작성 21 commit에 대한 분석 commit 살펴보기 현업에서 개발되는 대규모의 SW의 경우 다수의 commit들이 모여서 만들어짐. Linux의 경우, https://github.com/torvalds/linux 22 commit에 대한 분석 commit 구분 각 커밋에는 고유한 커밋 해시가 있음 커밋 해시란 마치 학번, 사번과 같이 각 커밋이 가진 고유한 ID 특정 커밋(특정 변경사항)을 지칭할 때 사용 “상위 항목”에서는 특정 커밋을 지칭하기 위해 짧은 커밋 해시를 사용 상위항목: 어떤 커밋을 변경해서 만들어진 커밋인지 나타내는 항목 23 commit에 대한 분석 commit과 release SW를 개발해나가는 과정에서 다양한 commit이 쌓이게 됨. 로그인 기능, 글쓰기 기능과 같이 새로운 기능을 추가하는 커밋, 버그를 수정하는 커밋, 아주 사소한 변경 사항만 담은 커밋 등 24 commit에 대한 분석 commit과 release (cont’d) commit이 점점 쌓이며 SW 개발이 완성되어 감. SW가 충분히 개발됐다고 판단되면 마침내 사용자에게 결과물을 선보일 것인데, 개발한 SW를 사용자에게 선보이는 것을 release라고 함. 즉, 커밋이 쌓이면 언젠간 사용자에게 릴리스하게 됨 이제 사용자에게 릴리스해볼까? 25 commit에 대한 분석 commit과 release (cont’d) 사용자에게 release할 버전 설정은 어떻게 할까? 커밋 해시 이용? >> 가독성이 떨어져서 추후 수많은 커밋 중 유의미한 버전이 무엇인지 찾기 어려움‘ 일반적으로 가독성이 높은 태그(tag) 이용 - 특정 커밋에 붙일 수 있는 꼬리표 - 분기점이 되는 특정 커밋에 태그 사용: 주로 버전을 명시. 2wefxdf3jdkwif v1.0.0 26 commit에 대한 분석 commit과 release (cont’d) Sourcetree에서는 “태그” 버튼 클릭 태그 추가 or 태그 제거 가능 작업 사본 부모 : 최근에 만든 커밋에 태그를 붙이고 싶을 때 명시된 커밋: 특정 커밋에 태그를 붙이고 싶을 때 27 commit에 대한 분석 버전 표기법에 대한 이해 사용자에게 선보이는 버전 표기 방식은 소프트웨어마다 다름. 형태 형태 형태 등등 개발자가 정하기 나름. 28 commit에 대한 분석 버전 표기법에 대한 이해 예) 세자리 표기법 vX. Y.Z X: 가장 앞에 나오는 숫자는 주(Major) 버전이라고 부름 - 이는 가장 중요한 버전으로, 일반적으로 새롭게 내놓은 버전이 기존에 내놓은 버전과 호환되지 않을 정도로 큰 변화가 있을 때 증가 Y: 두 번째 숫자는 부(Minor) 버전이라 부름 - 일반적으로 새롭게 내놓은 버전이 기존에 내놓은 버전과 문제없이 호환되지만, 새로운 기능을 추가했을 때 증가 Z: 마지막 숫자는 수(Patch) 버전이라 부름 - 일반적으로 기존에 내놓은 버전과 문제없이 호환되며 버그를 수정한 정도의 작은 변화가 있을 때 증가 29 요약 하나의 버전을 만드는 과정 Working directory 내의 파일을 변경(추가, 삭제 등) 변경한 내용 중 버전에 포함할 파일을 stage에 올리기 커밋하기 => 버전 생성.gitignore를 작성해 버전 관리를 하지 않을 파일이나 폴더를 자동으로 걸러낼 수 있었음 Release 하기 개발한 SW를 고객들에게 오픈하기 태그를 통하여 버전 명시 30 Software Engineering laboratory Yeungnam University 1 작업 되돌리기 하나의 버전을 생성하기 위한 과정 (요약) Working directory에서 변경 사항 발생 Stage로 올리기 commit 하기 변경된 파일들을 취소하려면? stage에 올라간 파일은 어떻게 취소해야 할까? 아직 stage로 올리지 않은 변경된 파일을 취소하려면 어떻게 해야 할까? 이미 commit한 파일은 어떻게 취소할 수 있을까? 2 작업 되돌리기 stage에 올라간 파일 되돌리기 “선택 내용 스테이지에서 내리기” 클릭 3 작업 되돌리기 stage에 올라가지 않은 파일 되돌리기 돌아가는 것: 기존에 존재하고 있던 파일에 대한 수정 취소. 즉 변경사항을 폐기. 제거: 새롭게 생성된 파일의 변경 사항을 취소. 즉 파일이 만들어지기 전으로 돌아간다? 삭제의 의미 4 작업 되돌리기 commit 되돌리기 이전 돌아가고 싶은 커밋으로 가고 싶을 때 사용 릴리즈를 했는데 치명적인 버그로 인하여 롤백해야하는 경우 이전 커밋으로 되돌아가기 위해 사용 revert vs. reset 5 작업 되돌리기 commit한 파일 취소하는 방법 2가지 revert 버전을 되돌리되, 되돌아간 상태에 대한 새로운 버전(커밋)을 만드는 방식. 중요한 점은 기존의 버전은 삭제되지 않는다는 점. (예) 다섯 번째 버전을 revert하면 다음 그림과 같이 네 번째 버전으로 되돌아간 새로운 여섯 번째 커밋이 만들어짐 - 첫 번째 버전부터 다섯 번째 버전은 그대로 유지됨. 출처: 강민철, 모두의 깃&깃허브 6 작업 되돌리기 commit한 파일 취소하는 방법 2가지 reset 되돌아갈 버전의 시점으로 완전하게 되돌아가는 방식. - 즉, 되돌아갈 버전 이후의 버전은 삭제되는 방식. reset의 옵션 3가지: soft, mixed, hard 두 번째 버전으로 reset한 상황 출처: 강민철, 모두의 깃&깃허브 7 작업 되돌리기 commit한 파일 취소하는 방법 2가지 reset --soft 작업 디렉터리 내 변경 사항과 스테이지에 추가된 변경 사항은 유지, 커밋했다는 사실만 되돌리는 reset. 변경 이력은 모두 삭제하지만 변경 내용은 남아있음. stage 되어있음. 출처: 강민철, 모두의 깃&깃허브 8 작업 되돌리기 commit한 파일 취소하는 방법 2가지 reset --mixed 작업 디렉터리 내 변경 사항은 유지하되, 스테이지와 커밋을 되돌리는 reset. 변경 이력은 모두 삭제하지만 변경 내용은 남아있음. unstage 상태로 코드는 남아 있음. 출처: 강민철, 모두의 깃&깃허브 9 작업 되돌리기 commit한 파일 취소하는 방법 2가지 reset --hard 마지막으로 작업 디렉터리 내 변경 사항까지 통째로 되돌리는 reset. 돌아간 커밋 이후의 변경 이력은 모두 삭제. 출처: 강민철, 모두의 깃&깃허브 10 (실습) revert in SourceTree revert 하기 위한 커밋에서 마우스 우측버튼 “커밋 되돌리기” 클릭. 11 (실습) reset in SourceTree reset 하기 위한 커밋에서 마우스 우측버튼 “이 커밋까지 현재 브랜치를 초기화” 클릭. soft나 mixed 옵션일 경우, 해당 커밋 이후에 변경된 파일들은 “커밋하지 않은 변경사항”이라는 항목의 브랜치로 생성하여 (staging or unstaging 상태로) 유지함. 12 작업 임시 저장하기 stash(스태시) 아직 마무리하지 않은 작업을 스택에 잠시 저장할 수 있도록 하는 명령어 아직 완료하지 않은 일을 commit하지 않고 나중에 다시 가져와 마무리할 수 있음. 자신이 어떤 작업을 하던 중에 다른 요청이 들어와 하던 작업을 멈추고 잠시 브랜치를 변경해야 할 일이 있을 경우, 아직 완료하지 않은 일을 commit하는 것은 껄끄럽기 때문에 stash 이용. 아래에 해당하는 파일들을 보관해두는 장소 Modified이면서 Tracked 상태인 파일 (tracked: 과거에 이미 commit했던 관리 대상 상태의 파일) Staging area에 있는 파일 (staged 상태의 파일) https://gmlwjd9405.github.io/2018/05/18/git-stash.html 13 작업 임시 저장하기 stash(스태시) 아직 마무리하지 않은 작업을 스택에 잠시 저장할 수 있도록 하는 명령어 아직 완료하지 않은 일을 commit하지 않고 나중에 다시 가져와 마무리할 수 있음. 자신이 어떤 작업을 하던 중에 다른 요청이 들어와 하던 작업을 멈추고 잠시 브랜치를 변경해야 할 일이 있을 경우, 아직 완료하지 않은 일을 commit하는 것은 껄끄럽기 때문에 stash 이용. 아래에 해당하는 파일들을 보관해두는 장소 Modified이면서 Tracked 상태인 파일 (tracked: 과거에 이미 commit했던 관리 대상 상태의 파일) Staging area에 있는 파일 (staged 상태의 파일) 14 작업 임시 저장하기 stash(스태시) 적용 상황 출처: 강민철, 모두의 깃&깃허브 15 작업 임시 저장하기 stash(스태시)로 작업 내역 임시 저장하기 스태시를 하게 되면 작업 디렉토리에서 생성한 모든 변경 사항이 임시 저장됨. 다수의 임시 저장 항목 가능. 그 후 작업 디렉토리는 변경 사항이 생기기 전의 상태로 돌아감. 출처: 강민철, 모두의 깃&깃허브 16 작업 임시 저장하기 stash(스태시) 로 임시 저장된 변경사항 적용하기 스태시로 임시 저장된 변경 사항들은 언제든 다시 꺼내어 작업 디렉터리에 다시 적용할 수 있음. 출처: 강민철, 모두의 깃&깃허브 17 작업 임시 저장하기 stash(스태시) 적용시 주의사항 스태시는 git이 변경 사항을 추적하는(tracked) 파일에만 사용할 수 있음. 스테이지에 이미 올라와 있거나 한번이라도 커밋한 적이 있는 파일에만 사용할 수 있음. 방금 막 생성한 파일처럼 git이 기존에 변경 사항을 추적하지 않은(untracked) 파일에는 스태시를 사용할 수 없음. 출처: 강민철, 모두의 깃&깃허브 18 (실습) stash in SourceTree 스태시로 작업 임시 저장하기 파일 준비 임의의 로컬 저장소에 a.txt, b.txt, c.txt, d.txt, e.txt 파일을 만들고 이 다섯 개의 텍스트 파일에 각각 A, B, C, D, E를 저장 후, staging 및 commit 하기 변경 사항 생성 a.txt 파일 안에 B를 추가하고, b.txt 파일은 삭제 c.txt 파일 안에 D를 추가 19 (실습) stash in SourceTree 스태시로 작업 임시 저장하기 작업 내역 임시 저장 - 상단의 “스태시”를 클릭 ‘변경점을 Stash하겠습니까?’라는 물음에 대해 ‘임시저장 1’을 입력 스테이지에 있는 변경사항 유지 항목은 체크하지 않고 확인을 클릭하면 좌측 스태시 메뉴에 임시저장 생성. 탐색기에서 작업 파일들이 원래대로 복구됨 확인. 20 (실습) stash in SourceTree 스태시로 작업 임시 저장하기 추가 변경 사항 생성 이번에는 d.txt 파일과 e.txt 파일을 삭제해보기 stash 하기 위 두 개의 파일을 삭제한 변경 사항을 또 다시 임시 저장하기 스태시 메시지에는 ‘임시저장 2’를 적고, 확인 버튼 클릭 21 (실습) stash in SourceTree 임시 저장된 작업 내역 확인 스태시에 임시저장1, 임시저장2 클릭해보기 스태시 적용하기 위해서는 마우스 우측버튼 클릭 후 스태시 적용 클릭 파일 상태 체크해보면 원래 상태로 복구된 것을 확인 가능함. 22 Software Engineering laboratory Yeungnam University 1 git branch branch 개념 (branch: 나뭇가지?) SW 개발시 독립적인 개발 라인을 생성하고 관리하는 방법. 개발을 하다 보면 코드를 여러 개로 복사해야 하는 일이 자주 발생. 출처: 강민철, 모두의 깃&깃허브 코드를 통째로 복사하고 나서 원래 코드와는 상관없이 독립적으로 개발을 진행할 수 있는데, 이렇게 독립적으로 개발하는 것이 브랜치. - 독립적인 작업 공간 생성: 각 브랜치는 다른 브랜치의 영향을 받지 않으므로, 각기 다른 작업을 동시에 진행. - 병합 기능: 브랜치는 필요에 따라 다른 브랜치와 병합 될수 있어, 다양한 작업을 하나로 통합하는데 유용. Git에서는 기본적으로 master 브랜치 (main이라는 용어를 사용하기도 함)를 생성함. 고객과 협의를 거쳐 웹사이트를 개발하고 완성했는데 새로운 기능을 추가해달라고 고객이 요구했다고 가정해보자. 단순히 기존 파일에 새로운 기능을 위한 소스를 추가해서 버전을 새로 만들어도 될까? 만약 새로운 기능을 추가했을때 오류없이 완벽하게 동작한다고 보장할 수 없다면 어떤 방식으로 해야할까? 제대로 동작하는 소스는 그대로 둔 채 소스 추가 버전을 따로 만들어 관리하고, 완벽하게 완성한 다음 원래 소스에 더할 수 있다면 편리할 것이다. 2 git branch branch의 기본 활용 신규 기능 개발, 버그 수정 작업 등을 수행할 때 브랜치를 사용하여 다른 팀 구성원의 작업과 분리하여 진행함. 하나의 SW 프로젝트에서 여러 기능을 동시에 개발하고, 다른 브랜치의 영향을 받지 않으면서 작업 가능. 출처: 강민철, 모두의 깃&깃허브 3 git branch Master branch(Main branch)에서만 협업한다면? 내가 작업중인 파일을 누군가 건드릴 수 있게 됨. 기획 변경으로 개발중인 기능이 필요 없어졌을 때 혹은 문제가 발생했을 때 원하는 시점으로 롤백하기도 어려워짐. 여러 기능을 개발하면서 남겨진 커밋 히스토리가 메인 브랜치에 뒤죽박죽 섞이게 될 것이기 때문. 4 git branch branch 기능을 사용한다면? 다른 브랜치에 영향을 받지 않는 독립적인 환경에서 기능 개발 및 버그 수정 가능. 즉, 여러 기능을 여러 사람이 손쉽게 병렬적으로 개발할 수 있는 환경 구축 가능. 마치 프로젝트 폴더를 복사해서 복사한 폴더에서 각자 따로 작업하는 것과 같음. 일반적으로 기능을 개발할 때 브랜치를 생성하고, 코드를 작성하며 커밋을 남김. 이후 기능 개발이 완료된 경우에 메인 브랜치에 merge(병합)하면 안전하게 기능을 개발할 수 있음. 이런 브랜치를 사용하여 새로운 기능을 개발하다, 기획이 변경되어 기능이 필요 없어졌을 때도 간단하게 브랜치만 삭제해버리면 끝. 또한 실험적인 것들을 맘편하게 시도해보고, 안전하게 삭제할 수도 있을 것. 5 git branch HEAD와 checkout HEAD HEAD는 기본적으로 현재 작업 중인 브랜치의 최신 커밋을 가리키는 일종의 표시. 보통은 현재 작업 중인 브랜치의 최신 커밋을 가리키지만, 브랜치를 나누고 합치는 과정에서 HEAD의 위치를 자유자재로 바꿀 수 있음. checkout 특정 브랜치에서 작업할 수 있도록 작업 환경을 바꾸는 것을 의미. 특정 브랜치로 checkout하게 되면 HEAD의 위치가 해당 브랜치의 최신 커밋을 가리키고, 작업 디렉터리는 checkout한 브랜치의 모습으로 바뀌게 됨. 6 git branch HEAD와 checkout 예 HEAD가 master 브랜치의 최신 커밋을 가리킬 경우, 다시 말해 master 브랜치로 체크아웃할 경우 working directory에는 총 네 개의 커밋이 만들어진 직후의 모습으로 바뀌게 됨. HEAD가 foo 브랜치의 최신 커밋을 가리킬 경우, 다시 말해 foo 브랜치로 체크아웃할 경우 작업 디렉터리는 총 다섯 개의 커밋이 만들어진 직후의 모습을 띄게 됨. HEAD가 bar 브랜치를 가리킬 경우, 즉 bar브랜치로 체크아웃할 경우 작업 디렉터리는 총 여섯 개의 커밋이 만들어진 직후의 모습을 띄게 됨 출처: 강민철, 모두의 깃&깃허브 7 git branch branch 나누기 전략 실무에서는 branch 이름 정하고 관리하는 전략들이 존재함. branch 이름을 마구잡이로 지으면 해당 branch가 무엇을 위해 만들어졌는지 도무지 알 수가 없음. 출처: 강민철, 모두의 깃&깃허브 8 (실습) git branch 만들기 비어있는 로컬저장소 생성 후, a.txt 파일 만들고 커밋. 커밋 메시지는 “master 1번 커밋”. b.txt 파일 만들고 커밋. 커밋 메시지는 “master 2번 커밋”. c.txt 파일 만들고 커밋. 커밋 메시지는 “master 3번 커밋”. 9 (실습) git branch 만들기 branch 생성하기 상단에 브랜치 클릭 후 foo 라는 이름의 브랜치 생성. “새 브랜치 체크아웃” 클릭 확인. 작업환경을 새롭게 생성된 브랜치로 변경한다는 의미. 즉, 작업환경을 foo 브랜치로 변경함. 10 (실습) git branch 만들기 branch 생성하기 좌측의 브랜치 메뉴에 굵게 표기된 foo 확인 가능. 굵게 표기된 브랜치 이름이 현재 체크아웃된 브랜치를 나타냄. 11 (실습) git branch 만들기 branch 생성하기 foo 브랜치에 파일 추가하여 커밋 쌓아 올리기. d.txt 파일 만들고 커밋. 커밋 메시지는 “foo branch 4번 커밋”. e.txt 파일 만들고 커밋. 커밋 메시지는 “foo branch 5번 커밋”. master branch가 아닌 foo branch에 추가됨. - 현재 checkout된 branch가 foo branch이기 때문. 12 (실습) git branch 만들기 foo branch 파일 내용 확인 탐색기 클릭하여 현재 working directory에 txt파일 5개 확인 가능 (현재는 foo branch에 checkout 되어 있기 때문) master branch에는 커밋이 3개 master branch로부터 파생된 foo branch에는 커밋이 5개 master branch로 checkout 해보기 좌측 브랜치 메뉴에서 master를 더블클릭. 탐색기 클릭하여 현재 working directory에 txt파일 3개 확인 가능 (현재는 master branch에 checkout 되어 있기 때문) 13 (실습) git branch 만들기 새로운 branch 생성하기 bar 브랜치 생성하기 현재 master 브랜치에 체크아웃되어 있는 상태임. 상단에 브랜치 클릭. 작업환경을 bar 브랜치로 변경하기 위해 ‘새 브랜치 체크아웃’ 클릭 확인. 14 (실습) git branch 만들기 새로운 branch 생성하기 bar 브랜치에 파일 추가하여 커밋 쌓아 올리기 bar_d.txt 파일 만들고 커밋. 커밋 메시지는 “bar branch 4번 커밋”. bar_e.txt 파일 만들고 커밋. 커밋 메시지는 “bar branch 5번 커밋”. bar_f.txt 파일 만들고 커밋. 커밋 메시지는 “bar branch 6번 커밋”. master branch가 아닌 bar branch에 추가됨. - 현재 checkout된 branch가 bar branch이기 때문. 출처: 강민철, 모두의 깃&깃허브 15 git flow git 브랜치를 효과적으로 관리하기 위한 워크플로우 (대표적인 branch 전략) 각 SW개발업체별로 직접 브랜치 전략을 만들어 사용해도 되겠지만, 세상에는 브랜치를 효과적으로 관리하기 위한 모범 사례들이 존재함. 좋은 브랜치도 규칙 없이 마구잡이로 사용하면 혼란 발생: 명확한 기준 필요. - ‘이 브랜치는 어떤 목적으로 생성된거지?’, - ‘이 브랜치는 어떤 커밋에서 분기된거지?’, - ‘어떤 브랜치에서 내 브랜치를 생성해야하지?’, - ‘내 브랜치는 어디에 병합해야지?’, - ‘어떤 브랜치가 최신이지?’, - ‘어떤 브랜치가 배포된 버전이지?’ 등등 수 많은 의문점이 생길것이고 프로젝트는 엉망이될 것 이다. 16 git flow git flow의 브랜치 전략 (Main, Develop, Supporting branches) Main branch 프로젝트 시작 시 생성되며, 개발 프로세스 전반에 걸쳐 유지. 출시 가능한 프로덕션 코드를 모아두는 브랜치. 배포된 각 버전을 Tag를 이용해 표시. Develop branch 개발 프로세스 전반에 걸쳐 항상 유지되는 브랜치. 다음 버전 개발을 위한 코드를 모아두는 브랜치. 개발이 완료되면, Main 브랜치로 merge 됨. 출처: https://nvie.com/posts/a-successful-git-branching-model/ 17 git flow git flow의 브랜치 전략 Supporting branch Feature branch, - 하나의 기능을 개발하기 위한 브랜치. - Develop 브랜치에서 생성하며, 기능이 개발 완료되면 다시 Develop 브랜치로 merge 됨. - (주의점) Fast-Forward로 merge하지 않고, Merge Commit을 생성하며 머지를 해주어야 한다. 이렇게해야 히스토리가 특정 기능 단위로 묶이게 됨. - 네이밍은 feature/branch-name 과 같은 형태로 생성. Release branch, Hotfix branch. 18 git flow git flow의 브랜치 전략 Supporting branch Feature branch, Release branch, - 소프트웨어 release를 준비하기 위한 브랜치. - Develop 브랜치에서 생성하며, 버전 이름 등의 소소한 데이터를 수정하거나 배포전 사소한 버그를 수정하기 위해 사용. - 배포 준비가 완료되었다면 Main과 Develop 브랜치에 둘다 merge 함. - 이때, Main 브랜치에는 태그를 이용하여 버전을 표시. - Release 브랜치를 따로 운용함으로써, 배포 업무와 관련없는 팀원들은 병렬적으로 Feature 브랜치에서 이어서 기능을 개발할 수 있게 됨. - 네이밍은 release/v1.1 과 같은 형태로 생성. Hotfix branch. 19 git flow git flow의 브랜치 전략 Supporting branch Feature branch, Release branch, Hotfix branch. - 이미 배포된 버전에 문제가 발생했다면, Hotfix 브랜치를 사용하여 문제를 해결. - Main 브랜치에서 생성하며, 문제 해결이 완료되면 Main과 Develop 브랜치에 둘다 merge 함. - Release 브랜치와 마찬가지로 Hotfix 브랜치를 따로 운용함으로써, 핫픽스 업무와 관련없는 팀은 병렬적으로 기능 개발 가능. - 네이밍은 hotfix/v1.0.1 과 같은 형태로 생성. 20 branch 합치기 branch를 합치는 방법은 크게 2가지 (1) Merge 3-way merge - 각 branch에 새로운 commit이 하나씩 존재하는 경우 수행되는 merge - 새로운 commit에 2개의 branch를 합치는 것 - 가장 기본적인 형태 fast-forward merge - 3-way와 다르게 새로운 branch에만 commit이 존재하고 기존 branch에서는 commit을 하지 않은 경우에는 자동으로 fast-forward merge가 수행 https://bluishhot-star.tistory.com/246 21 branch 합치기 branch를 합치는 방법은 크게 2가지 (2) Rebase 브랜치의 시작점을 다른 commit으로 옮겨주는 것 - rebase 후 두 브랜치의 병합은 sub브랜치의 시작점을 main의 최근 commit으로 옮겨준 후 (rebase) - fast-forward merge를 수행 복잡한 브랜치 구조에서 3-way merge를 하다보면 git log가 복잡해지는데 간단하고 짧은 브랜치에 대해서 rebase를 사용하면 깔끔하게 정돈할 수 있음. (단점) conflict 발생 확률이 높기 때문에 이를 하나씩 해결해주어야 할 수도 있다. https://bluishhot-star.tistory.com/246 22 git merge merge (병합)개념 나누어진 브랜치를 하나로 통합하는 것. 앞선 실습에서 foo 브랜치를 master 브랜치로 병합하면 어떻게 될까? Merge가 없다면? 출처: 강민철, 모두의 깃&깃허브 23 git merge 3-way merge 각 브랜치의 마지막 커밋 두 개와 공통 조상의 총 3개의 커밋을 이용하는 merge 방식 3-way merge를 수행하여 새로운 커밋을 만들어 냄 (예) 두 브랜치의 마지막 커밋 두 개(C3, C4)와 공통 조상(C2)을 사용하는 3-way Merge로 새로운 커밋을 만들어 냄. 출처: Scott Chacon and Ben Straub, Progit, 2nd edition. 24 git merge Fast-forward merge 변화가 없었던 브랜치에 특정 브랜치가 병합되는 작업 (HEAD만 변경) (예) master 브랜치 입장에서는 자신의 브랜치가 마치 빨리 감기 하듯이 foo 브랜치와 동일하게 업데이트됨. master 브랜치가 빨리 감기 하듯 foo와 동일해질 수 있었던 이유는, foo 브랜치가 master 브랜치에서부터 뻗어나온 시점부터 병합되는 순간까지 master 브랜치에 어떤 변화도 없었기 때문임. 다시 말해, foo 브랜치는 master 브랜치에서 뻗어나온 이후로 여러 커밋이 쌓였지만, 그동안 master 브랜치는 어떤 새로운 커밋도 없이 그저 가만히 있었음. 그렇기 때문에 foo 브랜치를 master 브랜치로 병합할 적에 master 브랜치는 그저 foo 브랜치에 새롭게 쌓인 커밋을 반영만 하면 됨. 상위 branch에 변경사항이 없을 때에만 fast-forward merge 가능 출처: 강민철, 모두의 깃&깃허브 25 (실습) git merge foo 브랜치를 master 브랜치로 merge 하기 먼저 master브랜치로 병합하려면 master 브랜치로 체크아웃해야 함. foo 브랜치에서 마우스 오른쪽 버튼을 클릭. 현재 브랜치로 foo 병합이 있음 ‘현재 브랜치’는 현재 체크아웃한 브랜치, 즉 master 브랜치를 말함 master 브랜치로 foo 브랜치를 병합해야 하니 이를 클릭. 출처: 강민철, 모두의 깃&깃허브 26 (실습) git merge foo 브랜치를 master 브랜치로 merge 하기 ‘병합 확정’ 창이 뜨면 확인을 클릭 fast-forward가 가능해도 새 커밋으로 생성 항목은 체크하지 않음 foo 브랜치가 master 브랜치에 병합 완료 master 브랜치는 foo 브랜치와 같아졌음. 출처: 강민철, 모두의 깃&깃허브 27 (실습) git merge foo 브랜치를 master 브랜치로 merge 하기 브랜치를 병합하고 나서 더 이상 브랜치에 남은 작업이 없다면 삭제 권장. foo 브랜치를 master 브랜치와 병합한 뒤 foo 브랜치에서 더는 작업하지 않을 예정이라면 병합 후 foo 브랜치를 삭제하는 것을 권장 foo 브랜치를 삭제하기 위해서는 master 브랜치에 체크아웃되어 있는 상태로 foo 브랜치에서 마우스 오른쪽 버튼을 클릭한 후 foo 삭제를 클릭. 출처: 강민철, 모두의 깃&깃허브 28 (실습) git merge foo 브랜치를 master 브랜치로 merge 하기 foo 브랜치 삭제 완료 결과 화면 출처: 강민철, 모두의 깃&깃허브 29 (실습) git merge bar 브랜치의 4번 커밋을 master로 merge 하기 메뉴바 상단에 “병합” 메뉴도 이용 가능. master 브랜치로 체크아웃한 뒤 상단의 병합을 클릭. 여기서 master 브랜치에 병합할 브랜치의 커밋을 클릭한 뒤 확인을 누르면 해당 커밋이 병합 bar 브랜치의 4번 커밋을 master 브랜치로 병합하려면 4번 커밋을 클릭한 뒤 확인을 클릭 출처: 강민철, 모두의 깃&깃허브 30 (실습) git merge bar 브랜치의 4번 커밋을 master로 merge 하기 master 브랜치에 bar 브랜치 4번 커밋이 병합됨. Merge commit ‘’ 라는 새로운 커밋이 생성됐다는 것을 볼 수 있음. Fast-forward merge가 아닌 병합에서는 항상 새로운 commit이 생성됨. 다음 그림과 같이 bar 브랜치에는 없는 커밋이 master브랜치에 있고 master 브랜치에는 없는 커밋이 bar 브랜치에 있는 상태에서 두 브랜치를 병합할 때는 이렇듯 새로운 커밋이 생성됨. 출처: 강민철, 모두의 깃&깃허브 31 (실습) git merge bar 브랜치의 4번 커밋을 master로 merge 하기 탐색기의 파일 현재 파일 상태를 확인해보기 bar 브랜치의 네 번째 커밋이었던 bar_d.txt 파일이 master 브랜치에 생성 출처: 강민철, 모두의 깃&깃허브 32 (실습) git merge bar 브랜치의 5번 및 6번 커밋을 master로 merge 하기 master 브랜치로 체크아웃한 뒤 상단의 병합을 클릭. bar 브랜치의 6번 커밋을 클릭한 뒤 확인을 클릭 (6번 커밋에 5번 커밋도 포함). 출처: 강민철, 모두의 깃&깃허브 33 (실습) git merge bar 브랜치의 5번 및 6번 커밋을 master로 merge 하기 master 브랜치에 bar 브랜치 5번 및 6번 커밋이 병합됨. Merge branch ‘bar’ 라는 새로운 커밋이 생성. 출처: 강민철, 모두의 깃&깃허브 34 (실습) git merge bar 브랜치의 5번 및 6번 커밋을 master로 merge 하기 탐색기의 파일 현재 파일 상태를 확인해보기 bar 브랜치의 6번째 커밋이었던 bar_f.txt 파일이 master 브랜치에 생성 bar 브랜치의 5번째 커밋이었던 bar_e.txt 파일이 master 브랜치에 생성 foo 브랜치에서 생성했던 파일들과 bar브랜치에서 생성했던 파일들이 모두 잘 추가되어 있음을 확인 가능. 출처: 강민철, 모두의 깃&깃허브 35 git merge에서 충돌 해결하기 Resolve the Merge Conflicts 충돌이란 병합하려는 두 브랜치가 서로 같은 내용을 다르게 수정한 상황을 의미. 실제 SW 개발환경에서 브랜치를 병합하는 과정은 생각보다 순탄치 않음. 앞에서는 브랜치가 한 번에 성공적으로 합쳐졌지만 그렇지 못한 상황, 즉 충돌이 발생하는 경우도 있기 때문임. 충돌이 발생하면 브랜치가 한 번에 병합되지 못함. 충돌은 여럿이 협업하여 개발할 때 빈번히 발생함. 36 git merge에서 충돌 해결하기 Resolve the Merge Conflicts (예제) master 브랜치에서 foo 브랜치가 생성된 경우를 생각해보자. master 브랜치는 a.txt 파일의 첫 번째 줄을 B로 수정한 다음 커밋했고, foo 브랜치는 a.txt 파일의 첫 번째 줄을 C로 수정한 다음 커밋했다고 가정하자. 이런 상황에서 foo 브랜치를 master 브랜치에 병합한다면? Conflict 발생! - a.txt 파일에는 어떤 내용을 저장해야 할까? - master 브랜치를 따라 B라고 저장해야 할까? 아니면 foo 브랜치를 따라 C라고 저장해야 할까? - 결국, 개발자가 어떤 브랜치를 반영할지 직접 선택해야 함. 출처: 강민철, 모두의 깃&깃허브 37 git merge에서 충돌 해결하기 Resolve the Merge Conflicts 브랜치를 병합하는 과정에서 충돌이 발생했을 경우, 충돌이 발생한 파일들의 충돌을 해결한 뒤 다시 커밋해야만 브랜치가 올바르게 병합. 충돌을 해결한다는 의미는 어떤 브랜치 내용을 최종적으로 반영할지를 직접 선택하는 것. 충돌이 발생한 이유는 병합하려는 두 브랜치가 같은 내용을 서로 다르게 수정했기 때문임. 따라서 충돌이 발생하면 충돌이 발생한 두 브랜치 중 어떤 브랜치의 내용을 병합 결과에 반영할지를 개발자가 직접 선택. 38 (실습) Merge conflict 브랜치 충돌 상황 만들기 임의의 로컬 저장소를 만들기 master 브랜치에 A가 저장된 a.txt 파일을 만든 뒤 이를 커밋 커밋 메시지: master branch 1번째 커밋 새로운 브랜치 foo를 생성하기 생성한 foo 브랜치로 체크아웃 후 a.txt 파일에 적힌 A를 foo로 변경한 뒤 커밋. 커밋 메시지: foo branch 1번째 커밋 39 (실습) Merge conflict 브랜치 충돌 상황 만들기 master 브랜치로 체크아웃 후 a.txt 파일에 적힌 A를 master로 변경한 뒤 커밋. 커밋 메시지: master branch 2번째 커밋 현재 foo 브랜치와 master 브랜치는 같은 내용을 다르게 수정한 상태 foo 브랜치는 a.txt 파일을 foo로 변경한 뒤 커밋 master 브랜치는 a.txt 파일을 master로 변경한 뒤 커밋 이 상태에서 두 브랜치를 병합하면 충돌이 발생! 40 (실습) Merge conflict 브랜치 충돌 상황 만들기 충돌 확인을 위해 merge 진행해보기 master 브랜치로 체크아웃한 상태로 foo 브랜치에서 마우스 오른쪽 버튼을 클릭한 후 현재 브랜치로 foo 병합을 클릭. 출처: 강민철, 모두의 깃&깃허브 41 (실습) Merge conflict 브랜치 충돌 상황 만들기 충돌이 발생하면 다음과 같이 커밋하지 않은 변경사항이 생기고, 스테이지에 올라가지 않은 파일과 스테이지에 올라간 파일 항목에는 충돌이 발생한 파일이 추가 출처: 강민철, 모두의 깃&깃허브 42 (실습) Merge conflict 브랜치 충돌 상황 만들기 충돌한 파일 내용 확인 충돌이 발생한 파일에는 , ======= 기호: 일종의 영역 표기 ======= 기호를 기준으로 윗부분은 HEAD가 가리키는 브랜치, 즉 현재 체크아웃한 브랜치의 내용이 적혀 있고, 아랫부분은 병합하려는 브랜치, 즉 foo 브랜치의 내용이 적혀 있음. 이는 > 기호 사이의 내용을 선택할지 고르라는 표기 여러분은 이 두 영역 중 반영할 부분을 직접 선택해 충돌을 해결해야 함 출처: 강민철, 모두의 깃&깃허브 43 (실습) Merge conflict 브랜치 충돌 해결해보기: master 브랜치 내용 반영 충돌이 발생한 파일, 즉 스테이지에 올라가지 않은 파일 항목에 있는 a.txt 파일에서 마우스 오른쪽 버튼을 클릭 – 충돌 해결 클릭 ‘내것’을 이용해 해결 - 현재 체크아웃된 브랜치(HEAD, master 브랜치)의 내용을 병합에 반영하겠다는 의미 ‘저장소’것을 사용하여 해결 - 병합하려는 브랜치(foo 브랜치)의 내용을 병합에 반영하겠다는 의미 master 브랜치를 병합 결과로 반영할 예정이므로 ‘내것’을 이용해 해결을 클릭. master 브랜치의 최신 커밋 해시 출처: 강민철, 모두의 깃&깃허브 44 (실습) Merge conflict 브랜치 충돌 해결해보기: master 브랜치 내용 반영 충돌이 발생한 파일을 담고 있던 커밋하지 않은 변경사항이 사라짐: 충돌 해결! 브랜치 병합을 끝내려면 충돌을 해결한 뒤 다시 커밋해야 함 충돌을 해결했다고 해서 브랜치 병합이 끝난 것이 아님 파일 상태로 들어가 보면, 하단부에 다음과 같이 커밋 메시지가 자동으로 기입되어 있고, 커밋이 활성화되어 있음 커밋 클릭하기 출처: 강민철, 모두의 깃&깃허브 45 (실습) Merge conflict 브랜치 충돌 해결해보기: master 브랜치 내용 반영 History에서 충돌이 발생했던 foo 브랜치가 성공적으로 병합된 것을 확인할 수 있음. a.txt 파일 내용도 master 브랜치의 내용으로 업데이트 충돌 해결하기 요약 - 같은 내용을 다르게 수정한 브랜치를 병합하면 충돌이 발생 - 충돌이 발생하면 ======= 기호를 기준으로 나누어진 > 기호 사이의 코드 중 무엇을 반영할지 선택 - 그런 다음 다시 커밋하면 성공적으로 병합할 수 있음. 46 git rebase Rebase 개념 브랜치의 재배치 브랜치가 뻗어나온 기준점을 변경하는 것 출처: 강민철, 모두의 깃&깃허브 47 git rebase Rebase 동작 일단 두 브랜치가 나뉘기 전인 공통 커밋으로 이동하고 나서 그 커밋부터 지금 Checkout 한 브랜치가 가리키는 커밋까지 diff를 차례로 만들어 어딘가에 임시로 저장 Rebase 할 브랜치(experiment)가 합칠 브랜치(master)가 가리키는 커밋을 가리키게 하고 아까 저장해 놓았던 변경사항을 차례대로 적용 적용 후 master 브랜치를 fast-forward merge 시킴. Rebase를 하든지, Merge를 하든지 최종 결