References:
/questions/315911/git-for-beginners-the-definitive-practical-guide
http://www.kernel.org/pub/software/scm/git/docs/
http://progit.org/book/
git安装、配置用户名邮箱、SSH服务器搭建
Create/List/Remove a new Project/Repository
$ git init 将在当前目录创建一个隐藏的名为".git"的目录。$ git init project1等价于 $ mkdir project1 && cd project1 && git init$ git status 检查当前目录是否包含一个git repo$ ls .git 查看git目录$ rm -rf .git/ 移除有关git的所有东西
Configure git to ignore files
.gitignore文件可以定义要忽略的文件。详细规则见http://www.kernel.org/pub/software/scm/git/docs/gitignore.html
过滤文件夹: /build/过滤某种类型的文件:& *.tmp过滤某各文件: /Build/Products/test.app!开头表示不过滤： !*.c , !/dir/subdir/支持通配符： *.[oa] 过滤repo中所有以.o或者.a为扩展名的文件
有三种方法应用过滤：
对该repo的所有用户应用过滤:将 .gitignore 文件放在工作目录的跟目录，编辑.gitignore完成后提交git add .gitignore
仅对自己的repo备份过滤:添加/编辑你工作目录的$GIT_DIR/info/exclude,例如你的working copy目录是~/src/project1 , 则路径为~/src/project1/.git/info/exclude
系统全局过滤创建一个ignore文件，名字随意起，比如我的放在 ~/.gitglobalignore ，然后配置git：$ core.excludesfile = ~/.gitglobalignore
.gitignore文件示例:
.DS_Store### build directoryiMochaApp/build/iMochaSDK/build/### Testing projects directory/Testing/
Getting the latest Code
$ git pull &remote& &branch& # fetches the code and merges it into
# your working directory$ git fetch &remote& &branch& # fetches the code but does not merge
# it into your working directory$ git pull --tag &remote& &branch& # same as above but fetch tags as well$ git fetch --tag &remote& &branch& # you get the idea
Checking Out Code (clone)
$ git clone /dir/to/repo [Target DirName]
Commit Changes
当修改了文件，你需要提交(commit)这些更改。
$ git commit source/main.c上句将提交 ./source/ 目录下的 main.c 文件。
$ git commit -a-a标识表示提交所有修改过的文件，但是不提交新增加的文件。新增加的文件需要使用$ git-add 将其添加到git的索引中。
&提交&仅改变你本地repo，如果要提交更改到服务器，需要使用push：$ git push &remote& &branch&
查看当前状态
$ git status 可以查看当前工作与那个branch，将要提交什么，提醒你忘记了什么等等...
Undo/Revert/Reset a commit
如果不想让当前的更改生效，返回之前的提交，可以运行如下命令:# Revert to a previous commit by hash:$ git-reset --hard &hash&
可使用 HEAD^ 快捷指定上一次提交hash：# Revert to previous commit:$ git-reset --hard HEAD^
比较命令是 $ git diff
# to compare 2 revisions of a file:$ git diff &commit1& &commit2& &file_name&
# to compare current staged file against the repository:$ git diff --staged &file_name&
#to compare current unstaged file against the repository:$ git diff &file_name&
How do you see the history of revisions to a file?
$ git log -- filename
git branch (分支)
git默认分支叫 master
# create a new branch$ git branch &branch-name&# to see a list of all branches in the cureent repoitory $ git branch# if you want to switch to another branch you can use$ git checkout &branch-name&# to create a new branch and switch to it in one step$ git checkout -b &branch-name&# to delete a branch:$ git branch -d &branch-name&# to create a branch with the changes from the current branch,do :$ git stash$ git stash branch &branch-name&
How do you merge branches?
if you want to merge a branch(e.g. "master" to "release"), make sure your current branch is the target branch you'd like to merge into(use $git branch or $git status to see your current branch).
Then use$ git merge master(where master is the name of the branch you want to merge with the current branch).
If there are any conflicts, you can use$ git diffto see pending conflicts you have to resolve.
跟踪远程分支
假设你已经clone了一个具有 'some_branch' 分支的远端repo.下面的命令将本地跟踪这个分支：
# list remote branchesgit branch -r# start tracking one remote branchgit branch --track some_branch origin/some_branch# change to the branch locallygit checkout some_branch# make changes and commit them locally....# push your changes to the remote repository:git push
创建远程分支
# create a new branch locallygit branch name_of_branchgit checkout name_of_branch# edit/add/remove files
# ... # Commit your changes locallygit add fileNamegit commit -m Message# push changes and new branch to remote repository:git push origin name_of_branch:name_of_branch
删除远程分支
git push [远程名] :[分支名]
$ git push origin :mybranchname
阅读(...) 评论()Git Interactive Rebase, Squash, Amend and Other Ways of Rewriting History
Git Interactive Rebase, Squash, Amend and Other Ways of Rewriting History
&Please rebase on top of master and we&ll merge your pull request&.
&Can you please squash your commits together so we get a clean, reversible git
history?&.
&Can you rewrite your commit&s message to describe better the problem it
solves, and how it solves it?&.
Questions like these are commonly asked in pull requests. Let&s see why they
exist, how to perform them, and their possible problems.
One of the simplest history rewrites we can do with git is changing the last
commit message. Let&s say right after making a commit you find a typo in its
description, or you find a better way of describing the changeset. To make the
correction you run:
git commit --amend

