The following terms make up the basics of what you need to know about bazaar
The most common commands that will create branches are init, branch (a.k.a. get or clone),
The command for creating a new repository is init-repository.
Commands that deals with checkouts are checkout, bind, unbind.
Commands that includes commits are commit, pull, update
If you want to you can commit locally in the branch 'underneath' the chekcout. this means that you actually create new revisions and record the changes - but only locally, in what appears to be the 'the local branch'.
You do local commits with the command commit --local.
When you want these local commits to be committed to the branch the checkout is tied to you simply do a regular commit.
The command for unbinding checkouts is simply unbind.
If commits has been made to your master branch while you were detached from it you must first commit locally - and then bind. The bind may result in a merge, which in turn may require conflicts to be resolved and those too must be committed locally before you can make the regular commit and thus update the master branch with the work you did while you were detached.
The command for binding is just bind.
Pull required that the branches has not diverged. If the destination for the pull has made commits which the source of the pull doesn't know of, then the pull would simply overwrite (discard) these changes in the estination branch. Therfore the pull refuse to execute when the branches diverge.
You can force the synchronization and discard your commits in the destination by using pull --overwrite but typically that is not what you want to do.
The right thing to do is tho avoid the branches to diverge. Use the local branch as a representation of the master. if you need to change it then make sure you do those changes in a third branch setup for the purpose (use the branch command to set it up) and whne you are done developing at testing you pull from the master branch, then merge from thee development and finally push back to the master branch.
The commands for pulling is pull and pull --overwrite.
If you try to push and the distination is diverged then you will have to merge from you destination-to-be and resolve any conflicts and then push. But this workflow has some unwanted side effects:
Say two developers both got the master branch at revision 45 and one of the creates a new local version, commits it and pushes it - it becomes version 46 on the master branch. The other developers has also created a new version and committed the the development branch and has also created a revision 46, but when he tries to push he can't because the branches has diverged. The revision 46 on the master branch is still unknown to him. So he merges the master branch into his development branch, lets make it easy and say there werent any conflicts so the commit is simple and now he has revsion 47. Revision 46 was his own contibution and revision 47 is his integration with his colleague. Now he can push it the the master branch. And he's allowed to do that now since thcnically the branches don't diverge anymore. But pushing means that the destination becomes a mirror of the source, so the master branch will have revision 46 and 47.
What used to be revision 46 - the first developers original contibution is now an embedded merge in revision 47 - and 46 is the second developers contribution.
Clearly this is not a good way to collaborate between devlopers!
A simple way to solve the case is to work with checkouts of the master branch rather than branches. You can unbind or use local commits, but the point is that when you need to get in sync with you colleagues work on the master branch you'll be force to accept their work into your local commits first, and when you have resolved any conflicts and are ready to "push" you do a commit to the master branch - that will create a new revision - on top of the existing ones.
Aaaah - nice!
As described earlier (under the header 'pull') you also have the alternative (if you dont like checkouts) to have a local branch (get) of the master branch, and branch off from that (using branch), make your development here, keep the local mirror of the master branch updated (using pull) but restrain yourselv from actually doing any changes here except until you are ready to deliver your work. Then you merge the development branch into you synchronized master branch and then you commit your merge and push it to the real master.
The source of the merge doesn't have to be another branch. It can be a merge packet created by someone else using the send command.
Like most other version control tools, moving or renaming files and folders around in the structure requires that the system somehow gets the information that this has happende. som when you move ar rename, don't us the native files system commands, and don't drag and drop files in file exploreres that aren't educated in what such operations implies whne working in version controlled repositories. Use the commands rename and move
The command info will let you know the details of your branch: who's the parent, who submitted (where did you merge from) the default targert for your pushes etc.
The status command will show you the pending commits, the files that have changed since your lase commit.
Also have a look at annotate which gives details history for a specific file and diff which tells you the differences between tho files.
Using merge -preview doesn't actually change your branch, but tells somthing about what the consequneces af a merge would be.
The log command shows you the revision log for a branch (or a subset of it).