DEV Community: DanKim0213

내가 팀프로젝트에서 사용한 Git

DanKim0213 — Wed, 24 May 2023 07:06:48 +0000

Github Flow

다른 사람이 같은 이슈를 작업하고 있진 않는지 확인하기
그렇지 않다면, 깃랩에서 이슈 생성 및 feature 브랜치를 생성하기
1. 하루 단위로 작업할 수 있는 feature 브랜치를 만들어주세요
2. 이슈 생성시, label을 명확히 분간하여 달아주세요
일 하기
```
$ git add . && git commit
```
최신 업데이트 하기
```
$ git pull --rebase origin develop
```
깃랩에 푸시하기
```
$ git push origin feature-sth
```

FAQ

Q. Error: Updates were rejected because the tip of your current branch is behind

깃랩에 있는 feature 브랜치를 삭제하고 다시 푸시하세요

$ git push -d origin feature-sth && git push origin feature-sth

Q. 작업하던 feature 브랜치를 업데이트 하는 방법은?

develop 브랜치를 바탕으로 업데이트 합니다

$ git pull --rebase origin develop

Q. 집 노트북으로 작업하던 것을 외부 노트북으로 연이어 작업하는 방법은?

내 로컬 feature 브랜치를 깃랩 feature 브랜치로 업데이트 합니다

$ git pull --rebase origin feature-sth

Q. merge 가 안됩니다

merge는 오직 maintainers만 할 수 있습니다. maintainers 에게 말해주세요

Q. rebase 할때, conflict 났습니다.

철회하고 maintainers 을 불러주세요

$ git rebase --abort

Reference

GitHub Flow

How to Handle Error with Jest

DanKim0213 — Wed, 15 Feb 2023 21:13:56 +0000

Agenda

The goal of this post
expect.assertions(number) rather than done()
.rejects rather than try-catch
.toThrow rather than toMatch or toEqual
Use-case 1: Handle Error in a function
Use-case 2: Handle Error in an asynchronous function
References

1. The goal of this post

The goal of this post is to give you an opinionated way of how to handle error with jest. Since a bunch of source, including the official guide, suggests various ways (but each way has its own rule to comply with 😡), it would mislead to testing.

2. expect.assertions(number) rather than done()

Both expect.assertions() and done() are used to test async functions. However, expect.assertions() is focused on to verify that a certain number of assertions are called during a test while done() is focused on to wait a certain assertion to be called. Therefore, expect.assertions() would fail if the number of expectations are not called while done() would fail because of timeout (mostly from not calling done() at the end).

Let's compare between done() and expect.assertion(number) when doing async calls.

API - expect.assertions(number)

Make sure to add expect.assertions to verify that a certain number of assertions are called. Otherwise a fulfilled promise would not fail the test.

test('doAsync calls both callbacks', () => {
  expect.assertions(2);
  function callback1(data) {
    expect(data).toBeTruthy();
  }
  function callback2(data) {
    expect(data).toBeTruthy();
  }

  doAsync(callback1, callback2);
});

VS.

Testing Asynchronous Code - callbacks

done() is necessary. Otherwise, the test will complete as soon as fetchData completes, before ever calling the callback.

test('the data is peanut butter', done => {
  function callback(error, data) {
    if (error) {
      done(error);
      return;
    }
    try {
      expect(data).toBe('peanut butter');
      done();
    } catch (error) {
      done(error);
    }
  }

  fetchData(callback);
});

You could notice at a glance that done(error) is declared in the catch block in order to avoid timeout. On the one hand, you could easily notice errors and reduce your time to figure out what went wrong by doing so. On the other hand, you could easily forget that where you need to declare done() properly.

The rule of thumbs here is to declare expect.assertions(number) at the beginning of your tests. It never causes a problem at all.

3. .rejects rather than try-catch

API - .rejects

Use .rejects to unwrap the reason of a rejected promise so any other matcher can be chained. If the promise is fulfilled the assertion fails.

test('rejects to octopus', async () => {
  await expect(Promise.reject(new Error('octopus'))).rejects.toThrow('octopus');
});

VS.

Stack Overflow

You must handle errors at the catch block.

it('calls the API and throws an error', async () => {
  expect.assertions(2);
  try {
    await login('email', 'password');
  } catch (error) {
    expect(error.name).toEqual('Unauthorized');
    expect(error.status).toEqual(401);
  }
});

You know the test is supposed to cause an error. The key point of .rejects() is that the assertion fails when the promise is fulfilled.

!CAUTION
Be sure to return (or await) the promise - if you omit the return/await statement, your test will complete before the promise returned from fetchData resolves or rejects.

!tip
expect.assertions(number) while using .rejects is not required but recommended to verify that a certain number of assertions are called during a test.

4. .toThrow rather than toMatch or toEqual

You can provide an optional argument to test that a specific error is thrown such as regex, string, error object, and error class. However, toMatch and toEqual only do one thing each: to match a string and equal to an object.

API - .toThrow

test('throws on octopus', () => {
  expect(() => {
    drinkFlavor('octopus');
  }).toThrow();
});

Stack Overflow

test("Test description", () => {
  const t = () => {
    throw new TypeError("UNKNOWN ERROR");
  };
  expect(t).toThrow(TypeError);
  expect(t).toThrow("UNKNOWN ERROR");
});

!tip
You must wrap the code in a function, otherwise the error will not be caught and the assertion will fail.

!tip
You don't need to wrap a promise function. Just invoke it.
Code Example

test('the fetch fails with an error', async () => {
  await expect(fetchData()).rejects.toMatch('error');
});

5. Use-case 1: Handle Error in a function

Let's integrate what we learned into a simple code snippet.

test("Test description", () => {
  expect.assertions(2);
  const t = () => {
    throw new TypeError("UNKNOWN ERROR");
  };
  expect(t).toThrow(TypeError);
  expect(t).toThrow("UNKNOWN ERROR");
});

I declared expect.assertions(number) even though the above test is not asynchronous. It doesn't matter since expect.assertions() never causes a problem at all.
I used .toThrow() rather than .toMatch or .toEqual since it handles Error object and string alike.

6. Use-case 2: Handle Error in an asynchronous function

test('the fetch fails with an error', async () => {
  expect.assertions(1);
  await expect(fetchData()).rejects.toThrow('error');
});

I declared expect.assertions(number) even though it is not required while using .rejects().
I handled an error, by using .rejects, within a single block, not within a try-catch block.
I used .toThrow rather than .toMatch or .toEqual.

7. References

hint: Updates were rejected because the tip of your current branch is behind

DanKim0213 — Wed, 08 Feb 2023 11:40:30 +0000

Troubleshooting

I prefer rebasing my feature branch onto Master branch before PR (Pull Request). But, sometimes I got this:

$ git push origin feature/specific-feature
hint: Updates were rejected because the tip of your current branch is behind

hint: its remote counterpart. Integrate the remote changes (e.g.

hint: 'git pull ...') before pushing again.

hint: See the 'Note about fast-forwards' in 'git push --help' for details.

This happens when I already pushed Feature branch to Github and thus the sync between my local feature branch and the remote branch in GitHub got broken. To resolve this issue:

$ git push -d origin specific-feature
$ git push origin specific-feature

Some developers recommend using force-push. Though, in my preference, deleting the remote branch is more appropriate since force-push has several caveats and I or my colleagues in some situations would abuse force-push if we are used to force-push.

This flag disables these checks, and can cause the remote repository to lose commits; use it with care.

Is GitHub flow better than Git flow?

DanKim0213 — Wed, 08 Feb 2023 11:33:03 +0000

Git flow or Github flow?

The world of Git offers several collaboration strategies, including Github Flow, Git Flow, Gitlab Flow, and others. In this post, I'd like to share my thoughts on Github Flow specifically.

My team and I opted for Git Flow at the outset of our project, after a thorough discussion on which flow to adopt. We were all new to Git at the time, so we relied on a post for guidance and diligently followed its advice.

Let's do it: GitHub flow

As I continued to use Git Flow, I became aware of its limitations, particularly its complexity with the use of multiple branches - Master, Develop, Feature, Hotfix, and Release. However, this complexity can be mitigated through the use of Github Flow, which only requires two branches: Master and etc. As Scott Chacon stated,

Anything in the master branch is deployable.

Github Flow, first introduced by Vincent Driessen, is a more suitable option for teams practicing continuous delivery, as it provides a simpler workflow compared to Git Flow.

If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow)

What if we require versioned releases?

As previously mentioned, anything in the Master branch is deployable, but there are times when we need to maintain starting points for significant updates. This is where the Tagging feature in Git comes in handy. By utilizing the git tag command, we can easily create versioned releases, such as

$ git tag
v1.0
v2.0

Further

How to Set up SSH

DanKim0213 — Fri, 29 Apr 2022 07:22:52 +0000

Agenda

What is SSH
Advantages of ssh-key authentication
How to generate ssh-key
How to configure generated ssh keys
Use-case 1: GitHub
Use-case 2: Remote server
References

1. What is SSH

SSH stands for Secure Shell, by which users can manage systems or transfer of files from computer to computer. Users can access to remote machines by username + password or ssh key. I personally prefer ssh-key authentication to traditional login authentication since you can use ssh-key to authenticate yourself not only on remote computers, but also on GitHub and so on.

2. Advantages of ssh-key authentication

The use of multiple SSH keys to grant secure server access to multiple individuals affords three advantages over assigning separate user accounts with traditional login credentials.

Grants access to multiple parties without sharing passwords.
Simplifies permission management; all parties log in as the same user and thereby share permissions.
Allow for easy access revocation as needed.

3. How to generate ssh-key

There are multiple algorithms to generate ssh-key: RSA, DSA, ECDSA, and EdDSA. Mostly used algorithm is RSA (the default option for ssh-keygen), but EdDSA is newer and provides the highest security level compared to key length.

