Git setup and workflow

You will need:

Installing git is pretty easy, use this link for an installation guide.

The Git structure

We got three areas

I will show you how to go from one area to the other.

Setup Git for an existing project

Setting up git for an existing project is fairly simple.

To start using git you need to create a new git repository by executing the following command in your projects root folder: git init This will set up a Git repository, you can see in your directory you created a .git folder. By executing this command you are now also in the working directory.

If you’re starting a new project, make a change by creating a new file. If you have an existing project you won’t need to do this.

To view the current status of your repository using the following command: git status

Let’s add some files to our staging area! Once you executed the git status command you’ll see which files were created/changed.

Add a file name index.html to your staging are: git add index.html

Revisiting your Git status, you’ll see you now added index.html to your staging area. Ignore the other changes, for now, we’ll get back to those later!

As you are now in the staging area you can choose to add more files or commit these changes to your repository. A commit is created with this command: git commit -m "Adding index.html changes" The message between quotes can be anything, but you should make sure it’s clear what has changed.

Great! You’ve successfully looped through your first Git cycle.

Still, have other changes, but don’t want to add them one by one? git add . && git commit -m "Add multiple changes"This will add all changed files to the staging area and will commit them to the repository.

Add a Git remote

Before adding a git remote, you have to get yourself an account on Github, Gitlab, Bitbucket or any other Git repository hosting platform.

To let Git know who you are you will need to set up your name and email.

git config --global user.name "John Doe"
git config --global user.email [email protected]

I usually use Gitlab, but once you’re back in Git it’s all the same. So you’ll have to create an online repository.

Once your repository has been created you’ll get some good instructions on how to use it, but let’s start by adding this online repository to our local Git setup.

git remote add origin <repo-url>

You can find this URL to the repository on your platform.

The better but simple Git workflow

I tested several workflows in Git but I found the one I’m going to describe the easiest to use without sacrificing its usefulness.

Using branches

I use branches all the time, the first time you set up your repository you’re on the master branch. The master branch represents a working version, without bugs of your application.

Creating a new branch

git checkout -b <branch-name>

I tend to leave the master branch asap, and I create a development branch straight afterward.

git checkout -b development

You start working on a feature or enhancement?

For every task, I create a new branch, this way it’s really easy to switch back to the development branch if needed.

git checkout development to return to the development branch.

Branch naming is in practice very useful, especially when you’re working with multiple developers.

Easy, right?

For quick bugfixes, I use hotfix/<name-of-hotfix>

Done with your change?

Once you’re done with your changes you’re ready to merge your code with the development branch. Make sure you committed all your changes in the current branch before switching to development.

git checkout development to switch back to the development branch.

Merging is a big part of using Git, and quite magical at the same time.

Git will detect changes between branches and add those to your development branch.

git merge feature/<name-of-feature>

Usually, this will all go to plan without any merging issues, but if you’re working between multiple branches and the development branch has changed since you created your new branch you will have merge conflicts.

Don’t worry!

Merge conflicts are normal, Git does not know whether the development code is the correct version or if your new branches are.

This is the only point where the developer has to step in and help Git.

Using git status, Git will tell you where you have these merge conflicts.

Visiting the file where you have these merge conflicts Git added some comments on the position of the conflict looking like this:

If you have questions, please
<<<<<<< HEAD
open an issue
=======
ask your question in IRC.
>>>>>>> branch-a

The HEAD is the correct working directory, directly underneath it is the content of this version and it stops right at the =====.

This is where the content starts of your new branch ended by >>>>>>>.

Remove all of those comments and leave the right version of the code there.

Don’t forget to add these changes by using git add . && git commit -m "Solve merge conflicts"

Pushing your code online

To store your local code online you should push your code to your online repository platform (Git, ..)

git push origin <local-branch-name> (where origin is the remote name)

In case of the master and development branch, it’s easier to let Git know to push to this origin by default.

git push -u origin master, this will set the upstream of the master branch to origin by default. Using git push will now default into pushing the code online.

Pulling your code from online

It can happen that your code has changed online by a colleague, meaning your local Git repository is no longer up-to-date.

git pull origin development will fetch the online changes and tries to merge with your local version. There might be merge conflicts here, but it’s the same process as before.

You code will now be up-to-date, this is important as you won’t be able to push any new code without pulling the latest version.

Streamline your workflow

Now you know all the basics of Git, let’s summarize my workflow.

  1. Create a Git repository
  2. Create an online repository
  3. Connect the local Git repo with the online repo by using remotes
  4. Checkout all existing files in the master branch
  5. Create and switch to the development branch
  6. Push all changes online

You are ready to use your Git repository, now let’s introduce a new feature.

  1. Create a new branch using the feature prefix
  2. Add some changes to the staging area
  3. Continue Ohoh! A quick bugfix is needed!
  4. Checkout back to development branch
  5. Create a new branch with the hotfix prefix
  6. Commit the changes of the fix
  7. Merge with the development branch
  8. Check back into your feature’s branch
  9. Commit changes to the feature branch
  10. Checkout to development and merge the feature
  11. In case of conflicts, solve the merge conflicts

Your application looking good? Time to merge it with the master branch!

I hope this guide will help you with setting up Git and streamline our workflow, in case you have any questions feel free to comment below!