table of Contents
Preface
This article only briefly discusses the version control of the code, including version submission, branching, remote warehouse pull/push, version rollback, etc.It does not discuss Git commands, does not involve multi-person collaboration, and more is a record of the client's use process.
Sourcetree and GitHub clients are used to implement version control of the code. Both are similar in operation, so they are used to demonstrate the management of local warehouses and remote warehouses. Remote warehouses require servers to store project codes. Since Microsoft acquired GitHub, it has become private The project is also open for free, so the pull/push operation of the remote customer warehouse will be demonstrated using the GitHub client.
The so-called warehouse can be understood as a project, or a folder corresponding to this project.
Local warehouse (using Sourcetree)
Sourcetree client download address https://www.sourcetreeapp.com/
1. Create a local warehouse
Create a new folder LocalRepository, load a file README.md, and fill in the initial version information at will:
Open the Sourcetree client and create a local warehouse
Specify the folder just created
The warehouse is successfully created, and the number on the right represents the amount of modification
Double click to enter the main interface
Check the pending file (means put in the temporary storage area), fill in the version record information, and then submit it. At this time, there will be a version record in the historical version.
2. New version
Let's go back to the README.md file just now and add a new line of information:
Then we see that unsaved changes have been added to the file status in Sourcetree:
Check the file, fill in the version record information "it's raining", and then submit:
You can see that there is a version record in the history:
At this point in the discussion , we have completed the first version iteration. But there is a problem, this modified version is directly carried out on the master branch master, and the master should be used to store the releaseable stable version, and should not be directly supplied to the development stage Use. In
actual development, we should first separate a branch for development, and then merge it into the master to release after debugging. This can prevent multi-person collaboration from operating on the master at the same time and cause conflicts, and at the same time, we can split multiple branches for development. Multifunctional "parallel" development.
Suppose such a situation:
When we develop new features directly on the master, we find that the original code has bugs in the middle of the development. At this time, we have only two choices: either finish writing the other half of the function and then debug the bug, or abandon half of the existing function code. Debug bugs. This approach is like "thread blocking", which does not seem to meet our needs. Then, the branch can be launched at this time. Create a branch to develop this new feature, and we will have two branches at this time : master and new feature branches. When we find that the original code has bugs when we are halfway through development on the feature branch, we can switch to the master branch and create another temporary branch to fix the bugs. After the bug is fixed, the temporary branch will be merged into The master is used to release updates, and the functional branch is also merged into the master after the debugging is correct, and finally a stable code version is formed.
The reason why we can switch between branches at will is because the version management between branches is independent of each other, see the next section for details.
3. Branch
The flow of this example is as follows:
When the version of "it's raining" was released, we created a new grocery shopping branch to buy fish and tofu. After buying the fish, we remembered that the window was not closed at home (the code had a bug). At this time, we can switch to master and close the window (bug fix), then switch back to the grocery shopping branch, continue to buy tofu, and then return home (called merge).
New branch
Click the "Branch" button, or directly right-click on the specified version to choose a branch...
Select the designated node, name and buy food
Then we see the branch, there is a branch of "Buying Vegetables":
At this time, the current branch has been switched to shopping here, and future changes will only be effective for the current branch. To switch branches, double-click the branch name in the branch.
Go back to our project folder LocalRepository and add a new grocery file:
Then see that there is an update in the file status, we submit a version of this, note buying fish, and submit it to the "buy food" branch (we are currently on this branch at this time):
Then click History to view the version history:
Switching branches
At this point, the food shopping branch is one version ahead of the master (buy fish version).
We can verify that, double-click master in the branch to switch to the main branch. At this time, the food shopping file under our project folder LocalRepository is gone:
When switching back to the grocery shopping branch, the grocery shopping file appeared again:
Now we switch back to master and create a new temp branch to fix bugs (close the window). The process is similar to that of new grocery shopping, so only the key steps will be posted. Close the window in the temp branch:
Then temp and the grocery branch each have a different revision, and both are ahead of the master: temp has an "close window" version, and the grocery branch has an additional "buy fish" version:
Merging branches
Now that the bug is fixed, we merge temp into master.
We want to merge a source branch to a target branch, and we need to operate on the target branch. For example, we want to merge the closed window version of temp into master, you need to switch to master, and then right-click the closed window version and select merge:
Delete branch
Now that the stable version has been generated, you can now delete the temp branch:
Okay, the bug is fixed, we switch back to the grocery shopping branch and continue to buy tofu:
OK, now you can go home. Merged the grocery shopping branch to master.
The process will not be repeated, just look at the result:
4. Version rollback
We superimposed two new versions on the master for testing:
[External link image transfer failed. The source site may have an anti-leech link mechanism. It is recommended to save the image and upload it directly (img-x6za7TKI-1591860419618)(https://upload-images.jianshu.io/upload_images/8900795-f2864101dea16252.png ?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)]
If we want to go back to this version of Tianqing, we can right-click and choose to reset to this submission:
Then there are three reset methods for us to choose:
Both soft merge and hybrid merge will not delete the content of the windowed version, but become the state before the windowed version is submitted after the version is submitted. The difference is that the soft merge will add these changes to the temporary storage area. The mixed merge is still in the unstorage area.
Forcibly merged is to discard the entire windowed version, and the content of the project folder becomes this version.
When
we submit the temporary file, we will only record the content of the temporary file. So after we modify the content, we must ensure that the content we want to submit is placed in the temporary file, otherwise the modification will not be recorded when submitting content.
Soft merge
does not delete the contents of the windowed version, but sets the modification of the windowed version as uncommitted
The modified content is added to the temporary file area by default:
The
only difference between mixed merge and soft merge is that the modified content is still in the temporary file area. At this time, if we click to select the untempered file, it will be added to the temporary file, which is the same as soft merge.
Forcibly merge and
discard the windowed version, the content becomes Tianqing version content:
5. Sourcetree&Git part of the term explanation
Retrieved from https://www.cnblogs.com/fisherbook/p/11397168.html
克隆(clone)：从远程仓库URL加载创建一个与远程仓库一样的本地仓库
提交(commit)：将暂存文件上传到本地仓库（我们在Finder中对本地仓库做修改后一般都得先提交一次，再推送）
检出(checkout)：切换不同分支
添加（add）：添加文件到缓存区
移除（remove）：移除文件至缓存区
暂存(git stash)：保存工作现场
重置(reset)：回到最近添加(add)/提交(commit)状态
合并(merge)：将多个同名文件合并为一个文件，该文件包含多个同名文件的所有内容，相同内容抵消
抓取(fetch)：从远程仓库获取信息并同步至本地仓库
拉取(pull)：从远程仓库获取信息并同步至本地仓库，并且自动执行合并（merge）操作，即 pull=fetch+merge
推送(push)：将本地仓库同步至远程仓库，一般推送（push）前先拉取（pull）一次，确保一致
分支(branch)：创建/修改/删除分枝
标签(tag):给项目增添标签
工作流(Git Flow):团队工作时，每个人创建属于自己的分枝（branch），确定无误后提交到master分枝
终端(terminal):可以输入git命令行
Remote warehouse (using GitHub)
If you only need to upload the code to GitHub without involving subsequent modification iterations, then the web page is sufficient.
1. Upload (Push)
Register a GitHub account, click the + sign in the upper right corner to create a remote warehouse (stored in GitHub):
Choose public to make it public and visible to anyone; choose private to make it visible to yourself, or you can set it to be visible to a designated person. Generally, a project will have a readme file (README.md) to describe the project and how to use it.
Click Upload files to upload the code file:
Drag the file directly to the window or click to select upload:
The content of the file in the example is a HelloWord folder, and there is a text file of version records in it:
Because the original content is also a modification compared to the original empty content, GitHub will prompt us to submit this modification after the upload is complete:
Then return to the project homepage and find that this folder has been uploaded successfully:
2. Download (Pull)
Click the clone or download button, you can directly download the compressed file ZIP:
After decompression, you will see our HelloWord file and README file:
3. GitHub client
If you want to clone a remote warehouse to the local, and after modifying the content locally, push to synchronize to the remote warehouse, then the best solution is to download the GitHub client.
Download link: https://desktop.github.com/
Clone remote warehouse to local
Clone the remote repository to the local. Click the clone and download button, and select Open in Desktop to clone:
After cloning is complete, you will see the HelloWord folder and README file in the local folder we specified:
push
We modify the README file locally:
Then the GitHub client prompts for new modifications:
We submit this modification, remarks and other takeaways. Note that this submission is only recorded locally. If you need to synchronize to a remote warehouse, you need to push the push operation.
Click the History version record to push the specified version to the remote. Click the upload arrow:
Then we check the web page, the HelloWord project has been updated:
pull
On the contrary, we modify the content on the GitHub page (remote warehouse), and then pull it and synchronize it locally.
Then open the GitHub client and refresh it:
Then we see that there is a new version on the remote side:
Click Pull origin to pull it. Then History has one more version record:
At the same time, the local file has also been updated: