Branch management strategy
Usually Git will use the Fast forward mode when merging branches, but after deleting the branch, the branch information will be lost.
If you want to forcibly disable the Fast forward mode, Git will generate a new commit when merging, so that the branch information can be seen from the branch history.
Create and switch the dev branch, modify the readme.txt file, submit a new commit, and finally switch to master
git switch -c dev git commit -m "add merge" git switch master
Prepare to merge the dev branch, please pay attention to the --no-ff parameter, which means that Fast forward is disabled:
git merge --no-ff -m "merge with no-ff" dev
After merging, we use git log to see the branch history:
git log --graph --pretty=oneline --abbrev-commit
Summary:
In actual development, we should follow several basic principles for branch management:
First of all, the master branch should be very stable, that is, it is only used to release new versions, and you cannot work on it;
Where do you work then? All the work is on the dev branch, that is to say, the dev branch is unstable. At some point, such as when version 1.0 is released, the dev The branch is merged into the master, and version 1.0 is released on the master branch;
You and your friends are all working on the dev branch, and everyone has their own branch, just merge to the dev branch from time to time.
BUG branch
When we need to complete other tasks, but the current work has not been completed or submitted, but other tasks are more urgent, we can use the stash function to store the site and restore it later
git stash
Now, use git status to view the workspace, it is clean (unless there are files that are not managed by Git), so you can safely create branches to fix bugs.
When we finish other work, we return to the current branch work area and it is clean. Where is the work site saved just now? Use the git stash list command to see:
git stash list
The work site is still there. Git has stored the stash content somewhere, but it needs to be restored. There are two ways:
One is to use git stash apply to restore, but after restoration, the stash content will not be deleted, you need to use git stash drop to delete;
Another way is to use git stash pop to delete the stash content while restoring:
Then use git stash list to view, and you will not see any stash content:
git stash pop git stash list
After fixing the bug on the master branch, we have to think about it. The dev branch was branched from the master branch earlier, so this bug actually exists on the current dev branch.
The same bug, to be fixed on dev, we only need to “copy” the changes made by the commit 4c805e2 fix bug 101 to the dev branch. Note: We only want to copy the changes made by the commit 4c805e2 fix bug 101, not merge the entire master branch.
For the convenience of operation, Git specially provides a cherry-pick command, which allows us to copy a specific commit to the current branch:
git branch git cherry-pick 4c805e2
Git automatically made a commit to the dev branch. Note that the commit submitted this time is 1d4b803, which is different from the master’s 4c805e2, because the two commits are just the same changes. But it is indeed two different commits. With git cherry-pick, we don’t need to manually repeat the bug-fixing process on the dev branch.
Some smart children’s shoes will think, since you can “replay” the repair process on the dev branch after fixing the bug on the master branch, then directly fix the bug on the dev branch, and then “replay” the line on the master branch no? Of course you can, but you still need the git stash command to save the scene in order to switch from the dev branch to the master branch.
Feature branch
When adding a new feature, you definitely don’t want to mess up the main branch because of some experimental code. Therefore, every time you add a new feature, it’s best to create a new feature branch, develop on it, and merge it after completion. Finally, Delete the feature branch.
git switch -c feature-vulcan git add vulcan.py git commit -m "add feature vulcan" git switch dev
If all goes well, the feature branch and the bug branch are similar, merged, and then deleted.
but!
At this moment, I received an order from my superiors, due to insufficient funds, the new function must be cancelled!
Although it was done for nothing, this branch containing confidential information must still be destroyed on the spot:
The feature-vulcan branch has not been merged yet. If it is deleted, the modification will be lost. If you want to delete it forcibly, you need to use the uppercase -D parameter. .
Now we force delete:
git branch -D feature-vulcan
Remote collaboration
When cloning from a remote warehouse, Git actually automatically associates the local master branch with the remote master branch, and the default name of the remote warehouse is origin .
To view information about remote libraries, use git remote:
git remote:
Or, use git remote -v to display more detailed information:
The above shows the address of the origin that can be fetched and pushed. If you do not have push permission, you cannot see the push address.
Push branch
Pushing a branch means pushing all local commits on the branch to the remote library. When pushing, you need to specify the local branch, so that Git will push the branch to the remote branch corresponding to the remote library:
$ git push origin master
If you want to push other branches, such as dev, change it to:
$ git push origin dev
Crawl branch
When multiple people collaborate, everyone will push their own modifications to the master and dev branches.
Now, to simulate one of your little friends, you can clone it on another computer (note that you need to add the SSH Key to GitHub) or another directory on the same computer:
git clone https://github.com/htforerver/test.git
When your buddy clones from the remote repository, by default, your buddy can only see the local master branch.
Now, if your friend wants to develop on the dev branch, he must create the dev branch of the remote origin to the local, so he uses this command Create a local dev branch:
git checkout -b dev origin/dev
Now, he can continue to modify on dev, and then, from time to time, push the dev branch to the remote:
If the push fails, because the remote branch is newer than your local branch, you need to use git pull to try to merge;
Finally introduce the git rebase command
git rebase git log --graph --pretty=oneline --abbrev-commit
The submission that can make the git log fork now becomes a straight line, which is convenient for us to observe