@marcorichetta your pull request is missing a changelog!

Codecov Report

Merging #427 (672e0fc) into main (35ef8d9) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #427   +/-   ##
=======================================
  Coverage   95.21%   95.21%           
=======================================
  Files          22       22           
  Lines         710      710           
=======================================
  Hits          676      676           
  Misses         34       34           

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 35ef8d9...672e0fc. Read the comment docs.

@marcorichetta Everything else LGTM 👍🏾 can you just squash the commit into one ?

@Pradhvan I squashed commits on merge via github Squash and merge but never made it on the same branch.

After reading from Gitlab docs, I was able to squash them but I'm not sure of the final step:

If you haven’t pushed your commits to the remote branch before rebasing, push your changes normally. If you had pushed these commits already, force-push instead.

Is it correct to go with force-push or should I make a new branch?

@marcorichetta yes, you would need to force push after squashing your commit into one.

The reason we do this is so that the master branch commits have a cleaner commit history as your change can be easily tracked with one commit rather than having two.

Let me know if you need any help with anything.

Noooooo, I've merged it, sorry! My bad 😢

The reason we do this is so that the master branch commits have a cleaner commit history as your change can be easily tracked with one commit rather than having two.

@Pradhvan Thanks for the explanation!

I thnk @camilamaia merged the two commits with the Squash and merge option because on main there is only one commit => ccfb432

That said, is there an advantage on squashing locally vs squash on merge? I think the latter is easier both for contributor and for mantainer.

@marcorichetta yes the latter is an easier option but usually gives out a commit history that is definitely not clean.

For example, this is what the master branch's commit message looks like when it was squashed and merged it.

 Fix: Docstrings converted to single-line (#427)

* Fix: Docstrings converted to single-line

- Docstrings fits in a single line according to PEP8.
- Reference https://deepsource.io/gh/scanapi/scanapi/issue/FLK-D200/occurrences

Fixes #411

* Fix: doc line need to be <= 80 characters

On the other hand, if we had squashed and merged it into a single commit. We would have the liberty to make this message a bit cleaner and more understandable for others who were not involved with the PR. Something like this

 Fix: Docstrings converted to single-line (#427)

* Fix: Docstrings converted to single-line

- Updated `scanapi/__main__.py`, `scanapi/config_loader.py`, `scanapi/exit_code.py` one-line docstring 
to fit on one line with quotes.

Fixes #411

The latter commit message helps in keeping a clean commit history so others know what has been merged with master just by looking at the last commit.