CentOS7 SSH登陆慢的解决方法简述

1.  

Branching

means you diverge from the main line of
development and continue to do work without messing with that main line.

 

 
2. 

When you commit in Git, Git
stores a commit object that contains a pointer to the snapshot of the content
you staged, the author and message metadata, and zero or more pointers to the
commit or commits that were the direct parents of this commit: zero parents for
the first commit, one parent for a normal commit, and multiple parents for a
commit that results from a merge of two or more branches.

 
3. 

Staging the files checksums each
one (the SHA-1), stores that version of the file in the
Git repository (Git refers to them as blobs
),
and adds that checksum to the staging area. When you create the commit, Git
checksums each subdirectory and stores those tree objects in the Git repository.
Git then creates a commit object that has the metadata and a pointer to the
root project tree so it can re-create that snapshot when needed.



 
4. 

If you make some changes and
commit again, the next commit stores a pointer to the commit that came immediately
before it.

 
5. 

A branch
in Git is simply a lightweight movable pointer to one of
these commits. The default branch name in Git is master

. As you initially
make commits, you're given a master branch that points
to the last commit you made. Every time you commit, it moves forward
automatically.

 
6.  

git branch [branch-name]


command creates a new pointer at the same commit you're currently
on.

 
7. 

Git keeps a special pointer
called HEAD

which is a pointer to the local branch you're currently on.

 
8.  

To switch to an existing
branch, you run the git checkout

command:

$ git checkout testing



This moves HEAD

to point to the testing branch:



What is the significance of that? Well, do another commit
and you will see:



 
9. 

git checkout


command did two things: it moved the HEAD

pointer back to
point to the target branch, and it reverted the files in your working directory
back to the snapshot that the target branch points
to. Note that if your working directory or staging area has uncommitted changes
that conflict with the branch you're checking out, Git won't let you switch
branches.

 
10.  

A branch in Git is in actuality
a simple file that contains the 40-character SHA-1 checksum of the commit it
points to, branches are cheap to create and destroy. Developers are encouraged to
create and use branches often.

 
11. 

To create a branch and switch
to it at the same time, you can run the git checkout

command with the -b

switch:

$ git checkout -b iss53



 
12. 

If you want to merge hotfix
branch back into your master branch, you can do this:

$ git checkout master



$ git merge hotfix



 
13. 

When you try to merge one
commit with a commit that can be reached by following the first commit's
history, Git simplifies things by moving the pointer forward because there is
no divergent work to merge together—this is called a fast forward.

 
14. 

To delete a branch, you can
delete it with the -d

option to git branch

:

$ git branch -d hotfix



 
15. 

If the commit on the branch
you're on isn't a direct ancestor of the branch you're merging in, Git has to
do some work. In this case, Git does a simple three-way merge, using the two
snapshots pointed to by the branch tips and the common ancestor of the two.



Git creates a new snapshot that results from this three-way
merge and automatically creates a new commit that points to it. This is
referred to as a merge commit
and is special in that it has more than one parent.



 
16. 

If you changed the same part of
the same file differently in the two branches you're merging together, Git won’t
automatically created a new merge commit. It has paused the process while you
resolve the conflict. To see which files are unmerged at any point after a
merge conflict, you can run git status

. Git adds
standard conflict-resolution markers to the files that have conflicts, so you
can open them manually and resolve those conflicts.

 
17.  

Your conflict file contains a
section that looks something like this:

<<<<<<< HEAD:index.html



<div id="footer">contact :
email.support@github.com</div>



=======



<div id="footer">



 
please contact us at
support@github.com



</div>



>>>>>>> iss53: index, html



This means the version in HEAD

is the top part of
that block (everything above the =======

), whereas the version in
your iss53
 
branch looks like everything in the bottom part.

 
18. 

After you've resolved each of
these sections in each conflicted file, run git add

on each file to
mark it as resolved. Staging the file marks it as resolved in Git.

 
19. 

To use a
graphical tool to resolve these issues, you can run git mergetool

. You will
see all the supported tools listed at the top after "merge tool candidates

".
Type the name of the tool you'd rather use. After you exit the merge tool, Git
asks you if the merge was successful. If you tell the script that it was, it
stages the file to mark it as resolved for you. After you verify that
everything that had conflicts has been staged, you can type git
commit
 
to finalize the merge commit.

 
20.  I

f you run git branch

with no
arguments, you get a simple listing of your current branches. The
*



character that prefixes the branch indicates the branch that you currently have
checked out. To see the last commit on each branch, you can run git
branch –v

.

 
21.  

To see which branches are
already merged into the branch you're on, you can run git branch –merged

. To
see all the branches that contain work you haven't yet merged in, you can run git branch --no-merged

. Because it
contains work that isn't merged in yet, trying to delete it with git
branch -d

will fail, however you can force it with –D

.

 
22.  

Many Git developers have a
workflow that embraces this approach, such as having only code that is entirely
stable in their master
 
branch—possibly only code that
has been or will be released. They have another parallel branch named develop

