XX useful tips for mid-tier Git users. Part 1

Actually, I originally planned to translate Andy Jeffries’s 25 Tips for Intermediate Git Users article, but in the process I discarded stupid, well-known or very simple tips like “set up first thing user.name and user.email,” which are clearly not suitable for people who are already more or less closely acquainted with Git.
Instead, I will supplement the article with moments from personal practice (“Own practice”! It sounds great, as if I am a private doctor or lawyer!: -]

1. The very beginning.

')
Since the user. {Name, email, signingkey} is configured, you can look in the direction of small amenities, like $ git config --global help.autocorrect 1 - in case of typos, the git will try to guess what you mean
[solar @ hasher couchdb] $ git statu
WARNING: You are called a Git command named 'statu', which does not exist.
Continuing under the assumption of what you meant
in 0.1 seconds automatically ...
# On branch 0.10.x-alt
nothing to commit (working directory clean)

A value of 1 here shows tenths of a second.
A negative value will lead to the execution of the intended command immediately, and a zero value will simply result in a prompt (by default).

From alias I add only
git config --global alias.logp 'log --pretty = format: "% h -% an:% s"' - 10 last commits in the format "SHA - Author: Commit message"
git config --global alias.unstage 'reset HEAD'
git config --global alias.remotes 'remote -v' - This will make git remote a bit more detailed, but not so much like git remote show $ branch, in which, moreover, you need to specify a specific server.

2. Conflicts in merj

If there is a conflict, you can see the subject of contention in the normal standard diff -u:
$ git diff --merge
diff --cc dummy.rb
index 5175dde,0c65895..4a00477
--- a/dummy.rb
+++ b/dummy.rb
@@@ -1,5 -1,5 +1,5 @@@
class MyFoo
def say
- puts "Bonjour"
- puts "Hello world"
++ puts "Annyong Haseyo"
end
end


If you need to get a file from one of the merge brunches, you can do git checkout —ours flash / foo.fla or git checkout —theirs flash / foo.fla - this will eliminate the need to remember which brunches are merged.

Also, you can always see the differences before merging - $ git diff branch1 branch2

3. Tags.

To conveniently define the evolutionary stages of the code, you must use tags.
$ git tag -m '$ tag_description' $ tag_name
If your content is sent to the assembly for assembly, everything will be possible to build a specific specified version. By the way, most likely, you will need to create tags signed by your gpg-key (git config --global user.singingkey $ key_ID)

4. New Brunches

As everyone should be aware, you can get to the new brunch either by creating it and switching ($ git branch new_branch; git checkout new_branch), or immediately - $ git checkout -b new_branch.
By the way, you can rename the current brunch using git branch -m new_name, and third-party git branch -m current_name new_name.
Not the most frequently used feature, but sometimes it’s necessary and so it turns out more quickly than checkout -b and the subsequent manual removal of the old brunch.

5. Combine brunch. Merge and rebase.

To place changes from another branch in one branch, you can use either merge - m to create a new commit that contains the necessary edits, or rebase - to rewrite history. On the one hand, after the rebase, the story is more accurate, on the other - this is another story, so in the case of published all-party brunches, it is better to use merge. Moreover, no one takes money for the number of commits.

You can see the branches, changes in which have not yet been transferred to the current branch - this can be done through the git branch - no-merged. Such brunch is better not to drop, hehe.

6. Remote Brunches

Remote - in the sense remote: -]

You can push directly into the remote brunch — git push origin branch_name, if the local and remote brunch names are the same, or you can use the full form — git push origin localBranch: refs / heads / Remote_Branch_Name

By the way, in order not to specify the server name and brunch each time, you can create tracked branches using git checkout -b myfeature origin / myfeature. Now, being in this brunch, you can push / fetch / pull without specific names.

7. Stash

If someone else does not use git stash, I advise you to pay close attention to this command. It’s more than convenient, doing one thing, to “put aside” the current work to the side and get distracted, say, to urgently fix the bug, even if it is in a different brunch. After the correction and commit, you can calmly return to what was started.

i. hack-hack-hack
ii. git stash
iii. fix-fix-fix
iv. git commit -a -m 'bugfix # 31337'
v. git stash pop

Those who know about git stash, look at the last line - its difference from apply is that the postponed results do not remain in the temporary storage (see the git stash list after a few stash applications!)

If the change was actually complete, you can make a commit not moving away from the cash register - git stash save 'commit msg'

8. Search in history

If you know at least something about a commit, you can try to find it!
$ git log --grep = "Something in the message" - search by commit description
$ git log -S "{% include \" header.tmpl \ "%}" - search for a commit by line in the branch files. Note that there is no space after -S
$ git log templates / header.tmpl - search for commits that affected the specified file.

You can also refine the search using options like --since = X.months.ago --until = Y.day.ago --author = andy -S «something»
The --all-match option combines the parameters with AND, rather than the default OR.

Then I will describe the cancellation and manipulation of changes, interactive rebase, change of files throughout the entire history (I personally found it useful when I noticed that I keep the combat passwords in the main branch, hehe) and all other trifles ^ _ ^

PS: Thank you for such a necessary +1,% username%)