'공부/공부(프로그래밍)'에 해당되는 글 7건

  1. 2016.06.20 [c언어] Static 변수
  2. 2016.06.01 [git] Git 명령어 모음 (내가 자주 사용하는) 1

 

 

Static 변수는 변수 선언 시 앞에 static을 추가하여 선언하여 사용하며, 다음과 같은 특징이 있습니다.

 

  1. 선언 위치는 지역변수와 같을 수 있다.
  2. 특정 선언 지역에서만 접근 할 수 있다.
  3. 메모리 저장공간에서 변수의 저장 공간은 전역변수와 그 위치가 같다.
  4. 초기값을 주지 않을 경우 항상 0으로 초기화 되며, 프로그램을 실행 시킬 때 단 한 번만 초기화 된다.

 

아래와 같은 코드가 있다고 가정하면서 위의 static의 특징을 살펴보겠습니다.

 

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

void call();

   

int main()

{

    call();

    call();

    call();

    return 0;

}

   

void call(void)

{

    static int count = 0;

    count ++;

    printf("%d ", count);

}

cs

 

 

위의 call함수에서 static int count라는 변수가 선언되었습니다. 4번에 의하면 초기화는 딱 한 번만 하므로, main문에서 3번 call이 호출되었다고, 매번 count가 0으로 초기화 되지는 않습니다. 이 점을 주의해야 합니다.

 

또한, 2번의 특징처럼 count라는 변수는 선언이 된 call함수에서만 사용이 가능하며, 다른 위치에서는 사용을 할 수 없습니다. 만약 다른 함수에서 사용하고 싶다면, global변수처럼 main문 밖에서 선언하게 되면, main에서도 call에서도 사용이 가능합니다. 그래서 선언 위치는 자유롭지만, 그에 따른 제약에 주의가 필요합니다.

 

3번의 설명처럼 전역변수와 변수의 저장 공간이 같습니다.

 

 

이러한 특징을 토대로 결과 값은

1 2 3 이 나오게 됩니다.

 

만약 call에서 static int count 대신…. int count로 일반 변수로 선언되었다면, (static이 아니라)

값은 1 1 1 이 됩니다.

 

이러한 static의 특징 때문에 저의 경우는 static으로 선언 한 것은 어떤 동작의 count를 하는 목적으로 사용하고 있습니다. 예를 들면 특정 동작이 몇번 반복되었는지를 기록하여, 그에 따른 처리를 할 때 static int count라는 변수를 만들어 그 동작을 기록하도록 합니다.

   

  

Posted by 고무함지
,

자주 사용하고 있는 git명령어를 모아봤습니다.


저는 svn을 사용했었는데, 처음 git을 쓸 때는 잘 이해도 안되고, 자주 사용중 실수로 인한

error가 많이 생겼습니다.


그래서 첫 인상은 별로 였는데, 주변 동료들의 경우 잘 사용하는 것을 보면서, 

저도 익숙해지도록 공부하고 있는 중인데, 이제는 ... 어느정도 익숙해졌고, 

그 덕분에 업무중 잘 사용하고 있습니다.


어느정도 공부해보니... git의 개념을 이해하지 않고 단순히... 명령어 만 사용하는

것에는 한계가 있다는 걸 알게 되었네요.


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
 
1. Git 로그 검색하기
 
git log --name-only  ( 추천 ) // git log 보다는 변뎡된 파일 명도 같이 나오는 이걸 사용
git log --grep=검색어 ( 추천 )  // 검색어가 있는 내용만 검색
git log -p  -2          ( 추천 ) // 가장 최근 두개의 결과만 보여줌, 코드 변경사항도 같이 보여줌 
git log --oneline                 // 커밋의 제목만 볼 경우
 -> git log --oneline | grep PWM // pwm 관련 내용만 볼 경우
 -> git log --oneline | grep ---color=auto PWM  // 좀더 보기 편하게( -i 대소문자 구분없이 검색)
 
git log -p ./os/common_linux/dil/dil_pwm.c   특정 파일의 변경 이력만 볼 수 있다. (경로까지 알려줘야함)
 
git log // 일반적인 변경사항, 변경자 
git log --1   --word-diff  // 변경점을 줄단위가 아닌, 단어 단위로 보여줌
-> git log -p 커밋번호 -1  // 그 커멋 번호에 해당 되는 코드 변경 내용+커밋메시지 보기
---> git log --oneline 명령으로 찾은 후 커밋 번호만 복사해서 사용하면 편리하다.
 
git log --pretty=short  (간편히 볼때 추천)   // oneline : 한줄씩, short, full, fuller 옵션도 있음
git log --pretty=format:"%h %s" --graph ( 간편히 볼때 추천 ) // 부모 tree내용도 봄(--graph)
//... git log상태에서 /검색어 치고.... 단어 검색 대문자 N 은 윗 방향으로 검색, 소문자 n은 아래 방향으로 검색
 
<  Git show >
git show commit_id   // 그 커밋의 상세 변경점을 볼 수 있음. 
git show HEAD    // 가장 마지막 변경점 보기
git show HEAD^    // 전전 변경점 보기
git show HEAD~2    // HEAD로부터 2단계 위의 변경점 보기
 
 
 
2. 변경사항 Diff
git diff HEAD^ HEAD   ( 추천 )  // 현재의 내용과 바로전 내용(HEAD^) 비교함
git diff HEAD^^ HEAD            // 현재의 내용과 전전 내용(HEAD^^) 비교함 
git diff HEAD^ HEAD > diff_0518.patch  // 변경사항을 patch파일로 저장함.
git diff 커밋번호_B  커밋번호_A  // 번호별 차이도 볼 수 있음
 --> git log --oneline 으로 간략히 보고... 커밋번호 복사해서 위 명령어 사용
 
< 브렌치별 차이도 볼 수 있다>
git diff A_브랜치 B_브랜치
git diff --stat  // 간단히 어떤 파일들이 변경되었는지 세부 내용 보지 않고 통계치로만 보기
 
 
3. Git untracked file 보지 않기... git untracked files not showing
git status // 하면 변경파일과, untracked files 까지 보여짐
git status -uno // modified files만 볼 수 있다.
git status --untracked-files=no  // 다음도 modified files 만 보여준다.
git config status.showUntrackedFiles no // 또는 항상 안보고 싶다면, ... 설정을 변경한다.
git config status.showUntrackedFiles  
// 입력후 enter 키 누르지 말고, tab키를 누르면, untracked파일 리스트가 보인다.
 
 
4. commit-templates.txt 
이 파일은 commit할 때 문서 양식이다. 필요에 따라 내용을 변경할 수 있다.
vi .git/commit-templates.txt  
 
 
5. gitignore 파일로 변경점 관리 안 할(무시할) 파일 등록
 
//작업중인 최상위 폴더에서... 생성한다. 그래야 효력이 그 아래 폴더까지 해당됨
vi .gitignore  // 최상이 폴더에 파일 만들어 둔다.
.....................<.gitignore 본문>...............
// 이 폴더 내용 전체 무시  , '#' 문자는 주석을 넣을 때 앞에 사용
build/
// xxx.patch 파일 들 모두 무시      
*.patch    
.....................................................
 
 
6. git 작업브렌치 만들고, 이후 본브랜치에 merge하기
 
git branch // 현재 브렌치 확인 (만약 본 브렌치이면, 신규 bug_fix용 브랜치하나 생성)
 
git branch bug_fix_0519 // 신규 브랜치 생성
git checkout bug_fix_0519 // 신규 브랜치로 이동
// 위의 두가지를 한번에 하려면   
// git checkout -b bug_fix_0519 
 
// 여기서 코드 수정 작업하고, 변경 코드 저장한 후
git add 작업파일1 작업파일2 // 작업파일 add
git commit // 작업한 파일들 bug_fix_0519 브랜치에 올린다.
// git commit -"작업내용설명"  
// 이렇게 직접 수정 내용을 바로 적어도 되지만, 자세히 적기 위해
// git commit으로 하고 vi에디터를 통해 내용을 상세히 적는다.
git log   // 신규 내용 commit 잘 되었는지 확인
 
