Why?
When collaborating as part of a team, you can avoid a lot of confusion by using a Git workflow that you can repeat every day.
Git Workflow
The stages for a good workflow with Git are the following:
- track master
- create a feature branch
- add your changes
- commit your changes
- add more changes
- push the feature branch
- create a pull request
- get all changes
- merge all the changes from master
- select final commit
- update remote branch
- merge pull request
- remove feature branch
Let’s see how it’s done step by step.
Track Master
First thing we want to do is create our feature branch out of master, because we want to start with the latest+working changes.
git checkout master
Now we are on master.
Create a Feature Branch
Suppose we will add a new feature to our app, so lets create a feature branch which will contain the changes for our feature.
git checkout -b add-user-registration
We have created a brand new branch called “add-user-registration”
Add your Changes
Proceed to add/update/delete files in your app, just as an example:
touch registration.html
This command will create an empty registration HTML file.
Commit your Changes
Here is where we save our progress, we will commit our changes now.
git commit -m "Add user registration"
The commit message should be as short as possible, so it’s easy to read by the people who is going to review the pull request later on.
What if I Have to Take a Break?
It’s 5 PM and you have added a new change to the app, say you created a new HTML file so users know how to register in the app BUT you have not finished with this new file because you are missing some details:
touch how-to-register.html
We have added a new file, let’s commit this changes too.
git commit -m "WIP: how to register"
Notice we added “WIP” which stands for “Work in progress”, so our team knows we are still working on this feature branch.
Push the Feature Branch
git push origin add-user-registration
This will make your changes visible in your remote.
Create a Pull Request
So visit the Github repo and click the tab “Pull requests”, then click “New pull request”, then select one option from the left dropdown (target) and select one option from the right dropdown (source), then click “Create pull request”.
Note: For the target option, try to always select the “develop” branch (if available). The develop branch is meant to be for experimental changes, so it’s higly recommended to use it for new features like the one we are working on in this tutorial.
NOTE: I’m using Github, but this is very similar for other platforms.
Get all Changes
So, it’s the next day and we continue working on the same feature branch, remember?
Say our team has been adding changes into master but our feature branch does not have them because we were sleeping.
Let’s update our feature branch with the latest master changes.
git fetch
Git fetch will simply get all the changes from the remote repository (Github in this case). Note that it will not alter our branch in any way.
Merge all the Changes from Master
But git fetch is not enough to merge this changes into our feature branch, so let’s merge the changes we just fetched.
git rebase -i origin/master
This puts all the master branch commits before our feature branch commits so our feature branch commits are last. The following diagrams explain this better:
Before git rebase:
* - add-user-registration
* - *
* - master
After git rebase:
* - * - * - master - * - add-user-registration
Note: The -i option will open an interactive session, but let’s see that in the next section.
Select Final Commit
So in our pull request we don’t want to see two commits, we just want to see one because it’s easy to search in the repository history.
The interactive session is still open and we want to combine all the commits into one. Here is what it should look like:
``` pick e414s79 Add user registration s a767u81 WIP: how to register
… ```
At this point you can also change the commit message. As we have added multiple changes, it is generally a good idea to change it to something more descriptive and accurate.
Note: The pick option will indicate that we want to select that commit as our final commit, and the s option indicate that we want to append the changes from the commit (a767u81) to the selected commit (e414s79).
Note: These commits IDs are not going to be the same for you, since this IDs are different for each repository.
Update Remote Branch
Now that we have merged the changes into our feature branch, it’s time to update the remote branch.
git push origin add-user-registration -f
Notice we use the -f option since we want to force push the branch. The reason behind this it’s because we have changed the Git history (by using rebase).
Team Review Pull Request
Merge Pull Request
From your pull request page on Github, once it’s reviewed by your team you can click “Merge pull request”.
Remove Feature Branch
From your pull request page on Github, once it’s merged, you can remove the remote branch from there by clicking “Delete branch”. It’s a good practice to remove merged branches. You don’t need to worry about it because this changes has been merged already and it does not makes sense to keep it.
You should also remove your branch locally:
git branch -D add-user-registration
Final Thoughts
That’s it! You have learned how professional teams manage their version control in a daily basis using Git.
While every company has their own unique approach, in most cases it is very similar to this one. The details should be part of every project wiki since it makes it easier to onboard new team members.
