Open Source Product

xWiki 소개

이 페이지는 xWiki의 간단한 화면 덤프를 공유하기 위해 작성되었다.  Wiki Home Wiki Home은 별도의 페이지이고 아래와 같이 구성할 수 있다.  image2013-10-11 11:5:19.png Space 생성 문서를 정리하기 위해 먼저 Space(Project)를 생성한다.  image2013-10-11 11:7:43.png 스페이스 대시보드 스페이스 대시보드는 페이지로 구성된다. image2013-10-11 11:12:52.png 페이지 생성 스페이스 내부에 페이지를 생성하여 문서를 작성한다.  image2013-10-11 11:8:45.png 페이지 작업 아래는 Wiki 페이지 작성을 위한 에디터의 예시를 보여준다.  image2013-10-11 11:11:35.png 생성된 페이지 다음은 생성된 페이지의 예시를 보여준다.  image2013-10-11 11:12:7.png

Git 가이드

이 문서는 Git 가이드를 공유하기 위해 작성되었다.  image2019-6-15_13-14-24.png image2019-6-15_13-15-58.png image2019-6-15_13-16-16.png image2019-6-15_13-16-35.png image2019-6-15_13-16-54.png image2019-6-15_13-17-10.png 1. Git 시작하기 Git 저장소 https://confluence.curvc.com/pages/viewpage.action?pageId=51578247&src=contextnavpagetreemode git init git clone git config 변경 저장하기 git add git commit git diff git stash .gitignore 저장소 점검하기 git status git log git tag git blame 변경 취소하기 git 실행 취소 git clean git revert git reset git rm Rewriting history https://confluence.curvc.com/display/ASD/Rewriting+history?src=contextnavpagetreemode git commit --amend https://confluence.curvc.com/display/ASD/git+commit+--amend?src=contextnavpagetreemode git rebase https://confluence.curvc.com/display/ASD/git+rebase?src=contextnavpagetreemode git reflog https://confluence.curvc.com/display/ASD/git+reflog?src=contextnavpagetreemode 2. Git 협업하기 동기화하기 git remote https://confluence.curvc.com/display/ASD/git+remote?src=contextnavpagetreemode git fetch https://confluence.curvc.com/display/ASD/git+fetch?src=contextnavpagetreemode git pull https://confluence.curvc.com/display/ASD/git+pull?src=contextnavpagetreemode git push https://confluence.curvc.com/display/ASD/git+push?src=contextnavpagetreemode 브랜치 사용하기 git branch https://confluence.curvc.com/display/ASD/git+branch?src=contextnavpagetreemode git checkout https://confluence.curvc.com/display/ASD/git+checkout?src=contextnavpagetreemode git merge https://confluence.curvc.com/display/ASD/git+merge?src=contextnavpagetreemode 병합 충돌 해결하기 (Merge conflicts) https://confluence.curvc.com/pages/viewpage.action?pageId=51578393&src=contextnavpagetreemode 병합 전략 (Merge strategies) Pull request 만들기

GitLab 가이드

LDAP 가이드

이 문서는 LDAP 가이드를 공유하기 위해 작성되었다. 

쿠버네티스(Kubernetes) 가이드

이 문서는 쿠버네티스(Kubernetes - k8s) 가이드를 공유하기 위해 작성되었다. 

Eclipse Che 가이드

이 문서는 eclipse che 가이드를 공유하기 위해 작성되었다. 

Gradle 가이드

Jenkins 가이드

이 문서는 Jenkins 가이드를 공유하기 위해 작성되었다. 

Subversion 가이드

이 문서는 Subversion 가이드를 공유하기 위해 작성되었다. 

Open Source knowledge base

Selenium 가이드

이 문서는 Selenium 을 이용한 웹 테스트 자동화 방법을 정리한다. 개요 Selenium은 웹 브라우저를 자동화하기 위한 강력하고 널리 사용되는 오픈 소스 프레임워크입니다. 웹 페이지와 상호 작용하기 위한 테스트 스크립트를 작성하고, 사용자 작업을 시뮬레이션하며, 다양한 브라우저와 플랫폼에서 웹 애플리케이션의 동작을 검증할 수 있는 도구와 라이브러리를 제공한다. Selenium은 Java, C#, Python, Ruby, JavaScript를 포함한 다양한 프로그래밍 언어를 지원하여 웹 애플리케이션 테스팅에 있어 다재다능한 선택지를 제공한다. 제공 기능 다양한 언어 지원: Selenium은 Java, C#, Python, Ruby, JavaScript 등 여러 프로그래밍 언어를 지원하여 다양한 개발 환경에서의 사용을 가능하게 한다. 크로스 브라우저 테스팅: Selenium WebDriver를 통해 Chrome, Firefox, Internet Explorer, Safari 등 다양한 웹 브라우저에서 웹 애플리케이션을 자동으로 테스트할 수 있다. 웹 애플리케이션 자동화: 사용자의 웹 브라우징 활동을 모방하여 웹 페이지와의 상호 작용을 자동화할 수 있습니다. 이는 폼 제출, 마우스 클릭, 데이터 입력 및 추출 등을 포함한다. Selenium IDE: 브라우저 확장 프로그램으로 제공되며, 코드 작성 없이 테스트 케이스를 기록하고 재생할 수 있는 기능을 제공합니다. 이를 통해 비개발자도 쉽게 테스트 스크립트를 생성할 수 있다. Selenium Grid: 여러 시스템과 브라우저에서 동시에 테스트를 실행할 수 있게 해주어, 대규모 테스트 실행과 분산 테스팅이 가능합니다. 이는 테스트의 실행 시간을 단축시키고 효율성을 높여 준다. 오픈 소스: Selenium은 오픈 소스 소프트웨어로, 무료로 사용할 수 있으며, 활발한 커뮤니티의 지원을 받아 지속적으로 개선되고 있다. Selenium 테스트 자동화 구성 요소 Selenium은 여러 컴포넌트로 구성됩니다: Selenium WebDriver: 직접 브라우저 자동화와 상호 작용을 허용하는 핵심 컴포넌트입니다. 브라우저에 명령을 보내고 결과를 검색하여 웹 애플리케이션의 자동화를 가능하게 한다. Selenium IDE (Integrated Development Environment): 코드 작성 없이 상호 작용을 녹화 및 재생할 수 있는 Chrome과 Firefox 확장 프로그램으로, 테스트 스크립트를 빠르게 생성하는 데 유용하다. Selenium Grid: 다양한 머신과 브라우저에서 동시에 Selenium 테스트를 실행할 수 있게 하여 분산 테스트 실행을 가능하게 한다. https://browserstack.wpenginepowered.com/wp-content/uploads/2021/09/Selenium-WebDriver-for-Automation-Testing.webp Java Language 예시 사전 준비 사항 Java Development Kit (JDK): 시스템에 JDK가 설치되어 있는지 확인하세요. 공식 Oracle 웹사이트 또는 다른 JDK 제공업체에서 다운로드할 수 있다. Integrated Development Environment (IDE): Eclipse, IntelliJ IDEA, NetBeans와 같은 IDE입니다. 이 가이드는 Eclipse를 사용한다고 가정한다. Maven: 프로젝트의 빌드와 의존성을 관리하는 프로젝트 관리 도구입니다. Eclipse와 IntelliJ IDEA에 통합되어 있다. WebDriver: 테스트하고자 하는 브라우저용 WebDriver 실행 파일을 다운로드해야 한다(예: Google Chrome용 ChromeDriver, Firefox용 geckodriver). Selenium 테스트 프로젝트 생성 단계 Maven 프로젝트 생성: Eclipse를 열고 파일 > 새로 만들기 > Maven 프로젝트를 선택한다. 새 Maven 프로젝트를 생성하기 위한 마법사를 따릅니다. 기본 아키타입을 사용할 수 있다. Selenium 의존성 추가: pom.xml 파일을 편집하여 Selenium 의존성을 포함시킵니다. <dependencies> 섹션 내에 다음을 추가한다: LATEST_VERSION을 사용하고자 하는 최신 Selenium 버전으로 교체한다. <dependency> <groupId>org.seleniumhq.selenium</groupId> <artifactId>selenium-java</artifactId> <version>LATEST_VERSION</version> </dependency> 스트 클래스 작성: Java를 사용하여 웹 페이지를 열고, 제목을 검증하는 간단한 테스트 케이스를 작성합니다. import org.openqa.selenium.WebDriver; import org.openqa.selenium.remote.DesiredCapabilities; import org.openqa.selenium.remote.RemoteWebDriver; import org.junit.Assert; import org.junit.After; import org.junit.Before; import org.junit.Test; import java.net.URL; public class GridTitleTest { private WebDriver driver; @Before public void setUp() throws Exception { // 원하는 브라우저 구성을 설정합니다. DesiredCapabilities capabilities = DesiredCapabilities.chrome(); // 여기에서 chrome을 다른 브라우저로 변경할 수 있습니다. // Selenium Grid Hub URL을 설정합니다. 이 URL은 Selenium Grid Hub에 대한 실제 URL로 변경해야 합니다. URL hubUrl = new URL("http://localhost:4444/wd/hub"); // 원격 WebDriver 인스턴스를 생성합니다. driver = new RemoteWebDriver(hubUrl, capabilities); } @Test public void testWebTitle() { // 테스트할 웹 페이지를 엽니다. driver.get("http://www.example.com"); // 페이지 제목을 가져와서 검증합니다. String pageTitle = driver.getTitle(); Assert.assertEquals("Title of this web page", pageTitle); } @After public void tearDown() { // 테스트 후에 브라우저를 닫습니다. if (driver != null) { driver.quit(); } } } 설정(Setup): setUp 메서드에서는 원격 WebDriver 인스턴스를 생성합니다. 이때, Selenium Grid Hub의 URL과 원하는 브라우저 구성(예: Chrome)을 지정한다. 테스트 실행(Test): testWebTitle 메서드에서는 웹 페이지를 열고, 그 제목이 "Title of this web page"와 일치하는지 검증한다. 정리(Teardown): tearDown 메서드에서는 테스트가 완료된 후 브라우저를 닫는다. WebDriver 설정: 테스트 코드에서 시스템 속성을 설정하여 다운로드한 WebDriver 실행 파일의 경로를 지정한다. 테스트 실행: Eclipse에서 작성한 테스트를 실행하고, 웹 페이지가 예상대로 동작하는지 확인한다. UI 요소 찾는 방법 Selenium은 다양한 방식으로 UI 구성 요소를 접근하는 방법을 제공한다. Id Links Tag names CSS Selectors XPath JQuery Text 예시) driver.findElement(By.id(<elementID>)) driver.findElement(By.linkText(<linktext>)) Id driver.findElement(By.id(“name of id”)) UI 요소를 찾는 가장 이상적인 솔루션 ID가 존재하지 않을 수 있음 복수의 Id가 존재 할 수 있음 Links driver.findElement(By.linkText(“name of link”)) driver.findElement(By.partialLinkText(“name of link”)) 링크에 표시된 텍스트로 요소 찾기 Tag driver.findElement(By.tagName(“name of HTML tag”)) 태그 이름 HTML 태그를 기반으로 웹 요소 찾기 CSS Selectors Absolute path: driver.findElement(By.cssSelector(“html>body>div>p>input”)) Relative path: driver.findElement(By.cssSelector(“input”)) *first instance found Regula attribut: driver.findElement(By.cssSelector(“button[name=‘button name’]”)) Special attributes: id: driver.findElement(By.cssSelector(“#save")); tag & id: driver.findElement(By.cssSelector(“button#save")); class attribute: driver.findElement(By.cssSelector(“.yoyo")); tag & class attribute: river.findElement(By.cssSelector(“input.username")); tag with attribute value: driver.findElement(By.cssSelector(“img[alt=„kuku‟]")); tag which has attribute: driver.findElement(By.cssSelector(“img[alt]")); tag which doesn‟t have attribute: driver.findElement(By.cssSelector(“img:not([alt])")); XPath /html/body/div[5]/div[2]/div/div[2]/div[2]/h2[1] .//*[@id='answers']/h2[1]/a[1] XPath는 XML에서 노드를 찾는 데 사용되는 방법임 찾으려는 요소에 적합한 ID 또는 이름 속성이 없는 경우에 적합 절대 XPath 보다 상대 XPath 사용 권장 XPath-Attributes는 ID나 이름을 사용할 수 없을 때 사용 권장 Syntax: htmltag[@attribute1=‘value1’ and @attribute2=‘value2’] Example: input@id=‘Password’ and @placeholder=‘Password’] WebDriver API 목록 driver. get("http://www.google.com"); To open an application driver.findElement(By.id("passwd-id")); Finding Element using Id driver.findElement(By.name("passwd")); Finding Element using Name driver.findElement(By. Xpath("//input[@id=’passwd-id’]")); Finding Element using Xpath element.sendKeys("some text"); To type some data lement. clear(); clear the contents of a text field or text area driver.findElement(By. Xpath("//select")); Selecting the value findElement(By.id("submit")).click(); To click on Any button/Link driver.switchTo().window("window Name"); Moving from one window to another window driver.switchTo().frame("frame Name"); swing from frame to frame (or into iframes) driver.get("http://www.google.com"); To open an application driver.switchTo().frame("frameName.0.child"); to access sub frames by separating the path with a dot, and you can specify the frame by its index too driver.switchTo().alert(); Handling Alerts river.Navigate().to("http://www.example.com"); To Navigate Particular URL driver.Navigate().forward(); To Navigate Forward river.Navigate().back(); To Navigate Backward driver.close(); Closes the current window driver.Quit(); Quits the driver and closes every associated window driver.switch_to_alert(); Switches focus to an alert on the page. driver.Refresh(); Refreshes the current page driver.get_screenshot_as_file('/Screenshots/foo.png'); The full path you wish to save your screenshot to driver.get_screenshot_as_base64(); Gets the screenshot of the current window as a base64 encoded string select.findElements(By.tagName("option")); Selecting the value select.deselectAll(); This will deselect all OPTIONs from the first SELECT on the page select.selectByVisibleText("Edam"); select the OPTION with the displayed text of “Edam”

Eclipse

이 문서는Eclipse 사용에 대한 가이드를 공유하기 위해 작성되었다.

Redmine 가이드

JMeter 가이드

이 문서는 JMeter 가이드를 공유하기 위해 작성되었따.  Apache JMeter는 오픈 소스 소프트웨어로 기능 행위의 로드 테스트와 성능 측정을 위해 설계된 순수 Java 어플리케이션입니다. JMeter는 웹어플리케이션을 위해 설계되었지만 다른 테스트 기능으로 확장할 수 있습니다.  Apache JMeter는 정적 및 동적 자원, 웹 동적 어플리케이션 모두에서 성능을 테스트하는 데 사용될 수 있습니다. 서버, 서버 그룹, 네트워크 또는 개체의 과부하를 시뮬레이션하여 강도를 테스트하거나 다양한 로드 유형에서 전반적인 성능을 분석하는데 사용할 수 있습니다.  Apache JMeter 기능은 다음과 같다.  다양한 어플리케이션/서버/프로토콜 타입을 로드하고 성능 테스트할 수 있는 기능 Web - HTTP, HTTPS(Java, NodeJS, PHP, ASP.NET...) SOAP / REST Webservices FTP JDBC를 통한 데이터베이스 LDAP JMS를 통한 메시지 기반 미들웨어  메일 - SMTP(S), POP3(S), IMAP(S) 네이티브 명령 혹은 쉘 스크립트 TCP Java 오브젝트 빠른 테스트 플랜 레코딩(브라우저 혹은 네이티브 어플리케이션), 빌드, 디버깅이 지원되는 완전한 기능의 테스트 IDE 모든 Java 호환 OS(Linux, Windows, Mac OSX 등)에서 테스트를 로드하는 코멘드 라인 모드 완전하고 준비된 동적 HTML 보고서 HTML, JSON, XML 혹은 어떤 텍스트 포멧, 가장 인기있는 응답 포멧으로부터 데이터 추출 능력 풀 멀티 쓰레딩 프레임워크 많은 쓰리드로부터 병렬 샘플링 분리된 쓰레드 그룹으로 다른 기능의 동시 샘플링 캐싱과 테스트 결과의 오프라인 분석/반복수행 고도로 확장 가능한 코어 플러그인 샘플러는 무제한 테스팅 수용력을 허용 Groovy와 BeanShell과 같은 스크립트가능한 샘플러 플러그인 터이머내에 선택가능한 로드 통계 데이터 분석과 비주얼라이제이션 플러그인 동적 입력을 제공하는데 사용되는 기능 쉬운 지속적인 통합 라이브러리

CentOS 가이드

이 문서는 CentOS Linux 관련 가이드를 공유하기 위해 작성되었다.

Nginx 가이드

이 문서는 Nginx 가이드를 공유하기 위해 작성되었다. 

Open Source 설치가이드

이 문서는 개발환경과 관련된 가이드를 공유하기 위해 작성되었다.

Apache httpd

이 문서는 Apache httpd 웹 서버에 대한 가이드를 공유하기 위해 작성되었다. 

Docker 가이드

이 문서는 Docker 사용에 대한 가이드를 공유하기 위해 작성되었다. 

Gerrit 가이드

Git tips

Bare 저장소를 일반 저장소로 변환하기 1. bare 저장소에 .git 폴더 생성 mkdir .git 2. 모든 파일/폴더를 .git 폴더로 이동 mv branches/ .git/ mv config .git/ mv FETCH_HEAD .git/ mv HEAD .git/ mv hooks/ .git/ mv logs/ .git/ mv objects/ .git/ mv packed-refs .git/ mv refs/ .git/ 3. core.bare 설정 git config --local --bool core.bare false 4. master 브랜치 checkout git reset --hard mkdir .git mv branches/ .git/ mv config .git/ mv FETCH_HEAD .git/ mv HEAD .git/ mv hooks/ .git/ mv logs/ .git/ mv objects/ .git/ mv packed-refs .git/ mv refs/ .git/ git config --local --bool core.bare false git reset --hard Git username, password 저장하기 영구 저장 방법 ~/.git-credentials 파일에 plain text로 저장됨 (파일에 대해 access 권한 관리 필요) $ git config --global credential.helper store 임시 저장 방법 캐시에 임시 저장됨 $ git config credential.helper cache <timeout> Commit 개수 얻기 To get a commit count for a revision (HEAD, master, a commit hash): $ git rev-list --count <revision> 예) $ git rev-list --count branch-1 $ git rev-list --count 3930540717b How to authenticate user via git pre-receive hook https://stackoverflow.com/questions/38015205/how-to-authenticate-user-via-git-pre-receive-hook read old new ref author=$(git log -1 $ref --pretty=%an) committer=$(git log -1 $ref --pretty=%cn) echo author:$author echo committer:$committer fifty_first_commits = list(repo.iter_commits('master', max_count=50)) assert len(fifty_first_commits) == 50 # this will return commits 21-30 from the commit list as traversed backwards master ten_commits_past_twenty = list(repo.iter_commits('master', max_count=10, skip=20)) assert len(ten_commits_past_twenty) == 10 assert fifty_first_commits[20:30] == ten_commits_past_twenty

3. Git Branching

4. Git on the Server

2. Git 협업하기

Migration

1. Git 시작하기

Git 교육자료

Git 기본 환경 설정

이 페이지는 개발 환경 중 Git의 기본 환경 설정하는 방법을 가이드한다. Git 환경 설정 파일 위치 Git 환경 파일은 다음과 같이 구별된다. --system: 시스템 default (${prefix}/etc/gitconfig), 모든 사용자에게 적용 --global: 사용자 default (~/.gitconfig), 사용자에게 적용 --local: 현재 repository default(.git/config), 현재 작업중인 reporitory에 적용 사용자 정보 설정 커밋을 기록하는 사용자 정보를 설정한다. Git 환경 설정 파일에 아래와 같은 형식으로 설정한다. [user] name = username email = username@khmnc.or.kr 라인 개행 문자 처리 설정 checkout 과 add 시에 라인 개행 문자 (CR 또는 CRLF) 처리 방법을 설정한다. 설정하지 않으면 시스템에서 사용하는 개행 문자가 적용되어 개발자 환경에 따라 파일을 구성하는 라인의 개행 문자가 섞일 수 있다 (Linux: LF, Windows: CRLF). LF 로 저장소의 개행 문자를 통일하는 것을 권장한다. 저장소의 개행 문자를 LF로 유지할 때의 aotocrlf 설정: input: 입력 대로 처리 (Linux, Mac, Cygwin 환경) true: 자동으로 LF로 변환 (Windows) [core] autocrlf = true

특정 파일 이력 원복하기 (Intellij)

파일 단위 배포에서 변경목록 작업 중 Push 된 파일들을 원복 시키는 방법을 가이드 합니다. 원복 방법 방법1) 수동으로 소스 수정하여 다시 commit&push하면 변경목록에서 파일 제거 가능 방법2)File history에서 get으로 원복 후 commit&push하면 변경목록에서 파일 제거 가능 image2021-7-1_17-12-29.png image2021-7-1_17-13-10.png

Git push store in secure store가 동작하지 않을 때

현상 Git push 동작 시 계정정보를 계속 해서 물어보는 현상 (store in secure store를 체크했을때도) 원인 어떠한 원인으로 인하여 git 저장소의 key가 꼬여버림 해결방안 Windows > Preferences > General > Security > Secure Storage > Contents에서 git 저장소 선택 후 Delete image2021-7-7_17-5-20.png Eclipse 재시작 다시 commit&push하면서 계정정보 입력 및 store in secure store 체크하여 push하면 정상적으로 저장됨

Git 개행처리 설정 방법

이 문서는 Git 사용중 OS 간의 개행 처리 방법이 다른 문제를 해결하는 개행 처리 설정 방법에 대한 가이드를 공유하기 위해 작성되었다.  개요 Git config 적용 범위는 시스템 설정, 글로벌 설정, git 저장소별 설정이 가능하고 우선순위는 git 저장소 → 글로벌  → 시스템 순이다. (git 저장소가 가장 높음) 특별하게 저장소에 별도로 설정할 일이 있는 경우를 제외하고 일반적으로 사용자 레벨인 글로벌에 config를 설정한다. Config 파일 위치 : git저장소 : 저장소\.git\config 글로벌 : C:\Users\사용자계정\.gitconfig 시스템 : C:\ProgramData\Git\config autocrlf 설정 사용자 각자가 git bash에서 아래 config 설정 입력. .gitattributes의 경우 eclipse의 egit에서 해당 파일을 읽을 수 없어서 미사용. Windows 환경 윈도우에서는 CRLF 를 사용하므로 저장소에서 가져올 때 LF 를 CRLF 로 변경하고 저장소로 보낼 때는 CRLF 를 LF로 변경하도록 true로 설정한다. git config --global core.autocrlf true Linux, MAC, Unix 환경 리눅스, 맥, 유닉스는 LF 만 사용하므로 input 으로 설정한다. git config --global core.autocrlf input 파일모드 false 설정 git이 리눅스의 파일모드를 감시하기 때문에 파일 권한으로 인하여 파일이 git status에 변경된 이력으로 노출될 수 있음. 다음 설정을 통해서 filemode를 false 설정한다. git config --global core.filemode false git config 설정 적용 확인 git config --list Eclipse에서 Git config 적용 일반적으로 Eclipse의 git config는 git의 config를 바라보고 있으나 Eclipse에서도 git config 설정이 가능하다. 경로: 메뉴 > Window > Perference > Team > Git > Configuration User Settings 탭에서 Add Entry 등록 key : autocrlf / Value : true Key : filemode / Value : false crlf 변경하여 다시 적용하는 방법 git repository를 새로 Clone 받았을때 아무런 변경도 하지 않았는데 Changes에 파일들이 변경이 되었다고 나오면 개행이 달라서 변경이 된 것으로 노출되는 것이다. git에서 관리하는 파일의 개행이 깨졌을 경우 복구하는 방법은 다음과 같다.  본인의 작업 환경 crlf 설정 확인(Window의 경우 crlfauto = true) eclipse에서 clone import(git bash나 다른 클라이언트에서 clone진행시 클라이언트의 기능에 의해서 자동으로 개행처리해줘서 문제가 발생하지 않을 수 있음) workspace에서 git bash로 접속 git status 실행 시 개행으로 인하여 change로 변경된 파일들 리스트가 출력 git add . (.project파일을 제거) git commit -m "crlf change" git push commit change에서 + -가 개수 동일한지 확인 CRLF / LF 보기상 차이점 git diff를 입력하면 파일의 개행 변경 내용을 확인 할 수 있다. [CRLF -> LF로 변경된 예시] -This is line 1^M -This is line 2^M -This is line 3^M +This is line 1 +This is line 2 +This is line 3 [LF -> CRLF로 변경된 예시] -This is line 1 -This is line 2 -This is line 3 +This is line 1^M +This is line 2^M +This is line 3^M

Git diff 두 점(..)과 세점 (...) 옵션 차이

이 페이지는 Git의 diff 명령의 옵션 중 두 점 (..) 과 세 점 (...)의 차이점에 대해 정리한다. A---B---C topic / D---E---F---G master 커밋 A: a.txt 파일 수정 커밋 B: b.txt 파일 추가 커밋 C: c.txt 파일 삭제 커밋 F: f.txt 파일 변경 커밋 G: g.txt 파일 추가 위와 같이 커밋 이력이 발생한 경우, 두 점 (..) 또는 점 없는 옵션 master → topic git diff master topic --name-status 또는 git diff master..topic --name-status 은 F, G 커밋을 포함한 master 브랜치와 A, B, C 커밋을 포함한 topic 브랜치 사이의 차이점을 비교한다. 즉, 결과는 master (커밋 G)를 기준으로 topic 관점에서 차이점을 나타낸다. M       a.txt A       b.txt D       c.txt M      f.txt D       g.txt topic → master git diff topic master --name-status 또는 git diff topic..master --name-status 은 F, G 커밋을 포함한 master 브랜치와 A, B, C 커밋을 포함한 topic 브랜치 사이의 차이점을 비교한다. 즉, 결과는 topic (커밋 C)를 기준으로 master 브랜치 관점에서 차이점을 나타낸다. M       a.txt D       b.txt A       c.txt M      f.txt A       g.txt 세 점 (...) 옵션 master → topic git diff master...topic --name-status 은 master 브랜치와 topic 브랜치의 가장 최근 공통 커밋을 기준으로 topic 브랜치 관점에서 차이점을  비교한다. 즉, 결과는 커밋 E를 기준으로 topic 브랜치 (커밋 C) 관점에서 차이점을 나타낸다. M       a.txt A       b.txt D       c.txt topic → master git diff topic...master --name-status 은 topic 브랜치와 master 브랜치의 가장 최근 공통 커밋을 기준으로 master 브랜치 관점에서 차이점을  비교한다. 즉, 결과는 커밋 E를 기준으로 master 브랜치 (커밋 G) 관점에서 차이점을 나타낸다. M      f.txt A       g.txt

특정 파일 이력 원복하기 (Eclipse)

파일 단위 배포에서 변경목록 작업 중 Commit 또는 Push 된 파일들을 원복 시키는 방법을 가이드 합니다. 원복 방법 방법1) 수동으로 소스 수정하여 다시 commit&push하면 변경목록에서 파일 제거 가능 SR 브랜치가 생성된 시점과 완전히 동일해야 함 Whitespace, EOL도 일치해야함 방법2) Eclipse 가 제공하는 기능 활용하여 파일 내용 원복 원복 대상 파일 선택 Replace 메뉴선택 원복 대상 파일에 대해 마우스 우클릭 > Replace With 메뉴 선택 원목 대상 종류 선택 Replace With 메뉴 선택 > Commit... 선택 작업 중인 파일 삭제 확인 창 Replace With 기능은 지정한 이력으로 로컬 파일을 원복하므로 선택한 파일의 백업이 필요하다면 취소하여 백업 후 절차를 다시 시작한다. 진행 확인 파일이 복원되어도 좋다면 "Discard Changes" 클릭 복원할 커밋 선택 변경 목록의 파일 제거 목적이므로 SR 브랜치가 생성된 부모 커밋 (또는 SR의 최초 커밋의 이전 커밋) 선택 확인 OK 버튼을 클릭하여 파일 복원 완료 복원한 파일을 Git Add, Commit, Push 하여 삭제 중인 변경목록 내의 파일 제거 image2021-7-5_12-44-5.png

(i) 이력에서 파일 삭제하기

original site = https://rtyley.github.io/bfg-repo-cleaner/ https://rtyley.github.io/bfg-repo-cleaner/ an alternative to git-filter-branch The BFG is a simpler, faster alternative to git-filter-branch http://git-scm.com/docs/git-filter-branch for cleansing bad data out of your Git repository history: Removing Crazy Big Files Removing Passwords, Credentials & other Private data The git-filter-branch command is enormously powerful and can do things that the BFG can't - but the BFG is much better for the tasks above, because: Faster https://rtyley.github.io/bfg-repo-cleaner/#speed : 10 - 720x faster Simpler https://rtyley.github.io/bfg-repo-cleaner/#examples : The BFG isn't particularily clever, but is focused on making the above tasks easy Beautiful : If you need to, you can use the beautiful Scala language to customise the BFG. Which has got to be better than Bash scripting at least some of the time. Usage First clone a fresh copy of your repo, using the --mirror http://stackoverflow.com/q/3959924/438886 flag: $ git clone --mirror git://example.com/some-big-repo.git This is a bare http://git-scm.com/docs/gitglossary.html#def_bare_repository repo, which means your normal files won't be visible, but it is a full copy of the Git database of your repository, and at this point you should make a backup of it to ensure you don't lose anything. Now you can run the BFG to clean your repository up: $ java -jar bfg.jar https://repo1.maven.org/maven2/com/madgag/bfg/1.13.0/bfg-1.13.0.jar --strip-blobs-bigger-than 100M some-big-repo.git The BFG will update your commits and all branches and tags so they are clean, but it doesn't physically delete the unwanted stuff. Examine the repo to make sure your history has been updated, and then use the standard git gc http://git-scm.com/docs/git-gc command to strip out the unwanted dirty data, which Git will now recognise as surplus to requirements: $ cd some-big-repo.git $ git reflog expire --expire=now --all && git gc --prune=now --aggressive Finally, once you're happy with the updated state of your repo, push it back up (note that because your clone command used the --mirror flag, this push will update all refs on your remote server): $ git push At this point, you're ready for everyone to ditch their old copies of the repo and do fresh clones of the nice, new pristine data. It's best to delete all old clones, as they'll have dirty history that you don't want to risk pushing back into your newly cleaned repo. Examples In all these examples bfg is an alias for java -jar bfg.jar. Delete all files named 'id_rsa' or 'id_dsa' : $ bfg --delete-files id_{dsa,rsa} my-repo.git Remove all blobs bigger than 50 megabytes : $ bfg --strip-blobs-bigger-than 50M my-repo.git Replace all passwords listed in a file (prefix lines 'regex:' or 'glob:' if required) with ***REMOVED***wherever they occur in your repository : $ bfg --replace-text passwords.txt my-repo.git Remove all folders or files named '.git' - a reserved filename https://github.com/git/git/blob/d29e9c89d/fsck.c#L228-L229 in Git. These often become a problem http://stackoverflow.com/q/16821649/438886when migrating to Git from other source-control systems like Mercurial : $ bfg --delete-folders .git --delete-files .git --no-blob-protection my-repo.git For further command-line options, you can run the BFG without any arguments, which will output text like this https://repository.sonatype.org/service/local/artifact/maven/redirect?r=central-proxy&g=com.madgag&a=bfg&v=LATEST&e=txt. Your current files are sacred... By default the BFG doesn't modify the contents of your latest commit on your master (or 'HEAD') branch, even though it will clean all the commits before it. That's because your latest commit is likely to be the one that you deploy to production, and a simple deletion of a private credential or a big file is quite likely to result in broken code that no longer has the hard-coded data it expects - you need to fix that, the BFG can't do it for you. Once you've committed your changes- and your latest commit is clean with none of the undesired data in it - you can run the BFG to perform it's simple deletion operations over all your historical commits. Note: Cleaning Git repos is about completely eradicating bad stuff from history. If something 'bad' (like a 10MB file, when you're specifying --strip-blobs-bigger-than 5M) is in a protected commit, it won't be deleted - it'll persist in your repository, even if the BFG deletes if from earlier commits https://github.com/rtyley/bfg-repo-cleaner/issues/53#issuecomment-50088997. If you want the BFG to delete something you need to make sure your current commits are clean. Note that although the files in those protected commits won't be changed, when those commits follow on from earlier dirty commits, their commit ids will change, to reflect the changed history - only the SHA-1 id of the filesystem-tree will remain the same. If you want to turn off the protection (in general, not recommended) you can use the --no-blob-protection flag: $ bfg --strip-biggest-blobs 100 --no-blob-protection repo.git

Pull request 만들기

Git 가이드

브랜치 사용하기

Git 가이드

동기화하기

Git 가이드

git merge

머지는 분기된 이력을 병합하는 방법으로 하나의 브랜치 변경 이력을 다른 브랜치에 병합한다. 다음은 병합의 일반적인 절차를 설명한다. Step 1) 병합될 브랜치로 전환 본 예는 Feature → mastre 병합을 고려한다. git checkout master Step 2) origin 동기화 git pull origin Step 3) 머지 머지 명령를 이용해 Feature 브랜치를 master 브랜치로 병합한다. --no-ff 옵션은 머지 커밋을 생성하고 싶은 경우 지정한다.  git merge [--no-ff] Feature Screen Shot 2020-04-22 at 9.08.22 AM.png Setp 4) Feature branch 삭제 git branch -d Feature Fast-Forward Merge 아래 그림과 같이 머지 대상 (master)에 변경 이력이 없는 상태에서 Feature의 변경 이력을 병합하는 경우를 의미한다. Screen Shot 2020-04-22 at 9.23.43 AM.png 3-way Merge 머지 대상 (본 예의 경우 master)에 변경 이력이 존재하는 상태에서 Feature의 변경 이력을 병합하는 경우를 의미한다. Screen Shot 2020-04-22 at 9.22.55 AM.png Merge Conflict 3-way merge의 경우 동일한 파일에 같은 지점이 변경된 경우 병합 대상 (본 예의 경우 Feature 브랜치)와 master를 병합할 때 충돌이 발생할 수 있다. 이 때 git은 고유한 방법으로 해당 파일 위치에 출동을 표시한다. $ cat merge.txt <<<<<<< HEAD this is some content to mess with (현재 브랜치 변경 내용) content to append ======= totally different content to merge later >>>>>>> new_branch_to_merge_later 일반적인 해소 절차는 관련 페이지를 참조한다. Git 가이드

