• https://www.toptal.com/developers/gitignore
• 위 사이트에서 아래와 같이 옵션들을 추가한 뒤 생성을 클릭한다.

• 그럼 아래와 같은 gitignore 파일이 생성된다. 복사해서 본인의 gitignore에 추가하면 끝 ! 

• 아래는 이번 프로젝트때 내가 사용한 gitignore 파일 이다 : ) 

application-local.properties

# intelliJ
HELP.md
.gradle
.idea
build/
!gradle/wrapper/gradle-wrapper.jar
!**/src/main/**/build/
!**/src/test/**/build/

# User-specific stuff
.idea/**/workspace.xml
.idea/**/tasks.xml
.idea/**/usage.statistics.xml
.idea/**/dictionaries
.idea/**/shelf

# AWS User-specific
.idea/**/aws.xml

# Generated files
.idea/**/contentModel.xml

# Sensitive or high-churn files
.idea/**/dataSources/
.idea/**/dataSources.ids
.idea/**/dataSources.local.xml
.idea/**/sqlDataSources.xml
.idea/**/dynamic.xml
.idea/**/uiDesigner.xml
.idea/**/dbnavigator.xml

# Gradle
.idea/**/gradle.xml
.idea/**/libraries

# Gradle and Maven with auto-import
# When using Gradle or Maven with auto-import, you should exclude module files,
# since they will be recreated, and may cause churn.  Uncomment if using
# auto-import.
# .idea/artifacts
# .idea/compiler.xml
# .idea/jarRepositories.xml
# .idea/modules.xml
# .idea/*.iml
# .idea/modules
# *.iml
# *.ipr

# CMake
cmake-build-*/

# Mongo Explorer plugin
.idea/**/mongoSettings.xml

# File-based project format
*.iws

# IntelliJ
out/

# mpeltonen/sbt-idea plugin
.idea_modules/

# JIRA plugin
atlassian-ide-plugin.xml

# Cursive Clojure plugin
.idea/replstate.xml

# SonarLint plugin
.idea/sonarlint/

# Crashlytics plugin (for Android Studio and IntelliJ)
com_crashlytics_export_strings.xml
crashlytics.properties
crashlytics-build.properties
fabric.properties

# Editor-based Rest Client
.idea/httpRequests

# Android studio 3.1+ serialized cache file
.idea/caches/build_file_checksums.ser

### Intellij Patch ###
# Comment Reason: https://github.com/joeblau/gitignore.io/issues/186#issuecomment-215987721

# *.iml
# modules.xml
# .idea/misc.xml
# *.ipr

# Sonarlint plugin
# https://plugins.jetbrains.com/plugin/7973-sonarlint
.idea/**/sonarlint/

# SonarQube Plugin
# https://plugins.jetbrains.com/plugin/7238-sonarqube-community-plugin
.idea/**/sonarIssues.xml

# Markdown Navigator plugin
# https://plugins.jetbrains.com/plugin/7896-markdown-navigator-enhanced
.idea/**/markdown-navigator.xml
.idea/**/markdown-navigator-enh.xml
.idea/**/markdown-navigator/

# Cache file creation bug
# See https://youtrack.jetbrains.com/issue/JBR-2257
.idea/$CACHE_FILE$

# CodeStream plugin
# https://plugins.jetbrains.com/plugin/12206-codestream
.idea/codestream.xml

# Azure Toolkit for IntelliJ plugin
# https://plugins.jetbrains.com/plugin/8053-azure-toolkit-for-intellij
.idea/**/azureSettings.xml

### Java ###
# Compiled class file
*.class

# Log file
*.log

# BlueJ files
*.ctxt

# Mobile Tools for Java (J2ME)
.mtj.tmp/

# Package Files #
*.jar
*.war
*.nar
*.ear
*.zip
*.tar.gz
*.rar

# virtual machine crash logs, see http://www.java.com/en/download/help/error_hotspot.xml
hs_err_pid*
replay_pid*

### macOS ###
# General
.DS_Store
.AppleDouble
.LSOverride

# Icon must end with two \r
Icon


# Thumbnails
._*

# Files that might appear in the root of a volume
.DocumentRevisions-V100
.fseventsd
.Spotlight-V100
.TemporaryItems
.Trashes
.VolumeIcon.icns
.com.apple.timemachine.donotpresent

