03: Basic Git and Bitbucket Workflow

So, after dealing with Redmine it’s time to deal with Bitbucket. Workflow in my company looks like if you have done creating a task in Redmine, then it has a unique ID. When we work over a extension we take this ID from Redmine and we create a branch at Bitbucket named “task/[ID]”, to make everything transparent and easy to navigate between Redmine and Bitbucket. I won’t go deeper with creating branches, because it’s described pretty clear in Bitbucket docs and tips whenever you create a repo or branch.

Let’s talk about commiting changes in files. When we have cloned/initialized a working directory with project, what is explained pretty clear here, it’s time to work over extension. We want everything to be available the next day or even next hour if our desktop crashes.

How to commit and push changes?

First of all, thing to do after turning on the desktop is opening the terminal or command prompt and typing

git pull

It downloads all the changes to out local repo and we’re free of conflicts.

Whenever we made changes and we want to push them to the repository, we need to add the changed files, to our “buffer”. In order to do this, we need to use

git add [file_directory/file]

But, if you want to add everything you changed, go ahead and use

git add .

Where dot stands for everything recursively.

After we added everything we want, it’s time to commit it — in other words to label our “buffer” or certain changes (what we actually did change)

To do this, to label every change by one description, we can do

git commit

After typing it, strange things begin to happen. Terminal opens up a Nano for us (at least my setup), and we have some space to type. How I do this in work is:

The first line is for task, so I simply type

task #[ID]

And then there’s space for describing changes. We have adopted style convention, to mark adding file as

++ file name

Changing file as

~~ file name

And finally deleting file, as you can guess

— file name

But, as we did previously in adding file, we can label certain changes, by adding file name at the end. It’s wider described here.

After we’ve commited our changes, it’s time to push. There are two ways doing it, depending on project type. When it’s private project and every developer has the same access level, we rather just push files, but if the project has one administrator we have to make a pull request.

In the first case, all we need is

git push origin [branch]

Golden tip: You don’t have to type whole words like origin, master, development, etc. All you actually need is Tab. Try typing “ori ”and click the Tab.

In the second case we need to make our branch, then git push on it and make a pull request on GitHub/Bitbucket. It’s pretty simple when it comes to work with GitHub, because it detects new branch and changes and when we enter main branch, there’s an alert, which informs us about differences. There’s an option to make a pull request.

Now our changes are available until zombie apocalypse, but if you got a fuck up, you can revert the changes, and I’m gonna talk about it later. Next time I’m gonna show how to make work with PhpStorm enjoyable.