The cause of
Because there is a real need to use Git in the development process these days, I recently went through the Git tutorial again.
The company is using SVN now, and there was no complex team cooperation before, but recently there are more development tasks, and there are multiple requirement lines in the same project. Some tasks of A are half developed, so B needs to be developed first, or some bugs of B need to be fixed immediately. In this case, it is obvious that Git’s branch management strategy is more appropriate to handle this scenario. This article starts with a usage scenario.
The GUI tools use TortoiseGit and SourceTree.
Git’s general operations, such as pull/commit/push and some basic concepts, are not covered in detail here, forgetting that you can quickly go through the tutorial.
- Even monkeys can understand GIT introduction
- Liao Xuefeng – Git tutorial
- Pro Git CHS
Branch management
We’ll just go back to the scenario we described earlier, where we now have multiple development tasks going on at the same time and new bug fixes coming in. Obviously a master branch is out of its depth.
So let’s roughly divide it up and create two branches, two branches, feat1 and feat2.
Once created, we can checkout to the specified branch for development work. To the left of SourceTree, double-click the corresponding branch. Operations such as commit on the branch are the same as before.
The next most critical issue is the merging of branches.
There are two operations for merging branches, merge and rebase. Both of these operations can achieve the effect of branch merging, but there are some differences in the way they operate.
Merge
Basic features of Merge:
- A new COMMIT is added after the merge, and the commits that were merged are listed in chronological order
- Multiple commits merge need to handle only one conflict
In operation, there are three ways:
- Common merge: After a merge, a new merge COMMIT record is added
- Fast-forward: Merging feat1 into the Master branch will move the master branch’s HEAD pointer directly to Feat1 if the master branch’s state has not changed, and no additional COMMIT records will be generated.
- Squash, which combines all commits on a merge branch into a COMMIT and merges the commits to the target branch. This approach has the advantage of keeping the trunk branch clean. For the whole project, it doesn’t care how many times someone commits a feature, so it’s clearer to merge into the trunk branch and keep only one COMMIT.
The GUI operation
For details, look at TortoiseGit and SourceTree. Above is the current state of the two branches. At this point, we need to merge Feat1 into the Master branch.
In SourceTree, right-click Feat1 and click Merge Feat1 into current branch. Check whether the feat1 policy is fast-forward. If this option is selected, no matter whether the target branch has updates, Both result in a Merge COMMIT.
In TortoiseGit, you can configure more parameters. You can choose whether to use a Squash fast-forward policy. If Fast Forward Only is selected, the merger is aborting if the fast-forward policy is selected. If Squash is selected, you need to commit it manually.
Merge a commit. A Squash merges multiple commits into one and then merges them into a target branch. The logs generated automatically are retained. You can see it a little bit better.
Rebase
The rebase command has many functions, but one of the most important is to merge branches.
Basic features of Rebase:
- No merged COMMIT records are created, and updates to the target branch are placed at the top. Compared to merge, history is unforked and cleaner
- If there are multiple COMMITS on the target branch, conflicts must be resolved one by one after rebase from other branches
The GUI operation
In the previous record, we updated the Feat1 branch once on the Master branch, but the feat1 branch was already behind. During the development process, we needed to synchronize the main branch updates frequently to reduce the occurrence of conflicts. Now we need to merge the master updates into Feat1. This can be done using merge, as can Rebase.
In SourceTree, you can right click on branches that require rebase changes, such as feat1, which now needs to update the Master branch. Just right-click on the master branch and select “Rebase current Changes onto Master”. Rewrite the commits to the top of FEAT1) and click OK. If there are no conflicts, the rebase action should be completed. Otherwise you need to keep solving the conflict file and then click Actions -> Continue Rebase on the menu until the entire Rebase process is complete.
TortoiseGit Branch indicates the current Branch and Upstream indicates the Branch to be Upstream. The action below is Feat1 Rebase onto Master, which means that the updates to the Master branch are merged into Feat1 and the commits of Feat1 are rewritten to the top. The UI also provides access to Squash, which allows you to choose whether commits in FEAT1 should be modified or consolidated. And then just hit Start Rebase. If there is a conflict, it will get stuck. Once resolved, click Continue to Continue Rebase until it is finished.
The result of Rebase is shown below. The History diagram is the same as described previously, with no forks. And Feat1 commits were in the front.
Another important feature of Rebase is the ability to rewrite history and merge multiple submissions. That was mentioned earlier in the Rebase branch.
For example, after completing a feature and submitting it for many times, some commits may be too fine-grained or unnecessary, and can be merged. You can squash rebase -i.
On SourceTree and TortoiseGit History, right-click commit Rebase children of XXX interactively or Rebase onto… .
Suppose we want to merge the update[1] and update[2] for Feat1.
TortoiseGit works similarly, as shown in the figure below.
Merge vs Rebase
Merge and rebase merge and rebase merge and rebase merge and rebase merge
Due to the author’s lack of practical experience, it does not do the analysis. In large companies, leaders generally have corresponding specifications.
Git merge git rebase git rebase git merge git merge
Code Stash
The Stash command is used to temporarily save work progress. For example, if you are halfway through development and need to urgently fix a bug, local changes are still not committed and you cannot switch branches directly. At this point, local changes can be stored in the staging area, and when the bug is fixed, you can checkout to the current branch and release the files from the staging area.
The GUI operation
SourceTree operation
TortoiseGit operation, right click Stash Changes.
Version rollback (Reset, Revert)
Version rollback is divided into two granularity.
- Cascade back to a historical version, in other words, reset all commits made after the target version is reset
- Undo a historically submitted change (Revert)
Reset
The result of the reset command is described above. For example, if you need to reset to 9f72a8c init, after the reset command is executed, all the four references after 9f72a8c are cancelled.
Also, the reset command has three different modes.
- Soft – keep all local changes
- Mixed – keep working copy but reset index
- Hard – discard all working copy changes
If you are familiar with Git workspaces and staging areas, these three modes should be well understood. To put it simply:
- Soft-history Records rollback, but the rollback changes are retained locally and stored in a temporary storage area
- Mixed-history records rollback, but the rollback changes are retained locally and in the workspace
- Hard-history records are rolled back, and rollback changes are not retained at all
SourceTree and TortoiseGit default mode is Mixed.
Revert
The Reset command cascades back directly, while the Revert command undoes a historical commit and keeps the current commit. Typically, undoing a change in history will cause a conflict, review the historical changes, resolve the conflict and recommit.
The GUI operation
For both SourceTree and TortoiseGit, right-click on a commit in the History and select the command.
- SourceTree is Reverse to commit..
- TortoiseGit is an revert change by this Commit.
Reflog
The Reset and Revert items mentioned above rollback or undo changes to code that you’ve submitted. Can I roll back Git if I did something wrong? The answer is yes.
Reflog records all of the user’s Git operations, such as history in Linux.
In TortoiseGit, right-click Show reflog and you can view all the records. SourceTree does not have this feature yet.
For example, merge misbranches, or rebase flushes out local changes, can be resolved by rolling back reflog. The operation is very simple, right-click to select the specific operation reset.
Cherry Pick
Cherry-pick moves particular commits from one branch to another, and they should be at the top.
SourceTree and TortoiseGit all work the same:
- Select the target branch as the current branch
- Right-click at a commit in the History and select Cherry Pick
About GUI Tools
I personally developed on The Windows platform and currently SourceTree and TortoiseGit are used together.
TortoiseGit has more functions than TortoiseGit, but it is on the shell of Windows Explorer, so it often needs to right-click to operate, which is quite troublesome.
SourceTree is a software that makes viewing logs more intuitive and makes branching and commit/push/pull routine easier. But some functionality is missing, like Relog. Some commands are not configurable. For example, merge only controls ff and cannot squash.
conclusion
This article mainly describes some common Git commands and the use of GUI tools. These commands are basically part of the development requirement, especially the branch management part. As the need for version control increases, so does the need for Git mastery. When browsing Pro Git, I found that there are still many commands I haven’t read yet. I hope to have a further understanding in the future.
reference
- Even monkeys can understand GIT introduction
- Pro Git CHS
- Liao Xuefeng – Git tutorial
- What are the advantages and disadvantages of using Git rebase or Git Merge during development?
- Understand Git-rebase once and for all