How to overcome your fear of resolving Git conflicts? In this article, we will cover Git miscellaneous.

Just take one record

Consider a common development situation: I’m working on a particularly nasty Bug and add some debugging commands to the code and print some information to the console for debugging purposes.

These debug and print statements are in their respective commit records. I finally figured out the root cause of the Bug and felt smug when I solved it!

All that’s left is merging the work in the bugFix branch back into the Master branch.

You can choose to merge to the master branch by fast-forward, but then the master branch will contain these debugging statements. You don’t want to do this, there’s got to be a better way…

All you have to do is have Git copy the commit record that solved the problem. As we learned earlier in “handing over commit records”, we can use:

• git rebase -i
• git cherry-pick

To solve the problem, run the following command:

git checkout master
git cherry-pick C4
Copy the code

Submission Tips 1

It’s not uncommon for you to commit once on the newImage branch, then create the Caption branch based on it, and then commit again.

At this point you want to make some minor adjustments to some previous commit record. Let’s say the designer wants to change the resolution of the image in the newImage, even though the submission record is not up to date.

We can overcome the difficulties by the following ways:

Git rebase-i resorts the commits, moves the commits we want to change to the front, makes a few small changes with commit –amend, and reverses them back to their original order with git rebase-i. Finally, we move the master to the front of the change (use your own method), and there you are!

Of course there are more than one way to do this (I know you’re watching Cherry pick) and we’ll focus more on these techniques in the future, but for now we’ll just focus on this one.

git rebase -i caption~2 --aboveAll
git commit --amend
git rebase -i caption~2 --aboveAll
git branch -f master caption
Copy the code

Finally, it is necessary to specify those in the target state ‘, we moved this commit twice, each move produces one ‘; The extra one on C2 was generated when we submitted with the amend parameter, so the final result is like this.

Submission Tips 2

We can use rebase -I to reorder the committed records. By moving the submission record we want to the front, we can easily modify it with Amend and rearrange them in the order we want.

The only problem with doing this is sorting twice, which can cause rebase conflicts. Git cherry-pick

Keep in mind that cherry-pick can append commits from anywhere on the commit tree to the HEAD (as long as they are not commits upstream of the HEAD).

Take a look at this example:

git checkout master
git cherry-pick C2
git commit --amend
git cherry-pick C3
Copy the code

Git Tag

As you can see from the previous example, the branch is easily moved manually and will move when a new commit is made. Branches are easy to change, and most branches are temporary and keep changing.

You may be asking: is there a way to permanently point to a commit, such as a major software release, a major Bug fix or a new feature? Is there a better way to permanently point to a commit than to permanently point to it?

Of course there is! Git tags do just that. They can (in part because tags can be removed and re-created in another location) permanently name a particular commit as a milestone, which can then be referenced as a branch.

Even harder, they don’t move with new commits. You also can’t check out a TAB to commit changes, it’s like an anchor point in the commit tree that identifies a specific location.

Let’s see what the tag looks like:

git tag v0 C1
git tag v1 C2
Copy the code

Git Describe

Because tags function as “anchors” in your code base, Git has a special command that describes the anchor (tag) closest to you. It is called Git describe!

Git Describe can help you find your way after moving multiple times in your commit history; You might use git bisect when you find a commit with git bisect, or when you’re sitting at your colleague’s computer back from vacation.

Git describe syntax is:

git describe <ref>
Copy the code

This can be any reference that Git recognizes as a commit record, or if you don’t specify it, Git will use the location you are currently checking out (HEAD).

It outputs something like this:

<tag>_<numCommits>_g<hash>
Copy the code

Tag is the tag closest to the REF, numCommits are the number of commits that are different from the TAG, and hash is the first number of commits that were in the hash of the given REF.

When a label is on the REF submission record, only the label name is printed.

git describe master
/ / output
v1_2_gC2

git describe side
/ / output
v2_1_gC4
Copy the code

I believe you have a basic grasp of Git miscellaneous, you might as well try it in your own Git environment ~

Code on among