DEV Community

Cover image for How to use git efficiently

How to use git efficiently

Aditya Sridhar on October 29, 2018

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 ...
Collapse
 
theluk profile image
Lukas Klinzing

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.

Collapse
 
adityasridhar profile image
Aditya Sridhar

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 :)

Collapse
 
karlkras profile image
Karl Krasnowsky • Edited

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

Collapse
 
melezhik profile image
Alexey Melezhik

I'd not say that GitFlow has real advantages for me, the thing is you might end up with a lot of branch merging which is a real chore and always delays the speed of the development. In practice there is lot more merges b/w branches back and forth if one follow a git flow based approach.

You might consider trunk based development as an alternative.

Collapse
 
rbukovansky profile image
Richard Bukovansky

But the trunk based development doesn't allow me to manage what goes to release, you take what's in trunk branch and create a release from it (few of our product managers just fainted), you never know if your trunk is stable etc.

Merging between branches with git-flow is a chore if you let it be a chore (there are few git-flow scripts/tools that help with it).

Collapse
 
adityasridhar profile image
Aditya Sridhar • Edited

Till now haven't faced any issues with gitflow workflow. But in case issues do come will look into implementing something like trunk based development :)

Collapse
 
melezhik profile image
Alexey Melezhik • Edited

yeah. just a few questions:

  • how often you make prod releases? ( daily, weekly, few times a month or less frequent )
  • what is a frequency of commits? ( say per day )
  • average size of developers team? ( per one project )
  • if you have a hotfixes ( urgent bugs ) how do you deal with them in terms of SCM flow ... ?
Thread Thread
 
adityasridhar profile image
Aditya Sridhar • Edited
  • A monthly release

  • Maybe 10 to 20 commits a day max by all devs combined :D.

  • Varies. 4 to 8 depending on the requirement.

  • Current approach is to create a hotfix branch directly from master and make the change for high priority bugs. Low priority ones are generally pushed to the next release

There are situations where the codebase is shared between multiple projects and teams. That's one of the reason this approach worked well till now.

Thread Thread
 
melezhik profile image
Alexey Melezhik • Edited

Current approach is to create a hotfix branch directly from master and make the change for high priority bugs. Low priority ones are generally pushed to the next release

Ok. You did not say here. Do you propagate hotfix commits back to dev and release branches ?

Do you make production release immediately once new release branch is created? Do you continue to merge from dev to release after a new release branch is created?

There are situations where the codebase is shared between multiple projects and teams. That's one of the reason this approach worked well till now.

not sure, what you mean. please specify ...

Thread Thread
 
rbukovansky profile image
Richard Bukovansky • Edited

Git-flow:

1) The hotfix branches are cut from master branch and merged back to master and then to develop branch.

2) You do production release when the hotfix branch from 1) is merged back to master.

3) You don't merge develop branch once you cut release branch from it. This release branch is then just for fixes devs create against it directly or with PRs. Release branch in git-flow is used to QA testing and resolving bugs they find to stabilize that release. When it's signed off then it's merged to master and followed by merge to develop.

Thread Thread
 
melezhik profile image
Alexey Melezhik • Edited

Hi Richard. I am replying here to both of your comments. All it boils down to the fact that gitflow is hard to maintain. You have many branches that you have to merge back and forth in right order. It's not immediately seen on simple projects but it becomes painful as soon as frequency of releases and quantity of projects piles up. There is more about this here - endoflineblog.com/gitflow-consider...

In trunk based development there is one main branch ( I am not talking here about short leaving features branches and release / hotfix branches that also exist, anyway ... ) which radically simplifies and increasers the speed of development cycle. And trunk branch is always stable, you can read more about this on the mentioned site or other resources.

Yeah TBD has some tradeoffs but they are incomparable with disadvantages introduced by gitflow.

Thread Thread
 
rbukovansky profile image
Richard Bukovansky

Sorry, but what is hard on following commands to create a release branch and then close it?

gitflow release start "2.10.1"
gitflow release end "2.10.1"

Similar for hotfix branch:

gitflow hotfix start "2.10.1.1"
gitflow hotfix end "2.10.1.1"

Similar for creating short-lived feature or bugfix branch:

gitflow feature start "feat/new-login-page"
gitflow feature end "feat/new-login-page"

Sure, it's one of my scripts that does all the hard work, but I don't need to think about merging...

Sorry again, but people who do write off git-flow because they think it's complicated, they simply don't understand its beauty, sophistication, and advantages. And when you combine it with GitHub Flow (Fork&Pull Request), it can't simply be beaten.

And believe me, with TBD you get your trunk/master messy and unstable if anybody can merge there, I tried implementing that many times.
And I ask you again: How do you manage what goes to release when everybody is merging to one branch whatever and whenever they decide?

Thread Thread
 
melezhik profile image
Alexey Melezhik • Edited

Well, the shortcuts you have here is just smallest and easiest part of the workflow, the hardest part is merge branches not creating them. In classical git flow https://jeffkreeftmeijer.com/git-flow/git-flow.png you have 5 types of branches you have to merge and create in specific order and in specific times. If you don't follow the rules strictly you end up with the mess.

