In this post, I will show you a few basic git commands that I use every day.
When using Bitbucket to create a new branch, you have two options to get started with the command line:
- I have an existing project
- I’m starting from scratch
I usually use the first option, because I already have developed something locally and I’m looking to commit my code into bitbucket. They only show you there two commands to get started with, but I always get an annoying error every time I try to follow their commands.
error: src refspec master does not match any. error: failed to push some refs to '...'
Remember to read the Git documentation to better understand what commands you should use and why: https://git-scm.com/doc
To avoid the following error follow the steps below:
- Do a ‘git init’ in your project directory.
- Do ‘git remote add origin https://…’ (copy command from bitbucket)
- Do ‘git add .’ adds all the content in your directory to a stage where they’ll be ready for the next commit.
- Do ‘git commit -m “Add your message here.” ‘ this will commit the files you just added.
- git commit
- Do ‘git push –set-upstream origin master’ to push your commit into the master branch in bitbucket.
Your files are now committed to the master branch of your project, in bitbucket. This solved the error above. Optionally, follow the next steps to make sure your files have been committed and you check out your development branch.
As a developer, when working for a production system or any project in general, you should follow the Git Work Flow. Please read more details about it here.
The general rules are:
- master branch is for the production system (only work that has been tested and is ready to be deployed should be committed)
- all the work should go into another branch, usually called ‘develop’ (develop should include tested new features, that are not ready to be deployed yet)
- developers should work using feature branches; a new feature branch should be created for every new change/feature developed. When created, this feature branch should check out a copy of develop, not master branch. The feature branch should be committed back to the develop branch once is done. This offers more traceability within the project
- every code change of the main branches (develop, master) should not be merged until a pull request has been approved by the team members
- only when the develop branch is building correctly and it has been tested it can be merged into the master branch.
- Do ‘git status’ to check the status of your files.
- Do ‘git branch’ to check how many branches are available.
- Go to bitbucket and create a new branch.
- Do ‘git fetch && git checkout develop’ . This will do a ‘refresh’, see what’s new and will then check out the develop branch.
You should now be able to see that develop is the branch you are working into, instead of master:
In conclusion, using Git is really easy, you just need to read the documentation and understand what commands you need to use. The commands above are the ones most developers use on a daily basis. Remember to commit as much as possible or at least once a day, when you finished developing stuff.