Do we really need to branch in Git?

Question

I'm in my first software engineering class. It's the first time any of us has worked in a team and used git and github. In class our teacher told us that you should usually branch off the master, after you finish your new feature, merge it back to the master. This is what I've been doing. However the other members of my group are not branching. They pull from the master on github to their local machine, make edits, finish their feature on their local master, then push to the master on github.

I'm trying to convince them to branch but now that I think about it, i find it more confusing. I've been told that the purpose of the branch is to make a copy of the code and not worry about ruining the master by accidentally putting unrunnable code.

But isn't their local master really just like a branch itself? As they are making edits, they aren't changing the master on github, so others are free to pull working code from github. Then they merge, similar to a branch.

I'm confused, why should we branch if what they are doing seems to be working?

Thanks!

Answer 1

But isn't their local master really just like a branch itself?

Yes it is!

I'm confused, why should we branch if what they are doing seems to be working?

This depends on your workflow. What you seem to be describing is this workflow:

Alice makes a branch alice that tracks master and Bob makes a bob branch that also tracks master. Alice always commits to alice and Bob always commits to bob. Then when they are happy with their changes they merge into master.

Of course, there is hardly any difference from this and from Alice and Bob working on their local master branches!

The problem often comes in when the same person is working on multiple features at the same time. For example

Alice is working on Feature A and Bob is working on Feature B. Alice is halfway done with Feature A and has made a few commits in alice. However, Feature A is quite hard to implement so Alice decides that she should rather work on Feature C and makes a few commits onto alice. Bob finished Feature B and decides that he would like to tackle Feature A and so pulls alice into bob.

After Bob finishes Feature A he would like to merge bob into master. However, bob now contains Feature A, Feature B and parts of Feature C, but Feature C is not ready to be merged! It's easy to see that a workflow like this can lead to many confusing merge conflicts.

The trick is that instead of having personal branches one should have feature branches. Alice should have a branch for Feature A and Feature C and Bob should have a branch for Feature B and Feature A. That way they both can work on different features without tramping on each other's toes.

Answer 2

The idea is that you have a master branch where the code is stable and merged.

Let's say that I have an application that scrapes a website.

I will create a new branch called develop/pulldata. In this branch, I will work on pulling the data. One of my team members could work on applying some logic on the data, so he can create his own branch develop/applylogic.

Once he has a few commits and his code is stable, he can open a pull request to merge his code to master, which you can view in the github UI, to see what code he has changed and decide whether or not you want to merge, or if any changes are required.

Now, after a while, my code is done, I open a pull request to master, so my colleagues can view my code and approve or suggest changes. It's easy to view and everybody in the team knows that master branch is stable. However, other branches do not have to be. They have to be when they are merged to master.