# Directories potentially created on remote AFP share
.AppleDB
.AppleDesktop
Network Trash Folder
Temporary Items
.apdisk

### macOS Patch ###
# iCloud generated files
*.icloud

### Windows ###
# Windows thumbnail cache files
Thumbs.db
Thumbs.db:encryptable
ehthumbs.db
ehthumbs_vista.db

# Dump file
*.stackdump

# Folder config file
[Dd]esktop.ini

# Recycle Bin used on file shares
$RECYCLE.BIN/

# Windows Installer files
*.cab
*.msi
*.msix
*.msm
*.msp

# Windows shortcuts
*.lnk

https://www.toptal.com/developers/gitignore

https://niceman.tistory.com/114

PR (Pull Request)

① PR(Pull Request) 

• 내 작업내역을 바로 merge 하지 않고, 참여하고 있는 프로젝트에 내 작업(branch)를 merge해달라고 요청하는 것. 
• PR 메시지엔 항상 #이슈번호를 포함해 준다. 협업하는 사람들과 의사소통임을 기억하자 !
• 내가 참여하고 싶은 오픈소스 프로젝트가 있다면 코드를 작성해서 PR을 보내볼 수도 있다. 내가 다른 사람 소스를 사용하는 것을 넘어서 프로젝트에 참여할 수 있게 되는 것!  ( Github repo 의 contribution 페이지에 기여한 사람들 정보를 적어두기도 한다. )
• 내 컴퓨터에서 명령을 내려서 PR 을 하는 방법도 있지만, Github 페이지에서 PR 하는 것이 훨씬 직관적이므로 통상적으로, Github repo 페이지에서 PR 한다.

       + 오픈 소스 예시 : 주니어 개발자 채용 정보( https://github.com/jojoldu/junior-recruit-scheduler )

② 로컬 repo로 fetch(페치)후 pull 해오기

• pull은 commit 내역을 가져와서 로컬 branch 에 commit 을 합친다면, fetch 는 연결되어있는 원격 repo 의 commit 내역을 가져만 온다. 원격 repo 의 commit 내역을 합치지 않고 보기만 할때 주로 사용한다.
• PR 은 리뷰하는 과정을 통상적으로 포함한다. 아래와 같은 상황에서는 PR 후에도 추가적으로 commit을 해야할 경우가 있다.
  • 리뷰에서 추가 수정을 요청받거나
  • PR 을 그대로 merge한다고 했을 때 merge conflict 가 나는 것을 미리 고치기
  • 따라서 PR 이 완료되기 전까진 PR 요청을 한 로컬 브랜치를 삭제하지 않도록 한다 ! PR 이 반영되기 전 추가 commit을 해야한다면, 로컬 branch에서 commit 후 원격 branch에 push해서 변경된 내용을 반영한다.

③ fork(포크)

• 원본 소스코드를 복사해서 새로운 독립적인 소프트웨어로 개발하는 것
• 마치 어떤 문서를 복사해서 그 위에 내가 원하는대로 수정해서 사용하는 것과 비슷한다.
• repository 의 사용권한이 다른 사람에게 있을 때, 예를 들면 많은 사람들이 참여하는 오픈소스처럼 내가 소유하고 있는 repo 가 아니더라도 프로젝트 제안할 때는 일단 프로젝트의 내용을 내 공간으로 가져와야 한다.
• 원본 repo를 내 공간으로 fork 해 온 후 PR을 날린다.
• 내가 merge 할 권한이 없으므로 repo 관리자의 merge pull request (PR merge하기) 를 기다려야 한다.

amend - 최신 commit 고치기

amend : 최신의 commit을 수정하는 것.  amend 로는 가장 최신의 commit 만 고칠 수 있다.

① push 전 amend

• 아래 그림과 같이 file status 로 가서 오른쪽 하단의 옵션에서 마지막 커밋 수정을 클릭하면 된다.

② push 후 amend

1. 상단 메뉴바 - sourcetree - Preference 에 들어간다.
2. Advanced - force push 를 선택
3. amend 를 해서 commit 메시지를 수정한다.
4. 강제 푸시 옵션을 선택하고 푸시한다. 상단 push 를 누른 후 뜨는 창에 강제 푸시 옵션을 체크!

• 강제 푸시 옵션은 꼭 필요할 때만 나 혼자만 작업하는 branch에서 사용해야한다.
• 다른 사람이 내가 수정하려고 한 commit 을 pull 하지 않은 상태여야한다.
• 그렇지 않으면 다른 사람의 작업내역이 모두 꼬이기 때문에 다른 사람들은 기존에 작업하던 프로젝트를 지우고 새롭게 프로젝트를 clone 해야하는 상황이 발생!
• 일반적인 push 를 할 때는 강제푸시 옵션에 체크가 되어있지 않는지 꼭 확인하기 !

Revert, Reset

① Revert

• 앞서 배운 amend로 되돌리기는 가장 최신의 commit 만 되돌릴 수 있다. 그리고 어떤 걸 되돌렸는지도 알 수 없다.
• 다른 사람들과 같이 협업하고 있다면 어떤 내용이 되돌려졌는지 기록으로 남기는 것도 중요
• 어떤 내용을 되돌렸는지 새로운 commit을 남기는 것을 revert(리버트) 라고 한다. 최신 commit 뿐만 아니라 이전에 했던 commit 도 revert 로 되돌릴 수 있다!
• sourcetree 에서 되돌리고 싶은 commit 누르고 우클릭 - 커밋 되돌리기를 선택. 아래 같은 팝업창이 뜨면 확인/예 클릭.

② Reset

• reset (리셋)은 commit 했던 작업내역을 말 그대로 리셋시키는 것
• reset 에는 세 가지 모드가 있다.
  • soft : commit 들을 되돌리고 변경된 파일 작업 내역은 보존해서 파일 변경사항으로 보여준다. 이때 변경사항은 add 되지 않은 상태로 보인다.
  • mixed :commit 들을 되돌리고 변경된 파일 작업 내역은 보존해서 파일 변경사항으로 보여준다. 이때 변경사항은 add 된 상태로 보인다.
  • hard : commit 들을 되돌리고 그동안 작업했던 모든 것도 없애버린다. 즉, 작업내역을 복원할 수 없다.
• 히스토리를 남기지 않고 변경하는 것이므로 강제 푸시를 해야한다. 그렇지 않으면 변경내역 이력이 남게 됨.
• 꼭! 나 혼자 작업하는 branch 에서만 해야한다! 협업하는 브랜치에 작업을 하게 되면 다른 사람 작업내역이 꼬여버리는 대참사 !

Stash

• stash 는 숨겨두거나 넣어둔다는 뜻 - 프로젝트의 변경사항을 임시적으로 보관해둘 때 사용
• 예를 들면, 다른 branch 로 체크아웃 하는 경우 현재 branch 의 변경사항이 사라지게 된다. 아직 작업 중이라서 commit 하지 않고 변경사항만 보관해두고 싶을 때 commit 대신 stash 를 사용
• commit 한 적이 없는 파일이라면 stash 하지 않아도 된다.

1. 스태시를 사용할 브랜치에 체크아웃 되었는지 확인

2. 파일 상태를 먼저 확인하고 나서 상단 메뉴바에서 스태시 클릭

3. 창이 뜨면 stash에 대한 설명을 적어준다. (나중에 어떤 내용을 임시 보관했는지 알 수 있도록 메시지를 잘 적어주기)

4. 스태시 버튼을 누르면 임시 보관 완료! 

5. 다시 임시 보관 내용을 꺼내고 싶을 때는 :  왼쪽 메뉴바에서 [치워두기] - [원하는 파일] 선택 후 우클릭하고 [스태시적용]을 눌러준다.

6. 만약 더 이상 임시 보관한 내용이 필요가 없다면 스태시 삭제를 눌러준다.

마지막으로 꼭! commit 을 되돌리는 작업은 나만 사용하는 branch 에서만 작업을 해야한다! 그렇지 않으면 다른 사람의 commit history 가 엉망이 될 수 있다. 기억하기 !!! 

다음 주 미니 프로젝트가 시작되기 전에 점검차 스터디 팀원들과 github협업 연습을 했다.

아직 깃허브로 협업하는 과정이 익숙하지 않아 명령어로 진행해야 하는 Terminal을 사용하지 않고 비교적 직관적이고 사용이 쉬운 소스 트리로 진행하였다. 완벽한 깃허브 사용이라고 할 수는 없었지만, 그래도 큰 틀을 이해할 수 있는 연습이었다. 앞으로를 위해 일단 전반적인 협업 연습 과정을 정리해 보자! 

1. 이슈 생성 : 프로젝트 주제에 맞게 이슈를 생성한다. (예 - 제가 ~~기능을 추가하겠습니다!)

2. 각자 소스트리에서 내 담당 브랜치를 만들고, 파일을 commit(commit msg에 이슈 번호 추가) - push(dev 브랜치로) 해준다. 

3. github 프로젝트 페이지로 이동해 PR(Pull Requests) 날려준다 ! 

4. 반영 내용이 괜찮으면 confirm! - Merge를 진행한다.

5. 머지를 하는 과정에서 다음과 같이 충돌이 일어났다면 Resolve coflicts를 클릭한다.

6. 충돌이 일어난 부분을 확인하고 수정해 준다.

7. 머지에 성공하면 해결된 이슈를 close 해주고, 머지가 끝난 브랜치도 삭제해 줌으로써 훗날 헷갈리지 않도록 정리를 해준다! :) 

