[Split] Locking files with bazaar/git and Qt Creator
-
I can agree to what Tobias said about merging. We are a small team, working independently on the source code, but most of the times automatic merge just works. We hardly have to resolve merge conflicts manually. Once you're used to it you never will go back to locking based versioning :)
-
Is there any guide or reference about using Bazaar or Git with QtCreator?
I found the following:
"http://doc.qt.nokia.com/qtcreator-2.3/creator-version-control.html":http://doc.qt.nokia.com/qtcreator-2.3/creator-version-control.htmlBut not completely understand whole process check out, check in , restore old versions etc.
-
Git (don't know bazaar too well my self) is conceptually a bit more complex than traditional centralized version control systems.
Centralized systems are rather simple: You have a server which holds the "master data". You create a local copy to work with on your machine from that (checkout). Then you change a bit there and make those changes available to your team mates by pushing them onto the server (commit).
Distributed version control systems are a bit more complex since you do not have a single server holding the master data (well, usually you have, but that is a social agreement more than a technical necessity -- "all of us will use server X for the changes we want the team to see" vs. "all our data is housed in a version control system on server X").
So what you do is you generate a copy of all the version control history on a server X (and Y and Z if you care;-) on your local machine. That is the "clone" operation. Think of that as similar to setting up a private source safe server just for yourself, containing all the code changes up to now. You then create a working directory by checking out from that local copy of the repository, resulting in a tree of source files on your disk we will call 'A'. You commit your changes into that repository, too. As long as you are inside that "private source safe server" of yours you work pretty much like before. You create changes B on top of A and commit them. Then you proceed to do a new feature, resulting in a tree of sources we will call 'C'.
Now how do you get to see what your co-workers do, living in that private world of yours?
That is where "git fetch" comes in: It fetches all the changes that were made on some other server (X) and makes them available in your private copy. Let's assume your co-worker Bob implemented another feature, changing the common base 'A' you got from the server to a state 'D'. After a git fetch you have all the following pieces of history in your local copy: A->D as well as A->B->C.
That is usually not what you want: You want something that contains your work and Bob's! At thisyou have two options:
You can merge Bobs and your changes, which will make the complete development history visible by having you merge the tree of files in state 'D' (Bobs work) and the tree of files in state 'C' (your work) into a new commit 'E' which unifies them both. You end up with one branch of your history going A->B->C->E (your work + unification) and a parallel branch A->D->E (Bobs work + unification). The history of what you did and of what Bob did is fully visible there, all the intermediary steps are there for future generations of developers to see. This is nice when e.g. you are merging a set of changes implementing a new feature back into the main work branch.
You can rebase your changes. What git rebase does is basically this: It takes the changes you did going from state 'A' to 'B' and from 'B' to 'C' and then replays them on top of a new basis, in this case 'B'. So instead of your history going A->B->C with a parallel branch A->D you end up with a history of A->D->B->C. The advantage here is that this keeps the history simple: You get one linear history (as known from e.g. Subversion, CVS and probably source safe, too, instead of changes diverging and converging all the time.
Now that you have turned your work and Bobs into one consistent piece (either by merging or rebasing) you can push this state back to the server you originally cloned from. That is done by "git push".
Does this help a bit? It is kind of git specific since that is what I use, but should be applicable to a certain degree to all distributed version control systems.
-
Tobias
Your explanation is really great.
It is more clearer now.
Seems to be using Git it's like juggling with chunks of code :)
Thanks for that!And what about practical using with QtCreator (where to click, what button press), because after some times of using, files of my project where marked with red color, and i cant understand how fix it.
-
I realized
I only need to understand all features of this menu"Screen shot":http://www.freeimagehosting.net/e0923
-
Nothing special. You can use any of the free hosters. Dropbox is used by some others, for example. Google's picasa works too and I've seen some others as well, but forgot the names.
In any case, just make sure, that the image is accessible publicly for everyone. The error message "405 Not Allowed" seems caused by missing permissions for non-logged in users. I'd guess that the image is private by default at that hoster.
-
Yes this host is from my internet provider, and possible its closed for others :(
Any way i renew the upper link
"Screen shot":http://www.freeimagehosting.net/e0923 -
The menu entries reflect the usual commands of the bzr tool. I'd suggest you read one of the introductions at the "Bazaar website":http://bazaar.canonical.com/. Once you learned the usage there the menu will look familiar to you :)