Record my journey to GitHub (ii)

2015-12-09 Update

1, now that you have a library locally, you might think of GitHub creating a library and associating it. In this way, the remote library can be used as a backup and other people to collaborate through the warehouse.

2, Step:

(1) Login to GitHub, there should be a hint, (I have not created a remote library, it is easy to see this interface)

(2) Click on the Create a respository:

(3) This creates a library, and when the library is empty, GitHub tells us that we can clone a new warehouse from this repository. You can also associate an existing local repository with it.

(4) The local warehouse is associated with:

Open git Bash: Enter

$ git Remote add origin [email protected]:yourname/yourname.git

Note: replace the yourname with your own account name and library name

If you associate someone else, you can't push it because your SSH key public key is not in the other's account list

Once added, the remote library's name is origin, which is the default for git and can be changed to another

Next, you can push the contents of the local library to the remote library.

$ Git push-u Origin Master

Local content push to remote, with git push command, is actually to push the current branch master to remote

Since the remote library is empty, the first time you push master, plus the-u parameter , git pushes the local branch to the new master branch of the remote and associates the local master branch with the remote Master branch. You can simplify the commands later by pushing or pulling them.

After the push succeeds, the content of the remote library can be seen on the GitHub page as if it were local.

3, from now on, only local modifications, you can use the following command

$ GIT push origin master

Push the latest changes to the local master branch to GitHub.

4, Summary:

Associate a remote library: Git remote add origin [email protected]:yourname/yourname.git

First push to remote library: $ Git push-u origin Master

Later commit: $ GIT push origin master

-----Split Line-----

Cloning from a remote library

1, first create a library, and the above method is a little different

2, after this is created, the library will have a readme.md file. This will have a remote library,

3, open git bash, enter command

$ git clone [email protected]:yourname/yourname.git

In this way, a remote library is cloned locally, just like this.

4, Summary:

To clone a library, you have to know the address of the repository and then clone it with the git clone command.

2015-12-10 20:14:09

1, Branch Management: can create a branch of their own, others do not see, others continue to work on the original branch, and you yourself in the branch of the job, want to submit on the submission, after completion, and then merged together to the original branch, security does not affect the work of others.

2, creating and merging branches

(1) In the version fallback, each commit, Git will string them into a timeline, this time line is a branch. So far, there is only one timeline, in git, this branch is called the main branch (Master branch).

Head is strictly not pointing to commit, but pointing to Master,master is pointing to commit, so head is pointing to the current branch. (This is a bit of a mouthful)

(2) At the beginning, the master branch is a line, Git uses master to point to the latest commit, and then head to master, which determines the current branch and the commit point of the current branch:

In this way, after each commit, the master branch moves forward, and as you commit,the lines of the master branch grow longer. (When a new branch is not created)

(3) When we create a new branch, such as Dev, Git creates a new pointer called Dev, which points to the same commit as Master. Pointing head to dev again means that the current branch is on Dev:

Just like, just one more dev pointer, and then change the head point, the workspace file does not change . (Head always points to the current branch, here is Dev)

From now on, the workspace is modified and submitted to the Dev branch, each time the head is committed and the master pointer is unchanged.

(4) How do I merge with Master when Dev has finished working? The simplest way is to use master to point to the current commit of Dev . Like this, change the pointer and the contents of the workspace will not change.

Once you have merged the branches, you can delete the dev pointer. there is only one master branch left.

3, began fencing the actual combat:

(1) Create Dev branch and switch to Dev branch

$ git checkout-b dev

Git checkout plus the-b parameter means create and switch, equivalent to the following two commands:

$ git Branch Dev

$ git Checkout dev

Then, you can look at the current branch, GIT branch will list all branches, the current branch preceded by the * number

Next, change the commit in dev and switch back to the master branch

Then merge and delete the dev pointer to see the changes you just made at Dev

4, Summary:

View branches: Git branch//with * represents the current branch