8. dev에 머지 충돌을 해결한 모든 브랜치 병합을 완료했다면, 배포용인 main 브랜치로 push 해주면 완료! 

우리 10조 너무 좋았는데 다음주에 헤어질 생각 하니까 너무 아쉽다 ㅠ-ㅠ 그래도 앞으로 저녁 9시 이후 추가 공부 시간에 같이 하기로 ! 

모두들 한 주 고생 많으셨습니다 !! : ) ( 아! 그리고 우리조는 아니지만 우리조 같은 현빈님 민승님도 고생하셨습니다 ㅎㅎ) 

1. git은 현업에서 실제로 어떻게 쓰일까 ?

① 누가 이 작업할 거에요? - Issue 할당

② 각자 공간에서 작업하기 - Branch 

③ 작업 내용 합치기 - Merge(병합) / Merge conflict 해결

+ (경우에 따라) 작업한 내용을 리뷰하고 최종적으로 프로젝트에 반영한다. - PR 후 merge

2. Issue 할당

• 프로젝트에서 issue(이슈) : 프로젝트에서 해결해야하는 문제
  • 버그(프로그램이 원하는 대로 동작하지 않는 것)를 신고 (Bug report, 버그 리포트)
  • 기능 추가 등의 프로젝트 개선 제안 (enhancement)
  • 위 문제들을 해결하기 위한 작업단위
