Skip to main content

Home/ Larvata/ Group items tagged GitHub

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
crazylion lee

GitHub - cool-RR/PySnooper: Never use print for debugging again - 0 views

github.com/pysnooper

python debugger

shared by crazylion lee on 15 Jul 19 - No Cached
  • crazylion lee on 15 Jul 19
     
    "Never use print for debugging again"
張 旭

Introduction to GitLab Flow | GitLab - 0 views

docs.gitlab.com/...gitlab_flow.html

programming git gitlab flow

shared by 張 旭 on 14 Mar 20 - No Cached
  • GitLab flow as a clearly defined set of best practices. It combines feature-driven development and feature branches with issue tracking.
  • In Git, you add files from the working copy to the staging area. After that, you commit them to your local repo. The third step is pushing to a shared remote repository.
  • branching model
  • ...68 more annotations...
  • The biggest problem is that many long-running branches emerge that all contain part of the changes.
  • It is a convention to call your default branch master and to mostly branch from and merge to this.
  • Nowadays, most organizations practice continuous delivery, which means that your default branch can be deployed.
  • Continuous delivery removes the need for hotfix and release branches, including all the ceremony they introduce.
  • Merging everything into the master branch and frequently deploying means you minimize the amount of unreleased code, which is in line with lean and continuous delivery best practices.
  • GitHub flow assumes you can deploy to production every time you merge a feature branch.
  • You can deploy a new version by merging master into the production branch. If you need to know what code is in production, you can just checkout the production branch to see.
  • Production branch
  • Environment branches
  • have an environment that is automatically updated to the master branch.
  • deploy the master branch to staging.
  • To deploy to pre-production, create a merge request from the master branch to the pre-production branch.
  • Go live by merging the pre-production branch into the production branch.
  • Release branches
  • work with release branches if you need to release software to the outside world.
  • each branch contains a minor version
  • After announcing a release branch, only add serious bug fixes to the branch.
  • merge these bug fixes into master, and then cherry-pick them into the release branch.
  • Merging into master and then cherry-picking into release is called an “upstream first” policy
  • Tools such as GitHub and Bitbucket choose the name “pull request” since the first manual action is to pull the feature branch.
  • Tools such as GitLab and others choose the name “merge request” since the final action is to merge the feature branch.
  • If you work on a feature branch for more than a few hours, it is good to share the intermediate result with the rest of the team.
  • the merge request automatically updates when new commits are pushed to the branch.
  • If the assigned person does not feel comfortable, they can request more changes or close the merge request without merging.
  • In GitLab, it is common to protect the long-lived branches, e.g., the master branch, so that most developers can’t modify them.
  • if you want to merge into a protected branch, assign your merge request to someone with maintainer permissions.
  • After you merge a feature branch, you should remove it from the source control software.
  • Having a reason for every code change helps to inform the rest of the team and to keep the scope of a feature branch small.
  • If there is no issue yet, create the issue
  • The issue title should describe the desired state of the system.
  • For example, the issue title “As an administrator, I want to remove users without receiving an error” is better than “Admin can’t remove users.”
  • create a branch for the issue from the master branch
  • If you open the merge request but do not assign it to anyone, it is a “Work In Progress” merge request.
  • Start the title of the merge request with [WIP] or WIP: to prevent it from being merged before it’s ready.
  • When they press the merge button, GitLab merges the code and creates a merge commit that makes this event easily visible later on.
  • Merge requests always create a merge commit, even when the branch could be merged without one. This merge strategy is called “no fast-forward” in Git.
  • Suppose that a branch is merged but a problem occurs and the issue is reopened. In this case, it is no problem to reuse the same branch name since the first branch was deleted when it was merged.
  • At any time, there is at most one branch for every issue.
  • It is possible that one feature branch solves more than one issue.
  • GitLab closes these issues when the code is merged into the default branch.
  • If you have an issue that spans across multiple repositories, create an issue for each repository and link all issues to a parent issue.
  • use an interactive rebase (rebase -i) to squash multiple commits into one or reorder them.
  • you should never rebase commits you have pushed to a remote server.
  • Rebasing creates new commits for all your changes, which can cause confusion because the same change would have multiple identifiers.
  • if someone has already reviewed your code, rebasing makes it hard to tell what changed since the last review.
  • never rebase commits authored by other people.
  • it is a bad idea to rebase commits that you have already pushed.
  • If you revert a merge commit and then change your mind, revert the revert commit to redo the merge.
  • Often, people avoid merge commits by just using rebase to reorder their commits after the commits on the master branch.
  • Using rebase prevents a merge commit when merging master into your feature branch, and it creates a neat linear history.
  • every time you rebase, you have to resolve similar conflicts.
  • Sometimes you can reuse recorded resolutions (rerere), but merging is better since you only have to resolve conflicts once.
  • A good way to prevent creating many merge commits is to not frequently merge master into the feature branch.
  • keep your feature branches short-lived.
  • Most feature branches should take less than one day of work.
  • If your feature branches often take more than a day of work, try to split your features into smaller units of work.
  • You could also use feature toggles to hide incomplete features so you can still merge back into master every day.
  • you should try to prevent merge commits, but not eliminate them.
  • Your codebase should be clean, but your history should represent what actually happened.
  • If you rebase code, the history is incorrect, and there is no way for tools to remedy this because they can’t deal with changing commit identifiers
  • Commit often and push frequently
  • You should push your feature branch frequently, even when it is not yet ready for review.
  • A commit message should reflect your intention, not just the contents of the commit.
  • each merge request must be tested before it is accepted.
  • test the master branch after each change.
  • If new commits in master cause merge conflicts with the feature branch, merge master back into the branch to make the CI server re-run the tests.
  • When creating a feature branch, always branch from an up-to-date master.
  • Do not merge from upstream again if your code can work and merge cleanly without doing so.
