Aditya Sridhar

Posted on Oct 29, 2018 • Edited on Nov 7, 2018 • Originally published at medium.freecodecamp.org

How to use git efficiently

#programming #webdev #coding #git

This 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.

Feel free to connect with me in LinkedIn or follow me in twitter.

If you liked this post, you can checkout my website https://adityasridhar.com for other similar posts

Oldest comments (55)

Dani J. Pérez • Oct 29 '18

Hey!
I think this is the best and easy to read explication of Git Workflows I read.

Thank you!!

Aditya Sridhar • Oct 29 '18

Thanks for reading the article :)

Evan BOISSONNOT • Oct 29 '18

it’s easy to ready
thank you :)

Aditya Sridhar • Oct 29 '18

thanks. Happy it is easy to read :)

Pablo de la Vega • Oct 29 '18

Nice post, thanks for sharing!

I have a question, what is the pros and cons of using forks (with branches) instead of new branches in the "upstream" repository?

Regards,
-Pablo

Aditya Sridhar • Oct 29 '18

Thanks you

Generally in open source projects you would fork the repo, make your changes and then raise a pull request to the original repo. The reason for this is that you would not have write access to the original open source repo. Unless you have write ( collaborator ) access you cannot create branches in the original repo.

What I have explained in this article in a branching strategy which can be used provided you have write access to the repo :). This is easily applicable to enterprise projects.

Pablo de la Vega • Oct 29 '18

Yes, I know that, on the company I'm working I always recommend to fork the project and then work on the forked one, the devs don't have write access to the original repo, I like to keep clean the original repo and only have the branches I (or the Technical lead) want to keep.

For me the Pros i found:

Have clean original repo (few branch)
Each Branch belong to the developer how worked on that

Cons:

Extra steps to update your local code.
You can't prevent the dev work on master or developer branch.
- Easy to brake the master/developer branch.

What do you think? you add more pros and cons?

Thanks for your time, regards.
-Pablo

Aditya Sridhar • Oct 29 '18 • Edited

Thanks for mentioning them :)

You have pretty much covered the pros and cons. Here Will list out some more as well

Pros of forking:

The dev's do not need to worry much about breaking the code by mistake Since they wont have access to the original repo

cons

as you mentioned, it can be more time consuming to update local code

But I did come across branch level permissions as well. So one thing which can be done is only the tech lead and some senior devs have write access to the master and the release branch.

All the other developers will have complete access to feature branches, but a read only access to master and release branch. This will ensure the code in master branch and release branch are reviewed and tested code

What do you think about branch level permissions instead of forking in enterprise projects?

Open source I guess forking is the way to go, Since there will be an explosion of branches if every single open source developer gets their own branch in the original repo :D

Pablo de la Vega • Oct 29 '18

Agreed with you, I'm currently thinking on what is the best approach using fork or branch access on upstream.

As you say OS project is the way to go, but I'm thinking if we will use fork or branch, due the ore junior devs have a lot of issues when they need to update the code :/

Thanks,
-Pablo

Aditya Sridhar • Oct 30 '18

Either one should be fine :)

Use the method the team is more comfortable with :)

Vlastimil Pospichal • Oct 29 '18

Where is a branch bugfix?

Aditya Sridhar • Oct 30 '18

good point. Bugfix process is important as well :)

I was evaluating whether to add bugfix in this article or to have a separate article only for that.
Thought of writing a separate article for bug fix since I wanted to cover some other things as well along with that.

You can checkout atlassian.com/git/tutorials/compar...
for the bugfix process

Lukas Klinzing • Oct 29 '18

Good post, thank you!

Generally I disagree that the reviewer should solve conflicts. I had to do that and it's the hardest thing on planet when you have not written the actual code.

Conflicts happen when two or more people work in the same sphere. They should be able to handle it. The reviewer should only review the code that works.

Aditya Sridhar • Oct 30 '18

Ideal approach is the developers resolve the conflict themselves :).

But that said, if a developer is a beginner, then they will find it hard to resolve conflicts. So in that case the tech lead can resolve the conflicts. With more experience the developer will be able to resolve the conflicts by themselves :)

Karl Krasnowsky • Nov 2 '18 • Edited

100% agree. Why should the reviewer be tasked with resolving the conflicts?

EvilKittenLord • Oct 29 '18

Just do GitFlow, GitHub Flow, or GitLab Flow. These are industry standards. If you're the edge case new project that one of these doesn't satisfy, less hear about it. :p