```bash
GIT_COMMITTER_DATE="Tue Sep 15 2020 10:57:29 +0900" git commit --date="Tue Sep 15 2020 10:57:29 +0900"
```

주의: `git rebase`시 강제로 일시를 변경하기 때문에 꼬일 수 있음.

출처: https://stackoverflow.com/questions/454734/how-can-one-change-the-timestamp-of-an-old-commit-in-git


Git commit의 일시를 변경하기

여기저기 잘 만들어져 있는 Git Cheat Sheet를 모아서 한글로 번역해 보았다. 작성시 `[]`는 제거해야 한다.

## Table of Contents

## SETUP

- `git config --global user.name "[firstname lastname]"`: git에서 사용할 글로벌 이름을 설정한다.
- `git config --global user.email "[valid-email]"`: git에서 사용할 글로벌 이메일을 설정한다.
- `git config --global color.ui auto`: git 리뷰를 쉽게할 수 있도록 커맨드라인에 자동으로 색깔을 칠해준다.

## SETUP & INIT

- `git init`: git repository 초기화
- `git clone [url]`: URL을 통해서 git repository를 클론한다.

## STAGE & SNAPSHOT

- `git status`: 작업중인 디렉토리에서 변경된 파일 목록을 보여준다.
- `git add [file]`: 다음 커밋에 추가될 파일 (스테이징할)을 추가한다.
- `git reset [file]`: 작업중인 디렉토리에서 스테이징 된 파일을 다시 unstage 상태로 되돌린다.
- `git reset --hard [file]`: 스테이징 영역과 작업 디렉토리를 가장 최근 커밋과 일치하도록 리셋하고, 작업 디렉토리의 모든 변경사항을 엎어버린다.
- `git reset [commit]`: 현재 브랜치를 커밋ID 쪽으로 되돌리고, 모든 스테이징되어 있는 변경사항을 되돌리지만, 작업중인 내용은 되돌리지 않는다.
- `git reset --hard [commit]`: 스테이징영역과 작업중인 영역 모두를 리셋해 버린다. 커밋되지 않는 변경내역은 모두 날라가고, commit 이후의 내용도 모두 날라간다.
- `git diff`: 스테이징되지 않은 파일들 중에서 diff를 확인한다.
- `git diff --staged`: 스테이징된 파일들 중에서 diff를 확인한다.
- `git commit -m "[message]"`: 스테이징된 파일을 메시지와 함께 커밋한다.
- `git commit --amend`: 가장 마지막 커밋을 현재 스테이징되어 있는 내용가 마지막 커밋을 병합한다. 스테이징과 별도로 사용한다면, 단순히 커밋 메시지를 변경하는 용도로도 사용할 수 있다.

## BRANCH & MERGE

- `git branch`: 브랜치 목록을 보여준다. `*`이 떠있는 브랜치는 현재 활성화된 브랜치를 의미한다.
- `git branch [branch-name]`: 현재 커밋을 기준으로 새로운 브랜치를 만든다.
- `git checkout [branch-name]`: 다른 브랜치로 변경 한다음, 해당 내용을 작업중인 브랜치로 가져온다.
- `git merge [branch-name]`: 특정 브랜치의 작업 내용을 현재 브랜치와 병합한다.

## INSPECT & COMPARE

- `git log`: 현재 브랜치의 모든 커밋 히스토리를 보여준다.
- `git log [branchB]..[branchA]`: 브랜치A의 커밋중 브랜치B에 없는 히스토리를 보여준다.
- `git log --follow [file]`: 파일명 변경까지 포함해서 해당 파일의 커밋을 보여준다.
- `git diff [branchB]...[branchA]`: 브랜치A를 기준으로 브랜치B와 다른 내용을 보여준다.
- `git show [SHA]`: 사람이 읽을 수 있는 형태로 모든 오브젝트를 보여준다.

## TRACKING PATH CHANGES

