Git 태그에 대한 설명: Git에서 태그를 나열, 생성, 제거 및 표시 방법

태그 지정(Tagging)을 통해 개발자는 프로젝트 개발 과정에서 중요한 체크포인트를 표시할 수 있습니다. 예를 들어, 소프트웨어 릴리즈 버전에 태그(Tag)를 지정할 수 있습니다. (예: V1.3.2) 기본적으로 커밋에 특별한 이름(태그)을 부여할 수 있습니다.

생성된 모든 태그를 알파벳 순으로 보려면:

git tag

태그에 대한 자세한 정보를 얻으려면:

git show v1.4

태그에는 두 가지 유형이 있습니다:

주석이 달린 태그

git tag -a v1.2 -m "my version 1.4"

경량 태그

 git tag v1.2

두 유형은 저장되는 방식이 다르며 현재 커밋에 태그를 생성합니다.

이전 커밋에 태그를 지정하려는 경우, 태그할 커밋 아이디를 지정합니다.

 git tag -a v1.2 9fceb02

커밋을 체크아웃과 원격 저장소에 푸시하는 동안, 커밋 아이디 대신 태그 이름을 사용할 수 있습니다.

추가 정보:

• Git 문서: Git 문서 페이지 (영문)
• Git 태그 챕터: Git 태그 페이지 (영문)

git tag 명령을 사용해 프로젝트에서 사용할 수 있는 모든 태그를 나열할 수 있습니다. (알파벳 순으로 표시됨)

$ git tag
v1.0
v2.0
v3.0

이러한 태그 나열 방법은 작은 프로젝트에 유용하지만, 대규모 프로젝트에는 수백 개의 태그가 있을 수 있으므로, 기록에서 중요한 지점을 검색할 때 태그를 필터링해야 할 수 있습니다. git tag 명령어에 -l을  추가해 특정 문자가 포함된 태그를 찾을 수 있습니다.

$ git tag -l "v2.0*"
v2.0.1
v2.0.2
v2.0.3
v2.0.4

태그 생성하기

주석이 달린 태그와 경량 태그의 두 가지 유형을 만들 수 있습니다. 첫 번째 방법은 GIT 데이터베이스에서 객체를 놓고 경쟁하는 것입니다. 체크섬이 지정되고, 메시지(예: 커밋)가 필요하며, 이름, 이메일 및 날짜와 같은 기타 중요한 데이터를 저장합니다. 반면에 경량 태그는 메시지가 필요하거나 다른 데이터를 저장하지 않고, 프로젝트의 특정 지점에 대한 포인터 역할만 합니다.

주석 달린 태그 생성하기

주석 달린 태그를 생성하기 위해, git tag 명령어에 -a tagname -m "tag message"를 추가합니다.

$ git tag -a v4.0 -m "release version 4.0"
$ git tag
v1.0
v2.0
v3.0
v4.0

보시다시피, -a는 주석이 달린 태그를 생성하고 있음을 지정하고, 그 뒤에 태그 이름이 오고, 마지막으로 -m 뒤에는 GIT 데이터베이스에 저장할 태그 메시지가 뒤따릅니다.

경량 태그 생성하기

경량 태그는 커밋 체크섬만 포함됩니다. (다른 정보는 저장되지 않음). 하나를 생성하려면, 다른 옵션 없이 git tag 명령어를 실행하기만 하면 됩니다(이름 끝에 있는 -lw 문자는 경량 태그를 나타나는 데 사용되지만, 원하는 대로 표시할 수 있습니다.):

$ git tag v4.1-lw
$ git tag
v1.0
v2.0
v3.0
v4.0
v4.1-lw

이번에는 메시지나 기타 관련 데이터를 지정하지 않았으므로 태그에는 오직 참고된 커밋의 체크섬만 포함됩니다.

태그 데이터 보기