crazylion lee

GitHub - codeforequity-at/botium-speech-processing: Botium Speech Processing - 0 views

github.com/...botium-speech-processing

speech

shared by crazylion lee on 18 Feb 20 - No Cached
  • crazylion lee on 18 Feb 20
     
    "Botium Speech Processing"
crazylion lee

GitHub - mhinz/vim-galore: All things Vim! - 0 views

github.com/vim-galore

vim tutorial

shared by crazylion lee on 12 May 17 - No Cached
  • crazylion lee on 12 May 17
     
    " All things Vim!"
crazylion lee

GitHub - etsy/statsd: Daemon for easy but powerful stats aggregation - 0 views

github.com/statsd

node.js aggregation stats daemon sysadmin

shared by crazylion lee on 21 Apr 17 - No Cached
  • crazylion lee on 21 Apr 17
     
    "Daemon for easy but powerful stats aggregation"
crazylion lee

pupil/detect_2d.hpp at master · pupil-labs/pupil · GitHub - 0 views

github.com/...detect_2d.hpp

pupil

shared by crazylion lee on 12 May 17 - No Cached
  • crazylion lee on 12 May 17
     
    "pupil"
crazylion lee

GitHub - donnemartin/system-design-primer: Learn how to design large-scale systems. Pre... - 0 views

github.com/...system-design-primer

large scale

shared by crazylion lee on 12 May 17 - No Cached
  • crazylion lee on 12 May 17
     
    "Learn how to design large-scale systems. Prep for the system design interview. Includes Anki flashcards."
crazylion lee

GitHub - xmuSistone/android-pile-layout: An abnormal horizontal ListView-like pile layout. - 0 views

github.com/...android-pile-layout

android layout

shared by crazylion lee on 14 May 17 - No Cached
  • crazylion lee on 14 May 17
     
    "An abnormal horizontal ListView-like pile layout."
crazylion lee

GitHub - koalaman/shellcheck: ShellCheck, a static analysis tool for shell scripts - 0 views

github.com/shellcheck

shell check

shared by crazylion lee on 14 May 17 - No Cached
  • crazylion lee on 14 May 17
     
    "ShellCheck, a static analysis tool for shell scripts http://www.shellcheck.net"
crazylion lee

GitHub - tangchao5206/BleUtils: 安卓低功耗蓝牙ble快速上手 - 0 views

github.com/BleUtils

blue java android

shared by crazylion lee on 14 May 17 - No Cached
  • crazylion lee on 14 May 17
     
    "安卓低功耗蓝牙ble快速上手"
crazylion lee

GitHub - Rich-Harris/butternut: The fast, future-friendly minifier - 0 views

github.com/butternut

javascript minify

shared by crazylion lee on 14 May 17 - No Cached
  • crazylion lee on 14 May 17
     
    "The fast, future-friendly minifier https://butternut.now.sh"
crazylion lee

GitHub - rancher/os: Tiny Linux distro that runs the entire OS as Docker containers - 0 views

github.com/os

docker os container

shared by crazylion lee on 14 May 17 - No Cached
  • crazylion lee on 14 May 17
     
    "Tiny Linux distro that runs the entire OS as Docker containers "
crazylion lee

GitHub - yandex/gixy: Nginx configuration static analyzer - 0 views

github.com/gixy

nginx config

shared by crazylion lee on 14 May 17 - No Cached
  • crazylion lee on 14 May 17
     
    "Nginx configuration static analyzer"
crazylion lee

GitHub - intercom/hippie_csv: Tolerant, liberal CSV parsing - 0 views

github.com/hippie_csv

csv ruby gem

shared by crazylion lee on 12 May 17 - No Cached
  • crazylion lee on 12 May 17
     
    " Tolerant, liberal CSV parsing"
crazylion lee

GitHub - stevekane/promise-it-wont-hurt: A Workshopper module that teaches you to use p... - 0 views

github.com/...promise-it-wont-hurt

javascript promise

shared by crazylion lee on 12 May 17 - No Cached
  • crazylion lee on 12 May 17
     
    "A Workshopper module that teaches you to use promises in javascript"
« First ‹ Previous 61 - 80 of 364 Next › Last »
Showing 20▼ items per page