This is the fifth post in this series.
For our purposes, small team development, the majority of the time will be spent developing right in default. This is by far the simplest approach and for a small team is very doable with no major side-effects. However, it’s not without it’s own downsides. For that we’ll cover branching in a later article.
Let’s get started.
Open a command prompt by selecting your project's root folder and while pressing the Shift key, right-click the mouse and select open command window here
In a team scenario where you are working on the same code base you will want to look at pulling and updating your local repo with their changes. In our case, this is the abnormal case. For us we will almost always be working on the code base by ourselves. If your team is needing to be more collaborative then working in default will likely not fit your needs well. You’ll want to look more into developing in branches like the stable & default workflow outlined by Steve Losh.
With that in mind we can always start with checking the status of our code base.
Type hg stat.
hg stat will return a list (if there is any) of files that have either been added, deleted or changed since your last commit.
If it returns nothing then the repository is up to date (locally). This doesn't mean it's up to date with the Server (Bitbucket). However, in our simple case the Server / Bitbucket is used as central backup and retrieval. If your working on a new feature then running hg stat locally will be an indicator if you haven't committed in your latest changes locally.
Below is a sample session of a work in progress:
M - The file has been modified.
! - The file has been deleted.
? - The file is new.
Let's say we are done with these changes and we are ready to commit them.
Typing hg addremove would give us:
This marks all new files as added to the repository and marks removes/deletes files from the repository.
There are separate commands hg add & hg remove with options to add/remove only some files if desired.
However, the files have only been marked. They haven't actually been committed yet.
Note that the first two files that reported M are not in the list. That's because they don't need to be marked since they are already under source control.
Typing hg commit -m "commit message" would commit the changes to the repository.
You should get back a prompt without any messages. Looks like everything committed.
Typing hg stat (again) should report nothing. Your local repository is up to date with your latest changes on this machine.
You could keep on developing or push your changes up to Bitbucket. I like to do this often. Let’s update Bitbucket now. Updating Bitbucket
First create a repository in Bitbucket for your project.
Login to Bitbucket and create a repository.
Select your new repository from the Repositories drop down and copy the text after hg clone. Since we are going to do this from the Tortoise Client instead of the command line we leave off the hg clone.
It should look something like https://email@example.com/username/repositoryname.
We are using HTTPS to connect but you can also use SSH although I won’t be covering that here. If your interested in using SSH instead, Atlassian has a great write up.
Right click your project’s root folder and select Synchronize, under the Tortoise Hg menu item.
Select the local item in the dropdown list below the icons and paste in the repository address.
Then select the push icon.
You should be prompted for your password and possibly your username.
Getting code from Bitbucket
To get code from Bitbucket, we’ll do the same process as a push except now when we are in the Sync screen, we’ll use the pull icon instead.
I like to commit early and often. I try and break down the feature/bug I am working on into small chunks of logical work. When I get a logical chunk done I commit the work. If the feature or bug is small enough then I do it all in one commit.
I like breaking it up because this allows me to more easily go back to an early version if something goes wrong. It's easier to go back, start over if you will, than try and undo the mess I got myself into.The larger the feature, the more I try and work in logical chunks. For a large enough feature I also will use a branch.
I like to push my changes to Bitbucket often. At least once a day and perhaps more. On rare occasions I will not push my changes in a day. Usually this is when I am hammering out an idea and the code is unstable still. I try to live by “the code shouldn’t break the build” as a general rule of thumb for deciding if I should push it up. If you are working in small enough chunks this should be a rare occurrence.
As a general guideline I push changes to Bitbucket when I have completed a feature/bug fix. However, this is not a hard and fast rule and I try hard to push my changes at least at the end of the day.
When more than one developer is working on a codebase the general guideline is to push when you have completed and tested the feature along with everyone else's submitted work. In a team someone else could have pushed up a change. You’ll need to bring their work down (hg pull and hg up or hg merge) and test it with your code to ensure your changes continue to work as well as your teammates. If you need some more information on working in this kind of scenario please check out HgInit’s setting up for a team. SecretGeek also published a nice workflow sample based off of HgInit’s explanation.
The basic workflow of working on code on default is:
- hg stat
- hg addremove
- hg commit -m "Commit Message."
- hg stat
You can also run hg log to see what has been done lately.
Next, were going to go over deleting/reverting changes.