The design and development of the Demo project, part 2 of the “Single sign-on and Permission Management” series, will take some time to complete. During this period, I will share the knowledge I have learned, practiced and combed with you. I hope you will like it.

Index of part 1 of the “Single Sign-on and Rights Management” series:

  1. Session and cookie introduction
  2. HTTP redirection
  3. Introduction to single sign-on
  4. Cookie Security
  5. Rights Management

Next, git branch management and workflow specifications will be shared. When a project becomes large, multiple people will work together to develop it. Without a specification, there will be a lot of conflicts when merging code, and the version and commit history of the code will be messy. These two problems can be solved by branch management and workflow specification.

Create different branches for different scenarios, always keeping the main branch reliable and clean. For example, create different branches for new features, fixes for online problems, and fixes for bugs in the test environment. In addition, the functions to be launched in the next version should be planned well in advance, and the functions should be subdivided and assigned to everyone to complete. The functions that are interdependent should be in the same branch, and the functions that are uncertain to be launched should be created separately, so as to reduce the conflicts during the merger.

When submitting code, you should keep the submission history clear, and the submission comments should be standardized. About the submission history, we summarize three points:

  • A very important skill for git users is the ability to maintain a clear semantic change history;
  • By looking at the version change history, you can reflect the team’s development goals and functional changes;
  • Version change history records the evolution of the code, not the developer’s activities while coding;

Git branch Management and Workflow Specifications will be shared in three articles:

  • Git git
  • The specific specification
  • Different scenes are refined and demonstrated

This article mainly introduces git related concepts, but I will not introduce the basic ones. There are many online materials, mainly including:

  • File status
  • The concept of branching
  • The merge with
  • Rebase yan together
  • Git Workflow

File status

State the type
  • Modified: Modified a file but not yet committed for saving; (add)
  • Temporarily saved: Modified files are placed in the list to be saved for the next submission; (Add, no commit)
  • Committed: The file has been securely saved in the local database; (commit)
Working directory, staging directory, git directory

The three directories correspond to the file states. Different states are placed in different directories.

Git object
  • Objects include submission, file tree, file content, and other operation objects.
  • Consists of 40 hexadecimal digits;
  • You can run git cat-file to view the object information.
Basic workflow
  • Modify some files in the working directory;
  • Take a snapshot of the modified file and save it to the temporary storage area.
  • Commit the update to permanently dump the file snapshots saved in the staging area to a Git directory;
Status related commands
  • Git status displays which files have been modified, which files have been temporarily saved, and which files have not been committed.
  • Git diff compares files in different states
    • The default compares the difference between the working directory and the temporary file snapshot. (Files not temporarily saved after modification)
    • –cached compares the difference between the cached snapshot and the last committed snapshot;
  • Git reset Resets the current branch to the specified commit
    • –hard resets working directory and staging area;
    • — Mixed default, only temporary area reset, working directory unchanged;
    • – Soft simply points to HEAD, and commit after commit will enter the staging area;

The concept of branching

In essence, branches are just mutable Pointers to commit objects.

How does Git know which branch you are currently working on?

  • Holds a protected pointer named HEAD;
  • HEAD is a pointer to the local branch you are working on;

When you view branches with git branch -a, you will see all branches, including local and remote branches.

There are two main ways to merge branches, merge and rebase. Merge is an automatic merge, and different merge policies are available for different scenarios. Rebase is a manual merge. You can specify different merge policies for each commit, as described in the following sections.

The merge with

  • –commit –no-commit Specifies whether a commit node is automatically generated after the merge.
  • –edit –no-edit Whether to accept automatically merged information;
  • – the ff – no – ff options
    • By default, Git does a “fast-farward merge” and does not create a new commit node;
    • –no-ff creates a new commit;
  • –log –no-log
    • Whether the merge commit includes the log information of the COMMIT node in addition to the branch name
  • –squash
    • No historical information is kept on the branch to be merged, no HEAD is committed, no HEAD is moved, and an additional commit command is required.
    • The fundamental criterion for deciding whether to use –squash is whether the history on the branch to be merged is meaningful;
  • — abort
    • Discard the current merge conflict process and attempt to recreate the pre-merge state;

Rebase yan together

$ git rebase -i [branch|]

Three action commands –continue, –absort, and –skip, which mean “continue,” “quit,” and “skip,” respectively

What to watch out for:

  • Once a commit object in a branch has been published to a common repository, do not derivatives the branch;
    • In the process of derivatives, some existing submission objects are discarded and some similar but different new submission objects are created.
    • If you submit branch of the original object out, and others to update on the basis of the work after download, and later you use git rebase abandon these submission object, take the new released after repeated submission object out, your partner will have to merge again their work, so that when you get from them again, Commit the history and it gets messy;
  • Use derivatives as a means of cleaning up submission history before pushing, and only those submissions that have not been made public;

Specific examples, online information is very much, not here to explain.

Git workflow

Collaboration must have a regular workflow that allows people to work together effectively to keep the project in order.

[1] Ruan Yifeng: Git Workflow [2] Git flow tools

At last, attached is a quick list of commonly used commands: