Ім'я файлу: Git-Gitflow.pptx Розширення: pptx Розмір: 761кб. Дата: 04.07.2022 скачати Пов'язані файли: Славич Захар.pptx 14-16.docx педіатрія.docx Аристотель.docx ФІЗИКА 3.docx 2кур.docx ТЕХНОЛОГЫЧНЫ КАРТИ.docx 99763.ppt Git for Version ControlWhy Git?
Subversion Git Adding a file to git repository
Adding Multimpule files…Git flowGitflow is great for projects that have a planned release cycle. This model assumes no additional concepts beyond those described for the Feature Branch Workflow model. Instead, it assigns specific roles to different branches and determines how and when they should interact. In addition to feature branches, it uses separate branches for preparing, maintaining, and writing a release. Of course, you also need to make good use of all the benefits of the Feature Branch Workflow: pull requests, isolation for changes, and effective collaboration within the team. How it works?Master and Develop branches instead of using a single master branch, this model uses two branches to record the history of a project. The master branch holds the official release history, while the develop branch serves as an integration branch for new features. Also, it is convenient to tag all commits in the master branch with a version number. The first step is to create a develop branch from the master branch. The easiest way to do this is for a single developer to create an empty branch locally and push it to the central repository. This branch will contain the entire history of the project, while master contains a partial history. The rest of the developers must now clone the central repository and create a tracking branch for the develop branch. Feature branchesEach new feature should be developed on a separate branch that can be pushed to a central repository for backup/team collaboration. Feature branches are created not on the basis of master, but on the basis of develop. When work on a new feature is completed, it is merged back into develop. New code should not be sent directly to master. Release branchesWhen enough new code has already been merged into the develop branch for a release a release branch is created from the develop branch. The creation of this branch means the beginning of the next release cycle, during which new functionality is no longer added, but only bugs are debugged, documentation is created, and other release-related tasks are solved. When everything is ready, the release branch is merged into master and the version tag is assigned to it. In addition, it must also be merged back into the develop branch, which may have added changes since the release branch since the creation of the release branch. Using a separate release branch allows one team to work on the current release while another team is already working on features for the next release. It also allows you to delineate development milestones. Creating release branches is another simple branching operation. Like feature branches, release branches are based on the develop branch. When a release is ready to ship, it is merged into master and develop, and the release branch is deleted. It's important to merge it back into develop because critical updates may be added to the release branch and they need to be available for new features. If your team is focusing on code reviews, this is the perfect moment for a pull request. Hotfix branchesHotfix branches are used to quickly make fixes to the production version of the code. Hotfix branches are very similar to release and feature branches, except they are from master rather than from develop. This is the only branch that must be created directly from master. Once the fix is complete, the hotfix branch should be merged into both master and develop (or the current release branch), and master should be tagged with the updated version number. Having a dedicated bug fix branch allows the team to resolve issues without interrupting the rest of the workflow or waiting for the next release cycle. You can think of hotfix branches as special release branches that work directly with master. JWTJSON Web Token (JWT) – JSON object. It is considered one of the safest ways to transfer information between two parties. To create it, you need to define a header (header) with general information on the token, payload data (payload), such as user id, role, etc. and signatures. Suppose we want to register on the site. In our case, there are three members - the user, the application server, and the authentication server. The authentication server will provide the user with a token with which he can later interact with the application.First, the user logs into the authentication server using an authentication key (this can be a login / password pair, or a Facebook key, or a Google key, or a key from another account). The authentication server creates a JWT and sends its settings. When a user sends a request to an API application, it releases the JWT it received earlier. When a user submits an API request, the application can check against the submitted JWT request to see if the user is who they claim to be. In this server, the application framework is configured so that it is possible to verify that the incoming JWT is exactly what the authentication server was (the verification process will be described later in more detail). The application uses the JWT to authenticate the user to the specified path. Structure JWT
The JWT header contains information about how the JWT signature should be calculated. The header is also a JSON object that looks like this:The typ field doesn't tell us anything new, only that it's a JSON Web Token. More interesting here is the alg field, which defines the hashing algorithm. It will be used when creating the signature. HS256 is nothing but HMAC-SHA256 and only needs one secret key to compute it (more on that in step 3). Another RS256 algorithm can also be used - unlike the previous one, it is asymmetric and creates two keys: public and private. The private key creates a signature, while the public key only verifies the authenticity of the signature, so we don't have to worry about its security.Step 2. Create PAYLOAD
We put only one claim in payload. You can submit as many entries as you like. There is a list of standard claims for JWT payload - here are some of them:Step 3. Create SIGNATURE
Step 4. Now let's combine all three JWT components together. Now that we have all three pieces, we can create our JWT. It's quite simple, we connect all the received elements into a string through a dot. Types of tokens
Refresh TokensUnderstanding how client-side refresh token works
Storage of tokensThere are 2 common ways to store tokens on the client: browser local storage and cookies. There is a lot of debate about which way is better. Most people lean towards cookies because of their better security.
|