Regular code submission process
- 0. First run git pull — rebase to pull the latest code
- 1. After modifying the local code, run git add. To save all changes temporarily
- 2. Run git status to check the current file status and ensure that the files to be committed have been temporarily saved
- 3. Run git commit -m “ADD: Hello world” to commit a new commit
- 4. Verify that the code has been changed and is ready to be pushed to the remote repository. Before this is done, there is another git pull — rebase to merge the latest code from the remote repository, since there may be new commits from someone else in the meantime.
- 5. If a conflict occurs in the previous step, handle the conflict before continuing
- 6. Execute git push origin master to commit the code to the remote master branch (assuming it is currently on the master branch).
Git Branch Management
Merge general operations from branchA to branchB
- Git checkout branchB
- Git pull — rebase the latest branchB code
- Git merge origin/branchA –no-ff merge branchA
- 4. Handle possible conflicts
- 5. After checking the combined commit-ID of the two branches, run git push Origin barnchB to commit the code to the remote branchB branch
Branch switch with subModule
Sometimes there are submodules in the project, and when you switch branches, you need to switch subModules
1. This is mandatory when branch A switches to branch B.
Git status: Displays the status of sub-modules
2. New submodule submissions are found
Git subModule update-init – recursive does not update the submodule when switching branches, and the new branch may not reference the current node. Run git status again to check the status. Usually it works
3. Found that submodule has untraced files
Branch A has A child module, but branch B does not. When switched to B, the files contained in this submodule are considered uncommitted. In this case, run git submodule foreach -recursive git clean -ffd or go to the corresponding directory and run git clean -ffd manually
4. Found modified submodule
Branch A does not contain A module that exists in branch B, but there is A folder that is the name of A child module of branch B. When you perform an update, this child module will not be checked out, so the content will remain the same as that of branch A: Git submodule foreach — leaving git checkout. Or go to the corresponding child Module and execute Git Checkout manually.
Branch workflow
- 1. Master: Manages release status and uses labels to record release numbers
- Eg. We develop the daily development branch
- 3. Release: In preparation for each release, separate the Develop branch and merge the Master and Develop branches after the release
- 4. Hotfixes: Quickly fixes bugs after launching
- 5. Feature: Independent feature development across release cycles
Daily work flow
- 1. We are developing regularly
- 2. If there are large functions or other requirements, open a new branch: Feature/XXX to do it, and carry out packaging and testing on this branch.
- 3. On the release date, merge the release requirements into Develop, and then create a new branch release/ version number (e.g. Release /1.0.1) to merge Develop into that branch.
- 4. In the grayscale phase, fix the BUG on the Releases/releases branch, pack and release it, and tag the corresponding COMMIT with {release}_grey
- Commit commit commit commit commit commit commit commit commit commit commit commit commit commit commit commit commit commit commit Will merge into Develop at the same time
Git Commit Message specification
All commit messages, except those generated automatically during merge operations, follow the following format: OPERATION: Description A commit can have multiple operations, but preferably only one.
| OPERATION | When to use | What should I write in description |
|---|---|---|
| ADD | Add features/files | What features/files have been added (too many files can be written to directories) |
| MOD | Modify functions/files | What features/files were changed and why |
| DEL | Delete features/files | What features/files were removed and why |
| FIX | Fix the bug | If there is a bug report on JIRA, say ISSUE_ID |
| RFCT | refactoring | What was refactored |
| CLN | Clean up the | Cleaned up what? |
Git Git
Restore order
Git reset — hard HEAD
Remote branches force local overwrite
Git fetch — all git reset — hard origin/master
Use the git amend
Sometimes you commit code, and you find a mistake, and you don’t want to keep the last record the next time you commit; Or if your last commit message was incorrectly described, you can use git commit — -amend. Git Amend works for local commit or CodeReview, but merges code if it is used for a commit that has already been pushed to a remote location
Git merges multiple commits
The rebase method can be used to merge multiple commits into a single commit. The main steps are as follows:
1. Git log View the current commit history
For example, you need to merge 3 “leave application client code optimization” commits into one COMMIT.
2. Git rebase Git compression
Git rebase -i HEAD~4 rebase the last four commits. Git merge multiple commit
Git deletes a commit
Similarly, you can use git to compress the rebase directive to delete a commit. Git merge multiple commit
Why git merge — no-ff is recommended for merge
Git merge — no-ff Git merge — Git merge
–fast-forward
When Git merges two branches, it simply moves the pointer to the right (called “fast-forward”) if you follow one branch to the other.
–squash
Squash unnecessary commit files. For example, if your feature had a messy commit during development, you don’t want historical commit files to be added to it. If you merge the files using a -squash, the files are already the same as after merge, but you don’t move the HEAD and commit. An additional COMMIT is required to “wrap up” and then complete the final merge.
— – no – ff
When the fast-forward mode is disabled, a merge commit is created and merged to the master branch
The different actions of merge, looking back, actually merge code into the master branch, and the difference is only a simple and clear problem on the branch. Then, looking ahead, when we use reset, we can see that the different actions have different effects. The use of no-ff is safer when code is rewound. Therefore, the –no-ff mode is recommended for merge
Use the git stash
- “Save message” : When executing the storage, add a note to facilitate the search. Only git Stash save should also be available, but it is not convenient to identify when searching.
- (2) Git Stash list: See what stash stores are
- If you want to show another stash, add stash@{$num} to it. For example, if you want to show another stash, add stash@{$num}.
- If you want to display the other stash, run the git stash show stash@{$num} -p command. For example, run the git stash show stash@{1} -p command
- The first stash is used by default, stash@{0}. If you want to use another stash, stash@{$num} is used. git stash apply stash@{1}
- Delete the corresponding stash from the cache stack and apply the corresponding change to the current working directory. The default is the first stash, namely stash@{0}. If you want to apply and delete other stash files, run the following command: Git stash pop stash@{$num}, for example, apply and delete the second one: git stash pop stash@{1}
- Git stash drop Stash @{num} : Drop stash@{num} from the list
- Git Stash clear: Remove all cached stash files
The operation of temporarily merging code
For example, if your code is waiting for review and you need to merge your code, do as follows: The original branch is Feature /test and merge develop
- Git checkout -b temp
- 2. Git branch -d feature/test
- Git checkout feature/test restores the test branch to the remote
- Git merge origin/develop –no-ff
- Git cherry-pick temp = git cherry-pick temp
- Git push origin feature/test
- Git branch -d temp Delete the temp branch
Refer to the link
Git merge commit Git merge –no-ff