// 이후 이 개선사항을 본 브랜치에 넣고 싶으면
git checkout 본_브랜치명 // 본 브렌치로 이동(master가 될 수 도 있고, 프로잭트명일 수도 있고) 
git merge bug_fix_0519 // 아까 작업한 bug_fix_0519 브랜치 내용을 합친
 
// 만약 코드에 들어간 whitespace로 인해서 merge 잘 안된다면, whitespace 무시옵션사용
git merge -Xignore-space-change bug_fix_0519
 
// conflict 발생하면, 직접 git status 로 어떤 파일 문제인지 확인후, 수작업으로 고친다.
// 이후 다시 commit한다.
 
git merge --abort  // 이래저래 머지하다 문제 되면, 방금 merge한 것을 취소할 수 있다.
 
git log // bug_fix_0519 에서 작업한 것이 log에 들어왔는지 재 확인
git push review // 본브렌치의 원격 저장소에 코드 push 작업
 
// gerrit 사이트에서 push내용 잘 들어갔는지 확인 및, 동료에게 리뷰 요청 
git push review 목적지
 
그리고 전에 작업하던 브렌치는 지워버린다...
git branch -d bug_fix_0519 // 브랜치 지우기
 
 
8. git reset 
git reset HEAD~1   // 마지막 커밋 바로전으로 이동하기 
 
9. git tag  // 별명 붙이기
git tag v2.5 commit_id  // v2.5 라고 별명 붙이기
 
< git tag + git log >
git log v2.5..v2.6   // version 2.5와 2.6 사이의 commit들 보기
 
 
10. 패치 생성 및 적용하기
 
// 새로운 분기 생성
git branch mybugfix
 
// 새 브랜치로 이동
git checkout mybugfix
 
// 수정 작업 진행 후, git add , git commit을 진행하고 
 
// 수정한 패치를  생성한다.
git format-patch 메인브랜치명  // 메인 브랜치 명...
// 그러면 mybugfix 브랜치에서 수정하여, commit한 내용들이 나온다.
// LED버그 수정, sound버그 수정, video버그 수정등
// 3번의 commit작업이 있었다면, 번호-커밋제목.patch형식으로 파일이 자동생성됨.
 
0001-LEDbugFix.patch 
0002-SoundbugFix.patch 
0003-VideobugFix.patch 
 
// 이 작업은 중요한데,... 작업 브랜치에서 작업한 내용이 있고, 이후 메인 브렌치로 이동하면
그 내용이 잠시 안보이게 되는데(사실은 있지만)...
혹시라도 작업 브랜치를 실수로 지운다면.... 그 기록이 사라지므로. 이렇게 patch 파일로 
보관하는 것이 이중 안전 장치가 될 것 같다. 
 
// 이제 메인 브렌치로 이동한다. 
// 메인브렌치는 다같이 참여해서 개발하는 프로잭트 브랜치를 말한다.
git checkout 메인브렌치
 
// 이제 내 mybugfix브랜치에서 수정했던 내용이 있는 패치를 메인브렌치에 적용한다.
git apply 0001-LEDbugFix.patch
 
// 이제 patch로 수정을 적용하면, 이제 메인브렌치에서 add, commit을 하여,
// 다른 동료들도 적용된 내용을 볼 수 있게 한다.
 
cs



아래는 제가 공부하기 위해 많이 방문한 사이트 모음입니다.


참고 사이트 : 


1) 가상의 환경에서 git 체험해보기 : 실습을 웹상에서 할 수 있습니다.

http://learngitbranching.js.org/


2) git-scm.com 의 한글화된 git가이드 : 

https://git-scm.com/book/ko/v1/%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0


3) git - 간편 안내서 : 

http://rogerdudler.github.io/git-guide/index.ko.html



Posted by 고무함지
,