How I Use Bitbucket In My Regular Routine
Here is how, and why, one developers integrates Atlassian Bitbucket into his flow for version control.
Join the DZone community and get the full member experience.Join For Free
I’m an independent software developer, and I use Bitbucket for all my client projects. It works reliably and has a sense of "business software" I like. I mostly 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.
You may also enjoy: Source Control Using Atlassian Bitbucket
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 greenfield 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 codebase, 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, check out the branch you want to use as the starting point, and make sure you are up to date:
git checkout master git pull
Then 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_branch
Using 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, as opposed to 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.
Published at DZone with permission of Laurence Gellert. See the original article here.
Opinions expressed by DZone contributors are their own.