10 tips to get your git level up

Note: In this article, some commands contain a section with square brackets (e.g. git add -p [file_name] ). In these examples, you want to insert the required numbers, identifiers, and so on. You do not need to preserve square brackets.

1.Git Auto-complete

If you use git commands at the command line, it's annoying to manually enter commands every time. In order to solve this problem, you can easily turn on the automatic completion function.
Under UNIX systems, run the following command to get the script:

12	cd~curl https://raw.github.com/git/git/master/contrib/completion/git-completion.bash-o ~/.git-completion.bash

Then, ~/.bash_profile Add the following code to your file:

123	if[ -f ~/.git-completion.bash]; then    . ~/.git-completion.bashfi

Even though I mentioned it before, I still have to take the trouble to say that if you want to use all of the features that GIT provides, you need to use the command line instead.

2. Ignore files in git

Are you bored with the compiled files that appear in your Git repository (for example .pyc )?
Or have you been fed up with putting them into git?
Now there's a way to get git to ignore specific files or directories. Simply create a .gitignore file and list the files and directories you don't want Git to track. You can use the exclamation mark (!) to indicate an exception.

12345

*.pyc*.exemy_db_config/!main.pyc

3. Who moved My code?

It is human nature to blame others after a problem. If you have a problem with your production server, you can easily pull out the bad guys-just use the git blame command.
This command displays the author of each line in the file, the commit (commit) that was made after the last change, and the timestamp of the commit.

1	git blame [file_name]

, you can see what it looks like to use the command in a large warehouse.

4. Review of Warehouse History

In the previous tutorial, we learned about the git log use of commands, however, it also has three options that you should understand.

• --oneline--Compress the information displayed between each submission into a reduced hash value and commit information, displayed on one line.
• --graph-This option displays history in a text-based graphical representation on the left-hand side of the output interface.
  This feature is useless if you are simply browsing through the history of a separate branch.
• --all--Show the history of all branches

Here is the effect of using the above command in combination.

5. Never lose a Submit message

For example, you submit a code that you do not want to commit, and finally you return it to the previous state by using hard reset. Later, you realize that in the process you lose some other information and want to return or at least take a look at it. git reflogcommands can help you do this.

A simple git log command that shows you the most recent commit information, as well as the last commit message, and so on.

git reflogIt shows all of the head movement information. Remember that it is local, not part of your repository and will not be included in push and merge (merge).
If I use git log , I get the submission information that is part of my warehouse.

However git reflog , a commit message ( b1b0ee9 – [email protected]{4} ) is displayed, which is the one I lost when I used hard reset.

6. Staging a partial change to a file

In general, creating an attribute-based commit is a good practice, meaning that each commit must represent the creation of a new feature or a bug fix. Consider if you fixed two bugs, or added several new features but didn't commit the changes? In this case, you can put these changes in one commit. But there is a better way to do this: separate the files (stage) and submit them separately.

For example, you have made several changes to a file and want to submit them separately. In this case, you can add the option in the Adding command ( add ) -p

1	git add -p [file_name]

Let's demonstrate. I file_name added 3 lines of text to the file, and I just wanted to submit the first and third lines. Let's look at git diff the results of the display first.

Then, let's take a look at what happens when you add an option to a command -p .

It seems that git assumes that all changes are directed at the same thing, so it puts them in a single block. You have several options as follows:

• Input y to cache the block
• Input n does not cache the block
• Input e To manually edit the block
• Enter d to exit or go to the next file
• Input s to split the block.

For us, we certainly want to divide it into sections, selectively adding parts and ignoring others.

As you can see, we added the first and third rows and ignored the second line. You can check the status of the warehouse and submit it later.

7. Merging multiple submissions

When you submit your code for review and create a pull request (which often happens in open source projects), you often ask for some code changes before the code is accepted. You have made some changes, and in the next review you will be asked to make additional changes. You don't know how many changes you've been waiting for, and you've made several additional submissions before you know it. The ideal state is that you can use rebase commands to merge them all into one commit.

1	git rebase -i HEAD~[number_of_commits]

If you want to merge the last two commits, you need the following command

1	git rebase -i HEAD~2

Using this command, you will enter an interactive interface that shows the last two commits, and asks you which to compress. The ideal state is your pick last commit and commit it and the previous one squash .

Next you will be asked to fill in the descriptive information for the combined submission. This process actually overrides your commit history.

8. Save changes that have not yet been submitted

For example, if you are solving a bug or adding a new feature, you are suddenly asked to show your work. Your current job has not been completed to the point of submission, and you will not be able to show your work at this stage (if you do not return all changes). In this case, git stash you can be saved. The stash command essentially preserves all of your changes for future use. To save your changes, you only need to run the following command:

1

git stash

To view the staging list, you can run the following command:

1	git stash list

If you do not want to save or want to restore these changes, you use the following command:

1	git stash apply

In the last one, you can see that each save has an identifier, a unique number (although we only have one save here), in case you want to use only certain saves, you need to apply indicate the identifier after the command.

1	git stash apply [email protected]{2}

9. Check for lost submissions

Although reflog it is a way of looking at a lost commit, it does not work in a large warehouse. This is thefsck
(File system check) appeared.

1	git fsck--lost-found

Here you can see the missing commits, which you can use git show [commit_hash] to view the changes contained in these commits or git merge [commit_hash] to use to recover it.
git fsckthan reglog have an advantage. For example, if you delete a remote branch and clone the repository, fsck you can search for and restore the remote branch using the command.

10.cherry-pick command

I left the most elegant git command at the end. cherry-pickis my favorite git command, because its name means its function!

In short, it cherry-pick means selecting a commit from a different branch and merging it into the current branch. If you are developing two or more branches in parallel, you may notice that a bug exists in all branches. If you solve it in a branch, you can use cherry-pick to merge this commit into other branches without cluttering up other files or submitting them.

Let's imagine a scenario where the command can be used. I have two branches, and I want to put b20fd14: Cleaned junk this commit into another branch using the Cherry-pick method.

I switch to the branch where I want to put the commit, and then run the following command:

1	git cherry-pick [commit_hash]

Although we cherry-pick have no problem with this use, but you should be aware that this command will bring conflict, please use with caution.

Summary

Speaking of which we came to the end of the article, I think these techniques will make your git level higher.
Git is the best, and it can be done if you want to.
Therefore, you should always challenge your git level. In the end you will probably learn something new.

10 tips to get your git level up