- `git rm [file]`: 해당 파일을 삭제하고, 스테이지에서도 이를 제거한다.
- `git mv [existing-path] [new-path]`: 파일 위치를 변경하고 스테이지에 이를 기록한다.
- `git log --stat -M`: 경로가 이동한 모든 커밋 로그를 보여준다.

## IGNORING PATTERNS

```
logs/
*.notes
pattern*/
```

git이 무시하기를 원하는 파일들의 패턴을 `.gitignore`에 기록해 둔다.

- `git config --global core.excludesfile [file]`: 시스템 레벨에서 모든 레파지토리에서 무시할 파일을 설정한다.
- `git remote add [alias] [url]`: git URL을 별칭과 함께 추가한다.
- `git fetch [alias]`: Git remote에서 모든 브랜치를 패치한다.
- `git merge [alias]/[branch]`: 현재 브랜치에다가 리모트 브랜치의 최신내용을 병합한다.
- `git push [alias] [branch]`: 로컬 브랜치 커밋을 리모트 레파지토리의 브랜치에 전송한다.
- `git pull`: 리모트 브랜치에서 추적하고 있는 모든 커밋을 패치하고 병합하여 최신화 한다.

## REWRITE HISTORY

- `git rebase [branch]`: 현재 브랜치보다 앞서있는 모든 변경 내용 (커밋)을 땡겨와서 적용한다.
- `git reset --hard [commit]`: 스테이징 영역에 있는 것을 모두 클리어하고, 특정 커밋 버전으로 모든 작업내용을 덮어써버린다.

## TEMPORARY COMMITS

- `git stash`: 현재 수정되거나 스테이징되어 있는 변경사항을 모두 저장한다.
- `git stash list`: stack 순서로 되어 있는 모든 stash 목록을 보여준다.
- `git stash pop`: stash stack 최상단에 있는 변경사항을 적용한다.
- `git stash drop`: stash stack 최상단에 stash를 제거한다.

### References

- https://education.github.com/git-cheat-sheet-education.pdf
- https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet


이제 git도 GUI 대신에 커맨드를 활용해서 작업해보자.

Git Cheat Sheet

## 블로그의 성장

2018년 5월 1일에 블로그를 시작한 이례로 헛소리를 지껄이는 블로그에서, 제법 이사람 저사람 찾아오는 블로그로 성장했다.

![history1](./images/history1.png)

![history2](./images/history2.png)

꾸준한 블로그 뻘 글과 회사에서 일하는 것 덕분에 github contribution에 초록색 불도 많이 들어오고 있다.

![contribution1](./images/contribution1.png)