병합 전략 (Merge strategies)

Git 가이드

병합 충돌 해결하기 (Merge conflicts)

충돌 해소 절차는 다음과 같다. Step 1) 파일 확인 $ git status On branch master You have unmerged paths. (fix conflicts and run "git commit") (use "git merge --abort" to abort the merge) Unmerged paths: (use "git add <file>..." to mark resolution) both modified: merge.txt (충돌 파일) Step 2) 파일 수정 편집기를 통해 파일을 수정한다. $ cat merge.txt <<<<<<< HEAD this is some content to mess with content to append ======= totally different content to merge later >>>>>>> new_branch_to_merge_later Step 3) Add to index & commit git add <conflicted files> git commit -m <commit message> Step 4) Push to origin git push origin Git 가이드

git branch

Git 은 강력한 브랜치 기능을 제공하므로 브랜치 기능을 이해하는 것이 중요하다. 브랜치 생성 브랜치는 원격 또는 로컬 저장소에서 생성할 수 있고 저장소간 동기 가능하다. git 은 현재 브랜치의 HEAD를 기반으로 브랜치가 생성된다. git branch <branch> 브랜치 목록 보기 로컬 브랜치 목록 로컬 브랜치 목록을 표시한다. git branch 전체 브랜치 목록 로컬 및 원격  브랜치 목록을 표시한다. git branch -a 브랜치 삭제 git은 안전한 삭제와 강제 삭제 두 가지 삭제 옵션을 제공한다. 안전 옵션 머지 되지 않은 변경사항이 있는 경우 삭제 되지 않는다. git branch -d <branch> 강제 옵션 이 옵션은 머지 상태와 관계 없이 브랜치 삭제가 가능하다. git branch -D <branch> 브랜치 이름 변경 git은 브랜치 이름 변경을 지원한다. git branch -m <branch> Screen Shot 2020-04-22 at 8.13.33 AM.png Git 가이드

git checkout

git checkout은 파일, 커밋 그리고 브랜치를 전환하는 방법을 제공한다. 새로운 브랜치로 전환 신규 브랜치를 생성하여 해당 브랜치로 전환하는 방법을 제공한다. existing-branch가 주어진 경우 주어진 브랜치 기반으로 브랜치를 생성하며 생략된 경우 현재 브랜치 기반으로 생성한다. git checkout -b <new-branch> [existing-branch] 존재하는 브랜치 전환 기존에 존재하는 브랜치로 전환하는 방법을 제공한다. git checkout <branch> 파일 전환 브랜치의 특정 파일 또는 폴더 전환도 지원한다. git checkout master -- <path 또는 파일 경로> Detached HEAD Git은 HEAD을 이용해 현재 snapshot를 관리한다. 내부적으로 checkout은 HEAD이 가리키는 commit 또는 branch 을 변경한다. HEAD가 아닌 commit을 checkout하면 git은 detached HEAD 상태로 전환한다. detached HEAD 상태는 참조하는 브랜치가 없기 때문에 과거 커밋 내용을 확인하는 등의 용도에서 사용고  정상적인 기능 개발을 위해 사용하지 않도록 주의한다. Screen Shot 2020-04-22 at 8.50.30 AM.png Git 가이드

git fetch

git fetch는 원격 저장소 변경사항을 로걸 저장소에 동기화 한다. -all 옵션은 모든 원격 저장소 정보 동기화 한다. git fetch --all <remote>를 지정하면 특정 remote 의 변경 내용을 동기화 하며, branch가 지정되면 특정 브랜치 정보만 동기화 한다. git fetch <remote> [branch] --dry-run 옵션은 로컬 저장소에 반영하지 않는다. git fetch <remote> [branch] Screen Shot 2020-04-22 at 6.50.43 AM.png Git 가이드

git push

일반 기능 로컬 저장소의 커밋 내용은 push 동작을 통해 원격 저장소에 전송한다. branch가 지정되지 않으면 현재 로컬 저장소와 동일한 원격 브랜치에 정보를 업로드 (동기화) 한다. git push <remote> [branch] Screen Shot 2020-04-22 at 7.27.55 AM.png 강제 업로드 Git은 기본적으로 fast-forward 만 허용한다. --force 옵션을 사용해 non-fast-forward 로 push 할 수 있다.  이력에 대해 정확한 이해가 있을 때만 --force 옵션을 사용한다. git push <remote> --force 모든 로컬 브랜치 업로드 git push <remote> --all 태그 정보 업로드 git push 기본 동작은 태그 정보를 업로드 하지 않는다. git push <remote> --tags fast-forward vs. non-fast-forward git push는 원격 저장소의 보호를 위래 기본적 동작은 fast-forward 모드를 권장한다. fast-forward: 로컬 저장소가 원격 저장소와 동기가 이루어진 상태에서 업로드하는 모드 non-fast-forward: 로컬 저장소가 원격 저장소에 뒤쳐진 상태에서 업로드하는 모드 fast-forward.png Git 가이드

git pull

git pull은 원격 저장소 정보를 로컬 working folder에 반영한다. 상태1) 로컬 저장소의 master 브랜치가 원격 저장소에 뒤쳐진 상태 Screen Shot 2020-04-22 at 7.16.31 AM.png pull 후) git pull origin master 원격 저장소의 A-B-C 커밋이 단일 머지 커밋 (H)로 저장된다. Screen Shot 2020-04-22 at 7.19.22 AM.png rebase 옵션을 이용한 pull) rebase 옵션이 주어진 경우 원격 저장소의 A-B-C 커밋이 로컬 저장소의 브랜치에 rebase 된다. git pull --rebase origin Screen Shot 2020-04-22 at 7.22.40 AM.png Git 가이드

git remote

origin remote는 로컬 저장소의 원본 저장소를 지칭하며 origin은 clone 절차에서 자동으로 설정된다. 리모트 저장소 목록 보기 $ git remote [-v] origin upstream other_users_repo 원격 저장소 추가 아래 명령으로 원격 저장소를 추가한다. $ git remote add fake_test https://bitbucket.com/upstream_user/reponame.git; [remote "remote_test"] url = https://bitbucket.com/upstream_user/reponame.git fetch = +refs/heads/*:refs/remotes/remote_test/* 원격 저장소 점검 git remote show upstream * remote upstream Fetch URL: https://bitbucket.com/upstream_user/reponame.git Push URL: https://bitbucket.com/upstream_user/reponame.git HEAD branch: master Remote branches: master tracked simd-deprecated tracked tutorial tracked Local ref configured for 'git push': master pushes to master (fast-forwardable) 원격 저장소와 로컬 저장소 동기 방법 Git은 원격 저장소와 로컬 저장소 동기 방법을 제공한다. 세부 사용법은 해당 설명 페이지를 참고한다. git fetch git pull git push Screen Shot 2020-04-22 at 6.50.43 AM.png Git 가이드

Migrating a CVS repository to GIT