Create a branch: Git branch **name

Switch branches: git checkout **name

Create + Switch branch: git checkout-b **name

Merge a branch to the current branch: git merge **name

Delete branch: Git branch-d **name

2015-12-21 Update

Recently very busy, the company project a lot of bugs, it is really difficult. Ha ha haha

1. Resolving conflicts

Now assume the following scenario:

$ git checkout-b feature1//Create and switch to a new branch

The Readme.txt is then modified and submitted

Then switch back to Master branch $ git checkout master

Modify the Readme.txt on the master branch to commit

Then merge the master and Feature1 branches into the git merge Feature1

There is a conflict, Git tells us that there is a conflict in the Readme.txt file, and you must manually resolve the conflict before committing. You can view conflicting files in git status

At this time, run cat Readme.txt can view the contents of the file, for example, only part of the content

Git uses <<<<<<<,=======,>>>>>>> to mark the contents of different branches.

Now the Master branch and the Feature1 branch become the following:

Use the following command to see the merge of the branches:

Summary: When git cannot automatically merge branches, the conflict is resolved before it can be submitted.

$ git log--graph can see the branching merge diagram

2, Branch management policy

(1) Typically, when merging branches, Git uses "Fast forward" mode if possible. (The branch information is discarded when the branch is deleted)

(2) to force the "Fast forward" mode to be disabled, GIT will generate a new commit at merge, so you can see the branching information from the branch history

(3) Example:

$ git checkout-b dev//After face Readme.txt modification, forgive me for writing comments accustomed to this, although I also know this is not true, hahaha

$ git Add readme.txt

$ git commit-m "add merge" //Start Here

$ git Checkout Master

$ git merge--no-ff-m "merge with Np-ff" Dev //--no-ff disable "Fast forward"

because this merge will create a new commit, add-M, write the Commi description , merge, and then view the branch history

$ git log--graph--pertty=oneline--abbrev-commit

Without the fast forward mode, the merge is like this

(4) Branching strategy: The actual development should follow several principles of branch management

First, the master branch should be very stable and not be able to work here. Published on the Master branch.

The work is on the dev branch, everyone is working on the Dev branch, everyone has their own branch, and sometimes the merger is possible.

So the branch of teamwork is like this:

Summary: Merging branches with the--NO-FF parameter can be combined with normal mode, and the merged history has branches. I can see that I've done the merger.

And fast foward merge can not be seen to have been merged.

Note:.   Description of Fast forward mode. reference: http://bbs.scmlife.com/thread-22570-1-1.html

When using git merge, it could be one of the following three modes9 m& _7 c% N) J (B. M3 m 5 P6 U4 G0 n S "L3 F # I 1.Fast forward When the last commit of the 2 branch to be merged is a linear relationship' c& v:y-n+ p n+ B + v# R Or, a branch has no commit information since it was last updated. Git moves the pointer directly, does not have a real merge operation, and does not have a corresponding merge commit message # S7 O ' L "R, R3 R1 Z 2.Merge made by recursive% n$ X7 o ' {"]% N0 z2 g# q When the nearest commit of the 2 branch to be merged corresponds to the direct ancestor not simultaneouslyp. Z4 W s-l/O Git won't be able to merge with a simple move pointer Only a merge with the latest commit of 2 branch and their common ancestor: L + d& R5 Z4 _* P, z h, \ and corresponds with a merge commit message3 G1 _+ q! W) a-v) N8 S 3.Conflict When 2 branch have modified the same part of the same file4 to H) g) P ' y8 i*? 6 p1 J! J At this point, a conflict will occur, and Git's automatic merge will fail. At this point, using GIT status will see-F # r+ [-G1 J. M. _% Z-p# d! R4 H6; L7 w# M3 E! Y8 U2^/V "d* E5 k If you need to merge conflicts manually, git add a bit to indicate that the conflict has been modified Then, Git commit can!

Record my journey to GitHub (ii)