• issue 생성하는 방법 ( 각 항목을 아래처럼 적어주기 )
  • 제목과 상세 내용은 협업하는 사람도 잘 알아볼 수있도록
  • Assigness(담당자) : 이 이슈를 작업하거나 연관된 사람
  • Labels: 이 issue 가 어떤 건지 분류. Github이 만들어준 기본 라벨을 사용할 수도 있고, 내가 직접 만들어줄 수도 있다. 
  • 내용을 적은 후에 하단 초록색 버튼 Submit new issue 클릭!

3. 각자 공간에서 작업하기 - Branch

• 각 작업 브랜치에서 작업할 때는 다른 브랜치의 영향을 받지 않고 독립적으로 작업할 수 있다.
• 작업 목적에 따라 branch 를 만들어서 관련된 작업만 하고, 나중에 하나로 Merge하게 된다.
• Merge 하는 과정에서 같은 파일이 동일한 부분이 수정된 게 발견되면 Merge conflict(병합 충돌) 이 발생한다.

① 브랜치 생성하기:

1. 왼쪽 히스토리 탭을 선택하고 - 마지막 commit 에서 우클릭 한 후 브랜치 를 선택!

2. 새 브랜치 : 브랜치 이름을 내가 잘 관리할 수 있게 적어주기. ex) `feature/이슈번호_관리쉬운이름` 형식 (feature 는 기능 개발하는 브랜치에 관행적으로 붙여주는 이름)
3. 정보를 입력한 후 '브랜치 생성' 버튼 클릭!

• 왼쪽 브랜치 탭 : feature 밑에 3_jjigae 항목이 생긴걸 확인할 수 있다. sourcetree 에서는 브랜치명 안에 / 를 적어주면 마치 폴더처럼 보여준다. (create branch - feature/3_jjigae)
• 해당 commit 에 붙어있는 파란색 이름표는 브랜치명이다. 해당 브랜치의 최신 commit 에 이름표를 붙여 준다.
• 현재 작업하는 브랜치를 선택하는 것을 체크아웃(checkout) 이라고 한다. sourcetree 에서는 체크아웃된 브랜치, 즉 현재 작업 브랜치를 브랜치명 왼쪽 에 O 표시가 되어있다. 체크아웃된 브랜치에만 commit이 반영된다.

