Let’s be honest to each other - we have all been in a situation where we had to use Git for a project, but had no idea what workflow we should apply. Whether you are working on your own, within a company or you freelance your way through different projects, a good Git workflow should be implemented.
When you want to get started with a new coding project that uses Git, most of the times you have to start off by cloning the project from GitHub. All repositories offer you an option to clone the project through SSH. You could also download the repository as a zip file, but that’s not the way to go…
Step 1: Clone Repository
A repository needs to be cloned using the
git clone command, followed with the SSH URLs.
git clone email@example.com:[USERNAME]/[REPOSITORY_NAME].git
This command will download the repository in the directory your located in inside the command line interface. Once the repository has been downloaded, make sure that you change directories into the cloned repository.
Step 2: Check commit history
If other developers have worked on the repository before, you could check the recent changes of the project using the following command.
Step 3: Create a new branch
Once you have checked the history of the most recent commits and are up to date with the project, you should create a new branch where you could work on so you don’t work on the
git checkout -b new_paginator
Step 4: Modify & Track files
Within the new branch
new_paginator, files that are related to the functionality your going to build, need to be modified. If you are done building the functionality, you should always have a final review of the code you have written.
Find the modified file, and perform a
git diff to see what changes have been made.
git diff app/Http/Controllers/PaginatorController.php
If you are satisfied with the changes you have made, you are ready to add the modified files into the staging area.
git add app/Http/Controllers/PaginatorController.php
git add command, files are staged. But, the changes need to be put into work by committing them through the
git commit -m "Add pagination to the blog overview"
Step 5: Put it into work…
The changes have been stored safely, but in order to show the work to other developers or clients, the commit needs to be pushed to the remote server. In most cases, a code review needs to be done by the senior developer, but since this is only a demonstration, we will act like that has been done…
If a senior developer approves the changes you have made, you could merge the
new_paginator branch with the main snapshot of the project, which is the
master branch. This can be done by first changing branches to the
git checkout master
Here comes the tricky part: other developers might have made changes. Therefore, you should always retrieve those changes first before committing your own changes into the master branch. This will limit the risk of conflicts, since multiple developers have made changes to the same file. To prevent conflicts, the project must be pulled from the remote server, which is called the origin.
git pull origin master
If you don’t run into conflicts, you are ready to commit your new code into the master branch using the
git merge new_paginator
Finally, the changes need to be pushed to the main server using the
That’s it, as simple as it is. I recommend you to always refer to this Git workflow mentioned above when working on functionalities that include a Git repository. This is just a little demo, so be aware of the fact that you might run into conflicts if multiple developers are working on the same file.
Do you want to learn more about Git? I have created a 45-minute Git in the command line interface tutorial for beginners.