After learning of the previous theory, it is believed the model of git already have a more in-depth understanding, before explaining the development of common commands, look under the overall operational processes git
We follow a normal development process to learn, we are now beginning to develop, first of all we need to be synchronized to a remote repository local
git clone https://github.com/generalthink/git_learn.git
End run the above command, in our current working directory there will be a git_learn folder in which there .git directory (git repository of basic maintenance) as well as warehouse and remote files, and now our code and remote warehouse on the environment consistent, we can begin the process of our development.
Development Process
In general, both the development of new features (feature) or modify bug (issue) we will not be developed directly on the trunk, but will be working on a branch, and then verify correct after synchronized to master.
Now suddenly we had a bug that we want to open a new branch to fix the bug, then how should we do it?
First, create a bugFix branch, and switch to that branch
git branch bugFix
git checkout bugFix
或者
git checkout -b bugFix
Create a new branch, but more a pointer to the current date to submit it, after all the submissions are based on the current branch, the asterisk represents the current branch.
Then, to find the cause of the bug, modify the corresponding file, and now we modify a few files, you need to submit it to add to our local warehouse, synchronized to the remote repository will explain in a later article.
- Modified files added to the staging area
git add *.java
The above operation is actually the version of the file staging area and working directory of the same, but now and in repository also inconsistent. Want to see what are the specific documents to be submitted can be used git statusto view.
- Submission of documents to the local repository
git commit -m "fix bug"
commitCommand is to index the file is actually consistent version of the staging area and warehouse, after this step, the working directory, staging area and warehouse versions are the same, the following diagram is commit objects before and after the submission (you can view the data change model article) is.
After you modify the bug, while others have been submitted to the branch on the trunk code or other features of your local already exist two different branches, so fixes this bug, our warehouse looks like this
Merge branch
After the bug fixes, it is verified by testing, and then the next want to code this branch into the trunk branch (or merging two different branches), the commonly used two kinds of methods are combined
Go merge
The bugFix merged into the master branch
//切换到master分支
git checkout master
git merge bugFix
See no, master points to a record has submitted two parent node, if from the point of view began to master the arrow, on the road to reach the starting point will go through all the records submitted, which means master contains all of the code base modify.
This time if you want to merge the master branch to branch also possible bugFix
git checkout bugFix
git merge master
Because the master inherited from bugFix, Git do nothing, but simply moved to the master bugFix pointed that commit the record.
Now all submitted records are the same color, which indicates that each branch contains all the code changes the library!
Go to rebase
The second method is to merge branches git rebase. Rebase actually submitted out a series of records, "copy" them, and then one by one to go down in another place.
Rebase advantage is that we can create a more linear commit history.
git rebase master
Now working on a master bugFix branches at the top, but we also get to submit a more linear sequence.
Note that there is still commit record C3 (trees that dotted line node), and C3 'C3 is our Rebase to copy on the master branch.
The only problem is that master has not been updated, here we will update it now
git checkout master
git rebase bugFix
Since bugFix inherited from the master, so Git simply references the master branch moved forward about it.
Thumbs concern is not lost