or next

that they work from or use to test stability—it isn't
necessarily always stable, but whenever it gets to a stable state, it can be
merged into master

. It's used to pull in topic
branches (short-lived branches for hox-fix and new feature) when they're ready,
to make sure they pass all the tests and don't introduce bugs.



 
23. 

Remote branches
are references to the state of branches on your remote
repositories. They're local branches that you can't move; they're moved automatically
whenever you do any network communication. Remote branches act as bookmarks to
remind you where the branches on your remote repositories were the last time
you connected to them. They take the form (remote)/(branch)

: origin/master


 
24. 

If you clone from a remote git repoitory, Git
automatically names it origin
 
for
you, pulls down all its data, creates a pointer to where its master

branch is, and names it origin/master

locally; and you can't
move it. Git also gives you your own master

branch starting at the same
place as origin's master

branch:



 
25. 

When you run a git
fetch origin

command. This command looks up which server origin

is, fetches any data from it that you don't yet have, and updates your local
database, moving your origin/master
 
pointer to its new, more up-to-date position:



 
26. 

If you have a branch named serverfix

that you want to work on with others, you can push it up
the same way you pushed your first branch. Run:

Git push origin serverfix



 
27. 

This is a bit of a shortcut.
Git automatically expands the serverfix

branch name out to refs/heads/serverfix:refs/heads/serverfix

,
which means, "Take my serverfix

local branch and push it
to update the remote's serverfix

branch." You can also
do git
push origin serverfix:awesomebranch

if you don't want it to be called serverfix

on the remote. When you do a fetch that brings down new remote branches, you
don't automatically have local, editable copies of them. If you want your own serverfix

branch that you can work on, you can base it off your remote branch:

$ git checkout -b serverfix origin/serverfix



This gives you a local branch that you can work on that
starts where origin/serverfix

is.

 
28. 

Checking out a local branch
from a remote branch automatically creates what is called a tracking branch.
Tracking branches are local branches that have a direct relationship to a
remote branch. If you're on a tracking branch and type git push

,
Git automatically knows which server and branch to push to. Also, running git
pull
 
while on one of these branches fetches all
the remote references and then automatically merges in the corresponding remote
branch.

 
29. 

When you clone a repository, it
generally automatically creates a master

branch that tracks origin/master

.
That's why git push

and git pull
 
work
out of the box with no other arguments.

 
30. 

You can set up other tracking
branches if you wish—ones that don't track branches on origin

and don't track
the master
 
branch by:

git checkout -b [

branch] [
remotename]/[
branch]



You can also use --track

shorthand for Git version
1.6.2 or later:

$ git checkout --track origin/serverfix



 
31. 

You can delete a remote branch
using the rather obtuse syntax:

$
git push [remotename] :[branch]



  
 

A way to remember this command
is by recalling the git push [remotename] [localbranch]:[remotebranch]

syntax. If
you leave off the [localbranch]

portion, then you're basically saying, "Take
nothing on my side and make it be [remotebranch]

."

 
32. 

In Git, there are two main ways
to integrate changes from one branch into another: the merge


and the rebase


.

 
33. 

With the rebase
 
command, you can take all the changes that were
committed on one branch and replay them on another one.

Before rebase:



Then you run:

$ git checkout experiment



$ git rebase master



After rebase:



At this point, you can go back to the

master



branch
and do a fast-forward merge.

 
34. 

rebase


works by going to the common ancestor of the two branches (the one
you're on and the one you're rebasing onto), getting the diff introduced by each
commit of the branch you're on, saving those diffs to temporary files,
resetting the current branch to the same commit as the branch you are rebasing
onto, and finally applying each change in turn.

 
35. 

The snapshot pointed to by the
final commit you end up with, whether it's the last of the rebased commits for
a rebase or the final merge commit after a merge, is the same snapshot—it's the
history that is different. Rebasing replays changes from one line of work onto
another in the order they were introduced, whereas merging takes the endpoints
and merges them together, but rebasing makes for a cleaner history. If you
examine the log of a rebased branch, it looks like a linear history: it appears
that all the work happened in series, even when it originally happened in
parallel.

 
36. 

If you have following branches:



You can take the changes on client

that aren't on server

(C8 and C9) and replay them on your master

branch by using the --onto

option of git rebase:

$ git rebase --onto master server client



This basically says, "Check out the client
 
branch, figure out the patches from the common ancestor of
the client
 
and server
 
branches, and then replay them
onto master

.":

 



You can rebase the server

branch onto the master
 
branch without having to check it out first by running git
rebase [basebranch] [topicbranch]

—which checks out the topic branch (server

) for you and replays it onto
the base branch (master

).

 
37.  

Do not rebase commits that you
have pushed to a public repository. When you rebase stuff, you're abandoning
existing commits and creating new ones that are similar but different. If you
push commits somewhere and others pull them down and base work on them, and
then you rewrite those commits with git rebase
 
and
push them up again, your collaborators will have to re-merge their work and
things will get messy when you try to pull their work back into yours.