I only can imagine what a young developer can start using version control directly from git, but my knowledge is conditioned by my previous experience. First time I've work with cvs, I never remember how the commands works, what they mean, which order was the correct. But you learn. Migration to subversion, was good. Many of the things starts to work the way you think.
But git is a big step further. It has been a big change for me. To mention to books have helped:
Shorted than books are videos, and the one that I prefer about git is:
Recently I've seen another video that helps me on improve my way to work with git: the git flow.
This, together with the decentralized repository schema, make me happy. A long a go I was trying to find a way to have code in more than one repository and have them synchronized.
Nowadays this feature is even documented!
For example, the work with the Lima project. The main sources are on github but instead of have all the developers working in parallel and all of us committing to the same trunk (specially because I know a very short number of people that works with subversion with branches), each of the developers have their own branch by make a fork. That is great! You have your own branch, and with the sync feature mention before it's incredibly easy to get the official changes to your repository:
The first time you do it, from your clone of your fork:
$ git remote add esrf-bliss https://github.com/esrf-bliss/Lima.git
And when you like to take those changes:
$ git fetch esrf-bliss
$ git checkout master
$ git merge esrf-bliss/master
And with this you can upload the result of your synchronization:
$ git push origin master
Further than that, you can have as many remotes as forks it has. And you can repeat this with any of the branches that the other developers can do (remember that the master is only one branch more with an special name, meaning what you think is the trunk).
No comments:
Post a Comment