dannydannydanny/methodology
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
Mirror — primary at git.dannydannydanny.me
153 commits 1 branch 0 tags 362 KiB
Find a file
Daniel Thoren ffb0a5b087
🚚 re-order intro
2021-09-29 12:33:21 +02:00
projects/copr 📝 add project portfolio for CoPr 2021-07-20 14:10:09 +02:00
.bashrc_gitbash 🐛 fix wrong name on gitbash bashrc 2021-04-09 11:18:36 +02:00
.vimrc_gitbash ✨ add .vimrc_gitbash 2021-04-09 11:53:38 +02:00
_config.yml 💄 add github pages markdown rendering 2020-12-16 10:21:50 +01:00
diagrams.drawio Update diagrams.drawio 2021-08-18 15:23:20 +02:00
LICENSE Initial commit 2020-12-10 10:52:44 +01:00
python_kernel.md ✨ add python kernel management 2021-03-31 13:15:27 +02:00
README.md 🚚 re-order intro 2021-09-29 12:33:21 +02:00
vim.md ✨ add vim scratch pad 2021-03-31 12:56:19 +02:00

README.md

DannyDannyDanny/Methodology

Gitmoji

Repo Roadmap

This guide focuses on designing, developing and delivering Data-Processing Sytems, written primarily in python, deploying to Linux / FreeBSD servers, optionally communicating with external interfaces (APIs or DBs). The repo is actively being updated; bookmark 🔖 it, leave a Star ⭐ or Watch 👁️ the repo.

  • 2021Q1: Gitmoji -> (general) Methodology ✅
  • 2021Q2: Version control methodology
  • 2021Q3: Decide on sections
    • Python section Sections by Project Phase (setup, develop, deploy, deliver) each section should cover the same topics (i.e version control, DevOps)
    • Move as much as possible from Topic Hierarchy into phases
  • 2021Q4
  • 2022Q1 Consultancy Methodology
  • 2022Q2 Alternative to Github?

Gitmoji reference

Use the format :gitmoji: <commit message> in your commit messages. Only proper nouns, CamelCase and class names should have uppercases letters. Avoid using multiple gitmojis. Use several gitmojis if it makes sense.

emoji code description
✨ :sparkles: add new feature / function
🎨 :art: refactor code / improve readibility / structure and lint flake8
🥅 :goal_net: try/raise/handle errors or warnings
⚡ :zap: improve performance / coverage / profiling
🐛 :bug: bug fixing
🚚 :truck: moving / renaming
♻️ :recycle: work related to CI/CD, webhooks, automated tests
💥 :boom: work in progress / breaking changes
📝 :memo: doc / logging / verbosity / code comments
🔥 :fire: remove (dead) code / file
👽 :alien: changes related to APIs and Databases
🎉 :tada: clean / transform / validate data
💄 :lipstick: improve UI / UX, CLI or visualizations
🧠 :brain: statistical modelling, training and prediction
📌 :pushpin: dependency and environment versioning
🙈 :see_no_evil: changes to .gitignore and exclusively local files
🔍 :mag: changes in connection with PR-review change-requests

Missing a gitmoji? Get inspiration. Submit an issue (or Pull Request).

Setup

Setup Server Management

Setup Version Control

Oneliner install and run

When using git repositories, connect with ssh.

The README for your project should contain a one-liner code that dowloads, installs and runs a mini-test.

git clone https://github.com/user/repo.git cool-repo && cd cool-repo
pipenv install
pipenv run python .
#cd .. && rm -rf cool-user-repo-online

Develop

Python Developement

Develop with Version Control

# Git Log A DOG acronym
git log --all --decorate --oneline --graph

# when you have uncommitted changes
git add --patch <pattern>

# check what you've staged
git diff --cached

# NEW DEVELOPMENT FLOW
# clone repo with local_name enables several clones
git clone <repo> <local_name>

# optional: checkout (i.e switch to) a branch to continue developing from there
git checkout <feature/featurename>

# optional if you switched branch on the last step
# switched branch: branch out from 
git checkout <feature/newfeature>
git branch <feature/newfeature>
git push --set-upstream origin <feature/newfeature>

# delete branch locally (-d: normal, -D: force)
git branch -D <branch_name_1> <branch_name_2> <branch_name_1>
# delete remote
git push origin -d <branch_name>

# Comparing / Merging two branches
git merge --no-commit --no-ff <feature/otherfeaturebranch>

# get file from another branch
git checkout <otherbranch> -- path/to/dir

# delete branches not present on remote
git remote prune origin

# see all commits that affected somefile
git log --follow -- filename

# search code in all history
git log -S "some_old_varname" --oneline --all

Submitting multiple PRs

Context:

  1. submit PR for feature1
  2. from feature1 branch make new branch feature2
  3. commit and push feature2 changes
  4. submit PR
  5. Both PRs approved
# there should be one or more flows that account for cases where:
# -> feature1 gets change requests
# -> feature1 is rejected and made obsolete