※ 각 이름표는 아래와 같은 뜻을 가지고 있다.

• main : 로컬 repo의 main 브랜치
• feature/3_jjigae : 로컬 repo의 feature/3_jjigae 브랜치
• origin/main : origin(연결시켜준 원격 repo)의 main 브랜치
• origin/HEAD : 현재 작업중인 commit. origin(연결시켜준 원격 repo)의 최신 commit

② 브랜치 commit하기

③ 브랜치 삭제하기

• 삭제할 브랜치는 체크아웃(현재 작업 중인) 브랜치가 아니어야 한다.
• 다른 브랜치 이름을 더블 클릭해서 다른 브랜치로 체크아웃한 후 진행하기! 
• 삭제할 브랜치 선택 - 우클릭 - 해당 브랜치명 삭제 - 강제 삭제 옵션 선택 - 확인

4. 작업 내용 합치기 - Merge(병합) 

• 브랜치의 작업 내역 commit 들을 다른 branch 로 반영(합치기)는 것을 Merge(머지, 병합)라고 한다.
• 기본적으로 branch 단위로 merge 하게 된다.
• 개발할 때는 기준이 되는 기본 브랜치를 정해놓고 다른 브랜치들을 기본 브랜치에 merge한다. (주로 distribution용, development용으로 병합)
• 브랜치명은 규칙을 가지고 잘 이름 지으면 프로젝트 관리가 쉽다.
• 작업이 완료되면 작업한 브랜치는 보통 삭제해 줌으로써 나중에 브랜치 설정이 꼬이는 것을 방지할 수 있다.

① 브랜치 Merge 하기

• 커밋을 반영시킬 브랜치로 체크아웃
• 파일 수정이 필요한 경우 상단 오른쪽에 파인더에서 보기를 클릭하여 현재 체크아웃 된 브랜치 내부의의 정확한 파일을 수정하도록 한다.
• 머지할 부분을 클릭하고 소스트리 상단 merge(병합)을 클릭한다.
• 아래와 같이 체크리스트를 확인해 주고 병합한다.

② Merge conflict

• 에러를 안 내는 게 중요한게 아니라 버그(컴퓨터가 의도한 대로 동작하지 않는 것)를 고칠 수 있느냐 없느냐가 중요! 에러에 쫄지 말자
• 하나의 파일을 여러 브랜치에서 수정하고 하나의 branch에 merge 하려고 할 때 merge conflict(병합 충돌) 가 발생한다.
• 이럴 때 git 은 친절하게 이 충돌나는 내용 중에 어떤 내용을 반영하면 좋겠니? 하고 확인하는 메시지를 주고 자동으로 파일을 합친 다음에 충돌이 나는 부분을 아래처럼 보여준다.

• <<<<<<< 에서 >>>>>>> 까지가 충돌이 나는 부분이다. 변경된 내용 중 어떤 것을 브랜치에 반영할지 파악을 돕기 위해 정보를 알려주고 있다.
• 이 merge confilct 를 고치려면, 내가 원하는 대로 파일을 수정하고(어떤 내용을 반영할지 결정) <<<<<<< HEAD , ======= , >>>>>>> 충돌나는 브랜치명 또는 commmit 아이디 를 지우면 된다.
• 그러면 Git 이 해결되었구나! 하고 알아듣는다. =======를 기준으로 앞 부분 <<<<<<< HEAD 부분은 현재 브랜치, 즉 main 브랜치의 해당 파일의 내용을 보여준다.
• 즉, 현재 브랜치(main)의 파일 내용은 아래와 같다. 분홍색 부분이 다른 브랜치와 다른 부분을 보여준다.