Importing from a CVS repository can be done using git-cvsimport either by direct access to the remote CVS server or from a snapshot tarball. The procedure includes the following steps: Import a CVS repository to a git repository (ususally on a local machine) Create a bare clone of the latter to be used as a shared read/write repository (again locally) Set a new repository on the server through gitosis (see above "Starting a new project repository) Push the cloned one in 2. to the newly created one in 3. All steps above should be done on a local machine. 1.CVS repository import cvsimport 설치 필요 user@local# sudo yum install git-cvsimport Direct import from a server user@local# cvs -z3 -d :pserver:anoncvs@cvs.curvc.com:/home/gmx/cvs login user@local# git cvsimport -A ./authors.txt -v -a -i -k -d :pserver:anoncvs@cvs.curvc.com:/home/gmx/cvs -C gromacs-cvs.git cmx This way is very slow, and it is much faster to use a tarball of a CVS snapshot. authors.txt: CVS 사용자를 Git 사용자로 맵핑 형식 예) username1_in_cvs = Git User1 <gituser1@curvc.com> username2_in_cvs = Git User2 <gituser2@curvc.com http://curvc.com> (Alternative) Import from a CVS snapshot tarball rossen@cvs.curvc.com# cd /home/gmx rossen@cvs.curvc.com# tar cvfz /home/rossen/gromacs-cvs-20090218.tar.gz cvs rossen@local# pwd /home/rossen/temp rossen@local# scp cvs.curvc.com:gromacs-cvs-20090218.tar.gz . rossen@local# tar xvfz gromacs-cvs-20090218.tar.gz rossen@local# git-cvsimport -a -i -k -d /home/rossen/temp/cvs -C gromacs-cvs.git gmx 2. Create a bare clone of the imported GIT rossen@local# mkdir gromacs rossen@local# cd gromacs rossen@local# git --bare init --shared rossen@local# git --bare fetch ../gromacs-cvs.git master:master rossen@local# git remote add gromacs git@git.curvc.com:gromacs.git 3. Set a new repository on the server Git 서버에서 gromacs repository 생성 4. Push the clone to the server rossen@local# git push gromacs --mirror Links git-cvsmigration http://www.kernel.org/pub/software/scm/git/docs/gitcvs-migration.html git-cvsserver http://www.kernel.org/pub/software/scm/git/docs/git-cvsserver.html git-cvsimport http://www.kernel.org/pub/software/scm/git/docs/git-cvsimport.html

저장소 점검하기

Git 가이드

변경 저장하기

'체크인'은 중앙 서버로 원격 푸시하는 작업입니다. 이것은 SVN 커밋이 프로젝트 변경 사항을 완전히 '저장'하기 위해 인터넷 액세스가 필요하다는 것을 의미합니다. Git 커밋은 로컬에서 캡처 및 빌드 한 다음 필요에 따라 git push -u origin master 명령을 사용하여 원격 서버에 푸시 할 수 있습니다. 두 가지 방법의 차이점은 아키텍처 설계 간의 근본적인 차이입니다. Git은 분산 애플리케이션 모델이지만 SVN은 중앙 집중식 모델입니다. 분산 응용 프로그램은 중앙 집중식 서버와 같이 단일 지점에서 장애가 발생하지 않으므로 일반적으로 더 강력합니다. git add, git status, git commit 명령은 모두 Git 프로젝트의 현재 상태의 스냅 샷을 저장하는 데 사용됩니다. Git은 'stash'라는 추가 저장 메커니즘을 가지고있다. stash는 커밋 할 준비가되지 않은 변경 사항을 임시로 저장하는 영역입니다. stash는 세 개의 트리 중 첫 번째 트리 인 작업 디렉토리에서 작동하며 광범위한 사용 옵션이 있습니다. 자세한 내용은 git stash 페이지를 참조하십시오. Git 저장소는 특정 파일이나 디렉토리를 무시하도록 설정할 수 있습니다. 이것은 자식이 무시한 내용의 변경 사항을 저장하지 못하도록합니다. 힘내는 무시 목록을 관리하는 여러 가지 설정 방법을 가지고있다. Git ignore configure에 대해서는 git ignore 페이지에서 자세히 설명합니다. Git 가이드

변경 취소하기

Git 가이드

Git 저장소

Git은 새로운 저장소 생성과 기존 저장소 복제를 제공합니다. image2020-4-22_5-47-3.png 저장소 란? Git 저장소는 프로젝트의 가상 저장소입니다. 필요한 경우 액세스 할 수있는 코드 버전을 저장할 수 있습니다. 새로운 저장소 생성하기: git init 새 저장소를 만들려면 git init 명령을 사용합니다. git init은 새로운 repo의 초기 설정 중에 사용하는 일회성 명령입니다. 이 명령을 실행하면 현재 작업 디렉토리에 새 .git 하위 디렉토리가 만들어집니다. 그러면 새로운 마스터 브랜치가 작성됩니다. Versioning an existing project with a new git repository 이 예에서는 기존에 프로젝트 폴더를 만들었으며 프로젝트 내에 repo를 만들려한다고 가정합니다. 먼저 루트 프로젝트 폴더로 이동 한 다음 git init 명령을 실행합니다. cd /path/to/your/existing/code git init git init을 기존 프로젝트 디렉토리로 지정하면 위에서 언급 한 것과 동일한 초기화 설정이 실행되지만 해당 프로젝트 디렉토리로 범위가 지정됩니다. git init <project directory> 기존 저장소 복제하기: git clone 프로젝트가 중앙 저장소에 이미 설정된 경우 clone 명령은 사용자가 로컬 개발 복제본을 얻는 가장 일반적인 방법입니다. git init과 마찬가지로, 복제는 일반적으로 일회성 작업입니다. 개발자가 작업 복사본을 얻으면 모든 버전 제어 작업은 로컬 저장소를 통해 관리됩니다. git clone <repo url> git clone은 원격 리포지토리의 복사본이나 복제본을 만드는 데 사용됩니다. git clone에 저장소 URL을 전달합니다. Git은 몇 가지 다른 네트워크 프로토콜과 해당 URL 형식을 지원합니다.  HTTP 프로토콜를 지원하는 Bitbucket 저장소 URL 형식 예: https://user@bitbucket.almdemo.curvc.com/scm/gt/spring3example.git https://user@bitbucket.almdemo.curvc.com/scm/gt/spring3example.git user: Bitbucket username bitbucket.almdemo.curvc.com/scm http://bitbucket.almdemo.curvc.com/scm: Bitbucket URL gt: Bitbucket project key spring3example: 저장소 이름 실행되면 마스터 브랜치의 원격 repo 파일의 최신 버전이 풀다운되어 새 폴더에 추가됩니다. 새 폴더의 이름은이 경우 javascript-data-store의 REPONAME 다음에 지정됩니다. 이 폴더는 원격 저장소와 새로 생성 된 master 브랜치의 전체 히스토리를 포함합니다. 저장소에 변경사항 저장하기: git add and git commit 저장소가 설정되면 이제 저장소를 복제하거나 초기화 했으므로 파일 버전 변경을 커밋 할 수 있습니다. 다음 예제에서는 / path / to / project에 프로젝트를 설정했다고 가정합니다. 이 예제에서 수행되는 단계는 다음과 같습니다. 디렉토리를 / path / to / project로 변경합니다. 내용이 담긴 CommitTest.txt 파일을 만듭니다 ~ "git tutorial for test content"~ git은 CommitTest.txt를 저장소 스테이징 영역에 추가합니다. 커밋에서 수행 된 작업을 설명하는 메시지로 "CommitTest.txt 파일 추가" 지정 cd /path/to/project echo "test content for git tutorial" >> CommitTest.txt git add CommitTest.txt git commit -m "CommitTest.txt 파일 추가" 이 예를 실행하면 Repo에 기록에 CommitTest.txt가 추가되고 파일의 향후 업데이트를 추적합니다. 이 예제는 두 개의 추가적인 git 명령 인 add와 commit를 소개했다. 이것은 매우 제한된 예 였지만, 두 명령 모두 git add 및 git commit 페이지에서 자세히 다루어집니다. git add의 또 다른 일반적인 사용 예는 --all 옵션입니다. git add --all을 실행하면 repo에서 변경되거나 추적되지 않은 파일을 가져 와서 repo에 추가하고 repo의 작업 트리를 업데이트합니다. 저장소 간 협업: git push Git의 "작업 카피"에 대한 아이디어가 SVN 저장소에서 소스 코드를 체크 아웃하여 얻은 작업 카피와 매우 다르다는 것을 이해하는 것이 중요합니다. SVN과 달리 Git은 작업 사본과 중앙 저장소를 구분하지 않습니다. 그들은 모두 본격적인 Git 저장소입니다. 이것은 Git과 SVN과 근본적으로 다른 협력을 만든다. SVN이 중앙 저장소와 작업 사본 사이의 관계에 의존하는 반면, Git의 공동 작업 모델은 저장소와 저장소 간의 상호 작용을 기반으로합니다. 작업 복사본을 SVN의 중앙 저장소로 검사하는 대신 한 저장소에서 다른 저장소로 커밋을 푸시하거나 끌어 당깁니다. 물론, Git repos라는 특별한 의미를주는 것을 막을 수있는 방법은 없습니다. 예를 들어 Git repo를 "중앙"저장소로 지정하면 Git을 사용하여 중앙 집중식 워크 플로를 복제 할 수 있습니다. 이는 VCS 자체에 내장되어 있지 않고 규칙을 통해 수행됩니다. Bare vs. cloned repositories 이전의 "새 저장소 초기화"절에서 git clone을 사용하여 로컬 저장소를 설정 한 경우 저장소는 원격 협업을 위해 이미 구성되어 있습니다. git clone은 복제 한 Git URL을 가리키는 리모컨으로 자동으로 저장소를 구성합니다. 즉, 파일을 변경하고 커밋하면 원격 저장소에 변경 사항을 적용 할 수 있습니다. git init을 사용하여 새로운 repo를 작성했다면 변경 사항을 푸시 할 원격 저장소가 없습니다. 새로운 repo를 초기화 할 때 일반적인 패턴은 Bitbucket과 같은 호스팅 된 Git 서비스로 가서 repo를 생성하는 것입니다. 이 서비스는 Git URL을 제공하여 로컬 Git 저장소에 추가하고 호스트 된 저장소로 Push 할 수 있습니다. 선택한 서비스로 원격 저장소를 만든 후에는 매핑을 사용하여 로컬 저장소를 업데이트해야합니다. 이 프로세스는 아래의 구성 및 설정 안내서에서 설명합니다. 자신의 원격 저장소를 호스팅하려면 "기본 저장소"를 설정해야합니다. git init과 git clone 모두 --bare 인수를 허용합니다. 베어 레포의 가장 일반적인 사용 사례는 원격 중앙 저장소를 만드는 것입니다. 설정: git config 원격 저장소 설정이 끝나면 로컬 저장소에 원격 저장소 URL을 추가하고 로컬 분기에 대한 업스트림 브랜치를 설정해야합니다. git remote 명령은 그러한 유틸리티를 제공합니다. git remote add <remote_name> <remote_repo_url> 이 명령은 <remote_repo_url>의 원격 저장소를 <remote_name>의 로컬 저장소에있는 참조로 매핑합니다. 원격 저장소를 매핑하면 로컬 저장소를 해당 저장소로 푸시 할 수 있습니다. git push -u <remote_name> <local_branch_name> 이 명령은 <local_branc_name> 아래의 로컬 repo 분기를 <remote_name>의 원격 저장소로 푸시합니다. git remote에 대한 자세한 내용은 Git 원격 페이지를 참조하십시오. 원격 repo URL을 설정하는 것 외에도 username 또는 email과 같은 글로벌 Git 구성 옵션을 설정해야 할 수도 있습니다. git config 명령을 사용하여 명령 행에서 Git 설치 (또는 개별 저장소)를 구성 할 수 있습니다. 이 명령은 사용자 정보에서 환경 설정, 저장소 작동에 이르기까지 모든 것을 정의 할 수 있습니다. 몇 가지 일반적인 구성 옵션은 다음과 같습니다. Git은 개별 저장소 (로컬), 사용자 (전역) 또는 전체 시스템 (시스템)에 범위 옵션을 제공하는 구성 옵션을 3 개의 개별 파일에 저장합니다. 로컬 : <repo> /. git / config - 저장소 별 설정. 전역 : /.gitconfig - 사용자 별 설정. 여기에는 --global 플래그로 설정된 옵션이 저장됩니다. 시스템 : $ (접두사) / etc / gitconfig - 시스템 전체 설정. 현재 저장소의 모든 커밋에 사용할 작성자 이름을 정의하십시오. 일반적으로 --global 플래그를 사용하여 현재 사용자에 대한 구성 옵션을 설정하려고합니다. git config --global user.name <name> 현재 사용자가 모든 커밋에 사용할 작성자 이름을 정의하십시오. --local 옵션을 추가하거나 설정 수준 옵션을 전달하지 않으면 현재 로컬 저장소에 대한 user.name http://user.name이 설정됩니다. git config --local user.email <email> 현재 사용자가 모든 커밋에 사용할 작성자 전자 메일을 정의합니다. git config --global alias.<alias-name> <git-command> Git 명령에 대한 바로 가기를 만듭니다. 이것은 일반적으로 사용되는 git 명령에 대한 사용자 정의 바로 가기를 작성하는 강력한 유틸리티입니다. 단순한 예는 다음과 같습니다. git config --global alias.ci commit 이렇게하면 git commit 바로 가기로 실행할 수있는 ci 명령이 만들어집니다. git 별칭에 대한 자세한 내용은 git config 페이지를 참조하십시오. git config --system core.editor <editor> 현재 컴퓨터의 모든 사용자에 대해 git commit과 같은 명령이 사용하는 텍스트 편집기를 정의하십시오. <editor> 인수는 원하는 편집기 (예 : vi)를 시작하는 명령이어야합니다. 이 예제는 --system 옵션을 소개합니다. --system 옵션은 전체 시스템의 구성을 설정합니다. 즉, 모든 사용자와 시스템의 repos를 의미합니다. 구성 수준에 대한 자세한 내용은 git config 페이지를 참조하십시오. git config --global --edit 수동 편집을 위해 텍스트 편집기에서 글로벌 구성 파일을 엽니 다. git이 사용할 텍스트 편집기를 구성하는 방법에 대한 자세한 안내는 Git config 페이지에서 찾을 수 있습니다. Git은 구성 옵션을 세 개의 개별 파일에 저장하므로 개별 저장소, 사용자 또는 전체 시스템에 대한 옵션을 범위 지정할 수 있습니다. <repo> /. git / config - 저장소 별 설정. ~ / .gitconfig - 사용자 별 설정. 여기에는 --global 플래그로 설정된 옵션이 저장됩니다. $ (접두사) / etc / gitconfig - 시스템 전체 설정 이 파일의 옵션이 충돌하면 로컬 설정이 시스템 설정보다 우선하는 사용자 설정보다 우선합니다. 이러한 파일 중 하나를 열면 다음과 같은 내용이 표시됩니다. [user] name = John Smith email = john@example.com [alias] st = status co = checkout br = branch up = rebase ci = commit [core] editor = vim 이 값을 수동으로 git config와 동일한 효과로 편집 할 수 있습니다. Git 가이드

Rewriting history

Git 가이드

git blame

tag.png git blame 명령은 광범위한 사용법 옵션이있는 다목적 문제 해결 유틸리티입니다. git blame의 높은 수준의 기능은 파일의 특정 커밋 된 행에 첨부 된 작성자 메타 데이터의 표시입니다. 이는 파일 히스토리의 특정 지점을 검사하고 최종 작성자가 행을 수정 한 사람에 대한 컨텍스트를 얻는 데 사용됩니다. 이 코드는 특정 코드의 내역을 탐색하고 코드가 저장소에 추가 된 대상, 방법 및 이유를 알아내는 데 사용됩니다. Git blame은 종종 GUI 디스플레이와 함께 사용됩니다. Bitbucket과 같은 온라인 Git 호스팅 사이트는 저장소에 대한 blame 뷰를 제공합니다. 이러한 뷰는 pull rquest 및 커밋에 대한 협업에서 참조됩니다. 또한, Git 통합이있는 대부분의 IDE에는 동적 인 blame 기능을 제공합니다. 작동 원리 git blame을 증명하기 위해서 우리는 약간의 역사가있는 저장소가 필요하다. 우리는 오픈 소스 프로젝트 인 git-blame-example을 사용할 것입니다. 이 오픈 소스 프로젝트는 다른 저자의 커밋이있는 README.md http://README.md 파일이 들어있는 간단한 저장소입니다. git blame 사용 예제의 첫 번째 단계는 예제 저장소를 복제하는 것입니다. git clone https://kevzettler@bitbucket.org/kevzettler/git-blame-example.git && cd git-blame-example 이제 예제 코드의 복사본을 얻었으므로 git blame으로 살펴보기 시작할 수있다. 예제 repo의 상태는 git log를 사용하여 검사 할 수 있습니다. 커밋 내역은 다음과 같아야합니다. $ git log commit 548dabed82e4e5f3734c219d5a742b1c259926b2 Author: Juni Mukherjee <jmukherjee@atlassian.com> Date: Thu Mar 1 19:55:15 2018 +0000 Another commit to help git blame track the who, the what, and the when commit eb06faedb1fdd159d62e4438fc8dbe9c9fe0728b Author: Juni Mukherjee <jmukherjee@atlassian.com> Date: Thu Mar 1 19:53:23 2018 +0000 Creating the third commit, along with Kev and Albert, so that Kev can get git blame docs. commit 990c2b6a84464fee153253dbf02e845a4db372bb Merge: 82496ea 89feb84 Author: Albert So <aso@atlassian.com> Date: Thu Mar 1 05:33:01 2018 +0000 Merged in albert-so/git-blame-example/albert-so/readmemd-edited-online-with-bitbucket-1519865641474 (pull request #2) README.md edited online with Bitbucket commit 89feb84d885fe33d1182f2112885c2a64a4206ec Author: Albert So <aso@atlassian.com> Date: Thu Mar 1 00:54:03 2018 +0000 README.md edited online with Bitbucket git blame은 개별 파일에서만 작동합니다. 유용한 출력을 위해서는 파일 경로가 필요합니다. git blame의 기본 실행은 명령 도움말 메뉴를 출력합니다. 이 예에서는 README.MD 파일을 사용합니다. 프로젝트의 문서 소스로 git 저장소의 루트에 README 파일을 포함시키는 것은 일반적인 오픈 소스 소프트웨어 관행입니다. git blame README.MD 위의 명령을 실행하면 첫 번째 비난 출력 샘플을 얻을 수 있습니다. 다음 출력은 README의 전체 책임 출력의 하위 집합입니다. 또한이 출력은이 글을 쓰는 시점의 repo 상태를 반영합니다. $ git blame README.md 82496ea3 (kevzettler 2018-02-28 13:37:02 -0800 1) # Git Blame example 82496ea3 (kevzettler 2018-02-28 13:37:02 -0800 2) 89feb84d (Albert So 2018-03-01 00:54:03 +0000 3) This repository is an example of a project with multiple contributors making commits. 82496ea3 (kevzettler 2018-02-28 13:37:02 -0800 4) 82496ea3 (kevzettler 2018-02-28 13:37:02 -0800 5) The repo use used elsewhere to demonstrate `git blame` 82496ea3 (kevzettler 2018-02-28 13:37:02 -0800 6) 89feb84d (Albert So 2018-03-01 00:54:03 +0000 7) Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod TEMPOR incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum 89feb84d (Albert So 2018-03-01 00:54:03 +0000 8) eb06faed (Juni Mukherjee 2018-03-01 19:53:23 +0000 9) Annotates each line in the given file with information from the revision which last modified the line. Optionally, start annotating from the given revision. eb06faed (Juni Mukherjee 2018-03-01 19:53:23 +0000 10) 548dabed (Juni Mukherjee 2018-03-01 19:55:15 +0000 11) Creating a line to support documentation needs for git blame. 548dabed (Juni Mukherjee 2018-03-01 19:55:15 +0000 12) 548dabed (Juni Mukherjee 2018-03-01 19:55:15 +0000 13) Also, it is important to have a few of these commits to clearly reflect the who, the what and the when. This will help Kev get good screenshots when he runs the git blame on this README. 이것은 README.md http://README.md 파일의 처음 13 행의 샘플입니다. 이 출력을 더 잘 이해하기 위해 라인을 구분할 수 있습니다. 다음 표는 3 행의 내용을 표시하며 표의 열은 열의 내용을 나타냅니다. Id Author Timestamp Line Number Line Content 89feb84d Albert So 2018-03-01 00:54:03 +0000 3 This repository is an example of a project with multiple contributors making commits. blame 출력 목록을 검토하면 몇 가지 관찰을 할 수 있습니다. 저자가 세 명 있습니다. 프로젝트의 유지 보수 담당자 인 Kev Zettler 외에도 Albert So, Juni Mukherjee도 나와 있습니다. 저자는 일반적으로 git blame 산출물의 가장 중요한 부분입니다. 타임 스탬프 열은 주로 유용합니다. 변경 내용은 줄 내용 열에 의해 표시됩니다. 일반적인 옵션 git blame -L 1,5 README.md -L 옵션은 출력을 요청 된 행 범위로 제한합니다. 여기에서는 출력을 1-5 행으로 제한했습니다. git blame -e README.md -e 옵션은 사용자 이름 대신 작성자 전자 메일 주소를 표시합니다. git blame -w README.md -w 옵션은 공백 변경을 무시합니다. 이전 작성자가 탭에서 공백으로 바꾸거나 새 줄을 추가하여 파일의 간격을 수정 한 경우 불행히도 이러한 변경 사항을 표시하여 git blame의 결과를가립니다. git blame -M README.md -M 옵션은 동일한 파일 내의 이동 또는 복사 된 행을 감지합니다. 이렇게하면 선을 이동하거나 복사 한 마지막 작성자 대신 선의 원래 작성자가보고됩니다. git blame -C README.md -C 옵션은 다른 파일에서 이동되거나 복사 된 행을 감지합니다. 이렇게하면 선을 이동하거나 복사 한 마지막 작성자 대신 선의 원래 작성자가보고됩니다. Git Blame vs Git Log 634/5000 git blame은 라인을 수정 한 마지막 저자를 표시하지만 종종 원래 라인이 추가 된 시점을 알고 싶을 때가 있습니다. 이것은 git blame을 사용하여 성취하기가 번거로울 수 있습니다. -w, -C 및 -M 옵션을 조합해야합니다. git log 명령을 사용하는 것이 훨씬 더 편리 할 수 있습니다. 특정 코드 조각이 추가되거나 수정 된 모든 원래 커밋을 나열하려면 -S 옵션을 사용하여 git log를 실행하십시오. 찾고있는 코드에 -S 옵션을 추가하십시오. 위의 README 출력에있는 행 중 하나를 예로 들어 보겠습니다. README 출력의 12 행에서 "CSS3D 및 WebGL 렌더러"텍스트를 가져와 봅시다. $ git log -S"CSS3D and WebGL renderers." --pretty=format:'%h %an %ad %s' e339d3c85 Mario Schuettel Tue Oct 13 16:51:06 2015 +0200 reverted README.md to original content 509c2cc35 Daniel Tue Sep 8 13:56:14 2015 +0200 Updated README cb20237cc Mr.doob Mon Dec 31 00:22:36 2012 +0100 Removed DOMRenderer. Now with the CSS3DRenderer it has become irrelevant. 이 결과는 README의 내용이 3 명의 다른 저자에 의해 3 번 추가되거나 수정되었음을 보여줍니다. 그것은 원래 Mr.doob이 커밋 cb20237cc에 추가했습니다. 이 예제에서 git log 앞에 --pretty-format 옵션이 추가되었습니다. 이 옵션은 git log의 기본 출력 형식을 git log의 형식과 일치하는 것으로 변환합니다. 사용법과 설정 옵션에 대한 더 자세한 정보는 git log 페이지를 방문하십시오. Git 가이드

git log

git log 명령은 커밋 된 스냅 샷을 표시합니다. 프로젝트 기록을 나열하고, 필터링하고, 특정 변경 사항을 검색 할 수 있습니다. git status를 사용하면 작업 디렉토리와 스테이징 영역을 검사 할 수 있지만 git log는 커밋 된 히스토리에서만 작동합니다. 18.png 로그 출력은 커밋을 필터링하는 것에서부터 완전히 사용자 정의 된 형식으로 표시하는 것까지 여러 가지 방법으로 사용자 정의 할 수 있습니다. git log의 가장 일반적인 설정 중 일부는 다음과 같습니다. 사용법 git log 기본 포맷을 사용하여 전체 커밋 기록을 표시하십시오. 출력이 둘 이상의 화면을 차지하는 경우, 스페이스를 사용하여 스크롤하고 q를 사용하여 종료 할 수 있습니다. git log -n <limit> 커밋 수를 <limit>만큼 제한하십시오. 예를 들어, git log -n 3은 3 개의 커밋 만 표시합니다. git log --oneline 각 커밋을 한 줄로 압축하십시오. 이것은 프로젝트 히스토리에 대한 높은 수준의 개요를 얻는 데 유용합니다. git log --stat 일반 자식 로그 정보와 함께 변경된 파일과 각 파일에 추가 또는 삭제 된 행의 상대 번호가 포함됩니다. git log -p 각 커밋을 나타내는 패치를 표시합니다. 이것은 각 커밋의 전체 diff를 보여줍니다. 이것은 프로젝트 히스토리에 대해 가장 자세히 볼 수 있습니다. git log --author="<pattern>" 특정 작성자가 커밋을 검색합니다. <pattern> 인수는 일반 문자열이나 정규 표현식이 될 수 있습니다. git log --grep="<pattern>" <pattern>과 일치하는 커밋 메시지로 커밋을 검색합니다.이 커밋 메시지는 일반 문자열이나 정규 표현식이 될 수 있습니다. git log <since>..<until> <since>와 <until> 사이에 발생하는 커밋 만 표시합니다. 두 인수 모두 커밋 ID, 분기 이름, HEAD 또는 다른 종류의 수정 참조 일 수 있습니다. git log <file> 지정된 파일을 포함하는 커밋 만 표시하십시오. 이것은 특정 파일의 기록을 쉽게 볼 수있는 방법입니다. git log --graph --decorate --oneline 몇 가지 유용한 옵션을 고려해야합니다. 커밋 메시지의 왼쪽에 커밋의 텍스트 기반 그래프를 그리는 --graph 플래그. --decorate는 표시된 커밋의 브랜치 또는 태그 이름을 추가합니다. --online은 커밋 정보를 한 줄에 표시하여 커밋을 한 눈에 쉽게 탐색 할 수있게합니다. Git 가이드

git tag

tag.png 이 문서는 Git의 태그 지정과 git tag 명령에 대해 설명합니다. 태그는 Git 히스토리의 특정 지점을 가리키는 참조입니다. 태그 지정은 일반적으로 마크 업 된 버전 릴리스 (예 : v1.0.1)에 사용되는 기록의 한 지점을 캡처하는 데 사용됩니다. 태그는 변경되지 않는 분기와 같습니다. 브랜치와는 달리 태그는 생성 된 후에 더 이상 커밋 된 이력이 없습니다. 브랜치에 대한 자세한 정보는 git 브랜치 페이지를 참조하십시오. 이 문서에서는 다양한 종류의 태그, 태그 생성 방법, 모든 태그 나열 방법, 태그 삭제 방법, 태그 공유 방법 등에 대해 다룹니다. 태그 만들기 다음 명령어를 이용해 태그를 만들 수 있습니다. git tag <tagname> <tagname>을 태그가 생성 될 때의 레포 상태에 대한 의미 적 식별자로 바꿉니다. 일반적인 패턴은 git tag v1.4와 같은 버전 번호를 사용하는 것입니다. Git은 두 가지 유형의 태그, 주석이 달린 태그 및 간단한 태그를 지원합니다. 이전 예제에서는 간단한 태그를 만들었습니다. 경량 태그와 주석 태그는 저장된 메타 데이터 양이 다릅니다. 주석이 달린 태그는 공개로, 경량 태그는 비공개로 간주하는 것이 가장 좋습니다. 주석 태그는 태그 이름, 전자 메일 및 날짜와 같은 추가 메타 데이터를 저장합니다. 이것은 공개 자료의 중요한 데이터입니다. 경량 태그는 본질적으로 커밋에 '북마크'이며, 커밋에 대한 포인터와 포인터이며, 관련 커밋에 대한 빠른 링크를 만드는 데 유용합니다. Annotated Tags 주석이 달린 태그는 Git 데이터베이스에 완전한 객체로 저장됩니다. 다시 말하면, 그들은 tagger 이름, 이메일 및 날짜와 같은 추가 메타 데이터를 저장합니다. 커밋 및 커밋 메시지와 유사 주석이 달린 태그에는 태그 지정 메시지가 있습니다. 또한 보안을 위해 주석이 달린 태그는 GNU Privacy Guard (GPG)를 사용하여 서명하고 확인할 수 있습니다. git 태그 지정에 권장되는 권장 사항은 모든 관련 메타 데이터를 가질 수 있도록 가벼운 태그보다 주석 태그를 선호하는 것입니다. git tag -a v1.4 -m "my version 1.4" 이 명령을 실행하면 이전 호출과 유사하지만이 명령 버전에는 -m 옵션과 메시지가 전달됩니다. 이는 git commit -m과 비슷한 편리한 메소드로, 즉시 새 태그를 작성하고 로컬 텍스트 편집기를 열어 -m 옵션과 함께 전달 된 메시지를 저장하지 않아도됩니다. Lightweight Tags git tag v1.4-lw 이 명령을 실행하면 v1.4-lw로 식별되는 경량의 태그가 작성됩니다. 경량 태그는 -a, -s 또는 -m 옵션이 없으면 작성됩니다. 경량 태그는 새 태그 체크섬을 만들어 프로젝트의 repo .git / 디렉토리에 저장합니다. 태그 목록 보기 다음 명령을 통해 저장소에 저장된 태그 목록을 볼 수 있습니다. git tag 명령의 결과는 다음과 같습니다. v0.10.0 v0.10.0-rc1 v0.11.0 v0.11.0-rc1 v0.11.1 v0.11.2 v0.12.0 v0.12.0-rc1 v0.12.1 v0.12.2 v0.13.0 v0.13.0-rc1 v0.13.0-rc2 태그 목록을 구체화하기 위해 와일드 카드 표현식과 함께 -l 옵션을 전달할 수 있습니다. $ git tag -l *-rc* v0.10.0-rc1 v0.11.0-rc1 v0.12.0-rc1 v0.13.0-rc1 v0.13.0-rc2 v0.14.0-rc1 v0.9.0-rc1 v15.0.0-rc.1 v15.0.0-rc.2 v15.4.0-rc.3 이 이전 예제는 -l 옵션과 -rc 접두어로 표시된 모든 태그 목록을 반환하는 -rc의 와일드 카드 표현식을 사용합니다.이 태그는 전통적으로 릴리스 후보를 식별하는 데 사용됩니다. 과거  커밋에 태그 생성하기 이전 태깅 예제는 암시 적 커밋에 대한 작업을 보여주었습니다. 기본적으로 git 태그는 HEAD가 참조하는 커밋에 태그를 생성합니다. 또는 git 태그를 특정 커밋에 대한 참조로 전달할 수 있습니다. HEAD를 기본값으로하는 대신 커밋 된 커밋에 태그를 붙입니다. 이전 커밋 목록을 수집하려면 git log 명령을 실행하십시오. $ git log --pretty=oneline 15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'feature' a6b4c97498bd301d84096da251c98a07c7723e65 add update method for thing 0d52aaab4479697da7686c15f77a3d64d9165190 one more thing 6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiment' git log를 실행하면 커밋 목록이 출력됩니다. 이 예제에서 우리는 가장 새로운 커밋 Merge branch 'feature'를 선택합니다. Git에 전달하기 위해 SHA 해시 커밋을 참조해야합니다. git tag -a v1.2 15027957951b64cf874c3557a0f3547bd83b3ff6 위의 git 태그 호출을 실행하면 이전의 git 로그 예제에서 선택한 커밋에 대해 v1.2로 식별 된 새로운 주석 된 커밋이 만들어집니다. 태그 다시 하기 / 생성된 태그 교체하기 기존 태그와 동일한 식별자를 가진 태그를 만들려고 시도하면 Git은 다음과 같은 오류를 발생시킵니다. fatal: tag 'v0.4' already exists 또한 이전 커밋에 기존 태그 식별자를 사용하여 태그를 지정하려고하면 Git에서 동일한 오류가 발생합니다. 기존 태그를 갱신해야하는 경우 -f FORCE 옵션을 사용해야합니다. git tag -a -f v1.4 15027957951b64cf874c3557a0f3547bd83b3ff6 위의 명령을 실행하면 15027957951b64cf874c3557a0f3547bd83b3ff6 커밋을 v1.4 태그 식별자에 매핑합니다. v1.4 태그의 기존 내용을 덮어 씁니다. 태그 공유하기: Pushing Tags to Remote 태그를 공유하는 것은 분기를 푸시하는 것과 유사합니다. 기본적으로 git push는 태그를 푸시하지 않습니다. 태그는 git push에 명시 적으로 전달되어야합니다. $ git push origin v1.4 Counting objects: 14, done. Delta compression using up to 8 threads. Compressing objects: 100% (12/12), done. Writing objects: 100% (14/14), 2.05 KiB | 0 bytes/s, done. Total 14 (delta 3), reused 0 (delta 0) To git@bitbucket.com:atlasbro/gittagdocs.git * [new tag] v1.4 -> v1.4 여러 개의 태그를 동시에 푸시하려면 --tags 옵션을 git push 명령에 전달하십시오. 다른 사용자가 Repo를 복제하거나 가져 오면 새 태그가 수신됩니다. 태그 체크 아웃하기 git checkout 명령을 사용하여 태그에서 repo의 상태를 볼 수 있습니다. git checkout v1.4 위의 명령은 v1.4 태그를 체크 아웃합니다. 이렇게하면 repo가 분리 된 HEAD 상태가됩니다. 이는 변경 한 내용이 태그를 업데이트하지 않음을 의미합니다. 그들은 새로운 분리 된 커밋을 만들 것입니다. 이 새로운 분리 된 커밋은 모든 분기의 일부가 아니며 SHA 해시 커밋에 의해서만 직접 접근 할 수 있습니다. 그러므로 분리 된 HEAD 상태에서 변경을 수행 할 때마다 새 분기를 작성하는 것이 가장 좋습니다. 태그 삭제하기 태그를 삭제하는 것은 간단합니다. git 태그에 -d 옵션과 태그 식별자를 전달하면 식별 된 태그가 삭제됩니다. $ git tag v1 v2 v3 $ git tag -d v1 $ git tag v2 v3 이 예제에서는 git 태그가 실행되어 v1, v2, v3을 나타내는 태그 목록을 표시 한 다음 v1 태그를 삭제하는 git 태그 -d v1이 실행됩니다. Git 가이드

git status

tag.png git status 명령은 작업 디렉토리 및 스테이징 영역의 상태를 표시합니다. Git이 어떤 변경 내용을 준비했는지, 어떤 변경 사항이 추적되어 있지 않은지, 어떤 파일이 추적 중인지 확인할 수 있습니다. 상태 출력은 커밋 된 프로젝트 기록과 관련된 정보를 표시하지 않습니다. 이를 위해서는 git log를 사용해야합니다. 사용법 git status Staged, unstaged, 그리고 untracked 파일 목록을 보여줍니다. Ignoring Files 추적 할 수없는 파일은 일반적으로 두 가지 범주로 나뉩니다. 그것들은 방금 프로젝트에 추가되었고 아직 커밋되지 않은 파일이거나 .pyc, .obj, .exe 등의 컴파일 된 바이너리입니다. 이전에는 git에 포함하는 것이 유익했지만 상태 출력, 후자는 실제로 당신의 저장소에서 진행되고있는 것을보기 어렵게 만들 수 있습니다. 이러한 이유로 Git은 .gitignore라는 특수 파일에 경로를 넣어 파일을 완전히 무시할 수 있습니다. 무시하려는 파일은 별도의 줄에 포함해야하며 * 기호는 와일드 카드로 사용할 수 있습니다. 예를 들어 프로젝트 루트의 .gitignore 파일에 다음을 추가하면 컴파일 된 파이썬 모듈이 git 상태로 나타나지 않습니다. Example 뜻하지 않은 것을 실수로 저 지르지 않도록 변경하기 전에 저장소의 상태를 확인하는 것이 좋습니다. 이 예에서는 스냅 샷을 준비하고 커밋하기 전과 후에 리포지토리 상태를 표시합니다. # Edit hello.py git status # hello.py is listed under "Changes not staged for commit" git add hello.py git status # hello.py is listed under "Changes to be committed" git commit git status # nothing to commit (working directory clean) 첫 번째 상태 출력은 파일을 unstaged로 표시합니다. 자식 추가 작업은 두 번째 자식 상태에 반영되고 마지막 상태 출력은 커밋 할 것이 없다는 것을 알려주며 작업 디렉토리는 가장 최근의 커밋과 일치합니다. 일부 git 명령 (예 : git merge)은 우연히 변경 사항을 덮어 쓰지 않도록 작업 디렉토리가 깨끗해야합니다. Git 가이드

git add

git add 명령은 작업 디렉토리의 변경 사항을 스테이징 영역에 추가합니다. Git에게 다음 커밋에서 특정 파일에 대한 업데이트를 포함하길 원한다는 것을 알려줍니다. 그러나 git add는 저장소에 중요한 영향을 미치지 않습니다. 변경 사항은 git commit을 실행할 때까지 실제로 기록되지 않습니다. 이 명령들과 함께 작업 디렉토리와 스테이징 영역의 상태를 보려면 git 상태가 필요합니다. How it works git add와 git commit 명령은 근본적인 Git 작업 흐름을 구성합니다. 이 명령은 팀의 공동 작업 모델에 관계없이 모든 Git 사용자가 이해해야하는 두 가지 명령입니다. 그것들은 저장소의 히스토리에 프로젝트 버전을 기록하는 수단이다. 프로젝트를 개발하는 것은 기본적인 편집 / 단계 / 커밋 패턴을 중심으로 이루어집니다. 먼저 작업 디렉토리에서 파일을 편집합니다. 프로젝트의 현재 상태 사본을 저장할 준비가되면 git add 명령으로 변경 사항을 저장합니다. 준비된 스냅 샷에 만족하면 git commit을 사용하여 프로젝트 히스토리에 커밋합니다. git reset 명령은 커밋 또는 준비된 스냅 샷을 실행 취소하는 데 사용됩니다. git add 및 git commit 외에도 세 번째 명령 인 git push는 완전한 협업 작업 흐름을 위해 필수적입니다. git push는 협업을 위해 커밋 된 변경 사항을 원격 저장소에 보내는 데 사용됩니다. 이렇게하면 다른 팀 구성원이 저장된 변경 사항 집합에 액세스 할 수 있습니다. 11.png git add 명령을 저장소에 파일을 추가하는 svn add와 혼동해서는 안됩니다. 대신, git add는 더 추상적 인 변경 레벨에서 작동합니다. 즉, 파일을 변경할 때마다 git add를 호출해야하지만 svn add는 각 파일에 대해 한 번만 호출하면됩니다. 중복되는 것처럼 들릴 수도 있지만,이 워크 플로우는 프로젝트를 체계적으로 정리하는 것을 훨씬 쉽게 만듭니다. The staging area git add 명령의 주요 기능은 작업 디렉토리에서 보류중인 변경 사항을 git staging 영역으로 승격시키는 것입니다. 준비 영역은 Git의 고유 한 기능 중 하나이며, SVN (또는 심지어 Mercurial) 배경에서 오는 경우에는 머리를 감싸는 데 약간의 시간이 걸릴 수 있습니다. 작업 디렉토리와 프로젝트 기록 사이의 버퍼로 생각하는 것이 도움이됩니다. 준비 영역은 Git의 "세 나무"중 하나, 작업 디렉토리 및 커밋 기록 중 하나로 간주됩니다. 마지막 커밋 이후에 변경 한 사항을 모두 커밋하는 대신 스테이지에서 관련 변경 사항을 포커스가있는 스냅 샷으로 그룹화하여 실제로 프로젝트 기록에 커밋 할 수 있습니다. 즉, 무관 한 파일에 대한 모든 종류의 편집 작업을 수행 한 다음 관련 변경 사항을 스테이지에 추가하고이를 논리적 커밋으로 분리하여 개별적으로 커밋 할 수 있습니다. 모든 개정 관리 시스템에서와 마찬가지로 원자 커밋을 만들어 버그를 추적하고 변경 사항을 프로젝트의 나머지 부분에 미치는 영향을 최소화하면서 쉽게 되돌릴 수 있도록하는 것이 중요합니다. 공통 옵션 git add <file> 다음 커밋을 위해 <file>의 모든 변경 사항을 준비하십시오. git add <directory> 다음 커밋을 위해 <directory>의 모든 변경 사항을 스테이지하십시오. git add -p 다음 커밋에 추가 할 파일의 부분을 선택할 수있는 대화 형 스테이징 세션을 시작하십시오. 이렇게하면 변경 사항이 표시되고 명령을 묻는 메시지가 나타납니다. 청크를 스테이지하려면 y를, 청크를 무시하려면, 작은 청크로 분할하고, 청크를 수동으로 편집하고, q를 종료하십시오. Examples 새 프로젝트를 시작할 때 git add는 svn import와 동일한 기능을 제공합니다. 현재 디렉토리의 초기 확약을 작성하려면 다음 두 명령을 사용하십시오. git add . git commit 프로젝트를 시작하고 실행하면 git add에 경로를 전달하여 새 파일을 추가 할 수 있습니다. git add hello.py git commit 위의 명령을 사용하여 기존 파일의 변경 사항을 기록 할 수도 있습니다. 다시 한번 말하지만, Git은 새로운 파일의 준비 변경과 이미 저장소에 추가 된 파일의 변경을 구분하지 않습니다. Git 가이드

git commit

12.png git commit 명령은 프로젝트의 현재 단계별 변경 사항에 대한 스냅 샷을 캡처합니다. 커밋 된 스냅 샷은 프로젝트의 "안전한"버전으로 생각할 수 있습니다. Git은 명시 적으로 요청하지 않으면 변경하지 않습니다. git commit을 실행하기 전에 git add 명령을 사용하여 커밋에 저장 될 프로젝트의 변경 사항을 승격 또는 '수행'합니다. 이 두 명령 git commit과 git add는 가장 자주 사용되는 두 가지 명령입니다. Git commit 과 SVN commit 차이점 동일한 이름을 공유하는 동안 git commit은 svn commit과 같은 것이 아닙니다. 이 공유 용어는 svn 배경을 가진 Git 신규 사용자에게 혼란의 포인트가 될 수 있으며 그 차이를 강조하는 것이 중요합니다. git commit 대 svn commit을 비교하는 것은 중앙 집중식 애플리케이션 모델 (svn)과 분산 애플리케이션 모델 (Git)을 비교하는 것입니다. SVN에서 커밋은 변경 사항을 로컬 SVN 클라이언트에서 원격 중앙 집중식 공유 SVN 저장소로 푸시합니다. Git에서는 저장소가 배포되고 스냅 샷은 로컬 저장소에 커밋되며 다른 Git 저장소와는 전혀 상호 작용이 필요하지 않습니다. 자식 커밋은 나중에 임의의 원격 리포지토리에 푸시 될 수 있습니다. How it works 높은 수준에서 Git은 타임 라인 관리 유틸리티로 생각할 수 있습니다. 커밋은 Git 프로젝트 타임 라인의 핵심 빌딩 블록 단위입니다. 커밋은 Git 프로젝트의 타임 라인을 따라 스냅 샷 또는 마일스톤으로 생각할 수 있습니다. 커밋은 git commit 명령으로 생성되어 해당 시점의 프로젝트 상태를 캡처합니다. 스냅 샷은 항상 로컬 저장소에 커밋됩니다. 이는 SVN과 근본적으로 다르며 작업 카피는 중앙 저장소에 커밋됩니다. 대조적으로, 힘내라는 준비가 끝날 때까지 중앙 저장소와 상호 작용하도록 강요하지 않습니다. 준비 영역은 작업 디렉토리와 프로젝트 기록 사이의 버퍼이므로 각 개발자의 로컬 저장소는 기여와 중앙 저장소 사이의 버퍼입니다. Git 사용자를위한 기본 개발 모델을 변경합니다. Git 개발자는 변경 사항을 중앙 repo에 직접 커밋하는 대신 로컬 레포에 커밋을 축적 할 수 있습니다. 이것은 SVN 스타일의 협업에 비해 많은 이점을 가지고 있습니다. 즉, 기능을 원자 단위로 분할하고, 관련 커밋을 그룹화하고, 중앙 저장소에 공개하기 전에 로컬 내역을 정리하는 것을 더 쉽게 만듭니다. 또한 개발자는 격리 된 환경에서 작업 할 수 있으므로 다른 사용자와 편리하게 병합 할 때까지 통합이 지연됩니다. 격리 및 지연된 통합은 개별적으로 유익하지만, 자주 및 작은 단위로 통합하는 것이 팀의 이익입니다. 힘내 팀 공동 작업에 대한 우수 사례에 대한 자세한 내용은 팀에서 어떻게 힘내 워크 플로우를 구성하는지 읽어보십시오. Snapshots, not differences SVN과 Git 사이의 실질적인 차이점을 제외하고는 기본 구현은 완전히 다른 디자인 철학을 따릅니다. SVN이 파일의 차이를 추적하는 반면 Git의 버전 제어 모델은 스냅 샷을 기반으로합니다. 예를 들어, SVN 커밋은 저장소에 추가 된 원본 파일과 비교되는 diff로 구성됩니다. Git은 모든 커밋에서 각 파일의 전체 내용을 기록한다. 14-1.png 이는 특정 버전의 파일을 diff에서 "어셈블"할 필요가 없기 때문에 많은 Git 작업을 SVN보다 훨씬 빠르게 만듭니다. 각 파일의 전체 버전은 Git의 내부 데이터베이스에서 즉시 사용할 수 있습니다. Git의 스냅 샷 모델은 버전 제어 모델의 거의 모든 측면에 광범위한 영향을 미치며 분기 및 병합 도구에서부터 협업 작업 흐름에 이르는 모든 것에 영향을 미칩니다. 공통 옵션 git commit 준비된 스냅 샷을 커밋합니다. 그러면 커밋 메시지를 묻는 텍스트 편집기가 시작됩니다. 메시지를 입력 한 후 파일을 저장하고 편집기를 닫아 실제 커밋을 만듭니다. git commit -a 작업 디렉토리의 모든 변경 사항에 대한 스냅 샷을 커밋합니다. 이것은 오직 추적 된 파일 (히스토리의 어느 시점에서 git add로 추가 된 것들)에 대한 수정 만 포함합니다. git commit -m "commit message" 전달 된 커밋 메시지로 즉시 커밋을 만드는 바로 가기 명령입니다. 기본적으로 git commit은 로컬로 구성된 텍스트 편집기를 열고 커밋 메시지를 입력하라는 메시지를 표시합니다. -m 옵션을 전달하면 인라인 메시지를 선호하는 텍스트 편집기 프롬프트가 표시되지 않습니다. git commit -am "commit message" -a 및 -m 옵션을 결합한 파워 유저 바로 가기 명령입니다. 이 조합은 즉시 모든 단계적 변경 사항의 커밋을 생성하고 인라인 커밋 메시지를받습니다. git commit --amend 이 옵션은 커밋 명령에 다른 수준의 기능을 추가합니다. 이 옵션을 전달하면 마지막 커밋이 수정됩니다. 새 커밋을 만드는 대신 이전 커밋에 단계별 변경 사항이 추가됩니다. 이 명령은 시스템에 구성된 텍스트 편집기를 열고 이전에 지정한 커밋 메시지를 변경하라는 메시지를 표시합니다. Examples 커밋으로 변경 저장하기 다음 예제는 현재 브랜치에서 hello.py라는 파일의 일부 내용을 편집 한 것으로 가정하고 프로젝트 히스토리에 커밋 할 준비가되어 있다고 가정합니다. 먼저 git add로 파일을 준비한 다음 준비된 스냅 샷을 커밋 할 수 있습니다. git add hello.py 이 명령은 hello.py를 Git 스테이징 영역에 추가합니다. git status 명령을 사용하여이 작업의 결과를 검사 할 수 있습니다. git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: hello.py 녹색 출력 새로운 파일 : hello.py는 hello.py가 다음 커밋과 함께 저장 될 것임을 나타냅니다. 커밋에서 다음을 실행하여 만듭니다. git commit 커밋 된 로그 메시지를 요구하는 텍스트 편집기 (git config를 통해 사용자 정의 가능)가 열립니다. # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master # Changes to be committed: # (use "git reset HEAD ..." to unstage) # #modified: hello.py Git은 특정 형식 제약 조건을 따르는 커밋 메시지를 요구하지 않지만 표준 형식은 첫 줄에 전체 커밋을 50 자 미만으로 요약하고 빈 줄을 남기고 변경된 내용에 대한 자세한 설명을 제공합니다. 예 : Change the message displayed by hello.py - Update the sayHello() function to output the user's name - Change the sayGoodbye() function to a friendlier message 전자 메일과 마찬가지로 커밋 메시지의 첫 번째 줄을 제목 줄로 사용하는 것이 일반적입니다. 나머지 로그 메시지는 본문으로 간주되어 커밋 변경 집합의 세부 정보를 전달하는 데 사용됩니다. 많은 개발자들이 커밋 메시지에 현재 시제를 사용하기를 좋아한다는 점에 유의하십시오. 이것은 리포지토리에서의 작업과 같이 더 많이 읽을 수있게 해줌으로써 많은 역사 작성 작업을 더욱 직관적으로 만듭니다. 마지막 커밋 수정하기 위의 hello.py 예제를 계속 진행하십시오. hello.py에 대한 추가 업데이트를하고 다음을 실행합니다. git add hello.py git commit --amend 그러면 다시 구성된 텍스트 편집기가 열립니다. 그러나 이번에는 이전에 입력 한 커밋 메시지로 미리 채워질 것입니다. 이것은 우리가 새로운 커밋을 생성하는 것이 아니라 마지막 커밋을 편집하고 있음을 나타냅니다. Git 가이드

git stash

작업 복사본에 대한 숨김 보관함 (또는 숨김) 변경 내용을 숨겨서 다른 작업을 할 수있게 한 다음 나중에 다시 적용하여 나중에 다시 적용 할 수 있습니다. 숨기기는 컨텍스트를 신속하게 전환하고 다른 작업을해야하는 경우 편리하지만 코드를 변경하는 중반에 있으며 커밋 할 준비가되지 않았습니다. 작업 숨기기 git stash 명령은 커밋되지 않은 변경 (준비 및 언 스테이지 모두)을 취하고 나중에 사용하기 위해 저장 한 다음 작업 복사본에서 되돌립니다. 예 : $ git status On branch master Changes to be committed: new file: style.css Changes not staged for commit: modified: index.html $ git stash Saved working directory and index state WIP on master: 5002d47 our new homepage HEAD is now at 5002d47 our new homepage $ git status On branch master nothing to commit, working tree clean 이 시점에서 여러분은 자유롭게 변경을 할 수 있고, 새로운 커밋을 만들고, 분기를 전환하고, 다른 Git 작업을 수행 할 수 있습니다. 그런 다음 다시 돌아와서 준비가되었을 때 은닉을 다시 적용하십시오. 숨겨진 저장소는 Git 저장소에 로컬로 저장됩니다. 밀어 넣을 때 은폐는 서버로 전송되지 않습니다. 숨겨진 변경 적용하기 git stash pop으로 이전에 숨긴 변경 사항을 다시 적용 할 수 있습니다. $ git status On branch master nothing to commit, working tree clean $ git stash pop On branch master Changes to be committed: new file: style.css Changes not staged for commit: modified: index.html Dropped refs/stash@{0} (32b3aa1d185dfe6d57b3c3cc3b32cbf3e380cc6a) Popping your stash removes the changes from your stash and reapplies them to your working copy. Alternatively, you can reapply the changes to your working copy and keep them in your stash with git stash apply: $ git stash apply On branch master Changes to be committed: new file: style.css Changes not staged for commit: modified: index.html 여러 분기에 동일한 숨겨진 변경 사항을 적용하려는 경우 유용합니다. stashing의 기본 사항을 알았으므로 git stash를주의해야합니다. 기본적으로 Git은 추적되지 않거나 무시되는 파일의 변경 사항을 숨기지 않습니다. untracked or ignored 파일 숨기기 기본적으로 git stash를 실행하면 다음 항목이 숨겨집니다. 색인에 추가 된 변경 사항 (단계별 변경 사항) 현재 Git에 의해 추적되는 파일에 대한 변경 사항 (unstaged changes) 그러나 다음 항목은 숨겨지지 않을 것입니다 : 작업 복사본에서 아직 준비되지 않은 새 파일 무시 된 파일 위 예제에 세 번째 파일을 추가했지만 스테이지를 만들지 않으면 (즉, git add를 실행하지 않음) git stash가 stash하지 않습니다. $ script.js $ git status On branch master Changes to be committed: new file: style.css Changes not staged for commit: modified: index.html Untracked files: script.js $ git stash Saved working directory and index state WIP on master: 5002d47 our new homepage HEAD is now at 5002d47 our new homepage $ git status On branch master Untracked files: script.js -u 옵션 (또는 --include-untracked)을 추가하면 git stash가 untracked 파일을 숨긴다. $ git status On branch master Changes to be committed: new file: style.css Changes not staged for commit: modified: index.html Untracked files: script.js $ git stash -u Saved working directory and index state WIP on master: 5002d47 our new homepage HEAD is now at 5002d47 our new homepage $ git status On branch master nothing to commit, working tree clean git stash를 실행할 때 -a 옵션 (또는 --all)을 전달하여 무시 된 파일에 대한 변경 사항을 포함 할 수 있습니다. 15.png 숨겨진 목록 (stash) 관리하기 git stash를 여러 번 실행하여 숨겨진 목록을 만든 다음 git stash list를 사용하여 볼 수 있습니다. 기본적으로 stash는 작성된 분기 또는 커밋 위의 "진행중인 작업"(WIP)으로 식별 됩니다. 잠시 후 각 은닉 내용을 기억하는 것은 어려울 수 있습니다. $ git stash list stash@{0}: WIP on master: 5002d47 our new homepage stash@{1}: WIP on master: 5002d47 our new homepage stash@{2}: WIP on master: 5002d47 our new homepage 좀 더 많은 문맥을 제공하기 위해 stash에 설명을 추가하고 git stash save "message"를 사용하여 주석을 달아주는 것이 좋습니다. $ git stash save "add style to our site" Saved working directory and index state On master: add style to our site HEAD is now at 5002d47 our new homepage $ git stash list stash@{0}: On master: add style to our site stash@{1}: WIP on master: 5002d47 our new homepage stash@{2}: WIP on master: 5002d47 our new homepage 기본적으로 git stash pop은 가장 최근에 생성 된 stash를 다시 적용합니다 : stash @ {0} 식별자를 마지막 인수로 전달하여 다시 적용 할 스태프를 선택할 수 있습니다 (예 : $ git stash pop stash@{2} 숨겨진 내용 비교 (stash diffs) git stash show를 사용하여 stash 요약을 볼 수 있습니다. $ git stash show index.html | 1 + style.css | 3 +++ 2 files changed, 4 insertions(+) 또는 stash 전체 diff를 보려면 -p 옵션 (또는 - patch)을 전달하십시오. $ git stash show -p diff --git a/style.css b/style.css new file mode 100644 index 0000000..d92368b --- /dev/null +++ b/style.css @@ -0,0 +1,3 @@ +* { + text-decoration: blink; +} diff --git a/index.html b/index.html index 9daeafb..ebdcbd2 100644 --- a/index.html +++ b/index.html @@ -1 +1,2 @@ +<link rel="stylesheet" href="style.css"/> 부분 stashes 단일 파일, 파일 모음 또는 파일 내 개별 변경 사항을 숨기도록 선택할 수도 있습니다. git stash에 -p 옵션 (또는 --patch)을 전달하면 작업 복사본에서 변경된 각 "덩어리"를 반복하여 숨길 지 여부를 묻습니다. $ git stash -p diff --git a/style.css b/style.css new file mode 100644 index 0000000..d92368b --- /dev/null +++ b/style.css @@ -0,0 +1,3 @@ +* { + text-decoration: blink; +} Stash this hunk [y,n,q,a,d,/,e,?]? y diff --git a/index.html b/index.html index 9daeafb..ebdcbd2 100644 --- a/index.html +++ b/index.html @@ -1 +1,2 @@ +<link rel="stylesheet" href="style.css"/> Stash this hunk [y,n,q,a,d,/,e,?]? n 15-2.png 일반적으로 유용한 것들은 다음과 같습니다 : Command Description / search for a hunk by regex ? help n don't stash this hunk q quit (any hunks that have already been selected will be stashed) s split this hunk into smaller hunks y stash this hunk 명시 적 "중단"명령은 없지만 CTRL-C (SIGINT)를 누르면 숨김 프로세스가 중단됩니다. Stash로부터 브랜치 생성하기 브랜치의 변경사항이 stash의 변경사항과 다른 경우  stash를 적용 할 때 충돌이 발생할 수 있습니다. 대신 git stash branch를 사용하여 숨겨진 변경 사항을 적용 할 새 브랜치를 만들 수 있습니다 : $ git stash branch add-stylesheet stash@{1} Switched to a new branch 'add-stylesheet' On branch add-stylesheet Changes to be committed: new file: style.css Changes not staged for commit: modified: index.html Dropped refs/stash@{1} (32b3aa1d185dfe6d57b3c3cc3b32cbf3e380cc6a) 이것은 당신이 숨긴 곳을 만든 커밋을 기반으로 새로운 브랜치를 체크 아웃하고 숨겨진 변경 사항을 그 위에 놓습니다. stash 비우기 더 이상 stash가 필요 없다고 판단되면 git stash drop으로 삭제할 수 있습니다. $ git stash drop stash@{1} Dropped stash@{1} (17e2697fd8251df6163117cb3d58c1f62a5e7cdb) 또는 다음과 같이 모든 숨기기를 삭제할 수 있습니다. $ git stash clear How git stash works Stash가 어떻게 동작하는지 궁금하다면 이 절을 읽어도 좋습니다. 단지 stash 사용 방법이 알고싶다면 이 절을 읽지 않아도 됩니다. stash는 저장소에서 실제로 커밋 객체로 인코딩됩니다. .git / refs / stash의 특별한 ref는 가장 최근에 생성 된 stash를 가리키며, 이전에 생성 된 stash는 stash ref의 reflog에 의해 참조됩니다. 이것이 당신이 stash @ {n}을 은닉하여 참조하는 이유입니다. 실제로는 stash ref의 n 번째 reflog 항목을 참조하고 있습니다. stash는 커밋 일 뿐이므로 git log로 검사 할 수있습니다. $ git log --oneline --graph stash@{0} *-. 953ddde WIP on master: 5002d47 our new homepage |\ \ | | * 24b35a1 untracked files on master: 5002d47 our new homepage | * 7023dd4 index on master: 5002d47 our new homepage |/ * 5002d47 our new homepage 숨긴 것에 따라, 하나의 git stash 연산은 2 ~ 3 개의 새로운 커밋을 생성합니다. 위 다이어그램의 커밋은 다음과 같습니다. stash @ {0}, git stash를 실행할 때 작업 복사본에 있던 추적 된 파일을 저장하는 새로운 커밋 @ {0} 님의 첫 번째 부모를 숨기고 git stash를 실행할 때 HEAD에 있던 기존 커밋을 숨긴다. @ {0}의 두 번째 부모를 숨기고, git stash를 실행할 때 색인을 나타내는 새로운 커밋 @ {0}의 세 번째 부모를 숨기고, git stash를 실행할 때 작업 복사본에 있던 untracked 파일을 나타내는 새로운 커밋. 이 세 번째 상위 항목은 다음 경우에만 생성됩니다. 작업 복사본에는 실제로 untracked 파일이 포함되어 있습니다. 과 git stash를 호출 할 때 --include-untracked 또는 --all 옵션을 지정했습니다. git stash가 작업 트리와 인덱스를 커밋으로 인코딩하는 방법은 다음과 같습니다. 숨겨지기 전에 작업 트리에 추적 된 파일, 추적 할 수없는 파일 및 무시 된 파일에 대한 변경 사항이 포함될 수 있습니다. 이러한 변경 사항 중 일부는 색인에 포함될 수도 있습니다. 16.png git stash를 호출하면 추적 된 파일에 대한 모든 변경 사항이 DAG에서 두 개의 새로운 커밋으로 인코딩됩니다. 하나는 무단 변경에 대한 것이고 다른 하나는 인덱스에 준비된 변경에 대한 것입니다. 특수한 refs / stash ref가 그들을 가리 키도록 업데이트됩니다. 16-1.png --include-untracked 옵션을 사용하면 추적되지 않은 파일에 대한 변경 사항을 추가 커밋으로 인코딩 할 수 있습니다. 16-2.png --all 옵션을 사용하면 동일한 커밋에서 추적되지 않은 파일의 변경 사항과 함께 무시 된 파일의 변경 사항이 포함됩니다. 16-3.png git stash pop을 실행하면 위 커밋의 변경 사항이 작업 복사본과 인덱스를 업데이트하는 데 사용되며 stash reflog는 셔플되어 팝 된 커밋을 제거합니다. 팝 된 커밋은 즉시 삭제되지 않지만 향후 가비지 수집을위한 후보가됩니다. Git 가이드

git diff

변경 비교하기: git diff Diffing은 두 개의 입력 데이터 집합을 가져 와서 변경 내용을 출력하는 함수입니다. git diff는 실행시 Git 데이터 소스에서 diff 함수를 실행하는 다중 사용 Git 명령입니다. 이러한 데이터 소스는 커밋, 분기, 파일 등이 될 수 있습니다. 이 문서는 git diff와 diffing 작업 흐름 패턴의 일반적인 호출에 대해 설명합니다. git diff 명령은 git status 및 git log와 함께 사용되어 Git repo의 현재 상태를 분석합니다. Reading diffs: outputs Raw output format 다음 예제는 간단한 repo에서 실행됩니다. repo는 아래 명령으로 생성됩니다. $ mkdir diff_test_repo $ cd diff_test_repo $ touch diff_test.txt $ echo "this is a git diff test example" > diff_test.txt $ git init . Initialized empty Git repository in /Users/kev/code/test/.git/ $ git add diff_test.txt $ git commit -am"add diff test file" [master (root-commit) 6f77fc3] add diff test file 1 file changed, 1 insertion(+) create mode 100644 diff_test.txt 이 시점에서 git diff를 실행하면 결과가 출력되지 않습니다. diff에 대한 변경 사항이 없으므로 이는 예상되는 동작입니다. repo가 생성되고 diff_test.txt 파일이 추가되면 diff 출력을 실험하기 위해 파일 내용을 변경할 수 있습니다. $ echo "this is a diff example" > diff_test.txt 이 명령을 실행하면 diff_test.txt 파일의 내용이 변경됩니다. 일단 수정되면 diff를보고 출력을 분석 할 수 있습니다. 이제 git diff를 실행하면 다음과 같은 결과가 출력됩니다. $ diff --git a/diff_test.txt b/diff_test.txt index 6b0c6cf..b37e70a 100644 --- a/diff_test.txt +++ b/diff_test.txt @@ -1 +1 @@ -this is a git diff test example +this is a diff example 이제 diff 출력에 대한 자세한 분석을 살펴 보겠습니다. 1. Comparison input $ diff --git a/diff_test.txt b/diff_test.txt 이 행은 diff의 입력 소스를 표시합니다. a / diff_test.txt와 b / diff_test.txt가 diff에 전달되었음을 알 수 있습니다. 2. Meta data index 6b0c6cf..b37e70a 100644 이 행은 내부 Git 메타 데이터를 표시합니다. 이 정보가 필요 없을 것입니다. 이 출력의 숫자는 Git 객체 버전 해시 식별자에 해당합니다. 3. Markers for changes --- a/diff_test.txt +++ b/diff_test.txt 이 행은 각 diff 입력 소스에 기호를 지정하는 범례입니다. 이 경우 / diff_test.txt의 변경 사항은 ---로 표시되고 b / diff_test.txt의 변경 사항은 +++ 기호로 표시됩니다. 4. Diff chunks 나머지 diff 출력은 diff 'chunk'목록입니다. diff는 변경 사항이있는 파일의 섹션 만 표시합니다. 현재 시나리오에서는 간단한 시나리오로 작업하면서 하나의 청크 만 있습니다. 덩어리는 독자적인 세분화 된 출력 의미론을 가지고 있습니다. @@ -1 +1 @@ -this is a git diff test example +this is a diff example 첫 번째 줄은 청크 헤더입니다. 각 청크는 @@ 기호 안에 포함 된 헤더 앞에 추가됩니다. 헤더의 내용은 파일에 대한 변경 사항 요약입니다. 우리의 단순화 된 예에서 우리는 -1 +1 의미 라인 하나가 변경되었습니다. 보다 현실적인 diff에서는 다음과 같은 헤더가 표시됩니다. @@ -34,6 +34,8 @@ 이 머리글 예제에서는 34 행부터 6 행을 추출했습니다. 또한 34 행부터 8 행을 추가했습니다. diff chunk의 나머지 내용은 최근 변경 사항을 표시합니다. 변경된 각 줄 앞에는 + 또는 - 기호가 표시되어 변경 사항의 원본 버전을 나타냅니다. 앞에서 설명한 것처럼 -는 a / diff_test.txt의 변경 사항을 나타내며 +는 b / diff_test.txt의 변경 사항을 나타냅니다. 변경 사항 강조 표시 1. git diff --color-words git diff는 --color-words보다 훨씬 세분화 된 변경 사항을 강조하기위한 특수 모드도 제공합니다. 이 모드는 추가되거나 제거 된 행을 공백으로 토큰 화 한 다음 그 행과 비교합니다. $ git diff --color-words $ diff --git a/diff_test.txt b/diff_test.txt index 6b0c6cf..b37e70a 100644 --- a/diff_test.txt +++ b/diff_test.txt @@ -1 +1 @@ this is agit difftest example 이제 출력물에는 변경된 색으로 구분 된 단어 만 표시됩니다. 2. git diff-highlight git 소스를 복제하면 contrib이라는 하위 디렉토리가 있습니다. 여기에는 여러 git 관련 도구가 포함되어 있으며 흥미로운 비트와 조각은 아직 핵심 노드로 승격되지 않았습니다. 이 중 하나는 diff-highlight라는 Perl 스크립트입니다. diff 강조 표시는 diff 출력의 일치하는 행을 짝 지워주고 변경된 하위 단어 조각을 강조 표시합니다. $ git diff | /your/local/path/to/git-core/contrib/diff-highlight/diff-highlight diff --git a/diff_test.txt b/diff_test.txt index 6b0c6cf..b37e70a 100644 --- a/diff_test.txt +++ b/diff_test.txt @@ -1 +1 @@ -this is a git diff test example +this is a diff example 이제 우리는 가능한 가장 작은 변경 사항을 비교해 보았습니다. 바이너리 파일 비교하기 우리가 지금까지 보여준 텍스트 파일 유틸리티 외에도 git diff는 바이너리 파일에서 실행될 수 있습니다. 불행히도, 기본 출력은별로 도움이되지 않습니다. $ git diff Binary files a/script.pdf and b/script.pdf differ Git에는 diff를 수행하기 전에 이진 파일의 내용을 텍스트로 변환하는 쉘 명령을 지정할 수있는 기능이 있습니다. 그래도 약간의 설정이 필요합니다. 먼저 특정 유형의 바이너리를 텍스트로 변환하는 방법을 설명하는 textconv 필터를 지정해야합니다. 우리는 PDF 파일을 사람이 읽을 수있는 HTML로 변환하기 위해 pdftohtml이라는 간단한 유틸리티 (homebrew에서 사용 가능)를 사용하고 있습니다. 이 설정은 .git / config 파일을 편집하여 단일 저장소에 대해 설정할 수도 있고 ~ /.gitconfig를 편집하여 전역으로 설정할 수도 있습니다 [diff "pdfconv"] textconv=pdftohtml -stdout 그런 다음 하나 이상의 파일 패턴을 pdfconv 필터와 연결하기 만하면됩니다. 리포지토리의 루트에 .gitattributes 파일을 만들어이 작업을 수행 할 수 있습니다. *.pdf diff=pdfconv 일단 설정되면, git diff는 먼저 구성된 변환기 스크립트를 통해 이진 파일을 실행하고 변환기 출력을 diff합니다. jips, jars 및 기타 아카이브 : pdf2html 대신 unzip -l (또는 유사)을 사용하면 추가되거나 제거 된 경로가 표시됩니다. 이미지 커밋 : exiv2는 이미지 차원 문서와 같은 메타 데이터 변경 사항을 표시하는 데 사용할 수 있습니다. 변환 도구는 .odf, .doc 및 기타 문서 형식을 일반 텍스트로 변환하기 위해 존재합니다. 핀치 (pinch)에서 문자열은 형식 변환기가없는 바이너리 파일에서 종종 작동합니다. 파일 비교하기: git diff file git diff 명령은 명시 적 파일 경로 옵션을 전달할 수 있습니다. git diff에 파일 경로가 전달되면 diff 작업의 범위가 지정된 파일로 지정됩니다. 아래 예제는 이러한 사용법을 보여줍니다. $ git diff HEAD ./path/to/file 이 예제는 호출 될 때 ./path/to/file로 범위가 지정되며 작업 디렉토리의 특정 변경 사항을 인덱스와 비교하여 아직 준비되지 않은 변경 사항을 보여줍니다. 기본적으로 git diff는 HEAD와의 비교를 실행합니다. 위의 예에서 HEAD를 생략하면 git diff ./path/to/file과 동일한 효과가 나타납니다. $ git diff --cached ./path/to/file git diff가 --cached 옵션과 함께 호출되면 diff는 단계적 변경 사항을 로컬 저장소와 비교합니다. --cached 옵션은 --staged와 동의어입니다. 모든 변경 비교하기 git diff를 파일 경로없이 사용하면 전체 저장소의 변경 사항을 비교할 수 있습니다. 위의 파일 별 예제는 ./path/to/file 인수없이 호출 할 수 있으며 로컬 repo의 모든 파일에서 동일한 출력 결과를 갖습니다. 마지막 커밋 이후 변경 보기 기본적으로 git diff는 마지막 커밋 이후 커밋되지 않은 변경 사항을 보여줍니다. $ git diff 서로다른 커밋의 파일 비교하기 git diff는 diff에 커밋을 전달할 수 있습니다. 몇 가지 예제 ref는 HEAD, 태그 및 분기 이름입니다. Git의 모든 커밋에는 GIT LOG를 실행할 때 얻을 수있는 커밋 ID가 있습니다. git diff에이 커밋 ID를 전달할 수도 있습니다. $ git log --prety=oneline 957fbc92b123030c389bf8b4b874522bdf2db72c add feature ce489262a1ee34340440e55a0b99ea6918e19e7a rename some classes 6b539f280d8b0ec4874671bae9c6bed80b788006 refactor some code for feature 646e7863348a427e1ed9163a9a96fa759112f102 add some copy to body $ git diff 957fbc92b123030c389bf8b4b874522bdf2db72c ce489262a1ee34340440e55a0b99ea6918e19e7a 브랜치 비교하기 두 개의 브랜치 비교하기 브랜치는 다른 모든 ref 입력과 마찬가지로 git diff와 비교됩니다. $ git diff branch1..other-feature-branch 이 예제는 도트 연산자를 소개합니다. 이 예에서 두 점은 diff 입력이 두 가지의 팁임을 나타냅니다. 점이 생략되고 분기 사이에 공백이 사용되는 경우에도 동일한 효과가 발생합니다. 또한 점 연산자 3 개가 있습니다. $ git diff branch1...other-feature-branch 세개의 도트 연산자는 첫 번째 입력 매개 변수 branch1을 변경하여 diff를 시작합니다. branch1을 두 diff 입력, 즉 branch1과 other-feature-branch의 공유 조상 사이의 공유 공통 조상 커밋의 ref로 변경합니다. 마지막 매개 변수 입력 매개 변수는 other-feature-branch의 끝으로 변경되지 않습니다. 두 브랜치의 파일 비교하기 브랜치간에 특정 파일을 비교하려면 파일 경로를 git diff의 세 번째 인수로 전달하십시오 git diff master new_branch ./diff_test.txt Git 가이드

.gitignore

17.png Git은 작업 카피의 모든 파일을 세 가지 중 하나로 본다. 추적 - 이전에 수행되었거나 확약 된 파일. untracked - 준비되거나 커밋되지 않은 파일. 또는 무시 됨 - Git이 명시 적으로 무시하도록 지시 한 파일. 무시 된 파일은 일반적으로 저장소 소스에서 파생되거나 커밋되지 않아야하는 빌드 아티팩트 및 컴퓨터 생성 파일입니다. 몇 가지 일반적인 예는 다음과 같습니다. / node_modules 또는 / 패키지의 내용과 같은 종속성 캐시 .o, .pyc 및 .class 파일과 같은 컴파일 된 코드 / bin, / out 또는 / target과 같은 출력 디렉토리 빌드 .log, .lock 또는 .tmp와 같이 런타임에 생성되는 파일 .DS_Store 또는 Thumbs.db와 같은 숨겨진 시스템 파일 .idea / workspace.xml과 같은 개인 IDE 구성 파일 무시 된 파일은 저장소의 루트에서 체크인 된 .gitignore라는 특수 파일에서 추적됩니다. 명시 적으로 git ignore 명령은 없습니다. 대신에 .gitignore 파일을 편집하고 커밋해야합니다. 무시할 새 파일이 있으면 수동으로 커밋해야합니다. .gitignore 파일은 저장소의 파일 이름과 일치하는 패턴을 포함하여 무시해야하는지 여부를 결정합니다. Git ignore 패턴 .gitignore는 globbing 패턴을 사용하여 파일 이름과 일치시킵니다. 다양한 기호를 사용하여 패턴을 구성 할 수 있습니다. Pattern Example matches Explanation* **/logs  logs/debug.log logs/monday/foo.bar build/logs/debug.log You can prepend a pattern with a double asterisk to match directories anywhere in the repository.  **/logs/debug.log  logs/debug.log build/logs/debug.log but not logs/build/debug.log You can also use a double asterisk to match files based on their name and the name of their parent directory.  *.log debug.log foo.log .log logs/debug.log An asterisk is a wildcard that matches zero or more characters.  *.log  !important.log debug.log trace.log but not important.log logs/important.log Prepending an exclamation mark to a pattern negates it. If a file matches a pattern, but alsomatches a negating pattern defined later in the file, it will not be ignored.  *.log  !important/*.log trace.* debug.log important/trace.log but not important/debug.log Patterns defined after a negating pattern will re-ignore any previously negated files.  /debug.log debug.log but not logs/debug.log Prepending a slash matches files only in the repository root.  debug.log debug.log logs/debug.log By default, patterns match files in any directory  debug?.log  debug0.log debugg.log but not debug10.log A question mark matches exactly one character.  debug[0-9].log  debug0.log debug1.log but not debug10.log Square brackets can also be used to match a single character from a specified range.  debug[01].log  debug0.log debug1.log but not  debug2.log debug01.log Square brackets match a single character form the specified set.  debug[!01].log  debug2.log but not debug0.log debug1.log debug01.log An exclamation mark can be used to match any character except one from the specified set.  debug[a-z].log  debuga.log debugb.log but not debug1.log Ranges can be numeric or alphabetic.  logs logs logs/debug.log logs/latest/foo.bar build/logs build/logs/debug.log If you don't append a slash, the pattern will match both files and the contents of directories with that name. In the example matches on the left, both directories and files named logs are ignored  logs/  logs/debug.log logs/latest/foo.bar build/logs/foo.bar build/logs/latest/debug.log Appending a slash indicates the pattern is a directory. The entire contents of any directory in the repository matching that name – including all of its files and subdirectories – will be ignored  logs/  !logs/important.log logs/debug.log logs/important.log Wait a minute! Shouldn't logs/important.logbe negated in the example on the left Nope! Due to a performance-related quirk in Git, you can not negate a file that is ignored due to a pattern matching a directory  logs/**/debug.log  logs/debug.log logs/monday/debug.log logs/monday/pm/debug.log A double asterisk matches zero or more directories.  logs/*day/debug.log  logs/monday/debug.log logs/tuesday/debug.log but not logs/latest/debug.log Wildcards can be used in directory names as well.  logs/debug.log logs/debug.log but not debug.log build/logs/debug.log Patterns specifying a file in a particular directory are relative to the repository root. (You can prepend a slash if you like, but it doesn't do anything special.)  **이 설명은 .gitignore 파일이 협약과 마찬가지로 저장소의 최상위 디렉토리에 있다고 가정합니다. 저장소에 .gitignore 파일이 여러 개있는 경우 "저장소 루트"를 ".gitignore 파일이있는 디렉토리"로 정신적으로 대체하십시오 (팀의 온전한 고려를 위해 통합을 고려하십시오). * 이러한 문자 외에도 .gitignore 파일에 #을 사용하여 주석을 포함 할 수 있습니다. # ignore all logs *.log 파일이나 디렉토리가있는 경우 \를 사용하여 .gitignore 패턴 문자를 이스케이프 처리 할 수 있습니다. # ignore the file literally named foo[01].txt foo\[01\].txt 저장소에 .gitignore 공유하기 Git 무시 규칙은 일반적으로 저장소의 루트에있는 .gitignore 파일에 정의되어 있습니다. 그러나 저장소의 여러 디렉토리에 여러 .gitignore 파일을 정의하도록 선택할 수 있습니다. 특정 .gitignore 파일의 각 패턴은 해당 파일이 들어있는 디렉토리를 기준으로 테스트됩니다. 그러나 규칙과 가장 단순한 접근법은 루트에 단일 .gitignore 파일을 정의하는 것입니다. .gitignore 파일이 체크인되면 리포지토리의 다른 파일과 마찬가지로 버전이 지정되고 푸시 할 때 팀원과 공유됩니다. 일반적으로 .gitignore에는 저장소의 다른 사용자에게 도움이되는 패턴 만 포함시켜야합니다. Personal Git ignore rules 특정 저장소에 대한 개인 무시 패턴을 .git / info / exclude의 특수 파일에 정의 할 수도 있습니다. 이러한 버전은 버전이 지정되지 않으며 저장소와 함께 배포되지 않으므로 이점 만 얻을 수있는 패턴을 포함하는 것이 좋습니다. 예를 들어 사용자 정의 로깅 설정이나 저장소의 작업 디렉토리에 파일을 생성하는 특수 개발 도구가있는 경우 .git / info / exclude에 추가하여 실수로 저장소에 커밋되지 않도록 할 수 있습니다. Global Git ignore rules 또한 Git core.excludesFile 속성을 설정하여 로컬 시스템의 모든 리포지토리에 대한 전역 Git 무시 패턴을 정의 할 수 있습니다. 이 파일을 직접 만들어야합니다. 전역 .gitignore 파일을 어디에 둘지 확실치 않으면 홈 디렉토리가 나쁜 선택이 아니며 나중에 쉽게 찾을 수 있습니다. 파일을 만들었 으면 git config로 위치를 구성해야합니다. $ touch ~/.gitignore $ git config --global core.excludesFile ~/.gitignore 서로 다른 파일 유형이 서로 다른 프로젝트와 관련되므로 어떤 패턴을 전역 적으로 무시할지 선택해야합니다. 일부 개발자 도구로 만든 특별 운영 체제 파일 (예 : .DS_Store 및 thumbs.db) 또는 임시 파일은 전 세계적으로 무시할 수있는 대표적인 후보입니다. Ignoring a previously committed file 과거에 커밋 한 파일을 무시하려면 저장소에서 파일을 삭제 한 다음 .gitignore 규칙을 추가해야합니다. git rm과 함께 --cached 옵션을 사용하면 파일이 저장소에서 삭제되지만 작업 디렉토리에는 무시 된 파일로 남아있게됩니다. $ echo debug.log >> .gitignore $ git rm --cached debug.log rm 'debug.log' $ git commit -m "Start ignoring debug.log" 저장소 및 로컬 파일 시스템에서 파일을 삭제하려면 --cached 옵션을 생략 할 수 있습니다. Committing an ignored file git add와 함께 -f (또는 --force) 옵션을 사용하여 무시 된 파일을 저장소에 강제로 적용 할 수 있습니다. $ cat .gitignore *.log $ git add -f debug.log $ git commit -m "Force adding debug.log" 일반적인 패턴 (예 : * .log)이 정의되어 있지만 특정 파일을 커미트하려는 경우이 작업을 고려할 수 있습니다. 그러나 더 좋은 해결책은 일반적인 규칙에 대한 예외를 정의하는 것입니다. $ echo !debug.log >> .gitignore $ cat .gitignore *.log !debug.log $ git add debug.log $ git commit -m "Adding debug.log" 이 접근법은 팀원에게보다 분명하고 혼란스럽지 않습니다. Stashing an ignored file git stash는 로컬 변경 사항을 일시적으로 저장 및 되돌리기위한 강력한 Git 기능으로, 나중에 다시 적용 할 수 있습니다. 예상대로, 기본적으로 git stash는 무시 된 파일을 무시하고 Git에 의해 추적되는 파일에 대한 변경 사항 만 숨 깁니다. 그러나, --all 옵션을 사용하여 git stash를 호출하면 무시되거나 변경되지 않은 파일에 변경 사항을 숨길 수 있습니다. Debugging .gitignore files 복잡한 .gitignore 패턴이 있거나 여러 .gitignore 파일에 패턴이 퍼져있는 경우 특정 파일을 왜 무시하는지 추적하기가 어려울 수 있습니다. git check-ignore 명령을 -v (또는 --verbose) 옵션과 함께 사용하여 어떤 패턴이 특정 파일을 무시하게하는지 결정할 수 있습니다. $ git check-ignore -v debug.log .gitignore:3:*.log debug.log 결과: <file containing the pattern> : <line number of the pattern> : <pattern> <file name> 원하는 경우 여러 파일 이름을 git check-ignore에 전달할 수 있으며 이름 자체는 저장소에있는 파일에 해당 할 필요조차 없습니다. Git 가이드

git 실행 취소

undo.png 이 섹션에서는 사용 가능한 '실행 취소'Git 전략과 명령에 대해 설명합니다. Git은 워드 프로세싱 응용 프로그램에서 발견되는 것과 같은 전통적인 '실행 취소'시스템이 없다는 점에 유의해야합니다. Git 작업을 전통적인 '실행 취소'정신 모델에 매핑하는 것을 자제하는 것이 좋습니다. 또한 Git에는 '실행 취소'작업에 대한 고유 한 명명 규칙이 있으므로 이를 활용하는 것이 가장 좋습니다. 이 용어에는 재설정, 되돌리기, 체크 아웃, 정리 등과 같은 용어가 포함됩니다. 재미있는 은유는 Git을 타임 라인 관리 유틸리티로 생각하는 것입니다. 커밋은 프로젝트 히스토리의 타임 라인을 따라 특정 시점 또는 관심 지점의 스냅 샷입니다. 또한 분기를 사용하여 여러 타임 라인을 관리 할 수 있습니다. Git에서 '실행 취소'할 때, 보통 시간 내에 다시 이동하거나 실수가 발생하지 않은 다른 타임 라인으로 이동합니다. 이 튜토리얼에서는 소프트웨어 프로젝트의 이전 버전을 사용하기 위해 필요한 모든 기술을 제공합니다. 첫째, 이전 커밋을 탐색하는 방법을 보여주는 다음 프로젝트 기록에서 공용 커밋을 되 돌리는 것과 로컬 컴퓨터에서 게시되지 않은 변경을 다시 설정하는 것의 차이점을 설명합니다. Finding what is lost: Reviewing old commits 모든 버전 제어 시스템의 기본 아이디어는 프로젝트의 "안전한"복사본을 저장하여 코드 기반을 돌이킬 수 없을 정도로 파괴 할 필요가 없다는 것입니다. 커밋의 프로젝트 히스토리를 구축하면 히스토리에서 커밋을 검토하고 다시 방문 할 수 있습니다. Git 저장소의 히스토리를 검토하는 데 가장 좋은 유틸리티 중 하나는 git log 명령입니다. 아래 예제에서 git log를 사용하여 널리 사용되는 오픈 소스 그래픽 라이브러리에 대한 최신 커밋 목록을 가져옵니다. git log --oneline e2f9a78fe Replaced FlyControls with OrbitControls d35ce0178 Editor: Shortcuts panel Safari support. 9dbe8d0cf Editor: Sidebar.Controls to Sidebar.Settings.Shortcuts. Clean up. 05c5288fc Merge pull request #12612 from TyLindberg/editor-controls-panel 0d8b6e74b Merge pull request #12805 from harto/patch-1 23b20c22e Merge pull request #12801 from gam0022/improve-raymarching-example-v2 fe78029f1 Fix typo in documentation 7ce43c448 Merge pull request #12794 from WestLangley/dev-x 17452bb93 Merge pull request #12778 from OndrejSpanel/unitTestFixes b5c1b5c70 Merge pull request #12799 from dhritzkiv/patch-21 1b48ff4d2 Updated builds. 88adbcdf6 WebVRManager: Clean up. 2720fbb08 Merge pull request #12803 from dmarcos/parentPoseObject 9ed629301 Check parent of poseObject instead of camera 219f3eb13 Update GLTFLoader.js 15f13bb3c Update GLTFLoader.js 6d9c22a3b Update uniforms only when onWindowResize 881b25b58 Update ProjectionMatrix on change aspect 각 커밋에는 해시를 식별하는 고유 한 SHA-1이 있습니다. 이러한 ID는 커밋 된 타임 라인을 통해 이동하고 커밋을 다시 방문하는 데 사용됩니다. 기본적으로 git log는 현재 선택된 브랜치에 대해서만 커밋을 보여준다. 찾고자하는 커밋이 다른 지사에 있다는 것은 전적으로 가능합니다. git log --branches = *를 실행하여 모든 브랜치에서 모든 커밋을 볼 수 있습니다. git 브랜치 명령은 다른 브랜치를보고 방문하는 데 사용됩니다. 명령을 호출하면, git branch -a는 모든 알려진 브랜치 이름의 목록을 리턴합니다. git log <branch_name>을 사용하여 이러한 분기 이름 중 하나를 기록 할 수 있습니다. 히스토리에서 방문하고자하는 지점에 대한 커밋 참조를 발견하면 git checkout 명령을 사용하여 커밋을 방문 할 수 있습니다. 힘내 체크 아웃은 저장된 스냅 샷을 개발 컴퓨터에 "로드"하는 쉬운 방법입니다. 일반적인 개발 과정에서 HEAD는 대개 마스터 또는 다른 로컬 지사를 가리 킵니다. 그러나 이전 커밋을 체크 아웃 할 때 HEAD는 더 이상 지사를 가리 키지 않습니다. 바로 커밋을 가리 킵니다. 이를 "분리 된 HEAD"상태라고하며 다음과 같이 시각화 할 수 있습니다. co-1.png 이전 파일을 체크 아웃해도 HEAD 포인터는 이동하지 않습니다. 동일한 분기와 동일한 커밋에 남으며 '분리 된 헤드'상태를 피합니다. 그런 다음 다른 모든 변경 사항과 마찬가지로 새 스냅 샷에서 이전 버전의 파일을 커밋 할 수 있습니다. 결과적으로 파일에서 git checkout을 사용하면 개별 파일의 이전 버전으로 되돌릴 수 있습니다. 이 두 모드에 대한 더 자세한 정보는 git checkout 페이지를 방문하십시오. 과거 커밋 보기 이 예에서는 미친 실험을 시작했다고 가정하지만 계속 유지할지 여부는 확실하지 않습니다. 결정을 돕기 위해 실험을 시작하기 전에 프로젝트의 상태를 살펴보고 싶습니다. 먼저, 보려는 리비전의 ID를 찾아야합니다. git log --oneline 프로젝트 내역이 다음과 같다고 가정 해 보겠습니다. b7119f2 Continue doing crazy things 872fa7e Try something crazy a1e8fb5 Make some important changes to hello.txt 435b61d Create hello.txt 9773e52 Initial import git checkout을 사용하여 다음과 같이 "hello.txt에 대한 일부 변경 사항 가져 오기"커밋을 볼 수 있습니다. git checkout a1e8fb5 이렇게하면 작업 디렉토리가 a1e8fb5 커밋의 정확한 상태와 일치하게됩니다. 프로젝트의 현재 상태를 잃지 않고 걱정없이 파일을보고 프로젝트를 컴파일하고 테스트를 실행하고 파일을 편집 할 수 있습니다. 여기서 수행하는 작업은 저장소에 저장되지 않습니다. 계속 개발하려면 프로젝트의 "현재"상태로 돌아 가야합니다. git checkout master 여기서는 기본 마스터 분기에서 개발중인 것으로 가정합니다. 일단 master 브랜치로 돌아 왔으면 git revert 나 git reset을 사용하여 원하지 않는 변경을 취소 할 수 있습니다. Undoing a committed snapshot 기술적으로 커밋을 '실행 취소'하는 여러 가지 전략이 있습니다. 다음 예제는 우리가 다음과 같은 커밋 기록을 가지고 있다고 가정합니다 : git log --oneline 872fa7e Try something crazy a1e8fb5 Make some important changes to hello.txt 435b61d Create hello.txt 9773e52 Initial import 우리는 872fa7e를 실행 취소하는 데 초점을 맞출 것입니다. 어쩌면 일들이 너무 미쳤을 수도 있습니다. How to undo a commit with git checkout git checkout 명령을 사용하여 이전 커밋 인 a1e8fb5를 체크 아웃 할 수 있습니다. 미친 커밋이 발생하기 전에 저장소에 상태를 저장합니다. 특정 커밋을 체크 아웃하면 repo가 "분리 된 헤드"상태가됩니다. 즉, 어떤 지점에서도 더 이상 일하지 않습니다. 분리 된 상태에서, 분기를 확립 된 분기로 다시 변경할 때 사용자가 작성하는 모든 새로운 확약은 고아가됩니다. Git의 가비지 컬렉터가 고아가 된 커밋을 삭제합니다. 가비지 수집기는 구성된 간격으로 실행되고 고아 커밋을 영구적으로 파괴합니다. 고아 커밋이 가비지 수집되지 않게하려면 우리가 지점에 있는지 확인해야합니다. 분리 된 HEAD 상태에서 git checkout -b new_branch_without_crazy_commit을 실행할 수 있습니다. 그러면 new_branch_without_crazy_commit이라는 새 분기가 만들어지고 그 상태로 전환됩니다. repo는 이제 872fa7e 커밋이 더 이상 존재하지 않는 새로운 히스토리 타임 라인에 있습니다. 이 시점에서 우리는 872fa7e 커밋이 더 이상 존재하지 않고 '취소 된'것으로 간주하는이 새로운 분기에 대한 작업을 계속할 수 있습니다. 불행히도, 이전 분기가 필요하다면, 아마도 마스터 브랜치 일 것입니다.이 실행 취소 전략은 적절하지 않습니다. 다른 '실행 취소'전략을 살펴 보겠습니다. 더 많은 정보와 예제는 우리의 심도있는 git checkout 토론을 검토한다. How to undo a public (pushed) commit with git revert 우리가 원래의 커밋 히스토리 예제로 돌아가고 있다고 가정합시다. 872fa7e 커밋을 포함하는 기록. 이번에는 되돌리기 '실행 취소'를 시도해 보겠습니다. git revert HEAD를 실행하면, Git은 마지막 커밋의 역함수로 새로운 커밋을 생성합니다. 이렇게하면 현재 분기 기록에 새 커밋이 추가되고 다음과 같이 표시됩니다. git log --oneline e2f9a78 Revert "Try something crazy" 872fa7e Try something crazy a1e8fb5 Make some important changes to hello.txt 435b61d Create hello.txt 9773e52 Initial import 이 시점에서 우리는 다시 기술적으로 '취소 된'872fa7 커밋을 수행했습니다. 역사적으로 872fa7e가 존재하지만, 새로운 e2f9a78 커밋은 872fa7e의 변경과 반대입니다. 이전의 결제 전략과 달리 동일한 지점을 계속 사용할 수 있습니다. 이 솔루션은 만족스러운 실행 취소입니다. 이것은 공용 공유 리포지토리를 사용하기위한 이상적인 '실행 취소'방법입니다. 큐레이터와 최소한의 Git 히스토리를 유지해야하는 경우이 전략은 만족스럽지 않을 수 있습니다. How to undo a commit with git reset 이 실행 취소 전략에 대해서는 작업 예제를 계속 진행합니다. git reset은 여러 용도와 기능을 가진 광범위한 명령입니다. git reset --hard a1e8fb5를 호출하면 커밋 기록이 지정된 커밋으로 재설정됩니다. git log로 커밋 내역을 검사하면 다음과 같이 표시됩니다. git log --oneline a1e8fb5 Make some important changes to hello.txt 435b61d Create hello.txt 9773e52 Initial import 로그 출력은 e2f9a78 및 872fa7e 커밋이 더 이상 커밋 기록에 존재하지 않음을 나타냅니다. 이 시점에서 우리는 작업을 계속하고 마치 "미친"커밋이 발생하지 않은 것처럼 새로운 커밋을 만들 수 있습니다. 변경 사항을 취소하는이 방법은 기록에 가장 명확한 영향을줍니다. 리셋을 수행하는 것은 로컬 변경에 유용하지만 공유 원격 리포지토리로 작업 할 때 문제를 일으 킵니다. 커밋 872fa7e이 푸시된 공유 저장소가 있고, 해당 저장소에 히스토리가 reset 된 브랜치를 git push 하려고 시도하면 Git이 이를 잡아 오류를 던질 것이다. Git은 푸시 된 브랜치가 커밋이 누락되어 최신 상태가 아니라고 가정합니다. 이러한 시나리오에서 git revert 로 실행을 취소해야 합니다. Undoing the last commit 이전 섹션에서는 커밋을 취소하기위한 다양한 전략에 대해 논의했습니다. 이러한 전략은 모두 최신 커밋에도 적용됩니다. 그러나 어떤 경우에는 마지막 커밋을 제거하거나 재설정 할 필요가 없을 수도 있습니다. 어쩌면 그것은 조숙하게 만들어 졌을지도 모릅니다. 이 경우 가장 최근의 커밋을 수정할 수 있습니다. git add를 사용하여 작업 디렉토리에서 더 많은 변경을하고 커밋을 위해 준비하면 git commit --amend를 실행할 수 있습니다. 이것은 Git에 구성된 시스템 편집기를 열고 마지막 커밋 메시지를 수정할 수있게합니다. 새로운 변경 사항이 수정 된 커밋에 추가됩니다. Undoing uncommitted changes 변경 사항이 저장소 히스토리에 커밋되기 전에 스테이징 색인 및 작업 디렉토리에 살고 있습니다. 이 두 영역에서 변경 사항을 실행 취소해야 할 수도 있습니다. 스테이징 색인과 작업 디렉토리는 내부의 Git 상태 관리 메커니즘입니다. 이 두 메커니즘이 어떻게 작동하는지에 대한 자세한 내용을 보려면 git reset 페이지를 방문하십시오. The working directory 작업 디렉토리는 일반적으로 로컬 파일 시스템과 동기화됩니다. 작업 디렉토리의 변경 사항을 취소하려면 일반적으로 좋아하는 편집기를 사용하는 것처럼 파일을 편집 할 수 있습니다. 힘내는 작업 디렉토리를 관리하는 데 도움이되는 몇 가지 유틸리티를 가지고있다. 작업 디렉토리의 변경을 취소하기위한 편리한 유틸리티 인 git clean 명령이 있습니다. 또한, git reset은 --mixed 또는 --hard 옵션을 사용하여 호출 할 수 있으며 작업 디렉토리에 재설정을 적용합니다. The staging index git add 명령은 스테이징 색인에 변경 사항을 추가하는 데 사용됩니다. Git 재설정은 주로 준비 인덱스 변경 사항을 실행 취소하는 데 사용됩니다. - 혼합 리셋은 보류중인 모든 변경 사항을 스테이징 인덱스에서 작업 디렉토리로 다시 이동시킵니다. Undoing public changes 원격 리포지토리가있는 팀에서 작업 할 때는 변경 사항을 취소 할 때 추가 고려해야합니다. Git 재설정은 일반적으로 '로컬'실행 취소 방법으로 간주되어야합니다. 사설 분기에 대한 변경을 취소 할 때 리셋을 사용해야합니다. 이렇게하면 다른 개발자가 사용하고있는 다른 브랜치에서 커밋을 안전하게 제거 할 수 있습니다. 문제는 공유 분기에서 리셋이 실행될 때 발생하며 그 브랜치는 git push를 사용하여 원격으로 푸시됩니다. 이 시나리오의 경우 Git은 푸시 된 브랜치가 커밋을 잃어 버렸기 때문에 원격 브랜치에 비해 오래된 것으로 인식하여 푸시를 차단할 것이다. 공유 기록을 실행 취소하는 기본 방법은 git revert 입니다. 되돌리기는 공유 기록에서 커밋을 제거하지 않기 때문에 재설정보다 안전합니다. 되돌리기는 실행 취소하려는 커밋을 유지하고 원하지 않는 커밋을 반전하는 새로운 커밋을 만듭니다. 이 방법은 공유 된 원격 공동 작업에서 더 안전합니다. 원격 개발자가 분기를 가져 와서 원하지 않는 커밋을 실행 취소하는 새로운 되돌리기 커밋을 수신 할 수 있기 때문입니다.   Git 가이드

git rm

Git을 시작할 때 가장 많이하는 질문은 "Git이 파일을 더 이상 추적하지 않게하려면 어떻게해야합니까?" git rm 명령은 Git 저장소에서 파일을 제거하는 데 사용됩니다. 그것은 git add 명령의 역으로 생각할 수 있습니다. Overview git rm 명령은 개별 파일 또는 파일 모음을 제거하는 데 사용할 수 있습니다. git rm의 주요 기능은 Git 색인에서 추적 된 파일을 제거하는 것입니다. 또한 git rm을 사용하여 스테이징 색인과 작업 디렉토리에서 파일을 제거 할 수 있습니다. 작업 디렉토리에서만 파일을 제거하는 옵션은 없습니다. 조작중인 파일은 현재 HEAD의 파일과 동일해야합니다. 파일의 HEAD 버전과 스테이징 색인 또는 작업 트리 버전간에 불일치가 있으면 Git이 제거를 차단합니다. 이 블록은 진행중인 변경 사항을 제거하지 못하도록하는 안전 메커니즘입니다. git rm은 브랜치를 제거하지 않는다. 사용법 … 제거 할 대상 파일을 지정합니다. 옵션 값은 개별 파일, 파일로 구분 된 file1 file2 file3 또는 와일드 카드 파일 glob (~. / directory / *) 일 수 있습니다. -f --force -f 옵션은 HEAD의 파일이 스테이징 색인 및 작업 디렉토리의 현재 내용과 일치하도록하기 위해 힘내 기가 만드는 안전성 검사를 무시하는 데 사용됩니다. -n --dry-run "dry run"옵션은 git rm 명령을 실행하지만 실제로 파일을 삭제하지 않는 보호 장치입니다. 대신 제거 된 파일을 출력합니다. -r -r 옵션은 'recursive'의 줄임말입니다. 재귀 적 모드에서 작동 할 때 rm은 대상 디렉토리와 그 디렉토리의 모든 내용을 제거합니다. -- separator 옵션은 파일 이름 목록과 git rm으로 전달되는 인수를 명시 적으로 구별하는 데 사용됩니다. 일부 파일 이름에 다른 옵션과 혼동 될 수있는 구문이있는 경우 유용합니다. --cached 캐시 옵션은 스테이징 색인에서만 제거가 수행되도록 지정합니다. 작업 디렉토리 파일은 그대로 남습니다. --ignore-unmatch 이로 인해 파일이 일치하지 않아도 명령이 0 sigterm 상태로 종료됩니다. 이것은 유닉스 수준의 상태 코드입니다. 코드 0은 명령의 성공적인 호출을 나타냅니다. --ignore-unmatch 옵션은 정상적으로 실패해야하는 더 큰 쉘 스크립트의 일부로 git rm을 사용할 때 도움이 될 수 있습니다. -q --quiet quiet 옵션은 git rm 명령의 출력을 숨 깁니다. 이 명령은 일반적으로 제거 된 각 파일에 대해 한 줄씩 출력합니다. git rm 취소하기 git rm을 실행하는 것은 영구적 인 업데이트가 아닙니다. 이 명령은 스테이징 색인과 작업 디렉토리를 업데이트합니다. 이러한 변경 사항은 새 확약이 작성되고 변경 사항이 확약 내역에 추가 될 때까지 유지되지 않습니다. 즉, 여기있는 변경 사항은 일반적인 Git 명령을 사용하여 "실행 취소"할 수 있음을 의미합니다. git reset HEAD 리셋하면 현재 스테이징 색인과 작업 디렉토리가 HEAD 커밋으로 되돌아갑니다. 이렇게하면 git rm이 실행 취소됩니다. git checkout . 체크 아웃은 동일한 효과를 가지며 HEAD에서 최신 버전의 파일을 복원합니다. git rm이 실행되었고 제거를 지속하는 새로운 커밋이 생성 된 경우 git reflog를 사용하여 git rm 실행 전의 참조를 찾을 수 있습니다. git reflog 사용에 대해 자세히 알아보십시오. git rm 의 영향 git rm 명령은 현재 분기에서만 작동합니다. 제거 이벤트는 작업 디렉토리 W 스테이징 색인 트리에만 적용됩니다. 파일 h 제는 새 확약이 작성 될 때까지 저장소 실행 기록에 보존되지 않습니다. rm 대신 git rm 을 사용해야하는 이유 Git 저장소는 추적중인 파일에서 일반 셸 rm 명령이 실행 된 시점을 인식합니다. 제거를 반영하도록 작업 디렉토리를 업데이트합니다. 제거로 스테이징 색인을 업데이트하지 않습니다. 스테이징 색인에 변경 사항을 추가하려면 제거 된 파일 경로에서 추가 git add 명령을 실행해야합니다. git rm 명령은 작업 디렉토리와 스테이징 색인을 제거와 함께 업데이트한다는 점에서 바로 가기를 수행합니다. 예제 git rm Documentation/\*.txt 이 예에서는 와일드 카드 파일 glob을 사용하여 Documentation 디렉토리의 하위 디렉토리 및 해당 하위 디렉토리의 모든 * .txt 파일을 제거합니다. 이 예에서는 별표 (*)가 슬래시로 이스케이프됩니다. 이것은 셸이 와일드 카드를 확장하지 못하게하는 가드입니다. 그런 다음 와일드 카드는 Documentation / 디렉토리 아래에있는 파일 및 하위 디렉토리의 경로 이름을 확장합니다. git rm -f git-*.sh 더이상 파일시스템에 존재하지 않는 파일 제거하기 "rm 대신 git rm을 사용하는 이유"에서 설명한 것처럼 실제로 git rm은 표준 쉘 rm과 git add를 결합하여 작업 디렉토리에서 파일을 제거하고 해당 제거를 스테이징 색인으로 승격시키는 편의 명령입니다. 표준 쉘 rm 명령 만 사용하여 여러 파일이 제거 된 경우 저장소가 성가신 상태가 될 수 있습니다. 의도적으로 제거 된 모든 파일을 다음 커밋의 일부로 기록하려는 경우 git commit -a는 다음 커밋 준비를 위해 모든 제거 이벤트를 스테이징 인덱스에 추가합니다. 그러나 쉘 rm을 사용하여 제거 된 파일을 지속적으로 제거하려는 경우 다음 명령을 사용하십시오. git diff --name-only --diff-filter=D -z | xargs -0 git rm --cached 이 명령은 작업 디렉토리에서 제거 된 파일 목록을 생성하고 그 목록을 git rm --cached에 저장하여 스테이징 색인을 업데이트합니다. Git 가이드

git revert

revert.png git revert 명령은 '실행 취소'유형 명령으로 간주 될 수 있지만 기존 실행 취소 작업은 아닙니다. 프로젝트 히스토리에서 커밋을 제거하는 대신 커밋에 의해 도입 된 변경 사항을 반전하는 방법을 알아 내고 역순으로 새로운 커밋을 추가합니다. 이것은 Git이 히스토리를 잃어 버리는 것을 방지하며 히스토리의 무결성과 신뢰성있는 공동 작업에 중요합니다. 되돌리기는 프로젝트 내역에서 커밋의 반대를 적용하고자 할 때 사용해야합니다. 예를 들어 버그를 추적하여 단일 커밋으로 도입 된 경우에 유용합니다. 수동으로 들어가서 수정하고 새 스냅 샷을 커밋하는 대신 git 되돌리기를 사용하여 자동으로이 모든 작업을 수행 할 수 있습니다. 동작 방법 git revert 명령은 저장소의 커밋 기록에 대한 변경 사항을 실행 취소하는 데 사용됩니다. git checkout 및 git reset과 같은 다른 '실행 취소'명령은 HEAD를 이동하고 지정된 포인터로 분기 포인터를 분기합니다. Git revert는 또한 지정된 커밋을 취하지 만, git revert는이 커밋에 대한 ref 포인터를 이동시키지 않습니다. 되돌리기 작업은 지정된 커밋을 취하여 해당 커밋에서 변경 사항을 역으로 적용하고 새로운 "되돌리기 커밋"을 만듭니다. 그런 다음 ref 포인터는 새로운 복귀 커밋을 가리 키도록 업데이트되어 지점의 끝으로 지정됩니다. $ mkdir git_revert_test $ cd git_revert_test/ $ git init . Initialized empty Git repository in /git_revert_test/.git/ $ touch demo_file $ git add demo_file $ git commit -am"initial commit" [master (root-commit) 299b15f] initial commit 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 demo_file $ echo "initial content" >> demo_file $ git commit -am"add new content to demo file" [master 3602d88] add new content to demo file n 1 file changed, 1 insertion(+) $ echo "prepended line content" >> demo_file $ git commit -am"prepend content to demo file" [master 86bb32e] prepend content to demo file 1 file changed, 1 insertion(+) $ git log --oneline 86bb32e prepend content to demo file 3602d88 add new content to demo file 299b15f initial commit 여기서는 git_revert_test라는 새로 생성 된 디렉토리에서 repo를 초기화했습니다. demo_file 파일을 추가하고 내용을 두 번 수정 한 repo에 대해 3 번 커밋했습니다. repo 설정 절차가 끝나면 git log를 호출하여 커밋 기록을 표시하고 총 3 개의 커밋을 표시합니다. 이 상태의 repo를 사용하여 git 되돌리기를 시작할 준비가되었습니다. $ git revert HEAD [master b9cd081] Revert "prepend content to demo file" 1 file changed, 1 deletion(-) Git Revert는 커밋 참조가 전달되고 전달되지 않고 실행되지 않을 것으로 기대합니다. 여기서 우리는 HEAD ref를 통과했다. 이렇게하면 최신 커밋을 되돌릴 수 있습니다. 이는 3602d8815dbfa78cd37cd4d189552764b5e96c58을 실행하기 위해 되돌릴 때와 동일한 동작입니다. 병합과 마찬가지로 되돌리기는 새 커밋 메시지를 요구하는 구성된 시스템 편집기를 열 수있는 새로운 커밋을 만듭니다. 커밋 메시지가 입력되고 저장되면 힘내 기능이 작동을 재개합니다. 이제 git log를 사용하여 repo의 상태를 검사하고 이전 로그에 새로운 커밋이 추가되었음을 확인할 수 있습니다. $ git log --oneline 1061e79 Revert "prepend content to demo file" 86bb32e prepend content to demo file 3602d88 add new content to demo file 299b15f initial commit 세 번째 커밋은 되돌리기 후에도 프로젝트 기록에 남아 있습니다. 삭제하는 대신 변경 사항을 취소하기위한 새로운 커밋이 추가되었습니다. 결과적으로 두 번째와 네 번째 커밋은 정확히 같은 코드 기반을 나타내며 세 번째 커밋은 우리가 길을 따라 다시 돌아가고 싶은 경우에 대비하여 우리 역사에 남아 있습니다. 일반적인 옵션 -e --edit 이 옵션은 기본 옵션이므로 지정하지 않아도됩니다. 이 옵션은 구성된 시스템 편집기를 열고 되돌리기를 커밋하기 전에 커밋 메시지를 편집하라는 메시지를 표시합니다. --no-edit 이것은 -e 옵션의 반대입니다. 되돌리기는 편집기를 열지 않습니다. -n --no-commit 이 옵션을 건네면 git revert가 타겟 커밋을 반대로하는 새로운 커밋을 만드는 것을 막을 수 있습니다. 새 커밋을 만드는 대신이 옵션을 사용하면 준비 인덱스 및 작업 디렉터리에 역 변경 사항이 추가됩니다. 이것은 Git이 저장소의 상태를 관리하는 데 사용하는 다른 트리입니다. 자세한 정보는 git reset 페이지를 참조하십시오. Resetting vs. reverting git revert가 단일 커밋을 취소한다는 것을 이해하는 것이 중요합니다. 모든 커밋을 제거함으로써 프로젝트의 이전 상태로 "되돌아 가지"않습니다. 힘내 (Git)에서는 이것을 실제로 리셋 (reset)이라고하며 되돌리기 (revert)라고 부르지 않습니다. revert-1.png 되돌리기에는 재설정보다 두 가지 중요한 이점이 있습니다. 첫째, 공유 저장소에 이미 게시 된 커밋에 대해 "안전한"작업을 수행하는 프로젝트 기록을 변경하지 않습니다. 공유 기록을 변경하는 것이 위험한 이유에 대한 자세한 내용은 [git reset] 페이지를 참조하십시오. 둘째, git revert는 히스토리의 임의의 지점에서 개별 커밋을 대상으로 할 수 있지만 git reset은 현재 커밋에서 뒤로 만 작동 할 수 있습니다. 예를 들어 git reset으로 이전 커밋을 실행 취소하려면 대상 커밋 이후에 발생한 모든 커밋을 제거하고 제거한 다음 모든 커밋을 다시 커밋해야합니다. 말할 필요도없이, 이것은 우아한 실행 취소 솔루션이 아닙니다. git 되돌리기와 다른 '실행 취소'명령의 차이점에 대한 자세한 설명은 재설정, 체크 아웃 및 되돌리기를 참조하십시오. Git 가이드

git clean

clean.png 이 절에서는 git clean 명령에 대해 자세히 설명합니다. 이러한 다른 명령은 이전에 Git 추적 색인에 추가 된 파일에서 작동하지만 git clean 명령은 추적되지 않은 파일에서 작동합니다. 추적 할 수없는 파일은 repo의 작업 디렉토리에서 작성되었지만 아직 git add 명령을 사용하여 저장소의 추적 색인에 추가되지 않은 파일입니다. 추적 된 파일과 추적되지 않은 파일의 차이를보다 잘 보여주기 위해 다음 명령 줄 예제를 참고 하세요. $ mkdir git_clean_test $ cd git_clean_test/ $ git init . Initialized empty Git repository in /Users/kev/code/git_clean_test/.git/ $ echo "tracked" > ./tracked_file $ git add ./tracked_file $ echo "untracked" > ./untracked_file $ mkdir ./untracked_dir && touch ./untracked_dir/file $ git status On branch master Initial commit Changes to be committed: (use "git rm --cached <file>..." to unstage) new file: tracked_file Untracked files: (use "git add <file>..." to include in what will be committed) untracked_dir/ untracked_file 이 예제는 git_clean_test 디렉토리에 새로운 Git 저장소를 생성합니다. 그런 다음, Git 색인에 추가 된 tracked_file을 작성하고, untracked_file이 작성되고 untracked_dir이 작성됩니다. 그런 다음 git status를 호출하여 Git의 추적 상태 및 추적되지 않은 변경 상태를 나타내는 출력을 표시합니다. 이 상태의 저장소를 사용하여 git clean 명령을 실행하여 의도 된 목적을 입증 할 수 있습니다. $ git clean fatal: clean.requireForce defaults to true and neither -i, -n, nor -f given; refusing to clean 이 시점에서 기본 git clean 명령을 실행하면 치명적인 오류가 발생할 수 있습니다. 위의 예는 이것이 어떻게 생겼는지를 보여줍니다. 기본적으로 Git은 시작하기 위해 git clean에 "force"옵션이 전달되도록 전역 적으로 구성됩니다. 이는 중요한 안전 장치입니다. 마지막으로 git clean을 실행하면 실행 취소 할 수 없습니다. 완전히 실행되면 git clean은 명령 줄 rm 유틸리티를 실행하는 것과 마찬가지로 하드 파일 시스템을 삭제합니다. untracked 파일을 실행하기 전에 정말로 삭제하고 싶은지 확인하십시오. 일반적인 옵션과 사용법 기본 git 정리 동작 및 경고에 대한 이전 설명이 주어지면 다음 내용은 다양한 git clean 사용 사례와 해당 작업에 필요한 명령 줄 옵션을 보여줍니다. -n -n 옵션은 git clean의 "dry run"을 수행합니다. 이렇게하면 실제로 파일을 제거하지 않고 어떤 파일을 제거 할 것인지 표시됩니다. 항상 제일 먼저 git clean을 수행하는 것이 가장 좋습니다. 이전에 만든 데모 저장소에서이 옵션을 시연 할 수 있습니다. $ git clean -n Would remove untracked_file git clean 명령을 실행하면 untracked_file이 제거됩니다. untracked_dir은 여기서 출력되지 않습니다. 기본적으로 git clean은 디렉토리에서 재귀 적으로 작동하지 않습니다. 우발적 인 영구 삭제를 방지하는 또 다른 안전 메커니즘입니다. -f or --force force 옵션은 현재 디렉토리에서 untracked 파일의 실제 삭제를 시작합니다. clean.requireForce 구성 옵션을 false로 설정하지 않으면 force가 필요합니다. 이렇게하면 .gitignore에서 지정한 추적되지 않은 폴더 나 파일이 제거되지 않습니다. 이제 우리의 예제 저장소에서 깨끗한 git clean을 실행 해 보겠습니다. $ git clean -f Removing untracked_file 명령은 제거 된 파일을 출력합니다. untracked_file이 제거 된 것을 볼 수 있습니다. 이 시점에서 git status를 실행하거나 ls를 실행하면 untracked_file이 삭제되었고 아무 것도 발견되지 않는다는 것을 알 수 있습니다. 기본적으로 git clean -f는 현재 디렉토리가 아닌 모든 파일에 대해 작동합니다. 또한 특정 파일을 제거하는 -f 옵션과 함께 <path> 값을 전달할 수 있습니다. git clean -f <path> -d include directories -d 옵션은 git clean에게 추적되지 않은 디렉토리를 지우고 싶다고 알려주며 기본적으로 디렉토리를 무시합니다. 앞의 예제에 -d 옵션을 추가 할 수 있습니다. $ git clean -dn Would remove untracked_dir/ $ git clean -df Removing untracked_dir/ 여기서 우리는 untracked_dir을 출력하는 -dn 조합을 사용하여 'dry run'을 실행했습니다. 그런 다음 강제 정리를 실행하고 untracked_dir이 제거 된 출력을 수신합니다. -x force removal of ignored files 일반적인 소프트웨어 릴리스 패턴은 리포지토리 추적 색인에 커밋되지 않은 빌드 또는 배포 디렉토리를 갖는 것입니다. 빌드 디렉토리에는 커밋 된 소스 코드에서 생성 된 임시 빌드 아티팩트가 포함됩니다. 이 빌드 디렉토리는 대개 저장소 .gitignore 파일에 추가됩니다. 추적되지 않은 다른 파일로도이 디렉토리를 정리하는 것이 편리 할 수 있습니다. -x 옵션은 git clean에 무시 된 파일을 포함하도록 지시합니다. 이전의 git clean 호출과 마찬가지로, 마지막 삭제 전에 먼저 'dry run'을 실행하는 것이 가장 좋습니다. -x 옵션은 프로젝트 빌드와 관련된 모든 파일에 적용됩니다. 이것은 ./.idea IDE 구성 파일과 같은 의도하지 않은 것일 수 있습니다. git clean -xf -d 옵션과 마찬가지로 -x는 다른 옵션과 함께 전달되고 작성 될 수 있습니다. 이 예제는 -f 옵션과 함께 현재 디렉토리에서 추적되지 않은 파일과 Git이 일반적으로 무시하는 파일을 제거하는 방법을 보여줍니다. Interactive mode or git clean interactive 지금까지 살펴본 ad-hoc 명령 줄 실행 외에도 git clean에는 -i 옵션을 전달하여 시작할 수있는 "대화 형"모드가 있습니다. 이 문서가 소개 된 예제 repo를 다시 살펴 보겠습니다. 초기 상태에서는 대화식 클린 세션을 시작합니다. $ git clean -di Would remove the following items: untracked_dir/ untracked_file *** Commands *** 1: clean 2: filter by pattern 3: select by numbers 4: ask each 5: quit 6: help What now> -d 옵션을 사용하여 대화식 세션을 시작 했으므로 untracked_dir에도 적용됩니다. 대화식 모드는 명령을 추적 할 수없는 파일에 적용 할 것을 요구하는 What now> 프롬프트를 표시합니다. 명령 자체는 상당히 자명합니다. 우리는 명령 6 : help로 시작하여 각각을 임의의 순서로 간략하게 살펴볼 것입니다. 명령 6을 선택하면 다른 명령이 더 설명됩니다. What now> 6 clean - start cleaning filter by pattern - exclude items from deletion select by numbers - select items to be deleted by numbers ask each - confirm each deletion (like "rm -i") quit - stop cleaning help - this screen ? - help for prompt selection 5: quit 똑바로 앞으로 대화 형 세션을 종료합니다. 1: clean 표시된 항목을 삭제합니다. 이 시점에서 1 : clean을 실행하면 untracked_dir / untracked_file이 제거됩니다. 4: ask each untracked 각 파일을 반복하고 삭제를 묻는 Y / N 프롬프트를 표시합니다. 다음과 같이 보입니다. *** Commands *** 1: clean 2: filter by pattern 3: select by numbers 4: ask each 5: quit 6: help What now> 4 Remove untracked_dir/ [y/N]? N Remove untracked_file [y/N]? N 2: filter by pattern Will display an additional prompt that takes input used to filter the list of untracked files. Would remove the following items: untracked_dir/ untracked_file *** Commands *** 1: clean 2: filter by pattern 3: select by numbers 4: ask each 5: quit 6: help What now> 2 untracked_dir/ untracked_file Input ignore patterns>> *_file untracked_dir/ 여기서 우리는 * _file 와일드 카드 패턴을 입력하여 untracked 파일 목록을 untracked_dir로 제한합니다. 3: select by numbers 명령 2와 마찬가지로 명령 3은 추적되지 않은 파일 이름의 목록을 수정합니다. 대화식 세션에서는 추적 할 수없는 파일 이름에 해당하는 번호를 묻습니다. Would remove the following items: untracked_dir/ untracked_file *** Commands *** 1: clean 2: filter by pattern 3: select by numbers 4: ask each 5: quit 6: help What now> 3 1: untracked_dir/ 2: untracked_file Select items to delete>> 2 1: untracked_dir/ * 2: untracked_file Select items to delete>> Would remove the following item: untracked_file *** Commands *** 1: clean 2: filter by pattern 3: select by numbers 4: ask each 5: quit 6: help Git 가이드

git reset

git reset 명령은 변경 사항을 실행 취소하기위한 복잡하고 다양한 도구입니다. 세 가지 기본 형식의 호출이 있습니다. 이러한 형식은 명령 줄 인수 --soft, --mixed, --hard에 해당합니다. 세 개의 인수는 각각 Git의 세 가지 내부 상태 관리 메커니즘 인 HEAD (The Commit Tree), 스테이징 색인 및 작업 디렉토리에 해당합니다. Git reset & three trees of Git git reset 사용법을 제대로 이해하려면 Git의 내부 상태 관리 시스템을 먼저 이해해야합니다. 때로는 이러한 메커니즘을 Git의 "three trees"라고 부릅니다. 나무는 엄격하게 전통적인 트리 데이터 구조가 아니므로 잘못된 이름 일 수 있습니다. 그러나 Git은 편집 타임 라인을 추적하는 데 사용하는 노드 및 포인터 기반 데이터 구조입니다. 이러한 메커니즘을 증명하는 가장 좋은 방법은 리포지토리에 변경 집합을 만들어 세 개의 트리를 따라 이동하는 것입니다. Undo a change with git reset 시작하려면 역사에서 가장 최근 커밋을 실행 취소하십시오. 이 경우 Bitbucket의 CI / CD 솔루션 파이프 라인을 활성화했지만 스크립트가 올바르지 않다는 것을 알았습니다. 터미널 창에 git log --oneline을 입력하십시오. 두 번째 커밋의 커밋 해시를 로그에 복사합니다 (52f823c). 그런 다음 q를 눌러 로그를 종료합니다. git reset --soft 52f823c를 터미널 창에 입력하십시오. 명령이 성공하면 명령이 백그라운드에서 실행됩니다. 그게 전부입니다. 당신은 당신의 첫 번째 변화를 취소했습니다. 이제이 작업의 결과를 보도록하겠습니다. 터미널 창에 git status를 입력하면 커밋이 취소되었고 커밋되지 않은 변경 사항이 표시됩니다. 다음과 같이 보일 것입니다 : $ git status On branch master Your branch is behind 'origin/master' by 1 commit, and can be fast-forwarded. (use "git pull" to update your local branch) Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: bitbucket-pipelines.yml Enter git log --oneline in your terminal window. You should see something like this: $ git log --oneline 52f823c repeated quote to show how a change moves through the process 4801b87 Merged in changes (pull request #6) 1a6a403 myquote edited online with Bitbucket 3b29606 (origin/changes) myquote2.html edited online with Bitbucket 8b236d9 myquote edited online with Bitbucket 235b9a7 testing prs c5826da more changes 43a87f4 remivng d5c4c62 a few small changes 23a7476 Merged in new-feature2 (pull request #3) 5cc4e1e add a commit message cbbb5d6 trying a thing 438f956 adding section for permissions and cleaning up some formatting 23251c1 updated snipptes.xml organization into resources. other files misc changes 3f630f8 Adding file to track changes ... 분기의 새로운 HEAD가 사용자가 원하는대로 커밋 52f823c임을 알 수 있습니다. q를 눌러 로그를 종료하십시오. 간단한 재설정을 수행하는 방법을 배웠으니 이제 좀 더 복잡한 것을 시도해보십시오. 터미널을 열어 두십시오. Undo several changes with git reset 당겨 받기 요청 # 6 (4801b87)을 다시 작성해야하고 git reset 명령을 사용할 때 HEAD가 1a6a403을 커밋하도록 재설정해야한다는 사실을 깨닫게되었다고 가정 해 보겠습니다. git log --online을 입력하십시오. 실행 취소하려는 변경 사항이있는 끌어 오기 요청 # 6 바로 아래 커밋 인 커밋 해시 1a6a403 (Bitbucket을 사용하여 온라인으로 편집 된 myquote)을 복사합니다. 터미널 창에 git reset 1a6a403을 입력하십시오. 출력은 다음과 같이 보일 것입니다 : $ git reset 1a6a403 Unstaged changes after reset: M README.md M myquote2.html 변경 사항이 현재 커밋되지 않은 상태에 있음을 알 수 있습니다. 이는 이제 프로젝트 기록과 준비 영역에서 몇 가지 변경 사항을 제거했음을 의미합니다. Enter git status in your terminal window. The output should look something like this: $ git status On branch master Your branch is behind 'origin/master' by 6 commits, and can be fast-forwarded. (use "git pull" to update your local branch) Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: README.md modified: myquote2.html Untracked files: (use "git add <file>..." to include in what will be committed) bitbucket-pipelines.yml no changes added to commit (use "git add" and/or "git commit -a") 이제 우리가 undid (bitbucket-pipelines.yml 파일)의 첫 번째 변경 사항이 git에서 완전히 추적 할 수 없음을 알 수 있습니다. git reset을 호출하면 브랜치의 헤드와 git의 추적 영역 또는 인덱스 영역 모두에서 변경 사항이 제거되기 때문입니다. 기본 프로세스는 여기에서 다룰 수있는 것보다 조금 복잡합니다. git reset에서 더 많은 것을 읽을 수 있습니다. Enter git log --oneline in your terminal window. 1a6a403 myquote edited online with Bitbucket 8b236d9 myquote edited online with Bitbucket 43a87f4 remivng d5c4c62 a few small changes 23a7476 Merged in new-feature2 (pull request #3) 5cc4e1e add a commit message cbbb5d6 trying a thing 438f956 adding section for permissions and cleaning up some formatting 23251c1 updated snipptes.xml organization into resources. other files misc changes 3f630f8 Adding file to track changes e52470d README.md edited online with Bitbucket e2fad94 README.md edited online with Bitbucket 592f84f Merge branch 'master' into new-feature2 Merge branch especially if it merges an updated upstream into a topic branch. 7d0bab8 added a line 879f965 adding to the quote file 8994332 Merged in HOT-235 (pull request #2) b4a0b43 removed sarcastic remarks because they violate policy. b5f5199 myquote2.html created online with Bitbucket b851618 adding my first file 5b43509 writing and using tests 로그 출력은 커밋 내역이 수정되어 커밋 1a6a403에서 시작됨을 보여줍니다. 데모 및 추가 예제를 위해 방금 수행 한 재설정을 실행 취소하려고한다고 가정 해 봅시다. 추가 고려 사항을 고려한 후에 풀 요청 # 6의 내용을 유지하려고했습니다. Pushing resets to Remote Git reset은 변경 을 취소하는 방법 중 하나입니다. git reset은 일반적으로 변경 사항을 취소하기위한 '안전하지 않은'옵션으로 간주됩니다. 격리 된 코드에서 로컬로 작업 할 때 재설정은 좋지만 팀 구성원과 공유 할 경우 위험 해집니다. 원격 팀으로 리셋 된 지점을 공유하려면 '강제 푸시'가 실행되어야합니다. 'forced push'는 git push -f를 실행하여 시작됩니다. 강제 푸시는 푸시 시점 이후에 만들어진 branch의 모든 기록을 삭제합니다. '안전하지 않은'시나리오의 예는 다음과 같습니다. Dev A는 새로운 기능을 개발하는 브랜치에서 작업하고 있습니다. Dev B는 별도의 기능을 개발하는 동일한 브랜치에서 작업하고 있습니다. Dev B는 Dev A와 Dev B가 모두 작동하기 전에 브랜치를 이전 상태로 재설정하기로 결정합니다. Dev B 그러면 강제로 재설정 브랜치를 원격 저장소로 푸시합니다. Dev A는 분기를 가져 와서 업데이트를받습니다. git pull 동안 Dev A는 강제 업데이트를받습니다. 이것은 기능 작업이 완료되고 커밋을 잃기 전에 Dev A의 로컬 브랜치를 원래대로 되돌립니다. Undo a git reset 지금까지 우리는 git commit에 Sha 해쉬를 보내고있다. 이제 git log 출력에 재설정 된 커밋이 없습니다. 어떻게 그 커밋을 되 찾을 수 있습니까? Git은 커밋을 지우지 않습니다. 또한 git은 "reflog"라고 불리는 모든 ref 동작의 개별 로그를 저장합니다. git reflog를 실행하여 reflog를 검사 할 수 있습니다. 1a6a403 HEAD@{0}: reset: moving to 1a6a403 1f08a70 HEAD@{1}: reset: moving to origin/master 1f08a70 HEAD@{2}: clone: from git@bitbucket.org:dans9190/tutorial-documentation-tests.git git reflog의 결과는 위와 비슷해야합니다. 레포에서 수행 한 내역을 볼 수 있습니다. 맨 위 줄은 풀 요청 # 6을 재설정하기 위해 수행 한 재설정에 대한 참조입니다. 이제 풀 리퀘스트 # 6을 리셋하기 위해 리셋을 리셋하자. 이 reflog 출력의 두 번째 열은 repo에서 수행하는 수정 작업에 대한 참조 포인터를 나타냅니다. 여기서 HEAD @ {0}은 이전에 실행 한 재설정 명령에 대한 참조입니다. 리셋 명령을 회신하지 않으려면 HEAD @ {1} (으)로 리포를 복원하십시오. $ git reset --hard HEAD@{1} HEAD is now at 1f08a70 Initial Bitbucket Pipelines configuration 이제 git log --oneline을 사용하여 repos commit history를 살펴 보겠습니다: $git log --online 1f08a70 Initial Bitbucket Pipelines configuration 52f823c repeated quote to show how a change moves through the process 4801b87 Merged in changes (pull request #6) 1a6a403 myquote edited online with Bitbucket 3b29606 myquote2.html edited online with Bitbucket 8b236d9 myquote edited online with Bitbucket 235b9a7 testing prs c5826da more changes 43a87f4 remivng d5c4c62 a few small changes 23a7476 Merged in new-feature2 (pull request #3) 5cc4e1e add a commit message cbbb5d6 trying a thing 438f956 adding section for permissions and cleaning up some formatting 23251c1 updated snipptes.xml organization into resources. other files misc changes 3f630f8 Adding file to track changes e52470d README.md edited online with Bitbucket e2fad94 README.md edited online with Bitbucket 592f84f Merge branch 'master' into new-feature2 Merge branch especially if it merges an updated upstream into a topic branch. 7d0bab8 added a line : 여기서 우리는 repo의 커밋 내역이 이전 버전으로 복원되었음을 알 수 있습니다. 우리는 4801b87이 첫 번째 재설정 작업에서 손실 된 것처럼 보였다고하더라도이를 복구 할 수 있음을 알 수 있습니다. git reflog는 저장소의 변경 사항을 취소하기위한 강력한 도구입니다. 자세한 내용은 git reflog 페이지에서 자세히 알아보십시오. Git 가이드

git config

이 문서에서는 git config 명령에 대해 자세히 살펴볼 것입니다. 저장소 설정 페이지에서 git config 사용법에 대해 간략히 설명했습니다. git config 명령은 전역 또는 로컬 프로젝트 수준에서 Git 구성 값을 설정하는 데 사용되는 편리한 기능입니다. 이러한 구성 수준은 .gitconfig 텍스트 파일에 해당합니다. git config를 실행하면 설정 텍스트 파일이 수정됩니다. 이메일, 사용자 이름 및 에디터와 같은 일반적인 구성 설정을 다루겠습니다. 우리는 자주 사용하는 Git 작업에 대한 바로 가기를 만들 수있는 Git 별칭에 대해 설명합니다. git config와 다양한 Git 구성 설정에 익숙해지면 강력하고 사용자 정의 된 Git 워크 플로우를 만들 수 있습니다. 사용법 git config의 가장 기본적인 사용 예는 구성 이름을 사용하여 그 이름에 설정된 값을 표시하는 것입니다. 구성 이름은 계층 구조에 따라 '섹션'과 '키'로 구성된 점으로 구분 된 문자열입니다. 예 : user.email git config user.email 이 예에서 전자 메일은 사용자 구성 블록의 하위 속성입니다. Git이 로컬에서 작성한 커밋과 연결할 전자 메일 주소를 반환합니다. git config levels and files git config 사용법을 더 자세히 설명하기 전에 잠시 시간을내어 구성 단계를 살펴 보겠습니다. git config 명령은 작동 할 구성 수준을 지정하는 인수를 허용 할 수 있습니다. 다음 구성 단계를 사용할 수 있습니다. --local 기본적으로 git config는 설정 옵션이 전달되지 않으면 로컬 레벨에 기록합니다. 로컬 레벨 설정은 git config가 호출 된 컨텍스트 저장소에 적용됩니다. 로컬 설정 값은 repo의 .git 디렉토리에있는 파일에 저장됩니다 : .git / config  --global 전역 레벨 구성은 사용자별로 다르기 때문에 운영 체제 사용자에게 적용됩니다. 전역 구성 값은 사용자의 홈 디렉토리에있는 파일에 저장됩니다. ~ /.gitconfig는 유닉스 시스템에서는 C : \ Users \ <username> \. gitconfig in windows  --system 시스템 레벨 구성은 전체 시스템에 적용됩니다. 여기에는 운영 체제의 모든 사용자와 모든 repos가 포함됩니다. 시스템 레벨 설정 파일은 시스템 루트 경로 밖의 gitconfig 파일에 있습니다. 유닉스 시스템에서는 $ (prefix) / etc / gitconfig. Windows에서이 파일은 Windows XP에서는 C : \ Documents and Settings \ All Users \ Application Data \ Git \ config, Windows Vista에서는 C : \ ProgramData \ Git \ config에 있습니다. 따라서 구성 수준의 우선 순위는 로컬, 글로벌, 시스템입니다. 이것은 구성 값을 찾을 때 힘내는 로컬 레벨에서 시작하여 시스템 레벨까지 버블 링된다는 것을 의미합니다. 변수 설정 git config에 대해 이미 알고있는 것에 대해 살펴보면서 값을 작성하는 예제를 살펴 보겠습니다. git config --global user.email "developer@curvc.com" 이 예에서는 값 developer@curvc.com mailto:developer@curvc.com을 구성 이름 user.email에 씁니다. 이 값이 현재 운영 체제 사용자에 대해 설정되도록 --global 플래그를 사용합니다. git config editor - core.editor 많은 Git 명령은 추가 입력을 요구하는 텍스트 편집기를 시작합니다. git config의 가장 일반적인 사용 사례 중 하나는 힘쓴 편집자가 사용해야하는 구성입니다. 다음은 인기있는 편집기와 일치하는 git config 명령의 표입니다. Editor config command Atom ~ git config --global core.editor "atom --wait"~ emacs ~ git config --global core.editor "emacs"~ nano ~ git config --global core.editor "nano -w"~ vim ~ git config --global core.editor "vim"~ Sublime Text (Mac) ~ git config --global core.editor "subl -n -w"~ Sublime Text (Win, 32-bit install) ~ git config --global core.editor "'c:/program files (x86)/sublime text 3/sublimetext.exe' -w"~ Sublime Text (Win, 64-bit install) ~ git config --global core.editor "'c:/program files/sublime text 3/sublimetext.exe' -w"~ Textmate ~ git config --global core.editor "mate -w"~ Merge tools 병합이 충돌하는 경우 Git은 "병합 도구"를 실행합니다. 기본적으로 Git은 일반적인 유닉스 diff 프로그램의 내부 구현을 사용한다. 내부 Git diff는 최소한의 병합 충돌 뷰어입니다. 대신 사용할 수있는 외부 타사 병합 충돌 해결 방법이 많이 있습니다. 다양한 병합 도구와 구성에 대한 개요는 Git과의 충돌을 해결하기위한 팁과 도구에 대한 가이드를 참조하십시오. git config --global merge.tool kdiff3 Colored outputs Git은 신속하게 힘내 출력을 읽는 데 도움이 색깔 터미널 출력을 지원합니다. Git 출력을 맞춤 설정하여 맞춤 설정된 색상 테마를 사용할 수 있습니다. git config 명령은이 색상 값을 설정하는 데 사용됩니다. color.ui 이것은 Git 색상의 마스터 변수입니다. false로 설정하면 Git의 컬러 터미널 출력이 모두 비활성화됩니다. git config --global color.ui false 기본적으로 color.ui는 auto로 설정되어 즉각적인 터미널 출력 스트림에 색상을 적용합니다. 자동 설정은 출력 스트림이 파일로 리디렉션되거나 다른 프로세스로 파이프되는 경우 색상 코드 출력을 생략합니다. color.ui 값을 always로 설정하면 출력 스트림을 파일이나 파이프로 리디렉션 할 때 색상 코드 출력도 적용됩니다. 수신 파이프가 색으로 구분 된 입력을 기대하지 않을 수 있으므로 의도하지 않은 문제가 발생할 수 있습니다. Git color values color.ui 외에도 다른 많은 세분화 된 색상 설정이 있습니다. color.ui와 마찬가지로이 색상 설정은 모두 false, auto 또는 always로 설정할 수 있습니다. 이 색상 설정에는 특정 색상 값 세트가있을 수도 있습니다. 지원되는 색상 값의 예는 다음과 같습니다. normal black red green yellow blue magenta cyan white 색상은 # ff0000과 같은 16 진수 색상 코드 또는 터미널에서 지원하는 경우 ANSI 256 색상 값으로 지정할 수도 있습니다. Git color configuration settings 1. color.branch Git 분기 명령의 출력 색상을 구성합니다. 2. color.branch.<slot>  이 값은 Git 브랜치 출력에도 적용됩니다. <slot>은 다음 중 하나입니다. current : 현재 브랜치 local : 로컬 브랜치 remote : 원격 지점 참조 ref/remotes upstream : 업스트림 tracking branch plain : 다른 ref 3. color.diff git diff, git log 및 git show 출력에 색상 적용 4. color.diff.<slot>  color.diff 아래에 <slot> 값을 설정하면 패치의 어느 부분에 특정 색상을 사용할지 알려줍니다. context : diff의 문맥 텍스트. 힘내 맥락은 변화를 강조하는 diff 또는 패치에 표시된 텍스트 내용의 줄입니다. plain : 문맥의 동의어 meta : diff의 메타 정보에 색상을 적용합니다. frag : 색을 "hunk header"또는 "hunk header의 기능"에 적용합니다. old : diff에서 제거 된 선에 색상을 적용합니다. new : diff의 추가 된 라인을 색칠합니다. 커밋 (commit) : diff에서 헤더 색상을 커밋합니다. 공백 : diff에있는 공백 오류의 색상을 설정합니다. 5. color.decorate.<slot>  git log --decorate 출력의 색상을 사용자 정의하십시오. 지원되는 <slot> 값은 branch, remoteBranch, tag, stash 또는 HEAD입니다. 로컬 브랜치, 원격 추적 분기, 태그, 숨겨진 변경 사항 및 HEAD에 각각 적용 가능합니다. 6. color.grep git grep의 출력에 색상을 적용합니다. 7. color.grep.<slot>  git grep에도 적용됩니다. <slot> 변수는 grep 출력의 어느 부분에 색상을 적용 할지를 지정합니다. 컨텍스트 : 컨텍스트 라인에서 일치하지 않는 텍스트 filename : 파일 이름 접두사 함수 : 함수 이름 행 linenumber : 줄 번호 접두사 일치 : 일치하는 텍스트 matchContext : 컨텍스트 라인에서 일치하는 텍스트 matchSelected : 선택한 줄의 일치하는 텍스트 selected : 선택한 줄에서 일치하지 않는 텍스트 구분 기호 : 한 줄에있는 필드 사이의 구분 기호 (:, - 및 =) 및 헌크 (-) 사이의 구분 기호 8. color.interactive  이 변수는 대화 형 프롬프트 및 표시에 색상을 적용합니다. 예는 git add --interactive 및 git clean입니다. --interactive 9. color.interactive.<slot>  더 구체적인 "대화 형 출력"을 목표로 지정할 수있는 <slot> 변수가 있습니다. 사용 가능한 <slot> 값은 prompt, header, help, error입니다. 각각은 해당 대화식 출력에서 작동합니다. 10. color.pager 호출기가 사용 중일 때 유색 출력을 활성화 또는 비활성화합니다. 11. color.showBranch git show branch 명령의 컬러 출력을 활성화 또는 비활성화합니다. 12. color.status  Git 상태에 대한 색상 출력을 활성화 또는 비활성화하는 부울 값입니다. 13. color.status.<slot> 지정된 자식 상태 요소에 대한 맞춤 색상을 지정하는 데 사용됩니다. <slot>은 다음 값을 지원합니다. header 상태 영역의 헤더 텍스트를 대상으로합니다. added or updated 추가되었지만 커밋되지 않은 두 대상 파일 changed 수정되었지만 git 인덱스에 추가되지 않은 파일을 대상으로합니다. untracked Git에 의해 추적되지 않는 파일을 대상으로합니다. branch 현재 분기에 색상을 적용합니다. nobranch "분기 없음"경고가 표시된 색상 unmerged 변경 사항이 병합되지 않은 색상 파일 Aliases 운영 체제 명령 줄에서 별칭 개념을 잘 알고있을 수 있습니다. 그렇지 않은 경우, 더 긴 명령이나 결합 된 명령으로 확장 할 명령을 정의하는 사용자 지정 바로 가기입니다. 별칭을 사용하면 자주 사용하는 명령을 입력하는 데 드는 시간과 에너지 비용을 절약 할 수 있습니다. 힘내 자체 별칭 시스템을 제공합니다. Git 별칭의 일반적인 사용 예는 커밋 명령을 줄이는 것입니다. 힘내 별칭은 힘내 설정 파일에 저장되어있다. 즉, git config 명령을 사용하여 별칭을 구성 할 수 있습니다. git config --global alias.ci commit 이 예는 git commit 명령에 대한 ci 별명을 작성합니다. 그런 다음 git ci를 실행하여 git commit을 호출 할 수 있습니다. 별칭은 다른 별칭을 참조하여 강력한 콤보를 만들 수도 있습니다. git config --global alias.amend ci --amend 이 예제는 ci 별명을 --amend flag를 사용하는 새 별명으로 작성하는 별명 수정을 작성합니다. Formatting & whitespace Git은 git diff를 사용할 때 공백 문제를 강조 표시하도록 구성 할 수있는 여러 "공백"기능을 가지고 있습니다. 공백 문제는 구성된 색상 color.diff.whitespace를 사용하여 강조 표시됩니다. 기본적으로 사용 가능한 기능은 다음과 같습니다. blank-at-eol :하이라이트 라인 엔딩에서 고아 공백 space-before-tab :줄을 들여 쓰기 할 때 탭 문자 앞에 나타나는 공백 문자를 강조 표시합니다. blank-at-eof :파일 끝에 삽입 된 빈 줄을 강조합니다. 다음 기능은 기본적으로 사용하지 않도록 설정되어 있습니다. indent-with-non-tab: 탭 대신 공백으로 들여 쓰는 줄을 강조 표시합니다. tab-in-indent :초기 탭 들여 쓰기를 오류로 강조 표시합니다. tailing-space :blank-at-eol과 blank-at-eof 모두에 대한 줄임말입니다. cr-at-eol :줄 끝에서 캐리지 리턴을 강조 표시합니다. tabwidth = <n> :탭이 차지하는 문자 위치의 수를 정의합니다. 기본값은 8입니다. 허용되는 값은 1-63입니다. Git 가이드

git clone

git clone 명령을 자세히 살펴 보겠습니다. git clone은 기존 저장소를 대상으로하고 대상 저장소의 복제본 또는 복사본을 만드는 데 사용되는 Git 명령 줄 유틸리티입니다. 이 페이지에서는 확장 구성 옵션과 git clone의 일반적인 사용 사례에 대해 설명합니다. 여기서 다루는 몇 가지 사항은 다음과 같습니다. 로컬 또는 원격 저장소 복제 원시 저장소 복제 얕은 옵션을 사용하여 저장소를 부분적으로 복제 URL 구문 및 지원 프로토콜 이 페이지는보다 복잡한 복제 및 구성 시나리오를 탐색합니다. 목적: 저장소 간 협업 (작업을 위한 저장소 복제) 프로젝트가 중앙 저장소에 이미 설정된 경우 git clone 명령은 사용자가 개발 복사본을 얻는 가장 일반적인 방법입니다. git init과 마찬가지로, clone은 일반적으로 일회성 작업입니다. 개발자가 작업 복사본을 얻으면 모든 버전 제어 작업과 공동 작업이 로컬 저장소를 통해 관리됩니다. 저장소 간 협업 Git의 "working copy"에 대한 아이디어가 SVN 저장소에서 코드를 체크 아웃하여 얻은 작업 카피와 매우 다르다는 것을 이해하는 것이 중요합니다. SVN과는 달리, Git은 작업 카피와 중앙 저장소를 구별하지 않는다. 그것들은 모두 본격적인 Git 저장소이다. 이것은 Git과 SVN과 근본적으로 다른 협력을 만든다. SVN이 중앙 저장소와 작업 사본 사이의 관계에 의존하는 반면, Git의 공동 작업 모델은 저장소와 저장소 간의 상호 작용을 기반으로합니다. 작업 복사본을 SVN의 중앙 저장소로 검사하는 대신 한 저장소에서 다른 저장소로 커밋을 push 하거나 pull 합니다. 03.png 04.png 물론, Git repos라는 특별한 의미를주는 것을 막을 수있는 방법은 없습니다. 예를 들어 Git repo를 "중앙"저장소로 지정하면 Git을 사용하여 중앙 집중식 워크 플로를 복제 할 수 있습니다. 요컨대, 이것은 VCS 자체에 내장되어 있지 않고 규칙을 통해 수행됩니다. 사용법 git clone은 주로 기존 repo를 가리키고 다른 위치의 새 디렉토리에서 해당 repo의 복제본 또는 복사본을 만드는 데 주로 사용됩니다. 원래 저장소는 로컬 파일 시스템이나 원격 머신이 액세스 할 수있는 지원 프로토콜에 위치 할 수 있습니다. git clone 명령은 기존 Git 저장소를 복사합니다. 이것은 일종의 "작업 카피 (working copy)"가 본래의 저장소를 가지고 있다는 것을 제외하고는 SVN 체크 아웃과 비슷합니다. 그것은 자체 히스토리를 가지고 있고, 자체 파일을 관리하며, 원래 저장소와 완전히 격리 된 환경입니다. 편의상 복제는 원래 저장소로 다시 향하는 "origin"이라는 원격 연결을 자동으로 만듭니다. 따라서 중앙 저장소와 쉽게 상호 작용할 수 있습니다. 이 자동 연결은 refs / remotes / origin에서 원격 지점 HEAD에 Git 참조를 만들고 remote.origin.url 및 remote.origin.fetch 구성 변수를 초기화하여 설정됩니다. git clone 사용 예제는 저장소 가이드 설정에서 찾을 수 있습니다. 아래 예제는 SSH 사용자 이름 john을 사용하여 example.com http://example.com에 액세스 할 수있는 서버에 저장된 중앙 저장소의 로컬 복사본을 얻는 방법을 보여줍니다. git clone ssh://john@example.com/path/to/my-project.git cd my-project # Start working on the project 첫 번째 명령은 로컬 컴퓨터의 my-project 폴더에있는 새 Git 저장소를 초기화하고 중앙 저장소의 내용으로 채 웁니다. 그런 다음 프로젝트에 들어가서 파일 편집, 스냅 샷 작성 및 다른 저장소와의 상호 작용을 시작할 수 있습니다. 또한 .git 확장자는 복제 된 저장소에서 생략됩니다. 이것은 로컬 복사본의 베어 메어가 아닌 상태를 반영합니다. 폴더에 복제하기 git clone <repo> <directory> <repo>에있는 저장소를 ~ <directory>라는 폴더에 복제하십시오! 로컬 컴퓨터에서. 복제 대상 테그 설정하기 git clone --branch <tag> <repo> <repo>에있는 저장소를 복제하고 <tag>에 대한 참조 만 복제하십시오. Shallow clone git clone -depth=1 <repo> <repo>에있는 저장소를 복제하고 옵션 깊이 = 1로 지정된 커밋의 이력 이 예에서는 <repo>의 복제가 만들어지고 가장 최근의 커밋 만 새 복제 된 Repo에 포함됩니다. 얕은 복제는 광범위한 커밋 내역이있는 repos로 작업 할 때 가장 유용합니다. 광범위한 커밋 내역으로 인해 디스크 공간 사용 제한 및 복제시 긴 대기 시간과 같은 확장 문제가 발생할 수 있습니다. 얕은 복제는 이러한 확장 문제를 완화하는 데 도움이 될 수 있습니다. 구성 옵션 git clone -branch -branch 인수를 사용하면 원격 HEAD가 가리키는 분기 (대개 마스터 분기) 대신 복제 할 특정 분기를 지정할 수 있습니다. 또한 동일한 효과를 위해 분기 대신 태그를 전달할 수 있습니다. git clone -branch new_feature git://remoterepository.git 위의 예제는 원격 Git 저장소에서 new_feature 분기 만 복제합니다. 이는 저장소의 HEAD ref 파일을 다운로드하고 필요한 ref를 추가로 가져와야하는 시간을 절약 할 수있는 순전히 유틸리티입니다. git clone -mirror vs. git clone -bare git clone --bare git init --bare와 비슷하게 -bare 인수가 git clone에 전달되면 원격 저장소의 복사본은 생략 된 작업 디렉토리로 만들어집니다. 즉, 리포지토리는 푸시 및 푸시가 가능하지만 직접 편집 할 수없는 프로젝트의 기록으로 설정됩니다. 또한 repo에 대한 원격 브랜치는 -bare 저장소로 구성되지 않습니다. git init --bare와 마찬가지로 개발자가 직접 편집하지 않는 호스트 저장소를 만드는 데 사용됩니다. git clone --mirror --mirror 인수를 전달하면 암시 적으로 --bare 인수도 전달됩니다. 즉, --bare의 동작은 --mirror에 의해 상속됩니다. 편집 가능한 작업 파일이없는 맨 페이지가 생성되었습니다. 또한 --mirror는 원격 저장소의 모든 확장 된 참조를 복제하고 원격 분기 추적 구성을 유지 관리합니다. 그런 다음 미러에서 git remote update를 실행하면 origin repo의 모든 참조를 덮어 씁니다. 정확한 '미러링 된'기능을 제공합니다. 기타 구성 옵션 다른 git clone 옵션의 포괄적 인 목록은 Git 공식 문서 https://git-scm.com/docs/git-clone를 참조하십시오. 이 문서에서는 다른 일반적인 옵션에 대해서도 다룰 것입니다. git clone --template git clone --template=<template_directory> <repo location> <repo location>에서 repo를 복제하고 <template directory>의 템플릿을 새로 만든 로컬 분기에 적용합니다. Git 템플릿에 대한 철저한 언급은 git init 페이지에서 찾을 수 있습니다. Git URLs Git은 원격 저장소 위치를 Git 명령에 전달하는 데 사용되는 자체 URL 구문을 가지고 있습니다. git clone은 원격 저장소에서 가장 일반적으로 사용되기 때문에 여기에서 Git URL 구문을 검사합니다. Git URL protocols -SSH SSH (Secure Shell)는 유비쿼터스 인증 네트워크 프로토콜로 대부분의 서버에서 기본적으로 공통적으로 구성됩니다. SSH는 인증 된 프로토콜이므로 연결하기 전에 호스팅 서버에 자격 증명을 설정해야합니다. ssh : // [사용자 @] host.xz [: 포트] /path/to/repo.git/ - GIT 자식에게 유일한 프로토콜. 자식은 포트 (9418)에서 실행되는 데몬과 함께 제공됩니다. 프로토콜은 SSH와 유사하지만 인증이 없습니다. git : //host.xz [: port] /path/to/repo.git/ - HTTP 하이퍼 텍스트 전송 프로토콜. 웹의 프로토콜로 인터넷을 통해 웹 페이지 HTML 데이터를 전송하는 데 가장 일반적으로 사용됩니다. Git은 HTTP http [s]를 통해 통신하도록 구성 될 수 있습니다 : http[s]://host.xz [: port] /path/to/repo.git/ Git 가이드

git init

이 페이지에서는 git init 명령을 자세히 살펴 봅니다. 이 페이지의 끝 부분에서 git init의 핵심 기능과 확장 기능 세트에 대해 알게 될 것입니다. 이 탐험은 다음을 포함한다 : git init 옵션과 사용법 .git 디렉토리 개요 사용자 정의 git init 디렉토리 환경 값 git init 과 git clone git init bare 저장소 git init 템플릿 git init 명령은 새로운 Git 저장소를 만듭니다. 그것은 버전없는 기존 프로젝트를 Git 저장소로 변환하거나 새로운 빈 저장소를 초기화하는 데 사용할 수 있습니다. 다른 Git 명령은 초기화 된 저장소 외부에서 사용할 수 없으므로 일반적으로 새 프로젝트에서 실행할 첫 번째 명령입니다. git init을 실행하면 현재 작업 디렉토리에 .git 하위 디렉토리가 생성됩니다.이 디렉토리에는 새 저장소에 필요한 모든 Git 메타 데이터가 들어 있습니다. 이 메타 데이터에는 개체, 참조 및 템플릿 파일의 하위 디렉터리가 포함됩니다. 현재 체크 아웃 된 커밋을 가리키는 HEAD 파일도 생성됩니다. 프로젝트의 루트 디렉토리에서 .git 디렉토리를 제외하고 기존 프로젝트는 변경되지 않습니다 (SVN과 달리 모든 하위 디렉토리에는 .git 서브 디렉토리가 필요하지 않습니다). 기본적으로 git init은 Git 구성을 .git 하위 디렉토리 경로로 초기화합니다. 다른 곳에서 살기를 원하면 하위 디렉토리 경로를 수정하고 사용자 정의 할 수 있습니다. $ GIT_DIR 환경 변수를 커스텀 경로로 설정하면 git init은 거기에있는 Git 설정 파일을 초기화 할 것이다. 또한 동일한 결과에 대해 --separate-git-dir 인수를 전달할 수 있습니다. 별도의 .git 하위 디렉토리를 사용하는 일반적인 경우는 .git 폴더를 다른 위치에 유지하면서 홈 디렉토리에 시스템 구성 "dotfiles"(.bashrc, .vimrc 등)을 유지하는 것입니다. 사용법 SVN과 비교하여 git init 명령은 새로운 버전 제어 프로젝트를 생성하는 매우 쉬운 방법입니다. Git에서는 저장소를 만들고, 파일을 가져오고, 작업 복사본을 체크 아웃 할 필요가 없다. 또한, 힘내는 기존의 서버 또는 관리자 권한이 필요하지 않습니다. 당신이해야 할 일은 프로젝트 서브 디렉토리에 cd하고 git init을 실행하는 것입니다. 여러분은 Git 저장소를 완벽하게 사용할 수 있습니다. git init 현재 디렉토리를 Git 저장소로 변환하십시오. 이렇게하면 .git 서브 디렉토리가 현재 디렉토리에 추가되고 프로젝트의 개정판을 기록 할 수있게됩니다. git init <directory> 지정된 디렉토리에 빈 Git 저장소를 만듭니다. 이 명령을 실행하면 .git 서브 디렉토리 만 포함하는 새 서브 디렉토리가 작성됩니다. 이미 프로젝트 디렉토리에서 git init을 실행했고 .git 서브 디렉토리가 있다면, 동일한 프로젝트 디렉토리에서 git init을 다시 안전하게 실행할 수 있습니다. 기존 .git 구성을 재정의하지 않습니다. git init vs. git clone 빠른 참고 사항 : git init 및 git clone은 쉽게 혼동 될 수 있습니다. 높은 수준에서, 그들은 둘 다 "새로운 자식 저장소를 초기화하는 데 사용할 수 있습니다." 그러나 git clone은 git init에 의존합니다. git clone은 기존 저장소의 복사본을 만드는 데 사용됩니다. 내부적으로, git clone은 먼저 git init을 호출하여 새로운 저장소를 만듭니다. 그런 다음 기존 저장소의 데이터를 복사하고 새로운 작업 파일 세트를 체크 아웃합니다. git clone 페이지에 대해 자세히 알아보십시오. Bare repositories --- git init --bare git init --bare <directory> 빈 저장소를 초기화하고 작업 디렉토리를 생략하십시오. 공유 저장소는 항상 --bare 플래그를 사용하여 만들어야합니다 (아래 토론 참조). 일반적으로, --bare 플래그로 초기화 된 저장소는 .git로 끝납니다. 예를 들어, my-project라는 저장소의 베어 버전은 my-project.git라는 디렉토리에 저장되어야합니다. --bare 플래그는 작업 디렉토리가없는 저장소를 작성하므로 파일을 편집하고 해당 저장소의 변경 사항을 커밋 할 수 없습니다. git push와 git pull을위한 맨 처음 저장소를 만들지 만 직접적으로 커밋하지 마십시오. 중앙 저장소는 베어지 저장소로 분기를 푸는 것이 변경 내용을 덮어 쓸 가능성이 있기 때문에 항상 베어 리지 저장소로 만들어야합니다. 개발 환경과는 반대로 저장소를 저장소 기능으로 표시하는 방법으로 생각하십시오. 즉, 사실상 모든 Git 워크 플로우에서 중앙 저장소는 노출되지 않았으며 개발자 로컬 저장소는 노출되지 않았습니다. 01.png git init --bare의 가장 일반적인 사용 사례는 원격 중앙 저장소를 만드는 것입니다 : ssh <user>@<host> cd path/above/repo git init --bare my-project.git 먼저, 중앙 저장소를 포함 할 서버로 SSH합니다. 그런 다음 프로젝트를 저장하려는 위치로 이동합니다. 마지막으로 --bare 플래그를 사용하여 중앙 저장소 저장소를 만듭니다. 개발자는 my-project.git을 복제하여 개발 컴퓨터에서 로컬 복사본을 만듭니다. git init templates git init <directory> --template=<template_directory> 새 Git 저장소를 초기화하고 <template_directory>의 파일을 저장소에 복사합니다. 템플릿을 사용하면 미리 정의 된 .git 하위 디렉토리로 새 저장소를 초기화 할 수 있습니다. 새 저장소의 .git 서브 디렉토리에 복사 할 기본 디렉토리와 파일을 갖도록 템플리트를 구성 할 수 있습니다. 디폴트의 Git 템플릿은 일반적으로`/ usr / share / git-core / templates` 디렉토리에 있지만 여러분 머신의 다른 경로 일 수 있습니다. 기본 템플리트는 좋은 참조이며 템플리트 기능을 사용하는 방법의 예입니다. 기본 템플릿에 표시되는 템플릿의 강력한 기능은 Git Hook 구성입니다. 미리 정의 된 Git 훅을 사용하여 템플릿을 만들 수 있으며, 일반적인 훅을 사용할 준비가 된 새로운 git 리포지토리를 초기화 할 수 있습니다. Git Hook에 대한 자세한 내용은 Git Hook 페이지를 참조하십시오. 구성 git init <directory>의 모든 설정은 <directory> 인수를 취합니다. <directory>를 제공하면 명령이 그 안에 실행됩니다. 이 디렉토리가 존재하지 않으면 생성됩니다. 이미 논의 된 옵션과 설정 외에도 Git init에는 몇 가지 다른 명령 행 옵션이 있습니다. 전체 목록은 다음과 같습니다. -Q, --QUIET :"위험 수준"메시지, 오류 및 경고 만 인쇄합니다. 다른 모든 출력은 음소거됩니다. --BARE :bare 저장소를 만듭니다. 위의 "bare repository"섹션을 참조하십시오. --TEMPLATE=<TEMPLATEDIRECTORY> :템플릿을 사용할 디렉토리를 지정합니다. 위의 "Git Init Templates"섹션을 참조하십시오. --SEPARATE-GIT-DIR=<GIT DIR> :<git dir>에 대한 경로를 포함하는 텍스트 파일을 생성합니다. 이 파일은 .git 디렉토리에 대한 링크 역할을합니다. .git 디렉토리를 프로젝트의 작업 파일과 별도의 위치에 저장하거나 드라이브에 저장하려는 경우 유용합니다. --separate-git-dir의 일반적인 사용 사례는 다음과 같습니다. .git 폴더를 다른 위치에 유지하면서 홈 디렉토리에 시스템 구성 "dotfiles"(.bashrc, .vimrc 등)을 유지하려면 Git 히스토리는 디스크 크기가 매우 커 졌으므로 별도의 대용량 드라이브로 옮겨야합니다. Git 프로젝트를`www : root`와 같이 공개적으로 접근 가능한 디렉토리에두고 싶습니다. 기존 저장소에서 git init --separate-git-dir을 호출하면 .git 디렉토리가 지정된 <git 디렉토리> 경로로 이동합니다. --SHARED[=(FALSE|TRUE|UMASK|GROUP|ALL|WORLD|EVERYBODY|0XXX)] :새 저장소에 대한 액세스 권한을 설정하십시오. Unix 레벨 권한을 사용하는 사용자와 그룹이 저장소로 푸시 / 풀을 허용하는 사용자와 그룹을 지정합니다. Examples 기존 코드베이스를위한 새로운 git 저장소 만들기 cd /path/to/code \ git init \ git add . \ git commit Bare 저장소 생성하기 git init --bare /path/to/repo.git 템플릿을 이용해 저장소 생성하기 mkdir -p /path/to/template \ echo "Hello World" >> /absolute/path/to/template/README \ git init /new/repo/path --template=/absolute/path/to/template \ cd /new/repo/path \ cat /new/repo/path/README Git 가이드

git reflog

Git은 reference log를 이용해 branch의 최신 버전을 유지한다. Reflog는 reference logs 를 뜻하며 reference 또는 ref는 commit 를 가르킨다. 기본 기능 Git 이력 정보를 얻을 수 있다. git reflog [show HEAD] 결과: eff544f HEAD@{0}: commit: migrate existing content bf871fd HEAD@{1}: commit: Add Git Reflog outline 9a4491f HEAD@{2}: checkout: moving from master to git_reflog 9a4491f HEAD@{3}: checkout: moving from Git_Config to master 39b159a HEAD@{4}: commit: expand on git context 9b3aa71 HEAD@{5}: commit: more color clarification f34388b HEAD@{6}: commit: expand on color support 9962aed HEAD@{7}: commit: a git editor -> the Git editor 특정 Reflog 보기 전체 Reflog 보기 git reflog show --all 특정 Reflog 보기 git reflog show <Reflog name> otherbranch 브랜치 지정 결과: git reflog show otherbranch 9a4491f otherbranch@{0}: commit: seperate articles into branch PRs 35aee4a otherbranch{1}: commit (initial): initial commit add git-init and setting-up-a-repo docs 시간 이력 Reflog는 timestamp를 가지고 있으므로 시간을 활용한 다양한 기능을 이용할 수 있다. master 브랜치에 대해 하루 이전의 이력 표시 예: git diff master@{0} master@{1.day.ago} 시간 표현 방법) 1.minute.ago 1.hour.ago 1.day.ago yesterday 1.week.ago 1.month.ago 1.year.ago 2011-05-17.09:00:00 Git 가이드

git commit --amend

git commit --amend는 최근 커밋을 변경하는 가장 쉬운 방법이다. 단, 커밋의 snapshot을 변경하지 않으며 커밋 메시지, 커밋 파일 추가 기능을 제공한다. 추가 옵션 없이 명령을 실행하면 편집기를 통해 커밋 메시지를 수정할 수 있다. git commit --amend -m은 편집기를 실행하지 않고 커밋 메시지 직접 입력할 때 유용하다. git commit --amend -m "커밋 메시지 수정" 또한 커밋에 누락된 파일을 추가할 수 있다. 1) A.java 수정 후 add > commit 2) B.java 수정 git commit --amend --no-edit 결과: B.java가 최종 커밋에 포함됨 Screen Shot 2020-04-22 at 6.05.46 AM.png Git 가이드

git rebase

Rebase는 커밋을 새로운 부모 커밋으로 옮기는 기능을 제공한다.  Push된 history를 rebase 하지 않도록 주의한다. 이 경우 history를 기반으로 작업하고있는 개발자들에게 영향을 주게된다. 다음 명령은 현재 working branch의 커밋을 <base> branch로 옮긴다. git rebase <base> git rebase의 기본 동작은 non-interactive이며, interactive mode (--interactive, -i)로 editor를 이용할 수 있다. git rebase -i new-base-branch editor 화면: pick 2231360 some old commit pick ee2adc2 Adds new feature # Rebase 2cf755d..ee2adc2 onto 2cf755d (9 commands) # # Commands: # p, pick = use commit (커밋 사용) # r, reword = use commit, but edit the commit message (커밋 메시지 변경) # e, edit = use commit, but stop for amending (커밋 수정을 위해 자동 수행 멈춤) # s, squash = use commit, but meld into previous commit (이전 커밋에 포함) # f, fixup = like "squash", but discard this commit's log message (이전 커밋에 포함) # x, exec = run command (the rest of the line) using shell (명령 수행) # d, drop = remove commit (커밋 삭제) editor를 종료하면 선택한 명령이 일괄 수행된다. --on-to 옵션은 브랜치을 rebase 하는 기능을 제공한다. git rebase --onto <newbase> <oldbase> featureB branch는 featureA와 의존성의 없어서 master로 rebase하고 싶은 경우, o---o---o---o---o master \ o---o---o---o---o featureA \ o---o---o featureB git rebase --onto master featureA featureB rebase 결과: o---o---o featureB / o---o---o---o---o master \ o---o---o---o---o featureA Screen Shot 2020-04-22 at 6.07.26 AM.png Git 가이드

GitLab offline 설치 가이드

Linux 7 설치 설치 파일 사전 준비 사항  1. 필수 사항  policycoreutils-python / openssh-server / openssh-clients / git2.29 이상  2. 선택 사항  curl / ca-certificates / postfix GitLab 설치 offline 설치 방법       (1) offline-{파일명}.tar.gz 압축 해제       (2) offline-{파일명}.repo 파일 복사 → /etc/yum.repos.d 디렉토리       (3) offline-{파일명} 디렉토리 복사 →  /var/tmp 디렉토리      (4) 설치 진행  yum -y install --disablerepo=\* --enablerepo=offline-{파일명} {파일명} -- Git 설치 $ tar -xvf offline-git-2.30.tar.gz $ cp -r git /var/tmp/ $ cp -r offline-git.repo /etc/yum.repos.d/ $ yum -y install --disablerepo=\* --enablerepo=offline-git git -- Gitlab 설치 $ tar -xvf offline-gitlab-ee.13.9.tar.gz $ cp -r gitlab-ee /var/tmp/ $ cp -r offline-gitlab-ee.repo /etc/yum.repos.d/ $ yum -y install --disablerepo=\* --enablerepo=offline-gitlab-ee gitlab-ee rpm 설치  디렉토리 정보 정보 디렉토리 경로 설치 디렉토리 /opt/gitlab 설정 파일 디렉토리 /etc/gitlab 데이터 디렉토리 /var/opt/gitlab 로그 디렉토리 /var/log/gitlab 포트 변경  * 포트 링크  https://docs.gitlab.com/omnibus/package-information/defaults.html https://docs.gitlab.com/omnibus/package-information/defaults.html $ vi /etc/gitlab/gitlab.rb 1.external_url 에서 포트 변경 external_url 'http://192.168.137.13:7990' 2. Advanced settings에서 주석 제거,포트 변경 puma['port'] = 8080 # 디폴트 포트가 자주 사용하는 포트이므로 확인 후 변경 Repository 디렉토리 변경  $ vi /etc/gitlab/gitlab.rb For setting up different data storing directory ! Docs: https://docs.gitlab.com/omnibus/settings/configuration.html#storing-git-data-in-an-alternative-directory ! **If you want to use a single non-default directory to store git data use a ! path that doesn't contain symlinks.** git_data_dirs({ "default" => {"path" => "/test/git-data"} # Repository 디렉토리 입력 }) 설정 변경  최초 reconfigure 실행  $ gitlab-ctl reconfigure 시작 / 종료 / 재시작  $ gitlab-ctl start $ gitlab-ctl stop $ gitlab-ctl restart GitLab 백업 방법 * 백업 링크  https://docs.gitlab.com/omnibus/settings/backups.html https://docs.gitlab.com/omnibus/settings/backups.html https://docs.gitlab.com/ee/raketasks/backup_restore.html#back-up-gitlab https://docs.gitlab.com/ee/raketasks/backup_restore.html#back-up-gitlab < config 백업 > EX)명령어 : sudo gitlab-ctl backup-etc {경로 입력} # 디폴트 디렉토리 : /etc/gitlab/config_backup $ sudo gitlab-ctl backup-etc /test/gitlab_backup <data 백업> $ sudo gitlab-backup create $ vi /etc/gitlab/gitlab.rb 설정 에서 변경 가능 -> 주석 제거,디렉토리 변경 -> gitlab-ctl reconfigure 진행 gitlab_rails['backup_path'] = "/var/opt/gitlab/backups" 백업 Crontab 설정  $ vi /opt/gitlab/bin/gitlab_cron.sh gitlab-ctl backup-etc /test/gitlab_backup gitlab-backup create $chmod +x /opt/gitlab/bin/gitlab_cron.sh $crontab -e 0 1 * * * /opt/gitlab/bin/gitlab_cron.sh # 매일 오전 1시 백업을 예약 서비스 등록 $ vi /etc/systemd/system/gitlab-run.service ============================================== [Unit] Description=gitlab server Service [Service] user=root ExecStart=/opt/gitlab/bin/gitlab-ctl start [Install] WantedBy=multi-user.target ============================================== $ systemctl enable gitlab-run.service $ systemctl daemon-reload $ systemctl start gitlab-run.service $ systemctl status gitlab-run.service

LDAP 관리자 가이드

백업 및 복원

이 페이지는 백업과 복원 가이드를 제공한다. 백업 대상 CentOS의 경우 백업될 데이터: /var/lib/ldap Configuration 데이터: /etc/openldap 설치폴터: 한 폴더에 모여있지 않고 /lib64 등으로 설치되기 때문에 설치폴더는 백업하지 않음 참고 문서 : https://www.techbrown.com/ldap-configuration-install-centos-7-rhel-7.shtml https://www.techbrown.com/ldap-configuration-install-centos-7-rhel-7.shtml

2. LDAP User 관리

이 문서는 LDAP Admin을 통해 Open LDAP을 관리하는 방법에 대해서 가이드하기 위해 작성되었다. Windows LDAP Admin  다운로드 다음 링크를 통해 LdapAdmin을 다운로드 받는다. LdapAdmin 1.7.2(http://www.ldapadmin.org/download/ldapadmin.html http://www.ldapadmin.org/download/ldapadmin.html) LDAP 설치 만약 Open LDAP이 설치되어 있지 않다면, 다음 링크를 통해 설치를 진행할 수 있다. Ldap 설치 가이드  LDAP 연결 설정 Ldap 서버로 연결 설정하기 위해 다운로드 받은 LdapAdmin.exe 실행한다. 메뉴의 start > connect를 선택한다. 또는 New connection을 선택한다. 1.install.png Connection properties 창이 나타나면 다음과 같이 정보를 입력한다.  Connection name : LDAP connection을 위한 이름을 입력한다.  General 탭 Host : LDAP 서버의 주소를 입력 Port : 389 (기본) Base : ex) dc=curvc, dc=com  Username : ex) cn=admin, dc=curvc, dc=com Password : 패스워드 입력 2.install.png 모든 정보가 입력되면 하단 Test connection을 통해 접속을 Test 하고 OK 버튼을 클릭한다.  3.install.png 새롭게 생성한 연결 정보로 접속하기 위해 해당 연결 정보를 클릭하고 OK 버튼을 클릭한다.  4.install.png 다음 그림은 Ldap 구조가 어떻게 되어 있는지 확인 가능하다. 5.install.png Organizational Unit 생성 새로운 Organizational unit을 생성하기 위해  LDAP 상위 Entry를 선택하고 오른쪽 마우스 클릭 > New > Organizational unit ...을 클릭한다.  만약 조직에서 사용하는 특별한 명명 법칙이 있다면, 거기에 준하여 Organizational Unit의 Name을 입력한다.  다음 그림은 people이라는 Organizational Unit을 생성하는예제를 보여준다. 6.install.png Create Organizational Unit의 name을 입력 하고 OK 버튼을 클릭 한다. 7.install.png 다음 그림은 Organizational Unit의 people이라는 object가 생성이 되었음. 8.install.png User 생성 새로운 사용자를 생성하기 위해 생성을 위한 Entry를 선택하고 오른쪽 마우스를 클릭하여 New > User를 클릭한다.  9.install.png Create User 창이 나타나면, 다음과 같이 필수 정보를 입력한다.  First name : 이름 Second name : 성 Display name : 보여지는 이름 Username : 로그인 이름 Home Directory : 홈디렉토리 10.install.png Business 탭으로 이동하여 하단에 E-Mail Addresses에서 Add 버튼을 클릭한다. Add Address 창이 나타나면 SMTP Address 필드에 이메일 정보를 입력하고 OK 버튼을 클릭한다. 11.install.png 다음 그림은 people 이라는 Organizational unit 아래의 Hong GilDong 이라는 user가 생성이 된것을 보여주고 있다. 12.install.png User 패스워드 설정 사용자 패스워드를 설정하기 위해서 해당 유저를 선택하고 Set Password를 선택한다. 13.install.png New password와 Confirm password를 입력합니다. Encryption method type를 선택하고 OK 버튼을 클릭한다. 14.install.png 다음 그림은 패스워드가 생성되었음을 보여주는 그림 이다. 15.install.png User 정보 수정 사용자 정보를 수정하기 위해 수정을 원하는 사용자를 선택하고 상단 메뉴의 체크 박스 아이콘 선택 또는 해당유저 선택 마우스 오른쪽 클릭 > Properties를 선택하여 사용자 정보를 변경한다. 16.install.png 해당 유저의 정보를 변경 하실 수 있다. 17.install.png 다음 그림은 정보가 변경 되었음을 알 수 있다. 18.install.png User 삭제 사용자 삭제하기 위해 해당 유저 선택 후 상단의 X 아이콘 버튼 클릭 또는 마우스 오른쪽 클릭 > Delete 버튼을 클릭한다. 19.install.png 다음 그림은 해당 되는 entry를 지우겠냐고 물어 봅니다. Yes 버튼을 클릭 하면 User 삭제가 된다. 20.install.png User가 삭제 되었음을 확인 할 수 있다. 21.install.png

3. LDAP Group 관리

Groups 생성 새로운 Group을 생성 하기 앞서 여러명의 User가 생성이 되어야 한다. 2. LDAP User 관리 Organizational Unit 생성 새로운 Organizational unit을 생성하기 위해  LDAP 상위 Entry를 선택하고 오른쪽 마우스 클릭 > New > Organizational unit ...을 클릭한다.  만약 조직에서 사용하는 특별한 명명 법칙이 있다면, 거기에 준하여 Organizational Unit의 Name을 입력한다.  다음 그림은 Groups이라는 Organizational Unit을 생성하는예제를 보여준다. 22.install.png Create Organizational Unit의 name을 입력 하고 OK 버튼을 클릭 한다. 23.install.png 다음 그림은 Organizational Unit의 Groups이라는 object가 생성이 되었다. 24.install.png Group 생성 새로운 그룹을 생성하기 위해 생성을 위한 Entry를 선택하고 오른쪽 마우스를 클릭하여 New > Group를 클릭 한다. Dev Group를 생성하는 예제 그림 이다. 25.install.png Create Group의 Group name을 입력 합니다. 그리고 Members 탭의 Add 버튼을 클릭 한다. 26.install.png Dev Group에 소속되야 할 User를 선택 하고 OK 버튼을 클릭 한다. 27.install.png 선택한 User가 속해 있는지 확인 하고 OK 버튼을 클릭한다. 28.install.png Dev Group에 추가한 User1,2,3 이 있음을 확인 할 수 있다. 29.install.png Group 의 Member 추가 및 삭제 Member를 추가 및 삭제 해야 할 Group를 선택하고 상단 메뉴의 체크 박스 아이콘 선택 또는 해당그룹의 선택 마우스 오른쪽 클릭 > Properties를 선택하여 Group의 Member를 추가 및 삭제 한다. 30.install.png Dev Group의 해당 Member를 Add 또는 Remove 할 수 있다. 31.install.png 다음 그림은 user3을 삭제 하고 user4를 추가 하는 예제 이다. user3를 선택 하고 Remove 버튼을 클릭 한다. 32.install.png user3이 삭제 되었음을 알 수 있습니다. Add 버튼을 클릭 한다. 33.install.png Choose members의 user4를 선택하고 OK 버튼을 클릭 한다. 34.install.png Dev Group의 Members의 user4이 추가 된 것을 알 수 있다. OK 버튼을 클릭하여 최종 적용 한다. 35.install.png Dev Group의 User1,2,4가 추가가 되었음을 알 수 있다. 36.install.png Group 삭제 Group를 삭제하기 위해 해당 그룹을 선택 후 상단의 X 아이콘 버튼 클릭 또는 마우스 오른쪽 클릭 > Delete 버튼을 클릭한다. 37.install.png 다음 그림은 해당 되는 entry를 지우겠냐고 물어 봅니다. Yes 버튼을 클릭 하면 Group이 삭제가 된다. 38.install.png Dev Group이 삭제 되었음을 알 수 있다. 39.install.png

1. LDAP 소개

이 문서는 LDAP에 대한 간단한 정보를 공유하기 위해 작성되었다. LDAP 이란 LDAP(Lightiweight Directory Access Protocol)은 네트워크 상에서 조직이나 개인정보 혹은 파일이나 디바이스 정보 등을 찾아 보는 것을 가능하게 만든 소프트웨어 프로토콜이다. LDAP은 X.500 디렉토리 서비스를 위한 DAP(Directory Access Protocol)의 일종이다. DAP 는 OSI Protocol stack 에서 작동되고, 컴퓨팅의 많은 자원을 사용하는 무거운 프로토콜이다. 이러한 문제점을 해결한것이 LDAP 이다. LDAP은 TCP/IP 에서 작동되며, 보다 저렴한 비용으로 DAP의 기능을 대부분 지원할 수 있다. image2017-2-21_11-8-58.png LDAP 구조 일반적으로 LDAP은 다음과 같이 구성된다.  cn (Common Name) : GilDong Hong 와 같은 일반적인 이름 sn (Sir Name) : 우리나라 성에 해당 ou (Organization Unit) : 그룹에 해당 dc (Domain Component) : 도메인의 요소 w http://ara.kaist.ac.kr/ww.google.com http://ww.google.com 의 dc 는 dc=www,dc=google,dc=com dn (Distinguished Name) : 고유의 이름 o : organization c : country uid : user id image2017-2-21_14-56-56.png

Ubuntu에서 쿠버네티스(k8s) 설치 가이드

이 문서는 쿠버네티스(k8s) 구축에 대한 정보를 공유하기 위해 작성되었다.  Docker 설치 Docker Engine 설치를 위해 다음 절차를 따라 진행한다. 세부적인 가이드는 아래 링크를 참고한다.  docs.docker.com http://docs.docker.com 가이드 참조 저장소 설정 Docker 설치를 위해 먼저 apt 패키지를 업데이트한다.  sudo apt-get update sudo apt-get install \ ca-certificates \ curl \ gnupg \ lsb-release Docker’s 공식 GPG key 추가하기 위해 다음 절차를 진행한다.  curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg Stable repository 설정을 위해 다음 명령을 수행한다.  echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null Docker 엔진 설치 최신 버전의 Docker Engine 및 containerd를 설치하기 위해 다음 명령을 수행한다.  sudo apt-get update sudo apt-get install docker-ce docker-ce-cli containerd.io 설치가 완료되면 Docker 버전 확인한다.  sudo docker version 설치된 버전 Client: Docker Engine - Community Version: 20.10.13 Server: Docker Engine - Community Version: 20.10.13 Docker를 서비스 등록 및 실행하기 위해 다음을 수행한다.  sudo systemctl enable docker sudo systemctl start docker Kubernetes 설치 Docker 설치가 완료되었다면 kubernetes 설치를 진행한다. k8s는 kubeadmin을 통해 설치를 진행할 수 있다.  설치 전 확인 사항 (master, node) 각 노드들은 Swap Disable 해야하기 때문에 각 노드별로 다음 명령을 통해 설정한다.  swapoff -a && sed -i '/swap/s/^/#/' /etc/fstab 혹은 sudo swapoff -a && sudo sed -i '/swap/s/^/#/' /etc/fstab 그리고 iptable 설정하기 위해 다음 명령을 수행한다.  cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf br_netfilter EOF cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-ip6tables = 1 net.bridge.bridge-nf-call-iptables = 1 EOF sudo sysctl --system 통신을 위해 방화벽 예외 설정을 수행한다.  sudo systemctl stop firewalld sudo systemctl disable firewalld 다음과 같이 방화벽 설정 이후 포트가 오픈되어 있는지 확인한다.  telnet 127.0.0.1 6443 kubelet, kubeadm, kubectl 설치 (master, node) 쿠버네티스 설치를 진행하기위해 저장소 업데이트 및 필수 패키지 추가한다. sudo apt-get update sudo apt-get install -y apt-transport-https ca-certificates curl 구글 클라우드 퍼블릭 키 다운로드를 수행한다.  sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg 쿠버네티스를 설치하기 위해 Kubernetes 저장소 추가한다.  echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list 저장소 업데이트 후 kubelet, kubeadm, kubectl 설치를 순차적으로 진행한다.  sudo apt-get update sudo apt-get install -y kubelet kubeadm kubectl sudo apt-mark hold kubelet kubeadm kubectl 쿠버네티스를 서비스 등록 및 재시작을 수행한다.  sudo systemctl daemon-reload sudo systemctl restart kubelet Control-plane 구성 (master only) contol-plane 노드 초기화 - 해당 작업은 반드시 master에서만 진행한다.  kubeadm init 만약 초기화 진행중에 다음과 같은 에러가 발생가 발생한다면 failed with error: Get "http://localhost:10248/healthz" 해당 문제 해결책하기 위해 아래와 같이 daemon.json 생성 후에 kubeadm을 reset 후에 다시 init을 수행한다. 하위 작업은 node에도 수행 해준다.  sudo mkdir /etc/docker cat <<EOF | sudo tee /etc/docker/daemon.json { "exec-opts": ["native.cgroupdriver=systemd"], "log-driver": "json-file", "log-opts": { "max-size": "100m" }, "storage-driver": "overlay2" } EOF sudo systemctl enable docker sudo systemctl daemon-reload sudo systemctl restart docker kubeadm reset 최종적으로 아래와 같이 node가 접속할 때 사용하는 토큰이 발행된다.  kubeadm join 10.0.100.40:6443 --token zbgv72.v9ac8xhex128xjwp \ --discovery-token-ca-cert-hash sha256:2193f25bad65918edbc41b543e22327741bdd99748b1 모든 사용자가 kube 명령어를 사용할 수 있게 하기 위해 다음을 설정한다. mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config Pod network 애드온 설치 (master only) Pod 간의 네트워크 통신 위해 다음 명령을 통해 써드파티 애드온인 Weave Net works 설치 수행한다.  kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')" Worker node 구성 (node only) 다음 명령을 통해 Worker node를 등록한다.  sudo kubeadm join 10.0.100.40:6443 --token zbgv72.v9ac8xhex128xjwp \ --discovery-token-ca-cert-hash sha256:2193f25bad65918197d7b543e282327741bdd99748b1a6d879e1b4dc image2022-3-15_18-59-50.png Master에서 노드 확인하기 (master) 다음 명령을 수행하여 모든 노드가 연결되었는지 확인한다.  kubectl get nodes -o wide image2022-3-15_19-2-12.png 자동 완성 설정 (master) bash에서 kubectl 명령어를 tab 자동 완성하기 위해 다음을 수행한다.  source <(kubectl completion bash) echo "source <(kubectl completion bash)" >> ~/.bashrc

eclipse che docker 설치

이 문서는 eclipse che docker 설치 가이드를 공유한다.  먼저 eclipse che 데이터를 저장할 폴더 생성한다. mkdir data cd data mkdir eclipse 다음 명령을 통해 docker container 실행한다. docker run -ti -v /var/run/docker.sock:/var/run/docker.sock -v ~/data/eclipse:/data eclipse/che start docker run -it -e CHE_MULTIUSER=true -v /var/run/docker.sock:/var/run/docker.sock -v ~/data/eclipse:/data eclipse/che start 최종적으로 다음과 같이 실행을 확인할 수 있다.  [root@localhost /]# docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock -v /data/eclipse:/data eclipse/che start WARN: Bound 'eclipse/che' to 'eclipse/che:6.2.0' INFO: (che cli): 6.2.0 - using docker 18.02.0-ce / native INFO: (che config): Generating che configuration... INFO: (che config): Customizing docker-compose for running in a container INFO: (che start): Preflight checks mem (1.5 GiB): [OK] disk (100 MB): [OK] port 8080 (http): [AVAILABLE] conn (browser => ws): [OK] conn (server => ws): [OK] INFO: (che start): Starting containers... INFO: (che start): Services booting... INFO: (che start): Server logs at "docker logs -f che" INFO: (che start): Booted and reachable INFO: (che start): Ver: 6.2.0 INFO: (che start): Use: http://192.168.0.146:8080 INFO: (che start): API: http://192.168.0.146:8080/swagger

Gradle 버전 지정 방법

개요 목적 빌드 서버에 두 가지 이상의 Gradle 버전이 필요한 경우 빌드 할 때 버전 지정 방법을 정리한다. 해결 방안 Gradle 은 어떤 버전을 실행하는지에 따라 다른 버전이 실행된다 방법 1) GRADLE_HOME 경로 구성  원하는 버전을 GRADLE_HOME 변수로 지정할 수 있다 방법 2) Gradle wrapper 구성 gradlew은 gradle/wrapper/gradle-wrapper.properties에 정의정 gradle version을 실행한다. 따라서 gradle-wrapper.properties 파일에 원하는 gradle version을 설정하여 gradle version을 지정할 수 있다. 다음과 같이 지정하면 이후 gradlew를 수행하면 version 3.3이 수행된다. $ wrapper --gradle-version 3.3

Jenkins & JBoss Integration - Publish over SSH Plugin

이 페이지는 Jenkins의 Publish over SSH plugin 을 이용해  빌드된 산출물을 원격 JBoss 서버에 배포하는 방법을 정리한다. 사전 준비 Publish over SSH plugin 설치 System Configuration Manage Jenkins >> System Configuration >> Publish over SSH SSH 서버 등록 Screen Shot 2017-04-04 at 8.51.19 PM.png Job Configuration Job configuration >> Post Steps 등록된 SSH 서버에 target/*.war 배포하는 구성 예) base-1.0.0-SNAPSHOT.war 파일 이름을 배포 파일로 변경하기 위해 shell 사용 target directory name 제거 Exec command란에 SSH login 후 실해할 명령어 기입 Screen Shot 2017-04-04 at 8.53.56 PM.png

Jenkins & JBoss Integrtaion - Wildfly Maven Plugin

이 페이지는 Wildfly Maven plugin과 Jenkins를 이용해 JBoss 용 웹 애플리케이션을 자동으로 빌드하고 배포하는 방법을 기술한다. JBoss는 Redhat 사의 WAS 이고 무료 제품인 community version과 상용 제품인 enterprise로 구성된다. JBoss Overview Homepage = http://www.jboss.org/ http://www.jboss.org/ Documentation home = https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform 다운로드는 회원 가입하면 가능 JBoss 설치 및 설정 JBoss 관리는 command line console과 Web console로 접근 가능 참고 문서 =https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.0/html/getting_started_guide/administering_jboss_eap#jboss_eap_installation_overview https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.0/html/getting_started_guide/administering_jboss_eap#jboss_eap_installation_overview 운영 모드 (Operating modes) JBoss는 두 가지 모드로 운영할 수 있다. 본 문서는 standalone mode를 기준으로 작성되었다. Standalone Server: 하나의 독립적인 프로세스로 실행됨 Managed Domain: 여러개의 서버로 구성되며 중앙에서 관리할 수 있음 원격 접속 설정 JBoss는 로컬에서 접근하는 것이 기본이므로 원격 PC에서 관리하려면 설정이 필요함 설정파일 <install-directory>/standalone/configuration/standalone.xml 기본 설정: 1 2 3 4 5 6 <interface name="management"> <inet-address value="${jboss.bind.address.management:127.0.0.1}"/> </interface> <interface name="public"> <inet-address value="${jboss.bind.address:0.0.0.0}"/> </interface> 위의 설정을 다음과 같이 변경 1 2 3 4 5 6 <interface name="management"> <any-address/> </interface> <interface name="public"> <any-address/> </interface> JBoss 설정 로딩하여 반영 <install-directory>/bin/jboss-cli.sh --connect --command=:reload 포트 목록 및 변경 <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}"> <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/> <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/> <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/> <socket-binding name="http" port="${jboss.http.port:8080}"/> <socket-binding name="https" port="${jboss.https.port:8443}"/> <socket-binding name="txn-recovery-environment" port="4712"/> <socket-binding name="txn-status-manager" port="4713"/> <outbound-socket-binding name="mail-smtp"> <remote-destination host="localhost" port="25"/> </outbound-socket-binding> </socket-binding-group> 서비스 모드 실행 설정 TBD original site = https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.1/html/Installation_Guide/Install_JBoss_Enterprise_Application_Platform_6_Red_Hat_Enterprise_Linux_Service.html https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.1/html/Installation_Guide/Install_JBoss_Enterprise_Application_Platform_6_Red_Hat_Enterprise_Linux_Service.html 3.9.2. Configure JBoss EAP 6 as a Service in Red Hat Enterprise Linux (Zip, Installer) Summary Use the following procedure to install JBoss EAP 6 as a service on Red Hat Enterprise Linux when the installation has been done with either the zip, text, or graphical methods. This process does not apply when the installation has been done using the RHN (RPM) method. Prerequisites Install JBoss EAP 6 using the Zip installation, Graphical Installer, or Text-based Installer: Section 3.2.2, “Install JBoss EAP 6 (Zip Installation)” https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.1/html/Installation_Guide/Install_JBoss_Enterprise_Application_Platform_6_Zip_Installation.html. Section 3.3.2, “Install JBoss EAP 6 (Graphical Installer)” https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.1/html/Installation_Guide/Install_JBoss_Enterprise_Application_Platform_6_Graphical_Installation.html. Section 3.4.2, “Install JBoss EAP 6 (Text-based Installer)” https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.1/html/Installation_Guide/Install_JBoss_Enterprise_Application_Platform_6_Text-based_Installation.html. Administrator privileges on the server are required. Procedure 3.17. Setup the Service Locate the start-up script and configuration file The start-up script and an associated configuration file are located in the EAP_HOME/bin/init.d/ directory. Open the configuration file jboss-as.conf to edit it. Customize the start-up options in the jboss-as.conf file There are several options within the jboss-as.conf file. At the minimum, specify the correct values for JBOSS_HOME and the JBOSS_USER variables. If these variables are absent, add them. Copy files into system directories Copy the modified configuration file to the /etc/jboss-as directory. [user@host init.d]$ sudo mkdir /etc/jboss-as [user@host init.d]$ sudo cp jboss-as.conf /etc/jboss-as/ Copy the start-up script to the /etc/init.d directory. [user@host init.d]$ sudo cp jboss-as-standalone.sh /etc/init.d Add the start-up script as a service. Add the new jboss-as-standalone.sh service to list of automatically started services, using the chkconfig service management command. [user@host init.d]$ sudo chkconfig --add jboss-as-standalone.sh Start the service. Test that the service has been installed correctly by using the standard syntax for starting Red Hat Enterprise Linux services. [user@host bin]$ sudo service jboss-as-standalone.sh start If everything has gone correctly, you should get a green [OK]. If you get an error, check the error logs and make sure your paths are correct in the configuration file. Make the service start automatically when you restart your server. To add the service to the list of services which start automatically when your server restarts, issue the following command. [root@host ~]# chkconfig jboss-as-standalone.sh on The service will now be started when your server reaches run-level 3, and will be stopped when your server is shut down or restarted. 실행 # > <install-directory>/bin/standalone.sh 애플리케이션 빌드 및 배포 이 절은 JBoss 용 애플리케이션을 빌드하고 배포하는 방법을 정리한다. 이 문서는 Maven 프로젝트를 기준으로 설명한다. Maven 프로젝트의 경우 Wildfly 플러그인을 이용해 배포한다. 배포 # > mvn install wildfly:deploy -Dname=admin -Dpassword=password 배포취소 # > mvn wildfly:undeploy -Dname=admin -Dpassword=password

Jenkins 관리자 가이드

이 문서는 Jenkins 관리자 가이드의 정보를 공유하기 위해 작성되었다.

Jenkins & Slack Integration

이 페이지는 빌드 및 배포를 상황을 프로젝트 구성원에게 전파하는 목적으로 빌드 및 배포 도구인 Jenkins와 협업 메신저인 Slack 을 연동하는 방법을 제공한다. 사전 조건 다음의 사전 조건이 만족되어야 한다. Jenkins Version 2.39 Slack Team manager 권한 계정 Jenkins  연동용 channel 생성 망 구성 Jenkins --[https]→ Slack 접속 가능 설정 흐름 설정은 아래의 과정으로 진행한다. Step 1)  Slack 설정 Jenkins App 설치 및 설정 Step 2) Jenkins plugin 설치 및 설정 Step 3) Jenkins job 단위로 post-build action 설정 Slack 구성 Step 1) Jenkins App 설치 Team menu >> Apps & Integrations >> Manage >> Apps  페이지로 이동하여 "Jenkins CI" 앱을 설치한다. Screen Shot 2017-04-14 at 1.41.28 PM.png Step 2) Jenkins CI 클릭 >> Add Configuration 이미 configuration이 추가했다면 연필 아이콘을 클릭하여 편집 화면으로 이동한다.  Post to Channel: 메시지가 표시될 기본 channel 설정 (Jenkins job 별로 설정 가능) Token: Jenkins에서 Slack에 접속할 때 사용할 token 나머지 항목은 설정하지 않아도 됨 Screen Shot 2017-04-14 at 1.44.24 PM.png Jenkins plugin 설치 및 설정 Step 1) Slack Plugin 설치 Jenkins 관리 >> Manage Plugin >> Available 화면으로 이동 Slack Notification Plugin을 찾아 check box 선택 >> Install without restart 클릭  Jenkins 2.74의 경우 Plugin 2.0 설치 권장 Step 2) Jenkins 재시작 Slack Notification plugin은 Jenkins 재시작을 요구한다. Restart Safely plugin이 설치된 경우 Jenkins menu에서 Restart Safely 메뉴를 선택하여 Jenkins를 재기동 시킨다. Step 3) Global 설정 Jenkins 관리 >> Configure System 메뉴를 선택하여 global 설정 페이지로 이동한다. Global Slack Notifier Settings 섹션으로 이동하여 세부 설정을 진행한다. Team Subdomain: Slack에 등록된 team URL의 subdomain 입력 (예: https://curvc.slack.com https://curvc.slack.com 이라면 "curvc"가 subdomain) Integration Token: Slack 설정의 Token을 복사하여 붙여넣기 Channel: Jenkins 메시지가 표시될 default Slack channel 설정. Job 구성에서 job 단위로 다른 channel 설정 가능 (예: #curvc-ci) Build Server URL: Slack message에 링크될 Jenkins 서버 주소 설정. 주소 마미막에 '/' 문자 입력 (예: http://jenkins-demo.curvc.com:78180) http://jenkins-demo.curvc.com:78180) image2017-4-14_21-24-11.png Jenkins Job 설정 Slack Channel에 빌드 상태 변경를 메시지를 표출하기 위해 Job을 구성한다. Step 1) Job 설정 페이지로 이동 Jenkins >> Job 이름 >> Configure 페이지로 이동한다. Add post-build action 을 펼쳐 >> Slack Notifications 메뉴를 선택한다. Step 2) 메시지 생성할 이벤트 설정 Slack channel에 표시될 이벤트를 모두 선택한다. Step 3) 추가 정보 설정 Advanced... 버튼 클릭 Team Subdomain: Global 설정과 동일하다면 설정하지 않아도 됨 Integration Token: Slack 설정의 Token. Global 설정과 동일하다면 설정하지 않아도 됨 Project Channel: Jenkins 메시지가 표시될 default Slack channel 설정. Global 설정과 동일하다면 설정하지 않아도 됨 Screen Shot 2017-04-14 at 9.25.43 PM.png Slack에 나타나는 빌드 수행 내용 Jenkins와 Slack 연동되면 빌드 상황이 Slack channel에 메시지로 전송된다. 아래는 Slack channel에 표시된 빌드 정보의 예를 보여준다. image2017-4-14_21-20-4.png

3. Jenkins Managing tools

이 문서는 Jenkins Global Tool Configuration에 대한 가이드를 제공한다.  Global Tool Configuration Global Tool Configuration에서는 Jenkins Job에서 사용되는 다양한 도구들의 설정을 구성할 수 있다. 이를 위해 Jenkins 관리 > Global Tool Configuration 클릭 한다. 3-1.Guide.png Maven Configuration Maven 설정에 대한 옵션을 선택할 수 있다. Default settings provider Use default maven settins : 기본 maven 설정 사용 Settings file in filesystem - File path : 파일 시스템의 설정 파일 Default global settings provider Use default maven global settings : 기본 글로벌 maven 설정 사용 Global settings file on filesystem : 파일 시스템의 글로벌 설정 파일 3-3.Guide.png JDK Jenkins 빌드에 사용될 수 있는 JDK 설정을 할 수 있다. JDK installations Name : 이름 Install automatically : 자동 설치 Version : 버전 Add Installer : 인스톨 3-4.Guide.png Git Jenkins 빌드에서 사용될 수 있는 Git Client 설정을 할 수 있다. Git installations Name : 이름 Path to Git executable : 실행 파일의 대한 경로 3-5.Guide.png Gradle Jenkins 빌드에서 사용될 수 있는 Gradle 설치 설정을 할 수 있다. Gradle installations Name : 이름 Install automatically : 자동 설치 Version : 버전 Add Gradle : Gradle 추가 3-6.Guide.png Ant Jenkins 빌드에서 사용될 수 있는 Ant 설치 설정을 할 수 있다. Ant installations Name : 이름 Install automatically : 자동 설치 Version : 버전 Add Ant : Ant 추가 3-7.Guide.png Maven Jenkins 빌드에서 사용될 수 있는 Maven 설치 설정을 할 수 있다. Maven installations Name : 이름 Install automatically : 자동 설치 Version : 버전 Add Maven : Maven 추가 3-8.Guide.png Docker Jenkins 빌드에서 사용될 수 있는 Docker 설치 설정을 할 수 있다. Docker installations Name : 이름 Installation root : root로 설치 Install automatically : 자동 설치 Add Docker : 독커 추가 3-9.Guide.png

4. Jenkins Managing Plugins

플러그인 관리 플러그인 관리에서는 Jenkins Job 설정을 돕는 다양한 플러그인들에 설치, 업데이트, 삭제를 수행한다. 이를 위해 Jenkins 관리 > 플러그인 관리로 이동 한다. 4-1.Guide.png 업데이트된 플러그인 목록 업데이트 된 플러그인 목록 탭에서는 설치되어 있는 플러그인 중에 업데이트가 가능한 플러그인의 리스트를 보여준다. 4-2.Guide.png 설치 가능 설치 가능 탭에서는 설치되지 않은 Jenkins의 플러그인 리스트를 확인할 수 있다. 상단 필터에 원하는 키워드를 입력하여 설치를 원하는 플러그인을 필터할 수 있다. 플러그인을 설치하기 위해서는 리스트에서 설치 컬럼을 체크하고 하단 설치하기 버튼을 클릭한다. 4-3.Guide.png 설치된 플러그인 목록 설치된 플러그인 목록 탭을 선택 시 설치된 플러그인 목록 리스트를 확인 및 설치 제거를 할 수 있다. 4-4.Guide.png 고급 고급 탭에서는 플러그인 설치를 위한 프록시 설정, 수동으로 플러그인 올리기, 업데이트 사이 정보등을 설정할 수 있다. HTTP 프록시 설정 : 프록시 설정을 통해 업데이트를 수행한다. 플러그인 올리기 : 다운로드 받은 플러그인 파일을 수동으로 설치한다. 업데이트 사이트 : 업데이트 사이트 경로를 입력한다. 4-5.Guide.png

9. Backing up/Restoring Jenkins

Backup ThinBackup 설치 Backup을 하기 위해 ThinBackup Plugin을 설치한다. Jenkins 관리 > 플러그인 관리 9-1.Guide.png 설치 기능 탭 선택 우측의 필터란에 backup 이라고 입력 후 ThinBackup 체크 하여 재시작 없이 설치하기 버튼 클릭 한다. 9-2.Guide.png ThinBackup 설정 ThinBackup을 통해 백업 설정을 위해 Jenkins 관리 > ThinBackup 선택한다. 9-5.Guide.png 설정을 위해 Settings를 클릭한다. 9-6.Guide.png Backup 설정은 다음 정보를 참고하여 설정을 수행한다. Backup Directory : ex) /home/backup Backup schedule for full backups : * * * * * command to execute[*minute(0-59),*hour(0-23),*day(1-31),*month(1-12),*day of week(0-6 sunday to saturday) Backup schedule for differential backups : 증분백업은 풀 백업 이후 수정된 전체 파일만 백업 합니다. Max number of backup sets : 백업 세트의 최대 수 Files excluded from backup : 백업에서 제외 된 파일 Wait until Jenkins/Hudson is idle to perform a backup : 백업을 수행하기 위해 Jenkins / Hudson이 idle 상태가 될 때까지 기다립니다. > Force Jenkins to quiet mode after specified minutes : 지정한 시간이 지난 후 Jenkins는 자동모드로 된다 Backup build results : 빌드 결과 백업 Backup build archive : 아카이브 빌드 백업 Backup only builds marked to keep : 백업만 유지되도록 표시된 빌드 Backup 'userContent' folder : userContent 폴더 백업 Backup next build number file : 다음 빌드 번호 파일 백업 Backup plugins archives : 아카이브 플러그인 백업 Backup additional files : 추가 파일 백업 > Files included in backup (regular expression) : 백업에 포함 된 파일 Clean up differential backups : 증분 백업 정리 Move old backups to ZIP files : 이전 백업 파일을 ZIP 파일로 이동 9-7.Guide.png Backup 시작 백업을 시작하기 위해 Backup Now 버튼을 클릭 한다. 9-8.Guide.png Restore 백업된 파일을 복원하기 위해 Restore 버튼을 클릭 한다. 9-10.Guide.png Restore Options 설정 후 Restore 버튼을 클릭 한다. restore backup from : 복원 시점 Restore next build number file (if found in backup) : 다음 빌드 번호 파일 복원 Restore plugins : 플러그인 복원 9-14.Guide.png Jenkins 관리 > System Log 확인 9-11.Guide.png 모든 Jenkins 로그 클릭 한다. 9-12.Guide.png Restore가 완료 되었음을 확인 할 수 있다. 9-13.Guide.png

5. Jenkins CLI(보류)

Jenkins CLI Jenkins 관리 > Jenkins CLI 메뉴로 접속 한다. 5-1.Guide.png

1. Jenkins 시스템 설정

Jenkins Configuring the System Jenkins의 시스템을 설정하기 위해 Jenkins 관리 > 시스템 설정 클릭한다. 1-1.Guide.png 일반 시스템 설정 다음과 같은 정보를 수정할 수 있다.  작업공간 최상위 디렉토리 빌드 기록 최상위 디렉토리 시스템 메시지 of executors Labels : 레이블 Usage Use this node as much as possible : 기본 설정 Only build jobs with label expressions matching this node : 노드와 레이블이 일치 할때 빌드 Quiet period : 젠킨스가 빌드 시작하기 전에 지정된 기간 동안 대기 SCM checkout retry count : 체크아웃 재 카운트 Restrict project naming : 프로젝트 이름 지정 제한 1-2.Guide.png Global properties Global properties에서는 환경변수, 도구 위치 등을 설정한다. Environment variables : 환경 변수 값을 추가하거나 삭제할 수 있다. Tool Locations : Tool 위치를 지정하거나 삭제할 수 있다. Help make Jenkins better by sending anonymous usage statistics and crash reports to the Jenkins project. : 젠킨스 사용에 대한 정보를 주기적 발송 1-3.Guide.png Timestamper Timestamper는 Jenkins에서 사용되는 시간 형식을 설정한다. System clock time format : 시스템 시간 형식 Elapsed time format : 경과 시간 형식 1-4.Guide.png Jenkins Location Jenkins Location에서는 Jenkins 주소 및 이메일 설정할 수 있다. Jenkins URL : 젠킨스 웹 주소 System Admin e-mail address : 시스템 관리자 이메일 주소 1-5.Guide.png SSH Server SSHD Port : SSHD 포트 1-6.Guide.png GitHub GitHub 섹션에서는 GitHub 연동을 위한 정보들을 설정할 수 있다. GitHub Servers Add GitHub Server > GitHub Server : GitHub 서버 세팅 Re-register hooks for all jobs Override Hook URL Specify another hook url for GitHub configuration : GitHub 다른 hook 주소 설정 Shared secret  Add > Jenkins : Jenkins가 요청을 GitHub에서 가져 왔는지 확인하기 위한 서명하는 데 사용 Additional actions  Convert login and password to token : 로그인, 비밀번호를 GitHub 개인 토큰으로 변환 1-7.Guide.png GitHub Enterprise Servers API endpoint : API 끝지점 Name : 이름 1-8.Guide.png Pipeline Model Definition Docker Lable : 독커 레이블 Docker registry URL : 독커 레지스트리 URL Registry credentials > Add > Jenkins : 레지스트리 자격증명 1-9.Guide.png Global Pipeline Libraries 시스템에서 Pipeline Job을 실행할때 이용가능한 라이브러리를 등록 한다. Name : 이름 Default version : 기본 버전 Load implicitly : 암시적으로 Allow default version to be overridden : 기본 저번을 무시하도록 허용 Retrieval method Modem SCM : 최신 인터페이스를 사용하여 SCM 플러그인에서 라이브러리를 로드 Legacy SCN : Jenkins Pipeline에서 지원하는 모든 SCM 플러그인에서 라이브러리를 로드 1-10.Guide.png Build-timeout Plugin > Build Step Action Enable BuildStep Action : 빌드셋업 동작 사용 1-11.Guide.png Git plugin Jenkins와 Git 연동 설정을 위한 설정 Global Config user.name Value : 글로벌 설정 유저 이름 값 Global Config user.email Value : 글로벌 설정 유저 이메일 값 Create new accounts base on author/committer's email : 커미터 이메일 기반으로 새 계정 만들기 1-12.Guide.png Subversion Jenkins와 Subversion 연동을 위한 설정 Subversion Workspace Version : Svn workspace 버전 Exclusion revprop name : 제외 리플롭 이름 1-13.Guide.png Shell Shell executable : 만약 sh 바이너리 PATH가 외부에 있을 경우, 절대 경로를 지정 1-14.Guide.png Extended E-mail Notification SMTP server : smtp 서버 Default user E-mail suffix : 기본 이메일 사용자 User SMTP Authentication : smtp 사용자 Use SSL : SSL 사용 SMTP port : smtp 포트 Charset : 캐릭터셋 Default Content Type Plain Text (text/plain) : 일반 텍스트 HTML (text/html) : HTML 텍스트 Use List-ID Email Header : 목록 ID 이메일 헤더 사용 Add 'Precedence: bulk' Email Header : 우선순위 이메일 해더 추가 Default Recipients : 기본 수신자 Reply To List : 응답 목록 Emergency reroute : 긴급 재 전송 라우터 Excluded Recipients : 제외된 수신자(필터링으로 수신자를 걸러냄) Default Subject : 기본 제목 Maximum Attachment Size : 최대 첨부파일 사이즈 Default Content : 기본 내용 Default Pre-send Script : 미리 보내기 스크립트 Default Post-send Script : 전송 후 스크립트 1-15.Guide.png Additional groovy classpath : 추가 그루비 클래스 패스 Enable Debug Mode : 디버그 모드 Require Administrator for Template Testing : 관리자 권한 있는 사용자에게 이메일 템플릿 링크 표시 Enable watching for jobs : 감시 기능 Default Triggers: 기본트리거 1-16.Guide.png E-mail로 알려줌 해당 섹션에서는 이메일 알림을 위해 사용되는 서버 정보를 입력한다. SMTP 서버 : smtp 서버 Default user e-mail suffix : 기본 유저 이메일 Use SMTP Authentication : smtp 인증 사용 SSL 사용 : SSL 사용 SMTP Port : smtp 포트 Reply-To Address : 회신 주소 Charset : 캐릭터셋 Test configuration by sending test e-mail : 테스트 세팅으로 테스트 이메일 전송 1-17.Guide.png

8. Jenkins Managing Users

이 문서는 Jenkins에서 사용자를 관리하는 방법에 대한 가이드를 제공한다. Jenkins 사용자 관리 Jenkins에는 다음과 같은 여러가지의 인증 방법이 지원되고 있다. Delegate to servlet container Jenkins own user database LDAP Unix user/group database 이를 설정하기 위해서는 Jenkins 관리 > Configure Global Security의 Access Control을 이용한다. 8-1.Guide.png Jenkins own user database Jenkins own user database는 Jenkins 자체적인 사용자 관리 시스템을 사용하는 방법으로 관리자가 사용자를 추가하는 방식과 일반 사용자가 가입을 하는 방법이 있다.  사용자 추가 Jenkins의 사용자를 추가하기 위해 Jenkins 관리 > Manage Users 메뉴로 이동한다. 왼쪽 메뉴에서 사용자 생성을 선택하고 적절한 정보를 입력 후 Create User 버튼을 클릭한다. image2017-3-8_12-56-0.png 사용자 가입 허용 설정 사용자 가입 허용을 위해 Jenkins 관리 > Configure Global Security > Access Control에서 사용자의 가입 허용을 체크 후 Save 버튼을 설정한다. 8-2.Guide.png 계정 생성 사용자의 가입 허용 후에 다음과 같이 로그인 화면에서 계정 생성을 확인할 수 있다. 8-3.Guide.png 회원 가입을 위한 적절한 Sign up 정보를 입력하고 Sign up 버튼을 클릭 한다. 8-4.Guide.png LDAP 방식의 사용자 관리 LDAP을 사용하여 사용자 인증을 위해 Jenkins 관리 > Configure Global Security > Access Control에서 LDAP을 선택하고 필요한 정보를 입력한다. image2017-3-8_13-1-23.png User 정보 변경 User 정보 변경 하기 위해선 admin 계정으로 접속 해야 한다. Jenkins 관리 > Manage Users 클릭 한다. 8-6.Guide.png 정보를 변경 할 유저 우측의 기어 모양을 클릭 한다. 8-7.Guide.png 아래 그림 처럼 정보를 변경 할 수 있다. 정보를 변경 하고 Save 버튼을 클릭 한다. 8-8.Guide.png User 삭제 User 삭제 하기 위해선 admin 계정으로 접속 해야 한다. Jenkins 관리 > Manage Users 클릭 한다. 삭제 하고 싶은 유저의 우측 image2017-3-7_10-52-29.png 아이콘을 클릭 한다. 8-10.Guide.png 삭제 할 것인지 한번 더 묻는다. Yes 버튼을 클릭 한다. 8-11.Guide.png 유저가 삭제 되었음을 확인 할 수 있다. 8-12.Guide.png User 권한 부여 유저 권한 부여 하기 위해선 admin 계정으로 로그인 해야 한다. Jenkins 관리 > Configure Global Security 클릭 한다. Authorization > Matrix-based security 또는 Project-based Matrix Authorization Strategy > User/group to add 의 유저를 추가 해주고 권한을 부여 하고 Save 버튼을 클릭 한다. 8-13.Guide.png 만약 실수로 Admin이 Access 할 수 없을 경우, 다음과 같이 $Jenkins_Home$config.xml 를 설정 후 Jenkins를 재 시작 한다. 8-15.Guide.png

2. Jenkins Managing Security

Configure Global Security Enable security TCP port for JNLP agents > Fixed, Random, Disable Disable remember me : 나를 기억하지 못하게 한다. Access Control 다음 사용자 접근 권한에 대한 간략한 정보를 보여준다. 사용자 구성 및 관리는 사용자 관리 섹션을 참고한다. Security Realm : 보안 영역 Delegate to servlet container  assets, cli, git, github-webhook, jnlpJars, subversion, whoAmI : 서블릿 컨테이너를 이용하여 사용자 인증 Jenkins' own user database 사용자 가입 허용 : Jenkins 데이터베이스 사용 LDAP  ex) ldaps://server:port : LDAP 사용자 인증 Unix user/group database  Service Name > Test : 유닉스 운영체제 사용자 데이터베이스 인증 Authorization : 권한 부여 Anyone can do anything : 누구나 무엇이든 할 수 있다. Legacy mode : 레거시 모드 Logged-in users can do anything Allow anonymous read access : 로그인 한 사용자는 무엇이든 할 수 있다. Matrix-based security : 매트릭스 기반 보안 Project-based Matrix Authorization Stategy : 프로젝트 기반 매트릭스 권한 부여 2-1.Guide.png Markup Formatter Plain text, Safe HTML : 일반 텍스트, HTML Prevent Cross Site Request Firgery exploits 교차 사이트 요청 위조 공격 방지 Crumbs Crumb Algorithm : Crumbs 알고리즘  Default Crumb Issuer > Enable proxy compatibility Plugin Manager Use browser for metadata download : 메타데이터 다운로드에 브라우저 사용 Enable Slave → Master Access Control : 슬래아브 활성화 2-2.Guide.png

7. Jenkins Managing Nodes

노드관리 Jenkins 관리 > 노드 관리 클릭 한다. 7-1.Guide.png 노드 설정 설정 하기 위해 노드의 우측의 기어 아이콘 버튼을 클릭 한다. 7-2.Guide.png 설정 of executors 라벨 Usage > Use this node as much as possible 7-3.Guide.png

백업 파일로 부터 하나의 Job 복원 방법

이 페이지는 백업 파일로 부터 하나의 Job를 복원하는 방법을 정리한다. 사전 조건 Jenkins 관리자 계정 Jenkins master 가 설치된 서버의 Jenkins 계정 thinBackup plugin이 생성한 백업 파일 존재 백업 절차 백업 폴더 확인 Jenkins 관리 > ThinBackup > Settings > Backup directory 필드 확인 Screen Shot 2021-09-03 at 9.55.06 PM.png 백업 파일 또는 폴더 확인 복원할 백업 폴더 이름 규칙: FULL-<yyyy-MM-dd_hh-mm> Jenkins home directory 경로 확인 Jenkins 관리 > 시스템 설정 > 홈 디렉터리 Screen Shot 2021-09-03 at 10.02.21 PM.png  복원할 job home directory로 복사 예)  $ cd /data/backup-jenkins-master/FULL-2021-10-20_13-20/jobs $ cp -r EXAMPLE-JOB /data/jenkins_home/jobs/ Job 읽어 들이기 복원한 job을 Jenkins에 반영한다. Jenkins 관리 > Reload Configuration from Disk 복원된 Job 확인 

CollabNet Subversion

Set up CollabNet Edge

CollabNet Edge는 administration console은 jetty 그리고 apache httpd로 svn 서비스가 구성된다. 설치 환경 Windows, Linux, MacOS 지원 사전 설치: Java 설치 가이드 CollabNet에서 제공하는 설치 가이드를 참조한다. Set up Subversion Edge http://help.collab.net/topic/csvn/action/setupcsvn.html

CollabNet Subversion Manage repositories

이 문서는 CollabNet Subversion에서 저장소를 관리하는 가이드를 제공한다. 저장소 관리 Repositories를 생성 하기 위해 http://ipaddress:3343 http://ipaddress:3343 으로 접속 및 로그인 한다. 저장소 리스트 보기 좌측 메뉴의 Repository List를 클릭 하면 모든 Repositories의 정보를 확인 할 수 있다. 해당 Repository의 아래 메뉴의 기능을 지원 한다. 생성 Discover 정보 Dump 검증 Load 삭제 저장소 생성 상단의 Repositories를 클릭 한다. 생성 버튼을 클릭한다. 14.Guide.png Repository를 생성하기 위해 다음 정보를 입력하고 Create 버튼을 클릭한다. Name : 저장소 명(영문, 빈칸 없이 생성) Initialize Empty repository : 빈 저장소 생성 Create standard trunk/branches/tags structure  Backup : 백업으로 생성 15.Guide.png 저장소 정보 새로운 저정소가 생성되며, 해당 저장소에 대한 정보를 확인할 수 있다. Status : 상태정보 Filesystem Format : 파일 시스템 포멧 정보 Revisions : 리비전 정보 Repoitory Format : Repoitory 정보 Size : 사이즈 정보 Sharding : 공유 정보 Packed : 패키지 정보 Representation Sharing  Supports : Supports 정보 UUID : UUID 정보 Hook Scripts : Hook Scripts Backup Files : 백업 파일의 대한 정보 Scheduled Jobs : 스케쥴 작업 정보 Size Report : 저장소 사이즈의 대한 정보 16.Guide.png 저장소 덤프 저장소를 덤프 하기 위해 해당 저장소를 선택 하고 Dump 버튼을 클릭 한다. 29.Guide.png 덤프 옵션 Revisions : 콜론을 사용하여 수정 범위를 입력 한다, 모든 수정본을 포함 하려면 입력란을 비워둔다. Incremental : 덤프의 첫번째 수정된 파일 디렉토리만 포함 Use deltas : 이전 버전의 델타로 표시되므로 파일을 작게 만들 수 있지만 필터랑이나 편집에는 적합하지 않다. Compress : zip 파일 형식으로 압축 Apply filter : 덤프되는 내용을 제한하는 경로 기반포함 또는 제외 필터 덤프 버튼을 클릭 한다. 30.Guide.png 덤프 파일이 생성이 되었다. 31.Guide.png 새로고침으로 백업 파일이 생성 되었음을 확인 할 수 있다. 덤프파일을 다운 받을 수 있거나 삭제가 가능하다. 32.Guide.png 저장소 검증 저장소 검증을 하기 위해 우선 Mail Server를 설정 해야 한다. SMTP 정보를 입력하고 저장 한다. 상단 메뉴의 Administraton > Mail Server Mail Server Name Port Username Password Connection Security Protocol From Address 33.Guide.png 저장소 리스트 화면으로 돌아 와서 해당 저장소를 선택하고 검증 버튼을 클릭한다. 34.Guide.png 저장소 검증의 대한 메일이 해당 메일로 전송이 되었음을 확인 할 수 있다. 35.Guide.png 저장소 Load 저장소 Load 하기 위해서 Dump파일이 있어야 한다. Dump 만드는 방법은 위에 저장소 덤프 설명을 참고 하기 바란다. 36.Guide.png zip으로 만든 Dump 파일을 업로드 한다. Schedule load 버튼을 클릭 한다. Load Repository from Dump File Repository name Status Head revision UUID 37.Guide.png 덤프파일이 저장소로 업로드 되도록 예약이 되었다. 진행사항은 Jobs 화면에서 볼 수 있다. 38.Guide.png Jobs 화면으로 이동 한다. Administraton > Jobs 작업이 완료 되었음을 확인 할 수 있다. 39.Guide.png 저장소 삭제 저장소 삭제 하기 위해 저장소 List로 이동 합니다. 삭제 할 저장소를 선택 하고 삭제 버튼을 클릭 합니다. 40.Guide.png 마지막으로 삭제 할 것인지? 묻는다. 계속 진행 하려면 화면에서 보여주는 텍스트를 입력 하고 OK 버튼을 클릭 한다. 41.Guide.png 저장소가 삭제 되었음을 확인 할 수 있다. 42.Guide.png 저장소 접근 권한 설정 저장소의 접근 권한을 설정하기 위해 저장소 메뉴에서 Access Rules을 선택한다. 편집 버튼을 클릭하여 편집을 수행한다. 18.Guide.png 그룹 설정을 위해서 [groups]을 사용한다. 다음과 같이 그룹명 = 사용자, 사용자2 와 같은 형태로 그룹에 사용자를 할당할 수 있다. [groups] mgrs = user1, user2 engrs = engr1, engr2 allgroups = @mgrs, @engrs 설명 /tags 라는 디렉토리는 전체 유저가 읽을 수 있는 권한이 있고 @mgrs 라는 그룹 유저들은 읽고 쓰기 권한이 있는 설정이다. [dev:/tags] * = r @mgrs = rw 설명 /banches/components/xxx 라는 디렉토리는 사용자1은 읽고 쓰기 권한이 있고 사용자2는 읽을 수 있는 권한이 있다. [dev:/banches/components/xxx] user1 = rw user2 = r user3 19.Guide.png Access Rules이 설정 되었음을 확인 할 수 있다.20.Guide.png 저장소 백업 설정 저장소 백업을 수행하기 위해 백업 스케쥴을 설정한다. 이를 위해 상단 메뉴의 Repositories 클릭 > 좌측 메뉴 Backup Schedule을 클릭한다. 새로운 백업 잡 생성 새로운 잡을 생성하기 위해 다음 그림과 같이 New Jobs를 클릭 한다. 21.Guide.png Repository List가 나온다 백업 스케쥴을 설정 할 대상 Repository를 선택하고 다음과 같이 스케쥴 타입을 설정한다. Type of Job :  Full Dump Backup,  Hotcopy Backup When to Run :  Hourly,  Daily,  Weekly Number to Keep :  Use deltas 22.Guide.png 해당 백업을 적용할 Repository를 선택 하고 Create 버튼을 클릭하여 스케쥴을 생성한다. 23.Guide.png 백업 스케쥴이 생성이 되었고 하단의 Repository의 백업 스케쥴 설정한 정보를 확인 할 수 있다. 24.Guide.png 저장소 백업 설정 변경 저장소 백업 설정 변경을 수행하기 위해 백업 스케쥴을 변경한다. 이를 위해 상단 메뉴의 Repositories 클릭 > 좌측 메뉴 Backup Schedule을 클릭한다. 아래 그림은 토요일에 AM 2:00에 백업 스케쥴로 변경한다고 가정하고 만든 예제 그림이다. 변경이 되었으면 Replace 버튼을 클릭한다. 25.Guide.png 저장소 백업 설정이 변경 되었음을 확인 할 수 있다. 26.Guide.png 저장소 백업 삭제 저장소 백업 삭제를 수행하기 위해 백업 스케쥴을 삭제한다. 이를 위해 상단 메뉴의 Repositories 클릭 > 좌측 메뉴 Backup Schedule을 클릭한다. 저장소 백업 스케쥴을 삭제 하고 싶은 저장소를 선택 하고 Delete 버튼을 누른다. 27.Guide.png 저장소 백업 스케쥴이 삭제 되었음을 확인 할 수 있다. 28.Guide.png 저장소 Hook 설정 사전 조건: Hook 관리 권한을 가진 사용자 계정 필요 csvn/data/conf/security.properties에 편집 가능 설정 hook.script.editor.enabled=true Step 1) Hook 관리 화면 진입 Repositories 화면 >> 저장소 오른편의 "OK" 버튼 클릭 Screen Shot 2018-02-20 at 1.20.32 PM.png Step 2) 관리할 hook 선택 원하는 설정에 맞는 버튼 선택 create: 새로운 hook script upload Edit: 등록된 script 수정 Copy: 등록된 script 복사 Rename: 등록된 script 이름 변경 Download: 등록된 script 다운로드 Delete: 등록된 script 삭제 업로드, 이름변경, 복사되는 script는 executable 속성이 지정됨 Screen Shot 2018-02-20 at 1.23.59 PM.png 참고 문서 : Manage repositories http://help.collab.net/topic/csvn/action/managerepositories.html

CollabNet Subversion Edge의 관리자 암호 초기화 방법

Edge의 관리자 암호 기준이 까다롭기 때문에 복잡한 암호를 설정해야 하기 때문에 자칫 설정했던 암호가 생각나지 않는 경우가 있다. 간단하게 암호를 초기화 할 수 있으니 다행 :) Screen Shot 2018-03-24 at 6.45.41 AM.png Step 1) Subversion Edge 서비스 중지 사용하는 Linux, Windows의 서비스 종료 방법에 따라 서비스 종료 Step 2) HSQL db 파일 찾기 csvn-production-hsqldb.script 파일의 위치 찾기 <csvn 설치 폴더>/data 하위에 위치 Step 3) 관리자 암호 수정 csvn-production-hsqldb.script 파일을 편집기로 열어서 Super Administrator 문자열을 찾아 암호 수정 INSERT INTO USER VALUES(1,2,'admin user','admin@example.com',TRUE, 'curvcasdef7898abde4252aedcb4352','Super Administrator','admin') curvc... 부분이 비밀번호 설정하는 부분이고 다음 문자열로 대체 (암호: admin 에 해당) 21232f297a57a5a743894a0e4a801fc3 Step 4) 파일 저장 후 서비스 재기동 id / password = admin admin 으로 로그인

CollabNet Subversion Manage users

User 생성 User 생성을 하기 위해 http://ipaddress:3343 http://ipaddress:3343 접속을 한다. 상단의 메뉴 Users 클릭 생성 아이콘을 클릭 한다. 1.Guide.png Create User 아래의 그림은 User를 생성 하는 화면 이다. 각 필드의 대한 설명이다. User를 생성할때 적절한 룰 권한을 설정하여 User를 생성 한다. Login Name Full Name Password Confirm Password Email Description Roles Granted ROLE_ADMIN - Super/Root Administrator (Full Privileges) ROLE_ADMIN_HOOKS - Repository Hook Scripts Administrator ROLE_ADMIN_REPO - Repositories Administrator ROLE_ADMIN_SYSTEM - System/Server Administrator ROLE_ADMIN_USERS - User Account Administrator ROLE_USER - Basic User Authority, required for console access 3.Guide.png User가 생성이 된 것을 확인 할 수 있다. 4.Guide.png User 정보 및 권한 변경 User 정보를 변경 하거나 권한 변경을 하기 위해서 ROLE_ADMIN_USERS 권한을 가진 User가 필요하다. 또는 슈퍼 권한을 가진 User가 일반 유저의 정보나 권한 변경이 가능하다. 아래 그림은 일반 유저를 생성하여 일반 유저를 정보를 변경하거나 권한을 변경하는 예제 이다. 먼저 일반 유저를 생성한다. 5.Guide.png User List의 새로 생성한 일반 user1를 클릭한다. 6.Guide.png 패스워드 변경시 Change Password를 클릭 한다. 7.Guide.png Password 및 정보를 변경하고 권한을 추가 해주고 Update 버튼을 클릭한다. 8.Guide.png User가 변경 되었음을 확인 할 수 있다. 9.Guide.png User 삭제 User 삭제를 하기 위해서 ROLE_ADMIN_USERS 권한을 가진 User가 필요하다. 또는 슈퍼 권한을 가진 User가 일반 유저를 삭제가 가능하다. 상단 Users 클릭 User List의 삭제 해야 할 유저를 클릭 한다. 10.Guide.png Delete 버튼을 클릭 한다. 11.Guide.png OK 버튼을 클릭 한다. 12.Guide.png 선택한 User가 삭제 되었음을 확인 할 수 있다. 13.Guide.png 참고 문서 Manage users http://help.collab.net/topic/csvn/action/manageusers_csvn.html

CollabNet Edge Reverse Proxy 구성 방법

이 문서는 CollabNet Edge를 reverse proxy로 구성하는 방법을 제공한다. Overview Reverse proxy를 구성하려면 base URL (외부 포트)과 내부 URL (내부 포트)를 다르게 구성할 수 있어야 한다. CollabNet management console은 내부/외부 포트 구성을 제공하지 않는다.  제한 사항 CollabNet이 운영되는 machine에 80포트를 사용하는 서비스가 없어야 함 CollabNet이 80과 추가의 내부 포트를 사용하게 되기 때문임 Reverse proxy란? 클라이언트가 service.com 웹 서비스에 데이타를 요청하면 Reverse Proxy는 이 요청을 받아서 내부 서버에 (internal.service.com)서 데이타를 받은후에 이 데이타를 클라이언트에 전달하는 방식이다. 공인 IP가 하나인 환경에서 여러개의 서비스가 80 또는 443 포트를 공유할 경우 유용하다. 80 또는 443 포트 전체를 수신하는 proxy server 구성 proxy server는 domain name (또는 IP 주소)을 기준으로 내부 서버에서 데이터를 받아서 요청한 외부 client로 전송 Forward proxy는? 내부 망에서 외부 서버 (service.com)에 연결을 요청하면 proxy server가 외부 서버로 부터 데이터를 수신하여 내부 client에 전달하는 방식이다. 정보보안을 위해 외부로 나가는 http(s) 연결 허용을 제어하거나 패킷을 감시할 때 사용하는 방식이다. 우리가 browser에 설정하는 proxy 서버가 예 Configuration 서비스 base  URL과 포트 설정 외부에서 접속하는 관점으로 Hostname (IP도 가능), Port 설정 Screen Shot 2018-02-27 at 9.24.31 AM.png Reverse Proxy 서버에 제공할 포트 설정 Step 1) httpd.conf 에 reverse proxy가 사용할 내부 포트 정의 <CollabNet SVN 설치 경로>/data/conf/httpd.conf Listen <포트> 예) Listen 18080 Step 2) HTTP service 재시작 Administration console에서 제공하는 서비스 제어 방법을 사용하여 HTTP 서비스를 재 시작 Screen Shot 2018-02-27 at 9.34.47 AM.png 구성 확인 내부 URL, 외부 URL 로 정상 접속되는지 확인 내부 URL 접속 확인 Browser로 http(s)://<CollabNet ip 주소>:<내부 포트>/<Browse repositories path: viewvc> 예) http://192.168.0.50:18080/viewvc http://192.168.0.50:18080/viewvc 외부 URL 접속 확인 Administration console >> Repositories 화면에서 제공되는 repository 주소를 browser 또는 svn client 로 접속 시도 Screen Shot 2018-02-27 at 9.37.58 AM.png