git show 명령을 실행하면 태그에 저장된 데이터를 볼 수 있습니다. 주석이 달린 태그의 경우, 태그 데이터와 커밋 데이터가 표시됩니다.

$ git show v4.0
tag v4.0
Tagger: John Cash <john@cash.com>
Date:   Mon Sat 28 15:00:25 2017 -0700

release version 4.0

commit da43a5fss745av88d47839247990022a98419093
Author: John Cash <john@cash.com>
Date:   Fri Feb 20 20:30:05 2015 -0700

  finished details

경량 태그를 보고 있을 때, 참조된 커밋 데이터만 표시됩니다.

$ git show v1.4-lw
commit da43a5f7389adcb9201ab0a289c389ed022a910b
Author: John Cash <john@cash.com>
Date:   Fri Feb 20 20:30:05 2015 -0700

  finished details

이전 커밋에 태그 지정하기

깃 태그 커밋을 이용해 과거 커밋에 태그를 지정할 수도 있습니다. 커맨드 라인에 커밋의 체크섬(혹은 최소한 그 일부)을 지정해야 합니다.

먼저 필요한 커밋의 체크섬을 찾기 위해 깃 로그를 실행합니다:

$ git log --pretty=oneline
ac2998acf289102dba00823821bee04276aad9ca added products section
d09034bdea0097726fd8383c0393faa0072829a7 refactorization
a029ac120245ab012bed1ca771349eb9cca01c0b modified styles
da43a5f7389adcb9201ab0a289c389ed022a910b finished details
0adb03ca013901c1e02174924486a08cea9293a2 small fix in search textarea styles

필요한 체크섬이 있으면, 태그 생성 행 끝에 추가합니다:

$ git tag -a v3.5 a029ac

git tag를 실행해 태그가 올바르게 추가됐는지 확인할 수 있습니다:

$ git tag
v1.0
v2.0
v3.0
v3.5
v4.0
v4.1-lw

태그 푸시하기

깃 푸쉬 명령을 실행할 때 깃은 기본적으로 태그를 푸시하지 않습니다. 따라서 서버에 태그를 성공적으로 푸시하려면 git push origin 명령을 실행해야 합니다.

$ git push origin v4.0
Counting objects: 14, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (16/16), done.
Writing objects: 100% (18/18), 3.15 KiB | 0 bytes/s, done.
Total 18 (delta 4), reused 0 (delta 0)
To git@github.com:jcash/gitmanual.git
 * [new tag]         v4.0 -> v4.0

git push origin 명령어에 --tags 옵션을 사용해 여러 태그를 한 번에 추가할 수도 있습니다:

$ git push origin --tags
Counting objects: 1, done.
Writing objects: 100% (1/1), 160 bytes | 0 bytes/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To git@github.com:jcash/gitmanual.git
 * [new tag]         v4.0 -> v4.0
 * [new tag]         v4.1-lw -> v4.1-lw

태그 채킹하기

평소처럼 git checkout을 사용해 태그를 체크아웃할 수 있습니다.
그러나 이 경우 HEAD 상태가 분리될 수 있습니다.

$ git checkout v0.0.3
Note: checking out 'v0.0.3'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

태그 삭제하기

특정 태그를 삭제하고 싶은 상황이 있을 수 있습니다. 이때 다음과 같은 유용한 명령어를 사용합니다:

$ git tag --delete v0.0.2
$ git tag
v0.0.1
v0.0.3
v0.0.4

추가 정보

• Git 프로 - 기본 태깅: Git 문서 태깅 페이지(영문)
• Git 프로 - 문서: Git 문서 페이지(영문)
• Git 사용법: Githowto 문서 페이지(영문)
• Git 팁: 태그: Alblue 블로그(영문)
• 태그 생성하기: drupal 문서 페이지(영문)

출처

깃 문서: 태그(영문)

영어 원문: An introduction to Git merge and rebase: what they are, and how to use them 글쓴이: [Vali Shah]

개발자로서 많은 사람이 머지(merge)와 리베이스(rebase) 중에 하나를 선택해야 하는 경우가 발생합니다. 인터넷에서 얻는 모든 참고 자료와 함께 모든 사람은 "심각한 문제가 발생할 수 있으니, 리베이스는 절대 사용하지 마세요."라고 생각합니다. 그럼, 리베이스와 머지가 무엇인지, 사용해야 하는 이유(사용해서는 안 되는 이유) 및 사용 방법에 관해 설명하겠습니다.

깃 머지와 깃 리베이스는 동일한 용도로 사용됩니다. 둘 다 여러 브렌치에서의 변경 사항을 하나로 통합하도록 설계됐습니다. 비록 최종 목표는 같지만, 이 두 방법은 다른 방식으로 목표를 달성하며, 더 나은 소프트웨어 개발자가 되기 위해서 차이점을 아는 것이 좋습니다.

이 질문은 깃 커뮤니티에서 말이 많습니다. 어떤 사람들은 항상 리베이스를 사용해야 한다고 생각하고, 다른 사람들은 항상 머지해야 한다고 믿습니다. 각각의 측면은 설득력 있는 이점을 가지고 있습니다.

깃 머지

버전 제어 시스템을 사용하는 개발자는 일반적으로 깃 머지를 사용하는 게 관행입니다. 테스트, 버그 수정 혹은 기타 이유로 브렌치가 생성됐는지 여부와 관계없이, 머지를 실행하면 변경 사항이 다른 위치에 커밋됩니다. 더 구체적으로 말하면, 머지는 소스 브렌치의 내용을 가져와 타겟 브렌치와 병합시킵니다. 이 작업을 통해, 타겟 브렌치만 변경되며 소스 브렌치 기록은 동일하게 유지됩니다.

마스터 브렌치에서 피처로 머지

장점

• 간단하고 친숙하다
• 전체 기록과 연대순으로 보존한다
• 해당 브렌치의 내용을 유지한다

단점

• 많은 머지 커밋으로 커밋 기록이 오염될 수 있다.
• git bisect를 사용한 디버깅이 더 어려워질 수 있다.

사용 방법

checkout과 merge 명령어를 사용해 마스터 브렌치를 피처 브렌치로 머지해 보겠습니다.

$ git checkout feature
$ git merge master

(or)

$ git merge master feature

이렇게 하면 두 브렌치의 기록을 두고 있는 피처 브렌치에 새로운 "머지 커밋"이 생성됩니다.

깃 리베이스

리베이스는 한 브렌치에서 다른 브렌치로 변경 사항을 통합하는 또 다른 방법입니다. 리베이스는 모든 변경 사항을 하나의 패치로 압축합니다. 그런 다음 타겟 브렌치에 이 패치를 통합합니다.

머지와 달리 리베이스는 완료된 작업을 한 브렌치에서 다른 브렌치로 전송하기 때문에 기존의 기록을 제거합니다. 이 과정에서 원치 않는 기록이 제거됩니다.

리베이스는 변경 사항이 계층 구조의 맨 위에서 아래로 전달되는 방식이며, 머지는 변경 사항이 다시 위로 흐르는 방법입니다.

마스터 브렌치에서 피처로 리베이스

장점

• 복잡해졌을 수도 있는 기록을 간소화한다
• 단일 커밋을 조작하기 쉽다(예: 되돌리기)
• 여러 브렌치가 있는 분주한 리퍼지토리에 머지 커밋 "노이즈"를 방지한다
• 중간 커밋을 단일 커밋으로 만들어 정리하고, 이는 DevOps 팀에 도움이 된다

단점