• 그런 후에 이렇게 수정된 파일을 commit 하면 완료!
• 충돌을 해결하기 위해서는 반영할 내용만 남기고 지워주면 되는데, 새로운 추가사항은 병합 후 다시 새로운 커밋메시지로 업데이트 해주는 것 좋다. 이렇게 하는 것이 나중에 버그를 찾기도 쉽고 팀원들과 더 원활한 소통을 할 수 있게 해준다.
• 파일을 수정하고 나서 sourcetree 를 켜고 하단 commit 메시지 적는 창에 마우스 클릭하면 자동으로 커밋 메시지가 작성된다. 
• 자동으로 작성되는 commit 메시지 끝부분을 보면 어떤 파일이 conflict(충돌)났는지도 정보도 적혀있다.

5. 원격 repo 와 Branch

• tracking 한다는 것은 로컬 repo와 원격 repo의 특정 브랜치를 연결해주는 것
• 따로 설정을 해주지 않으면 기본적으로 로컬 repo의 브랜치명와 같게 원격 repo의 브랜치명이 생성되어 tracking된다.
• push와 pull 은 기본적으로 tracking(추적)되고 있는 브랜치를 기준으로 commit 내역을 반영한다.

[ 오시영 튜터님의 꿀팁 자료들 ]

구글링이 무엇인가요?

• 여러분이 모르는 것, 전 세계 사람들 다 모릅니다. 이럴 땐 필요한 건 구글! 구글에 검색한다고 해서 구글링(Googling) 이라고 합니다.
• 기술(도구 이름) + 단어 조합으로 하면 훨씬 더 좋은 검색 결과를 얻을 수 있어요. ( 예. sourcetree branch )
• 검색어 팁
  • 아래처럼 검색어를 조합해 입력해보세요!
  • 기술을 처음 배우고 싶을 때 : '기술이름' + 'tutorial' (예. git tutorial)
  • 기능을 찾을 때 : '기술이름' + 'how to' + '찾을 내용' (예. git how to merge )
  • 어떻게 사용하는지 예제를 보고 싶을 때 : '기술이름' + '내용' + 'example' (예. github flow example)
  • 원하는 사이트명 포함해 검색할 수도 있습니다. (예: stackoverflow git merge - stackoverflow 라는 사이트에서 검색)
• 검색 결과 중에, 좋은 자료 고르기
  • 좋은 자료를 찾으려면 경험치가 필요해요. 많이 검색해보면 자연스레 나만의 검색 노하우와 자료 판단하는 눈이 길러질 거에요.
  • 해결책뿐만 아니라 문제(에러)의 이유까지 적어두어서 내 문제와 같은지 판단할 수 있는 정보를 제공하는 글
  • stackoverflow - 개발 QnA 사이트입니다. 전 세계적으로 많이 쓰입니다. 질문과 답변, 댓글에 사용자들이 vote 할 수 있어요. 좋은 질문과 답변에는 vote 수가 높습니다.
  • 기술 공식 문서
• 신뢰할 수 있는 블로그(tech 회사의 기술 블로그, IT 전문 매거진) ex) 우하한형제들 기술 블로그

개발 공부를 더 잘하기 위한 방법

1. 내용이 쉽다 → 난이도 높이기

• 추가자료 읽어 보고 생각/실제로 해보기
•  나만의 실험 고안하기
• 에러를 일부러 내보고 해결하는 거 구글링해보기
• 그 과정에서 내가 깨달은 것 TIL 에 적어보기

2. 아 적절해요 좋은데요?

• 다양하게 시도해보기
• 그 과정에서 내가 깨달은 것 TIL 에 적어보기

3. 너무 어렵다, 집에 있어도 집에 가고 싶다! 🏠

• 난이도 낮추기
• 영상 보면서 천천히 시간 들여서 따라해보기
• 그 다음에 다시 시도해보기
• 내가 어려워했던 내용이 무엇인지 정리해보기
• 그 과정에서 내가 깨달은 것 TIL 에 적어보기

[오늘 공부한 부분]

1. git 기본 개념

2. git 두 가지 error 해결

• error1 - 'Sourcetree 응용 프로그램이 예기치 않게 종료되었습니다.'
• error2 - Refreshing Remote Repositories Failed

1. git 기본 키워드 정리

① 버전 관리: 프로젝트 상태가 변경되는 정보를 알고 있다는 것! Git 은 가장 널리 쓰이는 버전관리 도구 중에 하나로 commit 을 사용해서 버전이 달라지는 것을 관리할 수 있다.