[github contribution은 2013년에 생긴 이래로](https://github.blog/2013-01-07-introducing-contributions/) 개발자의 daily 성과 지표를 알려주는데 도움을 주고 있다.

## contribution의 기준

```
What counts as a contribution
On your profile page, certain actions count as contributions:

Committing to a repository's default branch or gh-pages branch
Opening an issue
Proposing a pull request
Submitting a pull request review
```

- default branch (master)나 gh-pages (github page 브랜치)에 기여하는 것
- 이슈를 만드는 것
- PR을 만드는것
- PR 리뷰를 제출하는 것

![contribution2](./images/contribution2.png)

## 매일매일 Contribution 해보기

학교가 끝나서 심심해졌겠다, 2020년에 daily로 contribution을 해봐야 겠다. 달력에 모두 초록불이 들어오도록


## 블로그의 성장 2018년 5월 1일에 블로그를 시작한 이례로 헛소리를 지껄이는 블로그에서, 제법 이사람 저사람 찾아오는 블로그로 성장했다.  ![history1](./images/history1.png)  ![history2](./images/history2.png)  꾸준한 블로그 뻘 글과 회사에서 일하는 것 덕분에 github contributi...

2020년, 매일 github에 contribution 하기

remote에서 이미 master로 머지된 local/remote 브랜치를 삭제하는 스크립트

```shell
git fetch --all -p
git branch --merged | grep -E -v "master|\*" | xargs -n 1 git branch -d
git branch -vv | grep gone | sed | awk '{print $1}' | xargs -n 1 git branch -D
```

우교수님께 감사의 말씀을 🙇‍♂️


remote에서 이미 master로 머지된 local/remote 브랜치를 삭제하는 스크립트 ```shell git fetch --all -p git branch --merged | grep -E -v "master|\*" | xargs -n 1 git branch -d git branch -vv | grep gone | sed | awk '{print ...

머지된 브랜치를 삭제하는 스크립트

## Commit Message

[좋은 git commit 메시지를 위한 영어사전](https://blog.ull.im/engineering/2019/03/10/logs-on-git.html)

[좋은 git 커밋 메시지를 작성하기 위한 7가지 약속](https://meetup.toast.com/posts/106)

### 요약

Single Line

```
[#issue number] :emoji: Commit Message
```

Multi Line

```
[#issue number] :emoji: Commit Message
- change detail1
- change detail2
```

- Single Line 과 동일하지만, Multi Line 으로 가면 두 번째 라인은 반드시 비워둘 것
- 세 번째 라인부터 Change 상세를 리스트 형식으로 기술

## Linear History in git

### 장점

1. **git bisect**
2. **possibility of submitting with history to another version control system like SVN**
3. **Documentation for the posterity**. A linear history is typically easier to follow. This is similar to how you want your code to be well structured and documented: whenever someone needs to deal with it later (code or history) it is very valuable to be able to quickly understand what is going on.
4. **Improving code review efficiency and effectiveness**. If a topic branch is divided into linear, logical steps, it is much easier to review it compared to reviewing a convoluted history or a squashed change-monolith (which can be overwhelming).
5. **When you need to modify the history at a later time**. For instance when reverting or cherry-picking a feature in whole or in part.
6. **Scalability.** Unless you strive to keep your history linear when your team grows larger (e.g. hundreds of contributors), your history can become very bloated with cross branch merges, and it can be hard for all the contributors to keep track of what is going on.

[출처](https://stackoverflow.com/questions/20348629/what-are-advantages-of-keeping-linear-history-in-git)

### Rebase

리베이스가 최고다

[출처](https://dev.to/maxwell_dev/the-git-rebase-introduction-i-wish-id-had)

간단히 요약하면, 내가 작업한 내용을 master의 최신 커밋 뒤에 이어서 붙이는 것이다.

우리의 목표

![git-rebase](https://git-scm.com/book/en/v2../../../images/perils-of-rebasing-5.png)

1. rebase 대상 브랜치 (보통은 master)를 checkout해서 pull
2. rebase 하려는 브랜치 (내가 작업한 브랜치)를 checkout해서 pull

![git-rebase](https://git-scm.com/book/en/v2../../../images/basic-rebase-1.png)
현재까지의 상태는 이럴 것이다.

3. `git rebase master` 를 때린다

![git-rebase](https://git-scm.com/book/en/v2../../../images/basic-rebase-3.png)

4. 컨플릭이 없다면 6번으로

5. 컨플릭이 있다면 컨플릭을 해결한 후에 `git rebase --continue`를 한다.

6. `git push origin <branch> --force`로 force push를 한다.

리베이스는 과거 커밋을 지우고 뒤에 이어 붙인 새로운 커밋을 만들기 때문에, 저장소의 커밋 히스토리를 다시 쓰게 된다.


## Commit Message [좋은 git commit 메시지를 위한 영어사전](https://blog.ull.im/engineering/2019/03/10/logs-on-git.html)  [좋은 git 커밋 메시지를 작성하기 위한 7가지 약속](https://meetup.toast.com/posts/106)  ### 요약  Single Line  ...

Git 1

Git commit의 일시를 변경하기

Git Cheat Sheet

2020년, 매일 github에 contribution 하기

머지된 브랜치를 삭제하는 스크립트

Github을 아름답게 관리하기