with the last commit message, so you can modify it. After saving, a new commit
will be created with the same changes and the new message, replacing the commit
with the previous message.
This can be useful to include files you forgot to track, or include
modifications to the files you just commited. To do so, you can add the changes
and then perform the amend:
git add README.md config/routes.rb
git rm notes.txt
git commit --amend

Aside from editing the commit message, the new commit will contain the changes
specified with git add and git rm. You can also edit the author. For
git commit --amend --author="Tute Costa and Dan Croak &tute+&"

Achievement Unlocked! You can now change the last commit of
your repository to include newer changes to the files, and/or to improve the
commit message. But don&t start amending all-the-things before understanding the
last section of this blog post titled &DANGER&.
Would love to speak about this now, but we need to understand a more general
tool before. Stay tuned! Everything else will be easier once we read about&
re-applies commits, one by
one, in order, from your current branch onto another. It accepts several options
and parameters, so that&s a tip of the iceberg explanation, enough to bridge the
gap in between StackOverflow or GitHub comments and the git man pages.
An interesting option it accepts is --interactive (-i for short), which will
open an editor with a list of the commits which are about to be changed. This
list accepts commands, allowing the user to edit the list before initiating the
rebase action.
Let&s see an example.
Let&s say I want to reword any of the last 4 commits of this blog. I then run
git rebase -i HEAD~4, and here is what I see:
pick 07c5abd Introduce OpenPGP and teach basic usage
pick de9b1eb Fix PostChecker::Post#urls
pick 3e7ee36 Hey kids, stop all the highlighting
pick fa20af3 git interactive rebase, squash, amend

# Rebase 8db7e8b..fa20af3 onto 8db7e8b
#
# Commands:
#
p, pick = use commit
#
r, reword = use commit, but edit the commit message
#
e, edit = use commit, but stop for amending
#
s, squash = use commit, but meld into previous commit
#
f, fixup = like "squash", but discard this commit's log message
#
x, exec = run command (the rest of the line) using shell
#
# These lines can be re- they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

We see the four last commits, from older to newer. See the comment below the
list of commits? Good job explaining, git! pick (p for short) is the default
action. In this case it would reapply the commit as is, no changes in its
contents or message. Saving (and executing) this file would make no changes to
the repository.
If I say reword (r for short) in a commit I want to edit:
pick 07c5abd Introduce OpenPGP and teach basic usage
pick de9b1eb Fix PostChecker::Post#urls
r 3e7ee36 Hey kids, stop all the highlighting
pick fa20af3 git interactive rebase, squash, amend

When I save and quit the editor, git will follow the described commands, landing
myself into the editor again, as if I had amended commit 3e7ee36. I edit that
commit message, save and quit the editor, and here is the output:
tc-git-rebase % git rebase -i HEAD~4
[detached HEAD dd62a66] Stop all the highlighting
 Author: Caleb Thompson
 Date: Fri Oct 31 10:52:26 
 2 files changed, 39 insertions(+), 42 deletions(-)
