This is the second day of my participation in Gwen Challenge

It is important to follow a reasonable and clear Git usage process in team development

Otherwise, everyone commits a jumble of commitments, and the project quickly becomes difficult to coordinate and maintain

Branch is introduced

  1. Master – The primary branch
    • All official releases for user use are published on this main branch
    • Developers cannot push on this branch
  2. Dev – Development branch
    • The branch used for daily development where the developer completes the phased feature modules to be merged first
    • This branch is also used for team internal testing and phased work verification
    • Developers cannot push the branch, but can only merge individual branches into the branch through a Pull Request
    • Keep in sync with this branch frequently during development
  3. Feature/XXX – Feature branch
    • For the development of a functional module, for example: Zhang SAN created afeature/package-managerThe branch is responsible for developing the package manager module
    • When the functional module development task is completed, passPull RequestForm the request merge to the administratorCode ReviewAfter passing, merge the branch todevBranch; After that, the branch will be deleted
    • Once development is complete, they are mergeddevThe branch ** (can only be pulled Request) ** and is removed
    • Such branches are managed and used by individual developers and can be pushed
    • During development, such branches are often associated withdevKeep branches in sync
  4. Hotfix/XXX – Patch branch
    • A branch for emergency Bug fixes that can be created bymasterdevBranch to create
    • withfeature/xxxAs with branches, they will be merged in once the repair work is completemasterdevbranch(Only through Pull Request)“And then deleted

The working process

#Clone dev branch to local before development
git clone -b dev https://github.com/liangpengyv/vue-mvvm.git
Copy the code

Step 1: Create a branch

First, every time you develop a new feature, you should create a separate branch

#Get the latest dev branch code
git checkout dev
git pull

#Create a new feature branch
git branch feature/xxx
#Switch to the feature branch and develop
git checkout feature/xxx
Copy the code

Step two: Submit branches

Once the branch is modified, it is ready to commit

#Submit code
git add .
git commit

#Push feature branches from local repository development to remote repository (optional) during development
git push -u origin feature/xxx
Copy the code

The -u parameter of git push indicates that the remote repository origin/feature/ XXX is associated with the local repository feature/ XXX. The next time you run the push command, you can omit the remote repository name and branch name and directly enter git push

Step 3: Synchronize with the DEV trunk

During branch development, always keep in sync with the DEV trunk

#Get the latest dev branch code
git checkout dev
git pull

#Switch back to the branch of the feature currently under development
git checkout feature/xxx
#Merge the dev branch into the current branch
git merge dev
Copy the code

Step 4: Send a Pull Request

After completing all development tasks for the current feature branch, doing one last synchronization with the dev trunk, and submitting it to the remote repository, you can issue a Pull Request to the dev branch and Request the administrator to do a Code Review to confirm that it can be merged into the dev branch

#Finally, perform step 3 synchronization

#Commit to the remote repository
git checkout feature/xxx
git push origin feature/xxx

#Create a Pull Request on GitHub and wait for the Code Review
Copy the code

Step 5: Clean up unwanted branches

When a feature branch development task is complete, it should be deleted

#First, switch back to the dev branch
git checkout dev

#Delete the remote feature branch first
git push origin -d feature/xxx

#Delete the local feature branch
git branch -d feature/xxx
Copy the code