• 소수의 커밋으로 기능을 축소하면 내용이 숨겨질 수 있다
• 공용 리퍼지토리를 리베이스하는 것은 팀으로 작업할 때 위험할 수 있다
• 리베이스로 피처 브렌치를 항상 업데이트해야 하므로 더 많은 작업을 해야 한다
• 리모트 브렌치로 리베이스하려면 강제 푸쉬가 필요하다. 사람들이 직면하는 가장 큰 문제는 강제 푸시를 하지만 git push 기본값을 설정하지 않는 것이다. 이에 따라 로컬과 리모트 모두에서 동일한 이름을 가진 모든 브렌치가 업데이트되고, 이 문제는 처리하기가 매우 어렵다.

부정확하게 리베이스하다가 의도치 않게 기록을 재작성하면, 심각한 문제로 이어질 수 있으니, 리베이스 작업을 시도하기 전에 반드시 다시 한 번 확인하세요!

사용 방법

다음 명령을 사용해 피처 브렌치를 마스터 브렌치로 리베이스합니다.

$ git checkout feature
$ git rebase master

이렇게 하면 전제 피처 브렌치가 마스터 브렌치 위로 이동합니다. 원래(피처) 브렌치의 각 커밋에 대해 완전히 새로운 커밋을 만들어 프로젝트 기록을 다시 작성해 이를 수행합니다.

인터렉티브한 리베이스

Interactive 리베이스는 커밋이 새로운 브렌치로 이동할 때 커밋을 변경할 수 있습니다. 이는 브렌치의 커밋 기록을 완벽하게 제어할 수 있기 때문에 자동화된 리베이스보다 강력합니다. 일반적으로 피처 브렌치를 마스터에 머지하기 전에 지저분한 기록을 정리하는 데 사용됩니다.

$ git checkout feature
$ git rebase -i master

이 명령은 에디터를 열어 이동하려는 모든 커밋을 나열합니다. 아래 코드블록 같이 말이죠.

pick 22d6d7c Commit message#1
pick 44e8a9b Commit message#2
pick 79f1d2h Commit message#3

나열된 커밋의 내용과 순서는 리베이스가 수행된 후에 브렌치 이력이 어떻게 보일지 보여줍니다. 커밋들을 재정렬해 원하는 대로 기록을 표시할 수 있습니다. 예를 들어, pick 대신 fixup, squash, edit과 같은 명령어를 사용할 수 있습니다.

둘 중에 무엇을 선택해야 할까

그래서 뭐가 제일 좋을까요? 전문가들이 무엇을 추천할까요?

모든 팀이 다르기 때문에, 하나가 더 좋다고 일반화하고 결정하는 것은 어렵습니다. 하지만 일단 결정을 해야 뭐라도 시작하겠죠?

각 팀은 깃 리베이스와 머지를 사용할 상황을 정할 때 질문 몇 가지를 고려해야 합니다. 결과적으로 하나의 워크플로우 전략이 다른 하나보다 나은 것이 아니기 때문입니다. 그것은 당신의 팀에 따라 다릅니다.

조직 전체의 리베이스 및 깃 역량 수준을 고려해 봅시다. 머지의 추적 가능성 및 기록과 비교해 리베이스의 단순성을 어느 정도 중요시 하는지 결정합니다.

마지막으로, 머지와 리베이스에 대한 결정은 명확한 브렌치 전략의 맥락에서 고려되어야 합니다. (브렌치 전략에 대한 자세한 내용은 이 문서를 참조하세요). 성공적인 브렌치 전략은 팀 조직을 중심으로 설계됩니다.

제가 추천하는 방법은?

팀이 성장함에 따라, 항상 머지를 사용한다면 이후 개발 변경 사항을 추적하거나 관리하기가 어려워집니다. 깨끗하고 이해하기 쉬운 커밋 기록하기 위해서는, 리베이스를 사용하는 것이 효과적이고 합리적입니다.

다음 상황과 지침을 고려하면, 리베이스를 최대한 활용할 수 있습니다.

