from flask import Flask
app = Flask(__name__)
@app.route('/')
def example():
return '{"name":"Bob"}'
if __name__ == '__main__':
app.run()
Start Flask
flask run
* Environment: production
WARNING: This is a development server. Do not use it in a production deployment.
Use a production WSGI server instead.
* Debug mode: off
* Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)
127.0.0.1 - - [01/Aug/2019 12:19:00] "GET / HTTP/1.1" 200 -
127.0.0.1 - - [01/Aug/2019 12:19:00] "GET /favicon.ico HTTP/1.1" 404 -
Depending on the way, you install zsh, the installation process clones git-repositories to your home folder $HOME.
Starting zsh does at one point check files git ‘git ls-files’. So, if you have a lot of files and folders in your home directory, this will take some time.
If you want to speedup the start, create a .gitignore file in your home an include all files with not relations to zsh, e.g. .npm, .ssh or .Trash.
Customize Zsh Prompt
Powerlevel9k
Installation on mac OS
Install
$ brew tap sambadevi/powerlevel9k
$ brew install powerlevel9k
This dows not work, if you have set the environment var GIT_CONFIG. In this case, do
unset GIT_CONFIG
git config --global --list
Edit config files
git config --edit --global
git config --edit --system
DESCRIPTION
GIT COMMAND
Configure the author name to be used with your commits.
git config --global user.name "XXX"
Configure the author email address to be used with your commits
git config --global user.email xxx@example.com
Will remove user credential details from the repository
git config --local credential.helper ""
git config —show-origin
List all currently configured remote repository URLs
git remote -v
If you haven’t connected your local repository to a remote server, To add a remote server to a local repository
git remote add origin <repo_url>
Git Commit and Push
DESCRIPTION
GIT COMMAND
Create a file name README.md with Readme content content
echo "Readme content" >> README.md
List the files you’ve changed and those you still need to add or commit
git status
Add all or one file to staging
git add . OR git add file_name
Commit changes to head with message
git commit -m 'message'
Commit any files you’ve added with git add, and also commit any files you’ve changed since then
git commit -a
Send all commits from local repository to remote repository
git push
Do a git push and sets the default remote branch for the current local branch. So any future git pull command will attempt to bring in commits from the <remote-branch>into the current local branch
git push -u <remote-branch>
Send changes to the master branch of your remote repository
git push origin master
Push a specific branch to your remote repository
git push origin <branch_name>
Push all branches to your remote repository
git push --all origin
Working with the Git Workflow
The following steps are based on a branching model, described here.
If you have named a branch incorrectly AND pushed this to the remote repository follow these steps before any other developers get a chance to jump on you and give you shit for not correctly following naming conventions.
If you are on the branch you want to rename:
git branch -m new-name
If you are on a different branch:
git branch -m old-name new-name
2. Delete the old-name remote branch and push the new-name local branch.
git push origin :old-name new-name
3. Reset the upstream branch for the new-name local branch.Switch to the branch and then:
git push origin -u new-name
Or you as a fast way to do that, you can use these 3 steps: command in your terminal
git branch -m old_branch new_branch # Rename branch locally
git push origin :old_branch # Delete old branch
git push --set-upstream origin new_branch # Push new branch, set local branch to track new remote
$ git commit -a -m “release: changes for release 1.2”
Release beenden
$ git checkout master $ git merge –no-ff release-1.2 $ git tag -a 1.2
Git Flow
Initialize
Start using git-flow by initializing it inside an existing git repository:
$ git flow init
Start a new feature
Development of new features starting from the ‘develop’ branch.
git flow feature start MYFEATURE
Finish up a feature
Finish the development of a feature. This action performs the following
git flow feature finish MYFEATURE
Publish a feature
Publish a feature to the remote server so it can be used by other users.
git flow feature publish MYFEATURE
Getting a published feature
Get a feature published by another user.
git flow feature pull origin MYFEATURE
You can track a feature on origin by using
git flow feature track MYFEATURE
Start a release
git flow release start RELEASE [BASE]
It’s wise to publish the release branch after creating it to allow release commits by other developers. Do it similar to feature publishing with the command:
git flow release publish RELEASE
(You can track a remote release with the git flow release track RELEASEcommand)
Finish up a release
git flow release finish RELEASE
Don’t forget to push your tags with git push origin --tags
shows url of remote reposhows detail infos of a remote repo
.gitignore
contains filename to exclude from git
Git Workflow
Release
Creating a release branch
Release branches are created from the develop branch. For example, say version 1.1.5 is the current production release and we have a big release coming up. The state of developis ready for the “next release” and we have decided that this will become version 1.2 (rather than 1.1.6 or 2.0). So we branch off and give the release branch a name reflecting the new version number:
$ git checkout -b release-1.2 develop
After creating a new branch and switching to it, we bump the version number. Here, bump-version.sh is a fictional shell script that changes some files in the working copy to reflect the new version. (This can of course be a manual change—the point being that some files change.) Then, the bumped version number is committed.
This new branch may exist there for a while, until the release may be rolled out definitely. During that time, bug fixes may be applied in this branch (rather than on the developbranch). Adding large new features here is strictly prohibited. They must be merged into develop, and therefore, wait for the next big release.
$ ./bump-version.sh 1.2<br>
$ git commit -a -m "Version 1.2"
The --no-ff flag causes the merge to always create a new commit object, even if the merge could be performed with a fast-forward. This avoids losing information about the historical existence of a feature branch and groups together all commits that together added the feature.
In the latter case, it is impossible to see from the Git history which of the commit objects together have implemented a feature—you would have to manually read all the log messages. Reverting a whole feature (i.e. a group of commits), is a true headache in the latter situation, whereas it is easily done if the --no-ff flag was used.
Hotfix
$ git checkout -b hotfix-1.2.1 master
$ ... do changes ...
$ git commit -a -m "Hotfix Version 1.2.1"
$ .. fix bug
$ git commit -m "Fixed severe production problem"
$ git checkout master
$ git merge --no-ff hotfix-1.2.1
$ git tag -a 1.2.1
# incude hotfix into develop
$ git checkout develop
$ git merge --no-ff hotfix-1.2.1
# finally, remove hotfix branch
$ git branch -d hotfix-1.2.1
Error Message: Your local changes to the following files would be overwritten by merge:
error: Your local changes to the following files would be overwritten by merge:<br>
README.md<br>
Please commit your changes or stash them before you merge.
docker ps — Lists running containers. Some useful flags include: -a / -all for all containers (default shows just running) and —-quiet /-q to list just their ids (useful for when you want to get all the containers).
docker pull — Most of your images will be created on top of a base image from the Docker Hub registry. Docker Hub contains many pre-built images that you can pull and try without needing to define and configure your own. To download a particular image, or set of images (i.e., a repository), use docker pull.
docker build — Builds Docker images from a Dockerfile and a “context”. A build’s context is the set of files located in the specified PATH or URL. Use the -t flag to label the image, for example docker build -t my_container . with the . at the end signalling to build using the currently directory.
docker logs — Display the logs of a container. You must specify a container and can use flags, such as --follow to follow the output in the logs of using the program. docker logs --follow my_container
docker volume ls — Lists the volumes,. Volumes are the preferred mechanism for persisting data generated by and used by Docker containers.
docker rm — Removes one or more containers. docker rm my_container
docker rmi — Removes one or more images. docker rmi my_image
docker stop — Stops one or more containers. docker stop my_containerstops one container, while docker stop $(docker ps -a -q) stops all running containers. A more direct way is to use docker kill my_container, which does not attempt to shut down the process gracefully first.
Use them together, for example to clean up all your docker images and containers:
kill all running containers with docker kill $(docker ps -q)
delete all stopped containers with docker rm $(docker ps -a -q)
delete all images with docker rmi $(docker images -q)
Create new container
Start a new docker image with a given name
You can start a new container by using the run command and specify the desired image
As a result, you are in the container at the bash command line
Reconnect to image
$ docker attach playground
Commit changes in container
$ docker start playground
$ docker attach playground
root@c106fbb48b20:/# echo 1.0 >VERSION
root@c106fbb48b20:/# exit
$ docker commit playground playground:1.0
$ docker tag playground:1.0 playground:latest
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
playground 1.0 01703597322b Less than a second ago 94.6MB
playground latest 01703597322b Less than a second ago 94.6MB
$ docker network ls
NETWORK ID NAME DRIVER SCOPE
6742a11bff1e bridge bridge local
3af0a1c9eaac host host local
e60f68aad9d6 none null local
c97a80b449d9 playground_bridge bridge local
Start the database application using the bridges network
$ docker run -d --net=playground_bridge --name playground_db training/postgres
88abb9d018c628ed1abe7da0466289846a8342a28b2cbef3305ea5313c46d647
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept All”, you consent to the use of ALL the cookies. However, you may visit "Cookie Settings" to provide a controlled consent.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Duration
Description
cookielawinfo-checkbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.