While it's probably easy to follow gitflow with small projects and low frequency of releases, it is way too harder to keep this approach with frequent releases and large code base. This is why companies with large code base and frequent releases like Google practice kinda TDB methodologies ( with variations ) instead of gitflow.

And believe me, with TBD you get your trunk/master messy and unstable if anybody can merge there, I tried implementing that many times.

It's not true. Pull requests / Code Reviews are still here to fence main code from junior developers direct commits ( though you might not need this with mature teams, anyway )
Also if a build is broken - it's ok, but you have to stop all the current development and make a fix OR rollback - it's what all the pretty textbook stuff devops methodologies teach us. There is no problem with broken build, there is a problem with recklessness about it. Add here automatic tests triggered by CI/CD, pre commits / push hooks tests and you will get even more layer of confidence ...

And last thing:

Sure, it's one of my scripts that does all the hard work, but I don't need to think about merging...

Actually you do, but not about technical aspects of merging, but about WHAT you merge, even the fact you have no conflicts or resolved ones does not mean the resulted code is right. Don't get me wrong I am not against merging, but merging is still hard ( not technically but logically ), TBD tries to avoid a lot of merging while gitflow upholds.

And I ask you again: How do you manage what goes to release when everybody is merging to one branch whatever and whenever they decide?

The same as with gitflow. At some point you cut off from main branch and create release one.

Collapse
 
havarem profile image
André Jacques

Pretty good. I have one question about a project with multiple version alive (like apache 2.0.x, 2.2.x and 2.4.x) that are developed concurrently.

  • I have the master branch that holds the latest stable version.
  • I have RC branches (or staging) for debug and delivery.
  • I have hot-fix branch that by-pass directly from master.
  • I have my dev branch with all the stories that has been completed with unit test passing (usually) and
  • feature and bug-fix branches.

What strategy should be implemented in a case like Apache HTTPd server, where 3 main versions are maintained? Should we use 3 different repositories, or should we have three master branch (master20, master22 and master24 for exemple?). Is there other options?

Collapse
 
adityasridhar profile image
Aditya Sridhar • Edited

Interesting question.

Never worked on any project with multiple active versions.

I am guessing if the development is concurrent on all the versions, and if the versions have different features then its better to have separate repos for them like angularjs and angular.

Again, never worked on projects with multiple active version. It's better if someone who has actually worked on this answers :D

Collapse
 
rbukovansky profile image
Richard Bukovansky • Edited

Well, 3 repos if you don't trust your developers they will create their feature/bugfix branches from correct develop branch, and code lieutenants responsible for accepting PRs or merging from and to correct branches.

Otherwise with git-flow and if you develop new features to all those releases, you will need to have 6 branches (master2_0 => develop2_0, master2_2 => develop2_2, master2_4 => develop2_4). Actually, if you want develop new "main" version, you will end up with 8 branches, with additional branches like master-next and develop-next, where you develop new features which are going to next main release, like 2.6.

If you just maintaining those master2_2 and master2_4 branches for security fixes, you should be OK with just master2_2 and master2_4 without develop2_2 and develop2_4 branches and with classic git-flow hotfix branches.

Collapse
 
havarem profile image
André Jacques

That was basically my concern with one repo, it felt really troublesome for not many advantages. It seems for me that 3 repos are the way to go. The repo is cleaner, less confusing.

Collapse
 
agevaled profile image
Pablo de la Vega

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

Collapse
 
adityasridhar profile image
Aditya Sridhar

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.

Collapse
 
agevaled profile image
Pablo de la Vega

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

Thread Thread
 
adityasridhar profile image
Aditya Sridhar • 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

Thread Thread
 
agevaled profile image
Pablo de la Vega

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

Thread Thread
 
adityasridhar profile image
Aditya Sridhar

Either one should be fine :)

Use the method the team is more comfortable with :)

Collapse
 
rbukovansky profile image
Richard Bukovansky

Sorry, but this "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." is fundamentally wrong and that's not how Pull Requests work.

Before any Pull Request can be merged it has to have resolved any conflict with code in target branch (I believe GitHub wouldn't allow merge before the conflicts are resolved). And that is PR author's, no matter if begginer or senior, responsibility. This has been workflow for Linus, for GitHub and its clones, actually everybody for years.

Collapse
 
adityasridhar profile image
Aditya Sridhar

What you are saying is absolutely right for open source projects :)

But in enterprise projects, in case the developer is a beginner , it is better if the tech lead resolves the conflicts. Over time with experience the developer would learn how to resolve conflicts.

I guess i haven't mentioned that clearly in the post. Thanks for pointing out. Will make that more clear in the article

Collapse
 
rbukovansky profile image
Richard Bukovansky

What I have written is valid for both, open-source or enterprise...

If you developer is a beginner, he can ask somebody to help him with resolving of conflict which is anyway on his branch, not on develop branch. If the TechLead will always resolve those conflicts, those kids will never learn how to do that and would always dump that conflict on Tech Lead. Bad idea...