Successfully rebased and updated refs/heads/tc-git-rebase.

Now Caleb says in his commit message &Stop all the highlighting&, whether you
are a kid or not.
Achievement Unlocked! You can now change the message of any
commit you want. You may do so, just make sure you understand the &DANGER&
Two other commands rebase interactive offers us are:
squash (s for short), which melds the commit into the previous one (the
one in the line before)
fixup (f for short), which acts like &squash&, but discards this commit&s
We&ll continue to work on the . We had four commits, my own for this blog post, and
three others from Caleb, which were related to his previous post on PGP:
pick 07c5abd Introduce OpenPGP and teach basic usage
pick de9b1eb Fix PostChecker::Post#urls
pick 3e7ee36 Hey kids, stop all the highlighting
pick fa20af3 git interactive rebase, squash, amend

Let&s say I want to meld Caleb&s commits together, because they belong to the
same logical changeset, and so we can git revert it easily if we find we
prefer not to have those changes in this repository. We&ll want to keep the
first commit message, and squash the two subsequent commits into the previous
one. I change pick to squash where appropriate:
pick 07c5abd Introduce OpenPGP and teach basic usage
s de9b1eb Fix PostChecker::Post#urls
s 3e7ee36 Hey kids, stop all the highlighting
pick fa20af3 git interactive rebase, squash, amend

Save, and I land into the editor to decide the commit message of the melded
three commits (see how they are concatenated one after the other):
# This is a combination of 3 commits.
# The first commit's message is:
Introduce OpenPGP and teach basic usage

Besides demystifying a relatively complex tool, protocol, and etiquette,
this post is intended to help with problems such as the one outlined in
this tweet:

& Emailed sensitive info to someone with PGP. They replied, with my
& original email, all in clear text. They didn't realize it.

# This is the 2nd commit message:

Fix PostChecker::Post#urls

# This is the 3rd commit message:

Hey kids, stop all the highlighting

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Author:
Caleb Thompson
# Date:
Tue Sep 2 09:39:07 
#
# onto 71d4789
# You are currently editing a commit while rebasing branch 'tc-git-rebase' on '71d4789'.

I decide to remove the third commit message, and add a more relevant note to the
second commit message. Save the editor, and the four commits were transformed
into two: the one from Caleb, and mine after. Good!
We could have used the fixup command, if we had seen earlier that we want the
changes, but not the commit message, of the third commit. In that case, the
commands would have looked like:
pick 07c5abd Introduce OpenPGP and teach basic usage
s de9b1eb Fix PostChecker::Post#urls
f 3e7ee36 Hey kids, stop all the highlighting
pick fa20af3 git interactive rebase, squash, amend

When saved, the editor would have included the third commit message already
commented out for us:
# This is a combination of 3 commits.
# The first commit's message is:
Introduce OpenPGP and teach basic usage

Besides demystifying a relatively complex tool, protocol, and etiquette,
this post is intended to help with problems such as the one outlined in
this tweet:

& Emailed sensitive info to someone with PGP. They replied, with my
& original email, all in clear text. They didn't realize it.

- /csoghoian/status/060096

* Use examples that reasonably approximates `gpg2` output.
* Reject backslash from &abbr title="Uniform Resource Locator"&URL&/abbr&s

before checking them


Markdown allows backslashes in &abbr title="Uniform Resource

Locator"&URL&/abbr&s to escape characters, which are passed directly to the

&abbr title="Uniform Resource Locator"&URL&/abbr&, so `http://some\_`

becomes ``.


This mitigates issues with markdown syntax highlighting thinking that

emphasized text has started, such as `_this text_`.

# This is the 2nd commit message:

Fix PostChecker::Post#urls

# The 3rd commit message will be skipped:

#
Hey kids, stop all the highlighting

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Author:
Caleb Thompson
# Date:
Tue Sep 2 09:39:07 
#
# onto 71d4789
# You are currently editing a commit while rebasing branch 'tc-git-rebase' on
'71d4789'.

