Xiaobai asked git's question for an answer.
I just got in touch with GIT, and read Liao Xuefeng"s GIT tutorial. But there are some questions you want to ask?
demand:
the (PHP) code of an open source project needs to be updated periodically from github, as long as the author of the open source project submits the project update. I may need to update to my local project, but the author of this project will update it only once a month, not too often. I develop my own requirements in the local project every day. These newly developed requirements are only for my own use and do not need to be uploaded to this open source project again. There is no need to co-develop projects locally with others!
question:
after git clone this project for the first time, then go to GITHUB every month to see if the author has submitted any new updates, and if so, update them. When I develop new requirements locally, do I just need to commit these new changes into the local master branch in time, and if there are updates on the GIThub, I will git pull to the local master branch to merge the changes I submitted with myself, and resolve the code conflict between the two? Is this process correct? Because I saw the branching feature, I wondered if I would set up a local development branch after each git pull, then develop on the branch, and then merge it into the local master main branch after development. It seems that both ideas are the same?
if this is the process, do I only need to know some simple operations of git? What do you need to know about GIT, such as file merging, conflict resolution, code rollback? I feel that the water in GIT is too deep
start your own branch, since you have your own submission
if you currently update
on your own branch: git pull origin master:master
and then you git merge master
resolve conflicts.
Let's first talk about the GIT operations required by ordinary developers. In general, you only need to understand the operations required in the process of clone remote warehouse, pulling remote warehouse code, merging code to local warehouse, submitting commit to local warehouse, and pushing to remote warehouse.
often uses the following actions:
- clone remote warehouse to local:
clone
- pull remote repository and merge code to local warehouse:
fetch/merge or pull
- submit records to local repository:
commit
- push code to remote:
push
- temporary modification:
stash
- Branch Management:
branch
- remote warehouse management:
remote
- reset HEAD:
reset
- View history:
log
some of these operations will also have subdivision commands, ordinary developers should at least have a clear understanding of the specific use of the above commands.
demand: according to the purpose of the subject, it should only fork someone else's library, and then develop and use it by yourself, and push it to your own remote warehouse at most. If this is only the case:
one, you do not need to go to the original author's warehouse to see if there are any updates, you can directly use the local command to pull the code of the original author's remote warehouse, and the display of Already up-to-date means that there is no update, otherwise it will inform you that there is a conflict or that your code has not been submitted commit will be overwritten. And you can also pull the code of any branch to the local;
2. With regard to the branch, if you are sure that every update of the original warehouse should be reflected in your local, there is no need to build a new branch, because only for your own use, you will eventually have to return to the main branch, increasing the complexity.
3. This main branch for you does not have to be master,. You can keep the original warehouse branch unchanged, only develop functions on a new branch you create, pull new code, and do not eventually merge back to master, unless you have to use the master branch.
when you need to establish a branch, you need to develop new functions in addition to the normal use of the main branch, or there are several different functions in parallel development at the same time, in order not to influence each other, establish a new branch development on the basis of the main branch. In this way, if you want to abandon one of the functions in the development, you can delete the branch directly, it will not affect other functions, a bit modular meaning. The same is true for working with others, in the end, it is necessary to ensure that the normal operation of the main branch will not be affected, and then develop new features on other branches, and then merge back to the main branch after successful testing and release a new version.
finally, tools are for people and should be flexible in the simplest way to suit their needs.
you can just follow your own operation first. after all, you will learn more after you have just come into contact with it.
the correct posture should be fork to your own github,. All your own developed content can be pushed to this warehouse without affecting its open source repository, and then you can develop on different computers, not just one computer (which is also more secure and greatly reduces the risk of code loss).
your local repository can be associated with two remote repositories. By default, origin, is the remote repository of your clone (if you directly clone someone else's project address), you need to associate your own repository.
specific steps:
1. His open source project fork project to your own github.
2. If there is no clone to local, clone your own project locally and add two remotes.
the instruction to add a remote warehouse is:
git remote add source ''
the remote repository name added in this way is source instead of origin.
here you can set your own warehouse to origin (this is the name used to be remote), while his warehouse is called by another name, such as the complete instruction called source,:
git remote delete origin // clone
git remote add origin '' // clone
git remote add source ''
3. Development step
after the normal development of commit to the local, push to their own warehouse.
git push -u origin master // git push
when you need to merge the development content of the original author,
git pull source master
< hr >
