10 tips to quickly boost your Git level (GO)

We have recently launched two tutorials: familiarity with Git's basic features and the ability to use GIT in a development team. The command we're talking about is enough for a developer to work with Git. In this article, we try to explore how to effectively manage your time and fully use the features that GIT provides.

Note: Some of the commands in this article contain portions of the brackets (for example: git add -p [file_name] ). In these examples, you will insert the necessary numbers, identifiers, and so on, if there is no square brackets.

1.Git Auto-complete

If you run a git command using a command-line tool, it's annoying to manually enter commands every time.
In order to solve this problem, you can enable the automatic completion of git, it takes only a few minutes to complete the work.

To get this script, run the following command under the UNIX system:

CD ~curl Https://raw.github.com/git/git/master/contrib/completion/git-completion.bash-o ~/.git-completion.bash

Then, add the following lines to your ~/.bash_profile file:

] then    . ~/.git-completion.bashfi  

Although we have mentioned this earlier, the emphasis is not sufficient. If you want to use all of the features of Git,
You should definitely switch to the command line interface!

2. Ignore files in Git

Are you annoying those compiled files (for example) that .pyc appear in your Git repository? Or have you had enough of that already added to the Git repository? Well, there's a way you can tell Git to ignore those specific files and folders. Just create a .gitignore file and folder named then list those you don't want Git to track. You can also add exceptions by using the exclamation mark ( ! ).

*.pyc*.exemy_db_config/!main.pyc

3. Who messed up my code?

When things go wrong, it is one of human nature to blame others first. If your product server hangs up, using git blame commands can easily find the culprit. This command can show the author of each line in the file, the latest change submission, and the time of submission.

[file_name]

In the following, you can see how the commands are searched in a larger directory.

4. View Warehouse History

We've learned how to use git log in the previous section, but there are three options that you should know about.

• --oneline– Compression mode, which displays a streamlined commit hash code and submission information next to each submission, in one line.
• --graph– Graphical mode, which uses this option to draw a historical information representation of the text format on the left side of the output. This option is not available if you are viewing the history of a single branch.
• --all– Displays the history of all branches.

When you combine these options, the output looks like this:

5. Never lose track of commit

If you accidentally commit something you don't want, you have to do a mandatory reset to revert to the previous state. Then you realize that in the process you lose some other information and want to get it back, or at least take a look at it. That's what git reflog you can do.
A simple git log command can show you the last commit, its father, and his father's father, and so on. git reflogIt lists the series of commits that head once pointed to. Understand that they exist only in your native computer, not part of your version repository, and are not included in push and merge operations.
If I run the git log command, I can see some commits, all of which are part of my repository:

However, one git reflog command shows a commit ( b1b0ee9 - [email protected]{4} ), which I lost when I just forced the reset:

6. Partial changes to the staging file

In general, it is good practice to create an attribute-based commit, meaning that each commit must represent the creation of a new feature or a bug fix. What if you fixed two bugs, or added multiple new features but didn't commit the changes? In this case, you can put these changes in one commit. But a better approach would be to put the file on hold (stage) and submit it separately.
For example, you have made several changes to a file and want to submit them separately. In this case, you can add parameters to the Add command -p .

[file_name]

Let's demonstrate file_name that 3 lines of text are added to the file, but only the first and third lines are submitted. First look at git diff the results shown:

And then look at add -p how the arguments are added to the command?

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:

• Enter Y to temporarily save the block
• Input n is not staged
• Enter E to edit the block manually
• Enter D to exit or go to the next file
• Enter S to split the block

In our example, we end up with the desire to split into smaller parts, and then selectively add or omit portions of them.

As you can see, we added the first and third rows and ignored the second line. After that you can view the status of the warehouse and submit it.

7. Compress multiple commits

When you submit code for code review or create a pull request (which happens frequently in open source projects), your code is asked to make some changes before it is accepted. You have made a change and you have not been asked to change it again until the next review. You've got some extra commits before you know it's going to change again. Ideally, you can use rebase commands to compress multiple commits into one.

git rebase-i head~[number_of_commits] 

If you want to compress the last two commits, you need to run the following command.

Git rebase-i head~2

When you run the command, you'll see an interactive interface that lists a number of commits that let you choose which ones need to be compressed. Ideally, you choose the last commit and compress the other old commits.

You will then be asked to enter the submission information for the new commit. This process essentially overrides your commit history.

8.Stash UNCOMMITTED changes

You are modifying a bug or feature and are suddenly asked to show your work. And the work you're doing is not enough to submit, and you won't be able to show it at this stage (before you go back to the change). In this case, git stash can help you. Stash essentially takes all the changes and stores them for future use. Stash your changes, you simply run the following command-

Git stash

To check the Stash list, you can run the following command:

git stash List

If you want to release stash and resume uncommitted changes, you can apply stash:

Git stash Apply

In the screen, you can see that each stash has an identifier, a unique number (although in this case we only have one stash). If you only want to leave the apply stash, you should add a specific identifier to apply:

git stash apply [email protected]{2} 

9. Check for lost submissions

Although reflog it is the only way to check for lost submissions. But it is not adapted for use in large warehouses. That's fsck when the file System Test command comes in.

Fsck--lost-found

Here you can see the discarded submissions. You can git show [commit_hash] revert to the previous commit by running the change or run to view the commit git merge [commit_hash] .
git fsckreflogThere is a relative advantage. Let's say you delete a remote branch and then close the warehouse. fsckyou can search for and recover deleted remote branches.

10.Cherry Pick

I left the most elegant git commands to the end. The cherry-pick command is my favorite git command so far, both because of its literal meaning and because of its functionality.
In short, cherry-pick you pick up a separate commit from a different branch and merge it with your current branch. If you are dealing with two or more branches in parallel, you may find a bug in all branches. If you resolve it in a branch, you can use the cherry-pick command to commit it to another branch without messing up other files or commits.
Let's imagine a scene that would need it. I now have two branches, and I want cherry-pick b20fd14: Cleaned junk this commit to go to the other one.

I switched to the branch that I wanted to be cherry-pick applied to, and then ran the following command:

[Commit_hash]

Even though we've done a clean one this time cherry-pick , you should be aware that this command may have a conflict. So be careful when using it.

Summarize

At the end of the article, I think these techniques will elevate your Git level to a new height. Git is the best, and it almost does what you can think of. Therefore, you should always challenge your git level. In the end you will probably learn something new.

Http://www.techug.com/articlearticle

10 tips to quickly boost your Git level (GO)