Git Branching; the basics.
Git isn’t as complex as it seems; once you get the hang of it. But it can be daunting, I admit to that. So let me explain the basics to you, so you too can jump in and use Git in a team.
First rule of Git-club is:
Never work on
master; always use a branch to work on features and issues.
Why this matters? Because
master is your holy grail, your production.
Second rule of Git-club is:
Commit messages matter - a lot. This is so you know what happened and especially when. It allows you to roll back a commit if needed.
Learning both rules the hard way is how I came to see their importance. It caused me a lot of headache, so I’ll try to spare you the same. I will assume you’ve already set up your Git configuration, and that you’ve cloned your local repository or initialized it and pushed it to remote. If this isn’t the case; you can find out how to do that here.
Because branching effectively creates a copy of your local version of
master, it’s best to make sure your local copy is up-to-date.
Make sure you’re on
git checkout master
Get the most recent version of
git fetch git merge
You can do this in one go as well.
Creating your branch and switching to it. In this step you only create a local branch, you haven’t pushed it to remote yet.
git branch descriptive_branchname git checkout descriptive_branchname
Shorthand for this step is:
git checkout -b descriptive_branchname
Making your changes to your local new branch, adding them to the staging area - that’s how we call it when you prepare your files to be committed.
Adding 2 files
git add yourfile1 yourfile2
Add just one file
git add onefile
Add all changes in one go (Not recommended, makes future references harder.)
git add .
Creating a commit, adding a description to what happened in the changes files. The
-mswitch allows you to enter a message in-line. It’s fast and easy; if you do a commit without
-myour text editor will open for the message to be entered there.
git commit -m 'A description of what changed.'
Finally; adding our local new branch to the remote.
git push --set-upstream origin descriptive_branchname
Note: This step lets Git know where your local branch is on the remote; next pushes you no longer need to add the
--set-upstream. It is also possible to configure your local Git installation to do this for you every time.
git config --global push.default upstream
A shorter version of this is:
git push -u origin descriptive_branchname
At this point, you can happily work on your changes, do some bug fixing. Just remember to commit often, a push isn’t needed every single time. Every time you push to your branch, you’ll be prompted by Gitlab to create a merge request. It looks like this:
... remote: To create a merge request for descriptive_branchname, visit: remote: https://gitlab.com/projectname/merge_requests/new?merge_request%5Bsource_branch%5D=descriptive_branchname
It is possible to raise a merge request from the command line as well; by using push options. To find out more, visit the relevant page over at Gitlab
Once you’ve completed working in your branch and you’re ready to merge it into
master, go on and raise a Merge Request. You can opt to do it via the provided link or using push options as I’ve said.
There; that’s all there is to it. Working with Git for version control has some immense benefits and I wouldn’t want to work without having it in place.