simply:
ssh-keygen -t ed25519 -C "john@example.com"
or more securely:
ssh-keygen -o -a 100 -t ed25519 -f ~/.ssh/id_ed25519 -C "john@example.com"

-t specifies the type of key to create, in our case the Ed25519.
-f specifies the filename of the generated key file.
-C specifies a comment.

4. How to configure generated ssh keys

You need to use ssh-agent, which is a helper program that keeps track of user's identity keys and their passphrases. Make sure ssh-agent is running:
eval "$(ssh-agent -s)"

Add a host onto "~/.ssh/config":

Host myRemoteServer
  HostName 198.222.111.33
  User john
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

Finally, add your SSH key to the agent:

option1 (Mac user):
If you're using macOS Sierra 10.12.2 or later, you will need to modify your ~/.ssh/config file to automatically load keys into the ssh-agent and store passphrases in your keychain.

Host *
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/id_ed25519

ssh-add -K ~/.ssh/id_ed25519

option2 (linux user):
And then, add your newly generated Ed25519 key to SSH agent
ssh-add ~/.ssh/id_ed25519
or add all generated keys to SSH agent
ssh-add

5. Use-case 1: GitHub

First,
pbcopy < ~/.ssh/id_ed25519.pub

Click my profile image -> Settings -> In the "Access" section of the sidebar, click SSH and GPG keys -> Click New SSH key or Add SSH key -> paste the copied key into "Key" field.

6. Use-case 2: Remote server

First of all, copy the public key to the remote server:
ssh-copy-id -i ~/.ssh/id_ed25519.pub john@198.222.111.33

And then:
ssh john@198.222.111.33
or:
ssh myRemoteServer

7. References

How to use Git at Work

DanKim0213 — Mon, 25 Apr 2022 04:17:27 +0000

Agenda

General Concept
Caveats
how to clone
how to branch
how to commit
how to update
how to maintain
Last Words
References

1. General Concept

Basically, you'll get two branches at work: master and develop.

The master branch is designed for production. The maintainers of your team project handle this branch to publish.
The develop branch is designed for development. The developers of your team project stretch their own branches per feature and then merge the feature branches to the develop branch. The feature branches, of course, must be tested in advance of merging to the develop branch.

2. Caveats

You need to know the difference between "origin develop", "origin/develop", and "develop".

"origin develop" is a remote branch on sites such as GitHub, gitlab, etc. Thus, we use like: git fetch origin develop git push origin develop
On the other hand, "origin/develop" is a downloaded branch from a remote server such as gitHub, gitlab, etc. This means a downloaded branch could be out of date so that you must update the downloaded branch regularly. i.e. whenever you start coding in the morning or pushing your codes. Thus, we use like: git merge origin/develop git rebase origin/develop
"develop" is a local branch you can modify. Thus, we use like: git checkout develop git diff develop your-new-feature

3. How to clone

Before you start developing, you need to clone your team project so that your teammates can work with the same project maintained by the same git.

git clone https://github.com/<username>/<project.git>

and then, go to the develop branch:
git checkout develop

4. How to branch

git checkout -b your-new-feature

5. How to commit

Let's add all changed files except for declared files in .gitignore.

git add .
git status
git commit -m "message here."

6. How to update

You need to update your downloaded branch before pushing your changes.
git fetch
git rebase origin/develop

And then, go to the develop branch, update your local develop branch ,and push your changes to the remote git repository.
git checkout develop
git merge origin/develop
git merge your-new-feature --no-ff
git push origin develop

7. How to maintain

You can track git commits:
git log --all --oneline --graph

Or, you can track git commits of a specific file:
git log -p ./path/to/file

You can figure out what changes to be committed:
git status

You can figure out differences by two options:
git diff
git diff --staged

8. Last words

This post could be a very unkind one since I skipped describing all details of git commands but focused on how to use git commands in a chronological order. However, by doing so, you can figure out the whole picture of how to use git at work.

I will appreciate that all comments point out something wrong on my post :) Thanks.

DEV Community: DanKim0213

내가 팀프로젝트에서 사용한 Git

Github Flow

FAQ

Reference

How to Handle Error with Jest

Agenda

1. The goal of this post

2. expect.assertions(number) rather than done()

3. .rejects rather than try-catch

4. .toThrow rather than toMatch or toEqual

5. Use-case 1: Handle Error in a function

6. Use-case 2: Handle Error in an asynchronous function

7. References

hint: Updates were rejected because the tip of your current branch is behind

Troubleshooting

Is GitHub flow better than Git flow?

Git flow or Github flow?

Let's do it: GitHub flow

What if we require versioned releases?

Further

How to Set up SSH

Agenda

1. What is SSH

2. Advantages of ssh-key authentication

3. How to generate ssh-key

4. How to configure generated ssh keys

5. Use-case 1: GitHub

6. Use-case 2: Remote server

7. References

How to use Git at Work

Agenda

1. General Concept

2. Caveats

3. How to clone

4. How to branch

5. How to commit

6. How to update

7. How to maintain

8. Last words

9. References