After installing gitee. We will have some new business needs.
Scenario: L uses gitee to upload his own code again in the company, uploading once a day~ What about other people's codes? Isn't it a mess? Then upload it after writing it all, but the progress of the project has to be checked every day.
At this time, I realized the role of branching:
Branch management creation
Simple command line tutorial:
Git global settings:
git config --global user.name "****"
git config --global user.email "*******"
Create a git repository:
mkdir djang
cd djang
git init
touch README.md
git add README.md
git commit -m "first commit"
git remote add origin git@地址
Already have a warehouse?
cd existing_git_repo
git remote add origin [email protected]:H_sen/djang.git
git push -u origin master
# 默认在当前目录下创建和版本库名相同的文件夹并下载版本到该文件夹下
git clone <远程仓库的网址>
# 指定本地仓库的目录
git clone <远程仓库的网址> <本地目录>
# -b 指定要克隆的分支，默认是master分支
git clone <远程仓库的网址> -b <分支名称> <本地目录>
# 新建分支 并转移到此位置
git checkout -b NewBranch
# 查看所有分支
git branch
# 切换分支 切换到 master
git checkout master
# 删除本地分支 NewBranch
git branch -D NewBranch
Scenario: Assume that we have succeeded in creating the branch NewBranch, and if we need to pass in code for this.
git add -A (或文件名)
git commit -m "new branch"
git push origin NewBrLanch # 将代码上传到分支
Scenario: Assuming that the project is all completed, there are multiple branches ~ we need to merge them
Merge branch to main branch
# 回到主分支 master
git checkout master
# 将主分支数据拉到本地
git pull
# 强行合并 (可能会出错， master很有可能也更新)
git merge NewBranch
# 假设说上面的 和合并出现问题 那就手动合并
vim Readme # 手动合并标识文件
git add -A
git push origin master # 合并之后 就可以提交到 master 了
# 查看从什么地方出现的分支
git log -graph
Now you can understand why you want to use branches.
Moreover, there are also regulations for branches in the company. For example, the master cannot be easily uploaded, and the branch developed by dev must be used for project development, and each group must have a pyTeam branch, and know my H_sen branch in the group. Only after the test eliminates all problems will it be published to the master branch.
So will there be a BUG branch? Have! ! !
Bug branch
Scenario: Assume that all the interception methods still did not block the BUG upload to the master (yes, you wrote it), and you are developing other modules at this time. How to do it?
- Stop the work at hand,
- Switching the master branch to solve the bug on the master
will be very troublesome
git stash stands out
how to use:
- Bug found
# 突然出现的 bug
vim Readme
# 将 dev 中未保存的代码存放到临时区
git stash # 这样做完全的避免了 将 代码带入到 Bug 分支
- Fix bug
# 切换到 bug 分支
git checkout -b bug-100
# 切换后 修复 bug
vim Readme
git add -A
git commit -m "修复 bug" # 提交到工作区
- Merge the fixed bug with master
# 切换到 master
git checkout master
# 强行合并
git merge bug-100
# 推送 到主分支
git origin master
The bugs are exhausted. How to restore the previous file status?
- Retrieve the previous dev branch and restore the state
# 切换回开发的分支
git checkout dev
# 查看状态
git status
more Readme # 发现之前工作区 未提交的数据都消失了
git stash list # 查看之前使用 git stash 保存的数据
git stash apply # 恢复之前的文件
# 查看状态
git status # 此时就可以看到排bug 之前的完美状态了
git stash other operations
git stash drop # 删除最久的那个 使用 git stash 临时保持状态
git stash apply stash{
{0}} # 指定恢复到那个临时状态
git stash pop # 恢复并删除上一个临时状态
'''
注意！！！ git stash aplpy恢复后 stash的内容并不删除，需要 git stash drop 才能删除
git stash pop 就简单许多 恢复的时候直接删除
'''