ⓩ git 초기화(git initialize) : 컴퓨터에 있는 프로젝트를 Git 이 관리하는 프로젝트로 만들 수 있다. 깃초기화 작업 후엔 해당 파일에 .git 폴더가 생성되는 것을 확인 할 수 있다. git 초기화는 처음에 단 한번만 해 주면 된다.

③ commit : 현재 프로젝트의 상태를 찰칵 📸 저장하는 것.

• 누가(author), 언제 commit 했는지의 정보와 프로젝트 변경 내용알 수 있다.
• 작업내역이 어떤 것인지 알아볼 수 있게 적는 메시지를 'commit 메시지'라고 한다. ->협업과정에서 커밋메시지를 잘 쓰는 것도 중요!

④ add (혹은 staging, 스테이징) : commit 에 반영할지 안할지는 파일 단위로 선택할 수 있다. commit 에 반영할 파일을 선택하는 것. 작업 내역을 저장하기 위해서는 add - commit 만 하면 된다.

ⓢ commit history : commit 한 순서대로 리스트. 역사!

⑥ repo : 'Git으로 관리되는 프로젝트' 를 Git 에서는 repo(리포, repository 리포지토리의 약자) 라고 한다. 내 컴퓨터에 저장되어있는 리포지토리를 로컬 repo(local repository), Github 처럼 다른 곳에서 접속할 수 있는 공간에 저장되어있는 것을 원격 repo(remote repository) 라고 한다.

⑦ Tracking(추적) : 로컬 repo 와 원격 repo 를 연결하는 것

⑧ push : 로컬 repo 의 commit 들을 원격 repo 에 반영하기(push)! 밀어넣기. 원격 repo 에 없는 즉,새로운 commit 내역을 모두 원격 repo 에 한 번에 반영한다.

⑨ pull : 원격 repo 의 commit 들을 로컬 repo 로 반영하기(pull)! 땡겨오기. 로컬 repo 에 없는 즉,새로운 commit 내역을 모두 로컬 repo 에 한 번에 반영한다.

⑩ clone : 원격 repo 를 내 컴퓨터에 가져와서 초기 repo 세팅하는 것을 clone(복제하기)!

[ 정리 ]

1. 로컬 pc에 있는 작업물을 깃허브에 업로드 하는경우.

[git 초기화]

• sourcetree 계정연결 확인
• Create new existing locao repo
• 목적지 경로 옆에 ... 을 클릭해서 폴더를 선택
• 유형을 Git으로 바꿔주고 '생성하기' 버튼 클릭
• opne local repo(double click)

[add/ staging] - [commit 메시지 작성] - [commit] - [history확인] - github에서 [원격 repo] 만들기 - [tracking] - 파일 [push]

2. 원격 pc에 있는 작업물 내려 받아 작업하기

sourcetree 계정연결 - [원격 repo]에서 원하는 파일 [clone] 

2. Git error 

① error1 - 'Sourcetree 응용 프로그램이 예기치 않게 종료되었습니다.'

처음엔 인증문제라 생각해서 정말 수두룩 빽빽 올라온 구글링 정보로 키체인 재설정 (초기화)도 해보고, 깃허브 토큰도 몇 번 재발급 받아보고 했지만 2시간 가량 낑낑된 이 에러..... 정말 쉽게 해결 하였다.

→ 맥과 소스트리 언어설정을 영어(US)로 바꿔주면 해결 ... 쏘 간단 .... ㅠ-ㅠ

• 맥 언어 바꾸는 법 : [시스템 환경설정 ] - [언어 및 지역] - [ 왼쪽 하단 + 버튼 클릭후 영어 선택] - [기본언어 영어로 설정]
• 소스트리 언어 바꾸는 법 : [소스트리 설정 단축키는 commamd + ] - [ preffered language 영어로 설정] 

[출처] : 

② error2 - Refreshing Remote Repositories Failed

내 로컬 repo에 있는 파일을 원격 repo로  push하는 과정에서 이런 오류가 발생했다. 오류 이유는 원격 url/path를 추가하는 과정에서 깃헙의 링크를 복붙해서 설정했어야 하는데, 강의 자료만 보고 옆 지구본을 눌러서 나타난 문제였다. 해결은 간단하게 복사한 링크를 인풋창에다 붙여넣기 하면된다.

③ Mac 에서 sourcetree 기본 브랜치 이름 변경하는 방법