This guest post is by Laurence Gellert.
I’m an independent software developer. I use Bitbucket for all my client projects. It works reliably and has a sense of 'business software' I like. Mostly I use the Git command line, but there are a few places I have come to rely on the visual interface of Bitbucket. In this post, which is geared towards beginners, I’ll share my regular routine with Bitbucket and some thoughts on why I don't use GitHub.
Summary:
- Subscribe to the repo and review commits by other team members.
- Review my own commits and enter into daily hours log with notes.
- How to start a new feature branch (git basics).
- Check for conflicts before a merge, figure out what is going on between branches…
- Thoughts on why I don't use GitHub.
Keeping up with the team:
On any software project involving more than one committer, you need to be able to keep up with changes made by other team members. This is especially true if multiple people are working on the same branch. Yes, ideally everybody works in their own branch… but for green field projects that isn't the right way to go. I prefer to use feature branches for systems that are in production. For new work, which is often the case for client based projects, having everybody work in master forces you to deal with merge conflicts as they happen. This is really only okay for new projects when there is only a handful of team members.
When I get access to a code base, the first thing I do is make sure to subscribe to the repo. That way I get an email notification every time someone pushes a change.
It is good to read other people's code no matter what your role is. For junior developers you can probably learn something. For senior developers you can take the opportunity to fix bugs before they go out and be a mentor.
When I have a cognitive break I skim through the changes using the Bitbucket view commit screen, which shows me in color coded format what was changed, added or removed.
What I love is that I can comment on the entire commit, or a specific line if I see a problem or have a question. The git command line tool could show me what changed, but it is really clunky, and doesn't have the built in feedback system, so I never use the git command line to view changes made by others.
Tracking what I did that day:
As a freelancer / independent software developer I invoice my clients containing a line item detail of what I did each day. To help with generating that at the end of the day, I look back through my commit history and write a short summary. I suppose the git command line could do this too, but again, I prefer the visual interface here. To access it click on the repo you worked on that day and go to Commits:
I've seen other people use a clock in, clock out app, but I can't stand that. The 'review at the end of the day' strategy works well for me. If I'm super busy and forget to log my hours, I can still look back in time and piece it together.
How to start a new feature branch:
Part of my regular routine is to use the Git command line to start a new feature branch:
First, checkout the branch you want to use as the starting point, and make sure you are up to date:
git checkout master
git pullThen create the new branch locally, and push it to the remote repo establishing tracking:
git checkout -b my_new_branch
git push -u origin my_new_branchUsing Bitbucket before a merge to tell what is going on between branches:
Merging branches can be a real chore, and if you get it wrong or run into a conflict it can be very stressful. What I like to do before a merge is review the open branches under the repo's Branches screen. This gives me an overview of what is going on. Sometimes I'm just merging a branch to QA, which is pretty routine. Other times, I'm merging multiple branches to master or production for a live deploy.
From this screen I can click into the branch of interest. Bitbucket gives a summary of the diff, shows you what commits were involved, and if there is a merge conflict. Some teams use the pull request feature of Bitbucket and let it do the merge. A regular command line merge `Git merge my_new_branch` works too.
Why not use GitHub?
Today, Bitbucket vs GitHub is practically Ford vs Chevy – they are the same across many dimensions, and either would probably work for most of your needs . GitHub has an edge in community issue tracking, but Bitbucket has an advantage for business integrations with their gigantic suite of products. Here is an interesting comparison of the two.
For me, honestly, being on Bitbucket has to do with habit . Bitbucket has allowed free private repos for small teams since the beginning of time. That originally attracted me to the platform. GitHub historically wanted you to pay to get a private repo, but that changed after Microsoft bought them.
I have always liked Atlassian products because they take a business focused approach to their tools, vs a more "open source" mentality. I have never forgotten how in 2012 a developer / hacker by the handle Homakov was able to subvert GitHub to promote themselves to an admin on the Ruby on Rails project hosted there. That isn't to say Bitbucket won't someday fall prey to similar hack, but that publicity really stuck with me.
The bottom line:
Bitbucket works well for me, doesn't get in my way, and fills in the gaps in the Git command line. I have come to use it almost daily, it has been very reliable and secure.
Author bio: Laurence Gellert is a software developer living in Portland, Oregon. You can reach him on Twitter and at his software development blog.
Love sharing your technical expertise? Learn more about the Bitbucket writing program.