• 로컬에서 개발 중인 경우: 다른 사람과 작업을 공유하지 않은 시점에는 기록을 깔끔하게 유지하려면 머지보다 리베이스를 선호해야 합니다. 리퍼지토리의 개인 포크가 있고 다른 개발자와 공유되지 않는 경우, 당신의 브렌치를 푸쉬한 후에도 안전하게 리베이스 할 수 있습니다.
• 코드리뷰할 준비가 된 경우: pull request(PR)을 생성했거나 다른 사람들이 당신의 작업을 검토하기 위해 해당 작업을 본인의 로컬 저장소로 포크할 가능성이 있다면, 그 시점에서는 작업을 리베이스를 해서는 안 됩니다. '재작업' 커밋을 만들고 피쳐 브렌치를 업데이트해야 합니다. 이렇게 하면 PR의 추적 가능성에 도움이 되며 우발적인 기록 손상을 방지합니다.

-검토가 완료됐으며 타겟 브레치에 통합될 준비가 된 경우: 축하합니다! 당신의 피처 브렌치를 삭제하려고 합니다. 이 시점부터 다른 개발자가 변경 사항을 패치-머지하지 않을 것이라는 점을 감안할 때, 이는 당신의 기록을 정리할 기회입니다. 이 시점에서 기록을 재작성하고 원래 커밋과 성가신 'pr 재작업'과 '머지' 커밋을 작은 집중 커밋 집합으로 만들 수 있습니다. 이러한 커밋에 대한 명시적인 머지를 만드는 것은 선택 사항이지만 그럴만한 가치가 있습니다. 이는 피쳐가 마스터로 전환된 시점을 기록합니다.

마치며

이 글이 깃 머지와 깃 리베이스에 대한 이해도를 높였기를 바랍니다. 머지 혹은 리베이스 방식을 사용할지는 항상 논쟁의 여지가 있습니다. 그러나 이 글이 여러분의 의구심을 해소하고 팀에 맞는 접근 방식을 채택하는 데 도움이 되기를 바랍니다.

깃 워크플로우와 깃에 대한 글을 기대하고 있습니다. 다음에 제가 쓰길 원하는 주제가 있으면 댓글 달아주세요. 감사합니다!

소프트웨어 개발자를 위한 코딩 스쿨

폼은 웹에서 가장 중요한 부분 중 하나입니다. 데이터를 수집하고 리소스를 검색하거나 중요한 정보를 받기 위해 회원가입 하는 경우 폼을 이용하면 가장 쉽습니다.

여러분은 HTML form 요소를 사용해 웹사이트에 폼을 포함할 수 있습니다. 폼 요소 내부에는 여러 가지 입력이 중첩되어 있습니다. 이러한 입력들은 폼 컨트롤이라고도 합니다.

이 튜토리얼에서는 HTML 폼 요소, 다양한 입력 유형 및 데이터를 제출하는 제출 버튼을 만드는 방법에 관해 설명합니다.

마지막에는 폼이 어떻게 작동하는지 알게 되고 자신있게 폼을 만들 수 있을 것입니다.

기본 HTML 폼 구문

<form action="mywebsite.com" method="POST">
    <!--Input of any type and textareas goes in here-->
</form>

기본 HTML 폼 입력 유형

HTML에서 다양한 폼 컨트롤을 만들기 위해 input 태그를 사용합니다. 이 태그는 인라인 요소이며 type, name,minLength,maxLength,placeHolder 등과 같은 속성을 사용합니다. 이렇게 각각의 속성에는 사용하는 특정한 값을 가집니다.

placeHolder 속성의 경우, 사용자가 항목을 입력하기 전에 입력 필드의 목적을 이해하는 데 도움이 되므로 중요합니다.

그럼, 입력 유형은 20가지가 있으며 하나씩 살펴보겠습니다.

텍스트 유형

이 유형의 입력은 "text" 값을 사용하며, 한 줄의 텍스트 입력을 만듭니다.

<input type="text" placeholder="Enter name" />

텍스트 유형의 입력은 아래 스크린샷과 같습니다:

비밀번호 유형

이름에서 알 수 있듯이, 이 유형을 입력하면 비밀번호가 생성됩니다. 그리고 자바스크립트로 조작하지 않는 한, 사용자가 자동으로 입력값을 볼 수 없습니다.

<input type="password" placeholder="Enter your password" />

이메일 유형

이메일 유형의 모든 입력은 이메일 주소를 입력하기 위한 필드를 정의합니다.

<input type="email" placeholder="Enter your email" />

숫자 유형

이 입력 유형을 사용하면 숫자만 입력할 수 있습니다.

<input type="number" placeholder="Enter a number" />

라디오 유형

때에 따라 사용자는 다양한 옵션 중 하나를 선택해야 합니다. 유형 속성이 "radio"로 설정된 입력 필드를 사용하면 이 작업을 수행할 수 있습니다.

<input type="radio" />

체크박스 유형

앞서 언급했다시피, 라디오 입력 유형을 통해 사용자는 다양한 옵션 중 하나를 선택할 수 있습니다. 하지만 다양한 옵션을 선택하고자 한다면 어떻게 해야 할까요? 이때, checkbox유형 속성을 사용하면 됩니다.

<input type="checkbox" />

제출 유형

이 유형을 사용하여 폼에 제출 버튼을 추가합니다. 사용자가 버튼을 클릭하면, 폼이 자동으로 제출됩니다. 값 속성을 사용해 버튼 안의 텍스트를 정의합니다.

<input type="submit" value="Enter to Win" />

버튼 유형

버튼으로 설정된 유형의 입력은 자바스크립트의 onClick 이벤트 리스너 유형으로 조작할 수 있는 버튼을 만듭니다. 기본적으로 이 유형은 값이 비어 있으므로 값을 지정해야 한다는 점을 제외하고는 제출 입력 유형과 동일한 버튼을 만듭니다.

<input type="button" value="Submit" />

파일 유형

이 유형은 파일 제출을 위한 필드를 정의합니다. 사용자가 클릭하면, 원하는 파일 형식(이미지, PDF, 문서 파일 등)을 삽입하라는 메시지가 나타납니다.

<input type="file" />

파일 입력 유형의 결과는 다음과 같습니다:

색상 유형

