Gitlab project management
organizational structure
Development Department
Product department
- Product manager, product specialist
- Graphic design, UI/UE
Development Department
Development Department
- Software Project Manager
- Development team leader (determined according to the product line of parallel development of the project)
- Senior programmer, intermediate programmer, junior programmer
Testing department
Testing department
- Software Test Manager
- Test team leader (depending on the number of items tested in parallel)
- Senior Test Engineer (automatic test), intermediate test engineer (functional test), junior test engineer (functional test)
Operation and maintenance department
Operation and maintenance department
- Operations Manager
- Operation and maintenance team leader (depending on the number of servers)
- Senior operation and Maintenance Engineer (R & D of operation and maintenance tools), intermediate operation and Maintenance Engineer (8 hours, handling daily operation and maintenance), junior operation and Maintenance Engineer (7 * 24 subtotal monitoring)
Relationship between development, testing and operation and maintenance departments
- Development, testing and operation and maintenance are not three independent departments. They are closely related to each other, but they restrict each other
- Development is only responsible for writing programs and submitting the running programs to the version library
- The developer cannot privately hand over the program to the operation and maintenance deployment, nor can he hand over the compiled program to the testers
- The testing department can only extract the code from the version library, and then compile, package, run and test it
- The test department is not allowed to hand over the code to the operation and maintenance department for deployment
- Avoid the code flowing into the production environment without passing through the version library, resulting in inconsistency between offline and online codes
- The operation and maintenance department is responsible for the deployment of applications and configuration management. It only accepts the correct version confirmed by the test department, and the deployment code can only be obtained from the version library
Permission role
Document role: product, design
Reporting roles: testing
Development role: Development
Operation and maintenance role: operation and maintenance
project plan
I often compare the project development plan to a train timetable. Each station corresponds to a project node, namely a milestone.
The concept of train timetable comes from a British project I participated in in in the early years. We use TRAC management project, which is an ancient project management software. It is the prototype of many modern project management software. Many ideas are still used today, and can not even surpass it. Because it is developed in Python, the framework is old, and there is no maintenance and update in the later stage, it can not keep up with the pace of the times. Another project imitates 90% of its functions called redmine. Redmine is very popular, but there is still no unified Jianghu. Until the emergence of Github/Gitlab, all kinds of just needed problems encountered in software project management were solved in one stop. TRAC, redmine, Confluence, Bugzilla, Jira, Mantis, BugFree, BugZero... Slowly faded out of people's vision.
In TRAC, the task is called Ticker, which translates into "ticket" in Chinese. The project goes along the Roadmap. The road is called Timeline. Milestones are vividly compared to sites. There is a group of tickers in each Milestone. Each upgrade is like buying a ticket and getting on the train. The train does not wait. Similarly, the project runs according to its own Roadmap. If it is missed, it can only wait for the next shift.
The project manager will notify the departure time in the instant messaging software, and colleagues who need to upgrade will merge their own Ticker code into the trunk, and then wait for the departure.
[ Roadmap ]
---------------.
----\ \
Timeline -----o-----o-----o-----o-----o-----o----->
----------/ /
---------------------Occasionally, the train will be late, cancel the shift, stop temporarily or leave for the next station without stopping. The same is true for projects:
Delay is the project delay. The schedule taking shift is to stop the launch plan of this milestone. Temporary stop means hot repair and emergency launch. Non stop means skipping this milestone and solving the next milestone at one time.
We often publish the departure time and ask the departure time in instant messaging software.
The project plan should be like the train timetable. Once you have set it, you can't modify it at will. It must be pushed forward in an orderly manner according to the set milestones.
We found that many domestic projects are led by tasks, that is, there is no project roadmap. When you go there, you can go online. It's quite casual. Once there is a cross conflict, it will be in a hurry, and withdrawal is even more common.
Workflow
Project management requires design workflow
Will you find that Gitlab does not provide workflow? Why? Have you ever thought about it? Not only Gitlab, but also Microsoft Project. Why doesn't Microsoft Office provide this function?
Talk about a period of my career. I came to Shenzhen in about 2000, The first job was OA (office automation) system development. At that time, many companies developed similar products, including Jinshan software, UFIDA, etc. 20 years later, OA did not have a standard or a successful product. OA seemed to become one of the tools for enterprise digital transformation, and found that it could not be used at all.
The reason why OA has not become the mainstream is workflow. Each company has its own process and cannot unify standards. Even in western countries where management was born, there is no unified process. The process is constantly changing with the market and environment, and no process can continue from beginning to end. Enterprises that have experienced the Drucker era have retained only part of the administrative approval process so far.
This is why Microsoft doesn't touch this, IBM does it, and Oracle doesn't. Although the technically mature workflow engine and graphical configuration are extremely difficult to use, almost all non-technical administrators give up.
Whenever the design process, the designer will express himself. The final design process is extremely complex. It seems that the process can be called perfect. The implementation is either internal friction or obstruction. Almost all do additive thinking, and few people can do subtractive thinking.
Workflow design principles
- Follow the subtraction principle rather than the addition principle. The fewer participants, the better, and the fewer nodes, the better.
- Try to be linear, flow from one end to the other, and try not to bifurcate in the middle.
- There should be no logical judgment bifurcation as far as possible. For example, A decides whether to flow to B or C in the next step after approval
- Avoid loops, dependencies avoid loops, that is, the process goes back.
The purpose is to make the workflow operable, easy to operate and redundant.
Is there a problem with the following process?
Developer test -> Approved by the development team leader -> Approval of technical department -> Test department approval -> Approved by test team leader -> Assign testers
Don't enterprises with a little scale do this?
Developer test | Assign testers
--------------------------------------------------
Approved by the development team leader | Approved by test team leader
--------------------------------------------------
Approval of technical department | Test department approval The matrix transformation is clearer. The workflow flows from one section to another, going through two departments and six nodes. Theoretically, if the approval exceeds three levels, it should be controlled, and if it exceeds three levels, it will affect the progress. Why does this happen?
I have analyzed that the domestic management can be divided into two categories: one is to focus on the project process itself, and the other is to focus on the participants and results of the project. The former focuses on time management, and the latter tends to performance appraisal. [1]
The first type of managers know the Roadmap of the project, so they don't need to do it at all. The approval process from the technical department to the test department is set at the Roadmap meeting, and the train can be started on time.
The second type of manager usually comes from management and uses management tools to manage the project. He can't participate in the project process. He can only pay attention to the time point and progress and keep urging. He needs to know what to do now? When will it be finished? So everything needs to be approved.
Topics
Issues issues
Milestones
In agile development, there can be one milestone per week or one milestone per month.
Revised Roadmap
The setting of Roadmap needs to be adjusted at one end of each interval, because some projects will be delayed, some will be completed in advance, and factors such as demand change will affect Roadmap.
Work report
Since the project is broken down from top to bottom and strict roadmaps are formulated, each participant knows what to do, how to do it and when to complete it, so there is no need to report to the upper level.
All the team has to do is follow the time and nodes of Roadmap.
5W2H task allocation rule
Once the time point is determined, the next step is to assign tasks instead of specifying developers. The task allocation is very particular. The assigned tasks should be accurately described and fuzzy language should not be used, which will cause misunderstanding. My allocation principle is 5W2H method: -What: what do you do? -Why: Why did you do it? What's the point? What is the purpose? Is it necessary? -When: when will it be done and whether the completion time is appropriate? -Where: where and to what extent? -Who: who is responsible for it? Who is responsible for the implementation? Who is more suitable? Can people with low proficiency do it? -How: how -How much: cost (not all posts will involve cost)
Tasks / topics
Topics
Operation and maintenance tasks
For example, operation and maintenance tasks -What: load balance the api server by adding one more node. The load balancing algorithm adopts the minimum number of connections. -Why: at present, there is only one api server. If a failure occurs, it will affect all business operations. Considering that the server has a single point of failure, you need to add nodes. -When: completed within this week, online at the weekend. (date can be written here) -Where: connect the third port of the reverse switch at the lower 2 rack of cabinet A. -Who: XXX is responsible for network configuration, XXX is responsible for putting on the shelf, and XXX is responsible for acceptance test -How: Add / etc/hosts as follows - api.example.com 127.0.0.1 - api1.example.com 192.168.2.5 - api2.example.com 192.168.2.6
Development tasks
For example, development tasks -What: add picture verification code. -Why: at present, there is no verification for user registration, login and posting. Some users open accounts / post advertising posts in batches through robot software, which brings great trouble to management. -When: development started on June 15, 2014 and went online at 12:00, June 20, 2014. -Where: user registration, login and posting, add this function,. -Who: Zhang San is responsible for the development of verification code generation class, Li Si is responsible for user registration, login UI modification, and Wang Wu is responsible for posting UI modification. -How: for details of how to operate, 200 words are omitted here
Test task
For example, test tasks -What: measure the concurrency performance of XXX software. -Why: at present, after the online task of XXX software reaches 200, the user reflects that the speed is slow and often drops the line. -When: the failure time point is 10:00AM, the test needs to be completed on Tuesday, the optimization needs to be completed on Friday, and it will be launched at the end of the month. (date can be written here) -Where: check out the code in the AAA branch, compile and deploy it to the BBB environment. -Who: XXX is responsible for network configuration, XXX is responsible for software deployment, and XXX is responsible for testing -How: for details of how to operate, 200 words are omitted here
Operational tasks
For example, promotion tasks -What: XXX product promotion. -Why: at present, XXX products have a market share in XXX, and XXX users reflect XXX. -When: promotion start time XXX end time XXX -Where: AAA market segment, BBB region. -Who: XXX in charge of XX, XXX in charge of XX, XXX in charge of XX -How: for details of how to operate, 200 words are omitted here -How much: cost XXX
Parallel development
The most common problem encountered in the parallel development of multiple functions is conflict. For example, three functions a, B and C are developed at the same time and share a branch. A has completed the development, 1 / 3 of B has been developed, and C has a BUG. At this time, upgrade a function, and B and C will also be upgraded.
To realize parallel development, two conditions need to be met. The first is reasonable task decomposition, the second is supporting environment, and the third is branch application.
Task decomposition
Task decomposition should be decoupled as much as possible, and cross merge into one task. A task corresponds to a function. The dependency between functions must be clarified to avoid cross dependency and circular dependency.
A -> B -> C
\-> D -> E
\--> F aligned environment
Supporting environment refers to the development and testing environment, referring to the production environment to minimize instances and nodes, meet the environment of running projects, and minimize environmental differences, including differences in hard disk configuration, network, resource configuration, and application software installation configuration.
Prepare supporting environment
- Development environment, also known as integrated development environment, provides shared resources for the development team. Because it is unrealistic for each programmer to run a complete set of distributed system on his own computer, it is necessary to separate the public part and provide services centrally, such as database, cache, search engine, configuration center, registration center, etc.
- For testing, because the development environment needs to frequently merge new functions, deployment and restart will affect normal testing. For example, testing is general. New functions are added to the development environment, which will affect testing. So what we need is an independent and stable testing environment, which is controlled by the tester itself, when to deploy and the test has the final say.
- The user delivers the Stage/UAT environment, Beta/Preview demonstration environment, and regularly synchronizes the production environment database.
- Function test environment (feature/hotfix) new functions, BUG repair, etc.
For the above three environments, at least one independent server is required, and several servers are required for feature / hotfix. The server of the functional test environment is shared, that is, who proposes to test who uses it, and releases it after use.
Each environment has a complete set of supporting services, such as database, cache, search engine, message queue and so on
Code branch
Timeline branch
- The Development branch Development is for developers
- The test branch Testing is for testers
- Delivery acceptance branch, commonly known as UAT, is for testing and customers
- Production branch, user oriented
In small companies, UAT is usually omitted, and Testing is directly used in the production environment
Branch permissions
The purpose of branch protection is to prevent it from being deleted by mistake. It is forbidden to submit code to the branch. The code can only enter the branch by merging.
Permission management of branch:
- master: protection, code cannot be modified, can only be merged, and only the administrator has permission to push
- staging: protection, code cannot be modified, can only be merged, and only the administrator has permission to push
- testing: protection, code cannot be modified, and testers can merge
- development: protection, developers can modify code, merge and push
- tag: protection, corresponding to the Release version
Functional branch
Function branch: after task decomposition, each function corresponds to a branch. The code of the function branch comes from the development branch. We will have many function branches. The development task is developed on the function branch, and the task is marked as "test" after development , the test department will arrange the test environment and deploy the code on the branch. The test results are divided into BUG and Pending (test passed, suspended, waiting for departure).
Buy a ticket and get on the bus: in the function branch, we have many developed functions. They are suspended. Then, according to the upgrade plan, they are orderly merged into the development branch, then to the test branch, and finally upgraded to the production environment.
Operation steps of Feature branching:
- Create Issue issue
- Create Feature branch from Development
- Get Feature branch code
- Modify code, submit code, test code
- Merge Feature branch to Development branch
- Close Issue issue
Consolidation process
Code consolidation process
Development -> testing -> staging -> master(production)
Merge branch
Merge from development like testing branch
git checkout development git pull git checkout testing git pull git merge --no-ff "development" git push
Merging the testing branch to the master branch
Gets the branch of the testing merge request
git fetch origin git checkout -b "testing" "origin/testing"
If it has been executed before, use the following command to switch branches. After switching, pull the code to see what new submissions are
git checkout "testing" git pull
Switch to the master branch
git fetch origin git checkout "master" git branch --show-current git merge --no-ff "testing"
Push merge results to remote
git push origin "master"
Except for a single file
From development to testing
git checkout development git pull checkout testing git checkout development public/doc/UserGuide.pdf git status git commit -a -m 'Manual merge' git push
From testing to staging
git checkout staging git pull git checkout testing public/doc/UserGuide.pdf git commit -a -m 'Manual merge' git push
From stage to master
git checkout master git pull git checkout staging public/doc/UserGuide.pdf git commit -a -m 'Manual merge' git push
Merge branches resolve conflicts
For example, when we merge code from the testing branch to the master branch, how can we solve the conflict?
First, the two branches pull the latest code
neo@MacBook-Pro-Neo ~/workspace/api.netkiller.cn % git checkout testing neo@MacBook-Pro-Neo ~/workspace/api.netkiller.cn % git pull neo@MacBook-Pro-Neo ~/workspace/api.netkiller.cn % git checkout master neo@MacBook-Pro-Neo ~/workspace/api.netkiller.cn % git pull
Then merge the branches from the testing branch to the master
neo@MacBook-Pro-Neo ~/workspace/api.netkiller.cn % git merge --no-ff testing Auto merge neo-incar/src/main/java/com/neo/incar/utils/PaperlessConfig.java Conflict (content): Merge neo-incar/src/main/java/com/neo/incar/utils/PaperlessConfig.java
Auto merge failed. Correct the conflict and submit the correction result.
If a conflict occurs, edit the conflict file
vim neo-incar/src/main/java/com/neo/incar/utils/PaperlessConfig.java
Review the status after saving
neo@MacBook-Pro-Neo ~/workspace/api.netkiller.cn % git status In branch master Your branch and upstream branch 'origin/master' agreement. You have paths that have not been merged. (Resolve conflicts and run "git commit") (use "git merge --abort" Termination (Consolidation) Changes to submit: Modification: neo-admin/src/main/resources/application-prod.yml Modification: neo-admin/src/main/resources/application-test.yml Modification: neo-common/src/main/java/com/neo/common/enums/IncarAttachTypeEnum.java Modification: neo-incar/src/main/java/com/neo/incar/service/impl/IncarAttachServiceImpl.java Unconsolidated paths: (use "git add <file>..." Tag solution) Modified by both parties: neo-incar/src/main/java/com/neo/incar/utils/PaperlessConfig.java
Add merged files to git
neo@MacBook-Pro-Neo ~/workspace/api.netkiller.cn % git add neo-incar/src/main/java/com/neo/incar/utils/PaperlessConfig.java neo@MacBook-Pro-Neo ~/workspace/api.netkiller.cn % git status In branch master Your branch and upstream branch 'origin/master' agreement. All conflicts have been resolved, but you are still merging. (use "git commit" End (merge) Changes to submit: Modification: neo-admin/src/main/resources/application-prod.yml Modification: neo-admin/src/main/resources/application-test.yml Modification: neo-common/src/main/java/com/neo/common/enums/IncarAttachTypeEnum.java Modification: neo-incar/src/main/java/com/neo/incar/service/impl/IncarAttachServiceImpl.java Modification: neo-incar/src/main/java/com/neo/incar/utils/PaperlessConfig.java
Submit code
neo@MacBook-Pro-Neo ~/workspace/api.netkiller.cn % git commit -a -m 'Merge branches manually testing -> master' [master 3652bf8e] Merge branches manually testing -> master
Push code
neo@MacBook-Pro-Neo ~/workspace/api.netkiller.cn % git push Enumeration object: 1, complete. In object count: 100% (1/1), complete. Write to object: 100% (1/1), 240 byte | 240.00 KiB/s, complete. Total 1 (difference 0), multiplexing 0 (difference 0), packet multiplexing 0 remote: remote: To create a merge request for master, visit: remote: http://192.168.30.5/netkiller.cn/api.netkiller.cn/-/merge_requests/new?merge_request%5Bsource_branch%5D=master remote: To http://192.168.30.5/netkiller.cn/api.netkiller.cn.git fcaefaf4..3652bf8e master -> master
Hotfix / BUG branch
The Hotfix / BUG branch is similar to the function branch and is used to store bugs. The BUG branch will correspond to the BUG ID in the defect management system to make the defects and codes traceable.
In the usage scenario of hotfix branch, a bug found in the production environment needs to be repaired temporarily. There are ongoing projects on testing, which cannot be merged from testing - > master. At this time, you can create a branch from master - > hotfix, merge it into the master branch after repair and testing, and deploy the production environment. Finally, merge hotfix into the development branch
For small and medium-sized companies with a small number of teams, there is no need to establish a BUG branch. You can repair the functional branch and merge it into the development branch.
Roll forward and roll back
In case of emergency, it is temporarily decided to remove some functions, which will use roll forward and roll back operations
Roll back operation
Example of roll back operation
Timeline ----- [ Previous milestones ] -----> [ This upgrade milestone ] -----> [ Future upgrade milestones ]
｜
V
o----------o-----o----------o---------o-----o------------->
^ ^ ^ ^ ^ ^
A function B function C function D function E function N function
In the milestone of this upgrade, there are five functions for free riding. These five functions are merged in order, and the corresponding version ID can be found each time.
Let's simulate a scenario. These five functions are the five activities of the marketing department. Now, for various reasons, the function of activity D needs to be removed. We only need to find the version ID of function C, restore the code to function C, and then merge function E again
Roll back to C, then add E function
Timeline ----- [ Previous milestones ] -----> [ This upgrade milestone ] -----> [ Future upgrade milestones ]
｜
V
o----------o-----o----------o---------o
^ ^ ^ ^ ^
A function B function C function D to void E function
Roll forward operation
When the removed function needs to be restored, it is the roll forward operation
Timeline ----- [ Previous milestones ] -----> [ This upgrade milestone ] -----> [ Future upgrade milestones ]
｜
V
o----------o-----o----------o---------o
^ ^ ^ ^ ^
A function B function C function D function E function
Roll forward to any submitted version
Timeline ----- [ Previous milestones ] -----> [ This upgrade milestone ] -----> [ Future upgrade milestones ]
｜
V
o----------o-----o----------o---------o-----o------------->
^ ^ ^ ^ ^ ^
A function B function C function D to void E function N function
Common operations of roll forward and roll back
Export last modified file
Sometimes we want to copy the newly modified files while maintaining the original directory structure, which may be handed over to the operation and maintenance department to directly overwrite the code on the server. We can use the following command to complete this operation without copying files one by one.
git archive -o update.zip HEAD $(git diff --name-only HEAD^)
Export files modified in the specified version range
First, use git log to view the log and find the specified commit ID number.
$ git log
commit ee808bb4b3ed6b7c0e7b24eeec39d299b6054dd0
Author: 168 <lineagelx@126.com>
Date: Thu Oct 22 13:12:11 2015 +0800
Statistical code
commit 3e68ddef50eec39acea1b0e20fe68ff2217cf62b
Author: netkiller <netkiller@msn.com>
Date: Fri Oct 16 14:39:10 2015 +0800
Page modification
commit b111c253321fb4b9c5858302a0707ba0adc3cd07
Author: netkiller <netkiller@msn.com>
Date: Wed Oct 14 17:51:55 2015 +0800
Database connection
commit 4a21667a576b2f18a7db8bdcddbd3ba305554ccb
Author: netkiller <netkiller@msn.com>
Date: Wed Oct 14 17:27:15 2015 +0800
init repo
Import b111c253321fb4b9c5858302a0707ba0adc3cd07 to ee808bb4b3ed6b7c0e7b24eeec39d299b6054dd0 Modified files between.
$ git archive -o update2.zip HEAD $(git diff --name-only b111c253321fb4b9c5858302a0707ba0adc3cd07)Withdrawal submission
First, reset to the specified version, and select -- mixed or -- hard according to the actual situation
git reset --mixed 096392721f105686fc3cdafcb4159439a66b0e5b --
or
git reset --hard 33ba6503b4fa8eed35182262770e4eab646396cd --
git push origin --force --all
or
git push --force --progress "origin" master:masterWithdrawal of single document submission
For example, withdraw project / SRC / main / Java / CN / netkiller / controller / demoscenecontroller Java to previous version
➜ api.netkiller.cn git:(testing) git log project/src/main/java/cn/netkiller/controller/DemoSceneController.java
commit b4609646ee60927fe4c1c563d07e78f63ab106ea (HEAD -> testing, origin/testing)
Author: Neo Chen <netkiller@msn.com>
Date: Wed Nov 17 18:49:27 2021 +0800
Manual consolidation, temporary submission
commit bc96eb68ad73d5248c8135609191c51e258edf10
Author: Tom <tom@qq.com>
Date: Thu Oct 21 16:29:20 2021 +0800
Get active scene
commit d564ea25bd556324f1f576357563a8ee77b3bdd9
Author: Tom <tom@qq.com>
Date: Thu Oct 21 15:15:26 2021 +0800
Get active scene
commit d5a40165ad24a3a021fe58c6d78e0b7d97ab3cc5
Author: Tom <tom@qq.com>
Date: Thu Oct 21 14:43:16 2021 +0800
Added scene role
commit aa98662cb9e781e328ee3d5cec23af29c81050d9
Author: Tom <tom@qq.com>
Date: Thu Oct 21 09:55:29 2021 +0800
Added scene role
commit 140d22a8d4ea7fcc775d4372e8beb6d854831512
Author: Jerry <jerry@qq.com>
Date: Sat Oct 16 15:27:30 2021 +0800
Scene interface modification
commit 2ddbb1ff933de663305db2396d99030c938c267a
Author: Tom <tom@qq.com>
Date: Fri Oct 15 10:55:30 2021 +0800 Only the last five records are displayed
➜ api.netkiller.cn git:(testing) git log -5 project/src/main/java/cn/netkiller/controller/DemoSceneController.java
➜ api.netkiller.cn git:(testing) git reset bc96eb68ad73d5248c8135609191c51e258edf10 project/src/main/java/cn/netkiller/controller/DemoSceneController.java
Unstaged changes after reset:
M project/src/main/java/cn/netkiller/controller/DemoSceneController.java
➜ api.netkiller.cn git:(testing) ✗ git status
On branch testing
Your branch is up to date with 'origin/testing'.
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: project/src/main/java/cn/netkiller/controller/DemoSceneController.java
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: project/src/main/java/cn/netkiller/controller/DemoSceneController.java
➜ api.netkiller.cn git:(testing) ✗ git add project/src/main/java/cn/netkiller/controller/DemoSceneController.java
➜ api.netkiller.cn git:(testing) ✗ git commit -m 'Restore to previous version'
[testing 9959acd4] Restore to previous version
1 file changed, 6 insertions(+), 8 deletions(-) How to write comment information when submitting code
Write the task ID in the code submission comments to bind the code to the task. When we view the code on the project platform, we can directly click the number to jump to the corresponding task. In this way, it will be clear until any corresponding and requirements documents are submitted this time, so as to facilitate code traceability.
Fixed Bug
svn ci -m "- Fixed bug #53412 (your comment)"
Implemented
svn ci -m "- Implemented FR #53271, FR #52410 (Building multiple XXXX binary)"
Add
svn ci -m "- Add Feature #534 (your message)"Upgrade and release related
Relationship between branch and version
Various versions come from that branch. What is their corresponding relationship?
Relationship between branch and version:
- Alpha internal test environment, for testers, unstable version. From the testing branch
- Beta / Preview / Unstable new features, preview version, user experience oriented. From staging branch
- Stable = Release stable version. The release version comes from master/main and tag tags
Difference between branch and label
The difference between a branch and a label is that the code in the branch can be modified and the label can be regarded as a read-only branch.
Release Notes
Release Notes writing instructions
When a project is upgraded, a document needs to be written to record the change
- Content includes
- What's new
- What has changed
- What did you fix
- Unresolved issues
- What has improved
- What did you ignore
Common information types
New Changed Fixed Unresolved Improved Ignore
Example 1.3 Example - Release Notes
NEW - xxxxxxxxxxxxx CHANGED - xxxxxxxxxxxxx FIXED - xxxxxxxxxxx UNRESOLVED - xxxxxxxxx IMPROVED - xxxxxxxxx
You can also refer to Release Notes written by many open source organizations, such as apache, mysql, php and so on
License
To use open source software, you need to know the differences between various licenses to avoid legal disputes.
You can use GPL for free, but it must be open source after modification.
You can use GPLv3 for free, but it must be open source after modification. Closed source commercial code is not allowed.
You can use BSD for free. After modification, it is not open source. Basically, you can do what I want.
There are many BSD codes in Linux, but BSD cannot transplant Linux codes into BSD because of the GPL License.
http://www.apache.org/licenses/