Save, and outputs:
[detached HEAD 809241b] Introduce OpenPGP and teach basic usage
 Author: Caleb Thompson &caleb@calebthompson.io&
 Date: Tue Sep 2 09:39:07 
 2 files changed, 1429 insertions(+), 1 deletion(-)
 create mode 100644 source/posts/-pgp-and-you.md
Successfully rebased and updated refs/heads/tc-git-rebase.

Result is the same: 2 commits instead of 4, each with a single, different blog
Achievement Unlocked! You can now merge commits together. As
always, be mindful of the DANGER section.
We fork an open source library, start working on a feature branch, and master in
the upstream project moves ahead. Our history looks like:
A---B---C feature

/
D---E---F---G upstream/master

The library maintainer asks as to &rebase on top of master&, so we fix any merge
conflicts that may arise between both branches, and keep our changeset together.
The maintainer would like to see a history like:
A'--B'--C' feature

/
D---E---F---G upstream/master

We want to reapply our commits, one by one, in order, onto upstream&s master.
Sounds like the description of the rebase command! Let&s see what commands would
land us into the desired scenario:
# Point our `upstream` remote to the original fork
git remote add upstream /thoughtbot/factory_girl.git

# Fetch latest commits from `upstream` (the original fork)
git fetch upstream

# Checkout our feature branch
git checkout feature

# Reapply it onto upstream's master
git rebase upstream/master

# Fix conflicts, then `git rebase --continue`, repeat until done
# Push to our fork
git push --force origin feature

Achievement Unlocked! Your feature branch will be applied on
top of latest master of the original fork.
And so we get to&
See the --force in the last git push command? That means we are overwriting
repository&s history. This is always safe to do in commits we don&t share with
other team members, or in branches that belong to us (see my initials in the
example of this blog post).
But if you force push editions that were already shared with the team (commits
that exist outside of my repository, like the changes I made to the PGP commits
that have been already shared), then everyone&s branch gets out of sync.
Rewriting history means abandoning existing commits and creating new ones, that
may be very similar but are different. If others base work on your previous
commits, and then you rewrite and force-push your commits, your team members
will have to re-merge their work (if they notice the potential loss).
At thoughtbot we prefix our branches with our initials, signaling that those
commits may get rewritten and others shouldn&t add commits to the branch. When
those commits land into master or a shared branch we never rewrite them again.
So rewrite git history, provided rewritten commits exist only in your
repository, or you and your team know that no one else should base work off of
Achievement Unlocked! You now know how to rebase while being a
good citizen.
Got the basics of Git down? Master it in just a few hours with the
course on Upcase.How to show or change your Git username or email address
By Alvin Alexander. Last updated: February 19 2017
Git user FAQ: How do I show or change my
username (or email address)?
How to show your Git username
There are several ways to show your Git username. One way is with the git config command, like this:
git config user.name
which in my case returns:
Alvin Alexander
Another way to show your Git username is with this git config command:
git config --list
which returns this output:
user.name=Alvin Alexander
user.email=[omitted]
merge.tool=vimdiff
Finally, you can also see your Git username in the Git configuration file in your HOME directory on Unix systems, i.e., this file:
~/.gitconfig
My file on this new test system looks like this:
name = Alvin J. Alexander
email = [omitted]
tool = vimdiff
It’s important to note that this is your “global” Git username. You can also have a different username on a per-project basis, but I haven’t done that yet.
How to change your Git username
You can change your Git username like this:
git config --global user.name "Alvin J. Alexander"
You can probably also just edit the Git config file in your HOME directory and change it there:
vi ~/.gitconfig
I just did that on my test system, and it seems to work fine.
Again, it’s important to note that this is your “global” username. You can also have a different username on a per-project basis ... I just looked it up, and you should be able to change your Git username on a per-project basis like this, without the --global option:
git config user.name "Alvin J. Alexander"
How to change your Git email address
While I’m in the Git username neighborhood, I’ll also add that you can view your Git email address with this command:
git config user.email
And you can change your Git email address like this:
git config --global user.email [your email address here]
Finally, you can also see your password by viewing the Git config file in your HOME directory:
more ~/.gitconfig
There’s just one person if this article was helpful (or interesting), I’d appreciate it if you’d share it. Thanks, Al.
books i’ve written}