Thread Thread
 
adityasridhar profile image
Aditya Sridhar

That is a valid point :)

Maybe the right way of putting it in the article would be "The Tech lead can resolve the conflicts in case the deadlines are tight. But best practise is to ensure beginner devs take the help of someone to resolve conflicts so that they learn the process as well"

Collapse
 
evanboissonnot profile image
Evan BOISSONNOT

it’s easy to ready
thank you :)

Collapse
 
adityasridhar profile image
Aditya Sridhar

thanks. Happy it is easy to read :)

Collapse
 
coolman1011 profile image
CooLmAn1011

Nice post!
But i do hv a questions on feature -> release
in one of my new project
i expect some features will only be POC and may never implement into production
but user still want to test it first
my current approach is to create a develop branch which act as a UAT environment for user to test out features if feasible or not and only merge into release if they feel good about it
is it a good approach or not?

Thanks!

Collapse
 
adityasridhar profile image
Aditya Sridhar • Edited

I Have been in similar situations :D

I did exactly what you have mentioned.

The only catch is that it works very well for independent features. But if you have dependent features then we had to deal with it by manually changing the code. Still figuring out the best way of handling this

Collapse
 
coolman1011 profile image
CooLmAn1011

actually i think there may be a issue..
variation of develop and release will become greater and greater
and at some point, we may be forced to merge release into develop
just to get things a bit easier to work with..

hv any ideas about it?
maybe rebase can do the trick? but im not familiar with it

Thread Thread
 
adityasridhar profile image
Aditya Sridhar

Rebase is generally used to update the code in local with the latest code in remote. Using Rebase in the remote can create issues since it overwrites history.

I have written about rebase as well. You can check it out here
adityasridhar.com/posts/how-to-bec...

I guess one option is to handle it in the code itself rather than trying it with git. You can have a config to say which features to enable and disable.

So when users say they don't want a feature, you just go to the code config and disable it. In the future, they may want the feature back. In that case go to the config and enable it :D

I think having a config like that makes it easier than handling it with git. What is your take on this?

Thread Thread
 
coolman1011 profile image
CooLmAn1011

omg😲
using config file is a brilliant idea!
why i hvnt thought of this before!

i know rebase will overwrite the history, maybe i will just stick to local rebase first

Thank you!😘

Collapse
 
benenewton profile image
Ben Newton

One more thing I’d add is make sure the expected git flow is documented. I’ve found that devs will have their own ideas on branching and before you know it you have 3 different naming schemes going for branches. You can explain it once, but they will forget or go back to their way after a long weekend. Great article!

Collapse
 
karlkras profile image
Karl Krasnowsky

Document? What's that?

Collapse
 
adityasridhar profile image
Aditya Sridhar

Good point. Yes it needs to be documented :)

Collapse
 
jnareb profile image
Jakub Narębski

There is another method for developer to resolve conflicts, namely rebase his or her changes on top of the current state of main line of development (with interactive rebase the developer would also be able to clean up history to make for easier review). When doing a pull request from rebased branch, it should be able to be merged cleanly.

Collapse
 
adityasridhar profile image
Aditya Sridhar • Edited

Yup. I Have written about rebase in this article
adityasridhar.com/posts/how-to-bec...

Will soon post it in dev.to as well

Collapse
 
guerreroandres profile image
Andres Guerrero

Thanks for this outstanding article.

Actually, in my current company we're implementing Git workflow and it is a good material to my coworkers.

Regards from Ecuador

Collapse
 
adityasridhar profile image
Aditya Sridhar

Happy it helps :)

Collapse
 
bharris profile image
Benjamin Harris

I'd caution against using / in your branch names. It can cause conflicts with existing files and branches.

coderwall.com/p/qkofma/a-caution-a...

Collapse
 
adityasridhar profile image
Aditya Sridhar

Thanks for sharing :)

Collapse
 
vlasales profile image
Vlastimil Pospichal

Where is a branch bugfix?

Collapse
 
adityasridhar profile image
Aditya Sridhar

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

Collapse
 
djdany01 profile image
Dani J. Pérez

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

Thank you!!

Collapse
 
adityasridhar profile image
Aditya Sridhar

Thanks for reading the article :)

Collapse
 
tinsoldier6 profile image
Jason Gade

This was a very clear description of git workflow, thanks!

Collapse
 
adityasridhar profile image
Aditya Sridhar

Thank you

Collapse
 
evilkittenlord profile image
EvilKittenLord

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

Collapse
 
adityasridhar profile image
Aditya Sridhar

This is a slightly changed version of gitflow workflow
atlassian.com/git/tutorials/compar...

Had to make some changes to meet the needs when we worked on projects:D

But yes the ones you mentioned are the industry standards

Collapse
 
adityasridhar profile image
Aditya Sridhar

Agreed :D

That will make things more easier to follow

Collapse
 
kozkondev profile image
Konstantin Kožokar

Fun fact: Main photo of this article has been taken in subway Rajská Zahrada - Prague