이는 HTML5에서 소개된 화려한 입력 유형입니다. 예를 들어, 사용자는 자신이 가장 좋아하는 색상을 제출할 수 있습니다. 검은색(#000000)이 기본값이지만, 원하는 색의 값으로 재정의할 수 있습니다.

많은 개발자가 RGB, HSL 및 영숫자 형식으로 사용할 수 있는 다양한 색조를 선택하기 위한 속임수로 이 기능을 사용합니다.

<input type="color" />

색 입력 유형의 결과는 다음과 같습니다.

검색 유형

검색 유형이 있는 입력은 텍스트 입력 유형과 마찬가지로 텍스트 필드를 정의합니다. 하지만 이 유형은 정보를 검색하는 것일 유일한 목적입니다. 사용자가 입력을 시작하면 취소 버튼이 나타난다는 점에서 텍스트 유형과 다릅니다.

<input type="search" />

URL 유형

입력 태그의 유형 속성을 URL로 설정하면, 사용자가 URL을 입력할 수 있는 필드가 표시됩니다.

<input type="url" />

전화 유형

전화 유형을 사용하여 사용자로부터 전화번호를 수집할 수 있습니다.

<input type="tel" />

날짜 유형

당신은 특정 이벤트의 날짜를 요청한 웹사이트에 등록한 적이 있을 겁니다. 그 웹사이트에서 이 값을 얻기 위해 날짜로 설정된 유형 값이 있는 입력을 사용했을 것입니다.

<input type="date" />

날짜 유형이 있는 입력은 다음과 같습니다:

Datetile-local 유형

이 입력 유형은 날짜 유형처럼 작동하지만, 사용자가 특정 시간의 날짜를 선택할 수도 있습니다.

<input type="datetime-local" />

주 유형

이 입력 유형을 사용하면 특정 주를 선택할 수 있습니다.

<input type="week" />

월 유형

월 유형의 입력은 사용자가 클릭했을 때 선택할 수 있는 월을 채웁니다.

<input type="month" />

텍스트 영역

사용자가 텍스트 입력 유형에 적합하지 않은 여러 줄의 텍스트를 입력해야 하는 경우가 있습니다(텍스트 입력 유형은 한 줄 텍스트 필드를 지정하기 때문에).

텍스트 영역을 사용해 여러 줄의 텍스트 입력을 정의할 때 이 작업을 수행할 수 있습니다. 텍스트 영역의 고유한 속성으로, 행 수에 대해 cols, 열 수에 대해 rows가 있습니다.

<textarea cols="50" rows="20"></textarea>

다중 선택 박스

smoothjjuu marked this conversation as resolved.

이것은 하나의 패키지에 라디오 버튼과 체크박스가 있는 것과 같습니다. 선택 요소와 옵션의 두 가지 요소가 페이지에 포함돼 있으며, 옵션은 항상 선택 요소 내부에 중첩되어 있습니다.

기본적으로 사용자는 옵션 중 하나만 선택할 수 있습니다. 그러나 여러 속성을 사용하면, 사용자가 둘 이상의 옵션을 선택할 수 있습니다.

<select>
      <option value="HTML">Select a Language</option>
      <option value="HTML">HTML</option>
      <option value="CSS">CSS</option>
      <option value="JavaScript">JavaScript</option>
      <option value="React">React</option>
</select>

HTML 입력에 레이블 지정 방법

폼 컨트롤에 레이블을 할당하는 것은 중요합니다. for와 id 속성을 통해 입력 필드에 올바르게 연결되면, 사용자가 레이블 자체를 클릭해 입력에 접근할 수 있으므로 사용하기가 더 쉽습니다.

<label for="name">Name</label>
<input type="text" id="name" /> <br />
<label for="check">Agree with terms</label>
<input type="checkbox" id="check" />

HTML 폼 작동 방법

사용자가 폼을 작성하고 제출 버튼으로 제출하면, 폼 컨트롤의 데이터가 GET 또는 POST HTTP 요청 메소드를 통해 서버로 전송됩니다.

그럼, 서버에 어떻게 표시될까요? 폼 요소는 서버의 URL에 지정해야 하는 액션 속성을 사용합니다. 또한, 서버에 값을 전달하는 데 사용하는 지정된 HTTP 메소드 속성도 사용합니다.

이 메소드는 GET 혹은 POST가 될 수 있습니다. GET 메소드를 사용해, 데이터가 제출되면 사용자가 입력한 값이 URL에 표시됩니다. 그러나 POST를 사용하면, 값이 HTTP 해더에 전송되므로 해당 값이 URL에 표시되지 않습니다.

만약 메소드 속성이 폼에서 사용되지 않으면, 자동으로 디폴트인 GET 메소드를 사용하려는 것으로 간주합니다.

그렇다면 언제 GET 혹은 POST 메소드를 사용해야 할까요? 중요하지 않은 데이터를 제출하거나, 서버에서 데이터를 검색하려면 GET 메소드를 사용합니다. 중요한 데이터나 파일을 제출할 때는 POST 요청을 사용합니다.

미니 프로젝트: 기본 연락처 폼 만들기

이제 폼에 대해 배운 내용을 가지고 간단한 연락처 폼을 만들어 보겠습니다. 그리고 이 모든 것을 정리하면서 몇 가지 새로운 개념을 소개하겠습니다.

HTML 코드는 아래와 같습니다:

<form action="example-server.com">
      <fieldset>
        <legend>Contact me</legend>
        <div class="form-control">
          <label for="name">Name</label>
          <input type="name" id="name" placeholder="Enter your name" required />
        </div>

        <div class="form-control">
          <label for="email">Email</label>
          <input
            type="email"
            id="email"
            placeholder="Enter your email"
            required
          />
        </div>

        <div class="form-control">
          <label for="message">Message</label>
          <textarea
            id="message"
            cols="30"
            rows="10"
            placeholder="Enter your message"
            required
          ></textarea>
        </div>
        <input type="submit" value="Send" class="submit-btn" />
      </fieldset>
</form>

HTML 코드에서 무슨 일이 일어나고 있습니까?

첫째, 폼 요소는 다른 모든 요소를 감쌉니다. 폼 데이터를 수신할 더미 서버인 "example-server.com"으로 설정된 액션이 있습니다.

폼 요소 다음, 다른 모든 요소도 바로 아래에 legend 태그가 있는 fieldset 요소로 둘러싸여 있습니다.

fieldset 요소를 사용해 관련 입력을 그룹화하고, legend 태그에는 폼이 무엇에 관한 것인지를 전달하는 캡션이 포함되어 있습니다.

name, email 그리고 textarea 입력 모두 폼 컨트롤 클래스가 있는 div에 있습니다. 따라서 CSS로 스타일링을 쉽게 하기 위해 블록 요소처럼 작동합니다.

또한 필수 속성으로 검증되므로, 해당 필드가 비어 있거나 사용자가 적절한 형식으로 값을 입력하지 못하면 양식이 제출되지 않습니다.

결과는 아래 스크린샷에서 확인할 수 있습니다:

스타일링 없는 HTML은 너무 안 예쁘네요. 그럼, 이제 스타일링을 적용해 보겠습니다!

CSS는 아래와 같습니다:

body {
    display: flex;
    align-items: center;
    justify-content: center;
    height: 100vh;
    font-family: cursive;
  }
 input,
    textarea {
    width: 100%;
    padding: 5px;
    outline: none;
  }
  label {
    line-height: 1.9rem;
  }
  input[type="submit"] {
   transform: translate(2.2%);
   padding: 3px;
   margin-top: 0.6rem;
   font-family: cursive;
   font-weight: bold;
  }
 fieldset {
   padding: 20px 40px;
 }

CSS 코드 분석하기

Flexbox를 이용해 body의 모든 것을 수평으로, 뷰포트 높이를 100% 수직으로 중앙에 배치합니다. 그리고 font-family로 cursive 폰트를 사용했습니다.

입력과 텍스트 영역을 100% 너비로 지정해 모든 영역을 가로지르게 했습니다. 레이블은 최소 line-height로 1.9 rem(30.4px)으로 각각의 입력에 너무 가깝게 유지되지 않도록 헸습니다.

버튼(입력 타입 버튼)을 transform 속성으로 스타일을 지정해, 중앙에서 약간 벗어난 것처럼 중앙으로 밀어 넣었습니다. 3px의 padding을 주어 더 많은 간격을 두었고, font-family로 cursive를 font-weight는 bold로 굵게 선택했습니다.

버튼이 textarea에 너무 가깝기 때문에, margin-top을 0.6 rem으로 설정해 약간 아래로 밀었습니다.

fieldset 요소에 위쪽과 아래쪽에 20px의 padding을 지정했으며, 왼쪽과 오른쪽에 40px를 주어 감싸고 있는 폼 요소 주위에 생성된 테두리를 밀어냅니다.

결국에는 아래와 같은 아름다운 형태를 보이게 됩니다.

결론

이 튜토리얼이 폼이 어떻게 작동하는지를 이해하는 데 도움이 됐기를 바랍니다. 이제 이 글을 완독한 당신은 웹사이트에 데이터 수집을 시작할 수 있는 폼에 대한 지식을 갖췄습니다.

그럼 읽어주셔서 감사합니다. 즐거운 코딩 하세요.