Aditya SridharThis post was originally published in medium.freecodecamp.org
The code was working yesterday but today it is not
The code got deleted
A weird bug has been introduced suddenly and no-one knows how
If you have been in any of the above situations then this post is for you.
Apart from knowing git add, git commit , and git push , there are a bunch of other important techniques in Git. Knowing these will help a lot in the long run. Here I will be covering some of the things which will enable you to make the best use of Git.
Git workflows
Whenever multiple developers are involved in a project it is necessary to use the right workflow for Git. Here I will be covering one workflow which is very effective in big projects with multiple developers.
Scenario
All of a sudden you have become the tech lead for a project in which you are planning to build the next Facebook. The team has three developers:
Alice: has one year of experience and knows programming
Bob: has one year of experience and knows programming
John: has 3 years of experience and knows programming well
You: assigned as tech lead for this project
Development process in Git
Master branch
The Master Branch should always have a copy of the existing code in Production.
No-one — including the tech lead — should be coding directly in the master branch since it is a copy of production code.
The actual code is written in other branches.
Release branch
When the project begins the first thing to do is to create a release branch for the project. The release branch is created from the master branch.
All code pertaining to this project will be in the release branch. The release branch is just a normal branch with the prefix release/.
Let’s call the release branch for this example release/fb.
It’s possible that there are multiple projects running on the same code base. So, for each project, a separate release branch is created. Let’s say there is one more project running in parallel. Then that project can have a separate release branch like release/messenger
The reason to have a release branch is that the same code base can have multiple projects running in parallel — there should be no conflict between the projects.
Feature branch
For every feature that is built in the application a separate feature branch is created. This ensures that the features can be built independently
Feature branch is just like any other branch but with the prefix feature/
Now you, being the tech lead, have asked Alice to build a login screen for Facebook. So she creates a new feature branch for this. Lets call the feature branch feature/login. Alice would write the entire login code only in this feature branch.
The feature branch is generally created from the release branch
Bob has been tasked with building the “Friend” request page. So Bob creates a feature branch called feature/friendrequest
John’s task is to build the news feed. So John creates a feature branch called feature/newsfeed
All of the developers code in their individual feature branches. So far so good 😃
Now, let’s say that Alice finished her task and the login code is ready. She needs to send her code to the release branch release/fb from her feature branch feature/login. This is done through a pull request.
Pull request
First and foremost, a pull request is not to be confused with git pull .
The developer cannot push the code directly into the release branch. The tech lead needs to review the feature code before it goes into the release branch. This is done through a pull request.
Alice can raise the pull request as follows in GitHub — these steps are specifically for GitHub.
Right next to the branch name there is an option called “New pull request”. Clicking on this opens a new screen shown below:
Here:
the compare branch should be Alice’s feature branch feature/login
the base branch should be the release branch release/fb.
Once this is done, Alice needs to enter a title and description for the pull request, and finally click on “Create Pull Request”. Alice also needs to assign a reviewer for this pull request. She enters your name as the reviewer since you are the tech lead.
The tech lead then reviews the code in the pull request, and merges the code from the feature branch into the release branch
So now you have merged the code from the feature/login branch tothe release/fb branch and Alice is pretty happy that her code has been merged. 😃
Code Conflicts 😠
Bob has completed his code as well, and has raised a pull request from feature/friendrequest to release/fb.
Since the release branch already has the login code, code conflicts occur. It is the responsibility of the reviewer to resolve these code conflicts and merge the code. In this case, you as the tech lead need to resolve these code conflicts and merge the code.
Now John has also completed his code and wants to add his code to the release branch. But John is pretty good at handling code conflicts. John takes the Latest code from release/fb branch into his own feature branch feature/newsfeed ( either through git pull or git merge ). John resolves all the conflicts that are present. Now the feature/newsfeed branch has all the code present in release/fb as well.
Finally, John raises a pull request. This time there are no code conflicts in the pull request since John has already resolved them.
So there are two ways to resolve code conflicts:
- First method: the reviewer of the pull request needs to resolve the code conflicts.
- Second method: the developer ensures that latest code from the release branch is merged into the feature branch and resolves the conflicts themselves.
In Enterprise projects beginner developers can initially start with First Method and eventually move to the second method. Second method is the preferred method
Master branch again
Once the project is completed, the code from the release branch is merged back into the master branch. The code is then deployed to production. Thus, the code in production and the code in the master branch are always in sync. This also ensures that, for any future project, the up-to-date code is available in master.
References
More information about pull requests is here.
Congrats 😄
You now know about git workflows. Git has some other concepts like amending commits, and rebasing which are also useful. But Git workflow is pretty important for big projects to be successful.
For small projects this workflow can seem to be like an overhead. So other alternatives can be used in small projects.
