Git is an Open Source version control system (VCS). Developed by Mr. Linux himself to improve the workflow of managing code while collaborating as a team.
You will need:
- An example project
- Git installed on your machine
Installing git is pretty easy, use this link for an installation guide.
The Git structure
We got three areas
- Working directory
- Staging area
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:
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:
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.
- How to create a project on Gitlab
- How to create a repository on Github
- How to create a repository on Bitbucket
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.
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.
- For a new feature branch I use:
- For a new enhancement I use:
For quick bugfixes, I use
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.
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.
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.
- Create a Git repository
- Create an online repository
- Connect the local Git repo with the online repo by using remotes
- Checkout all existing files in the master branch
- Create and switch to the development branch
- Push all changes online
You are ready to use your Git repository, now let's introduce a new feature.
- Create a new branch using the feature prefix
- Add some changes to the staging area
ContinueOhoh! A quick bugfix is needed!
- Checkout back to development branch
- Create a new branch with the hotfix prefix
- Commit the changes of the fix
- Merge with the development branch
- Check back into your feature's branch
- Commit changes to the feature branch
- Checkout to development and merge the feature
- 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!