We have a discussion in our group regarding the practice of opening a new branch per each feature.
There are some voices who think that it is a bit redundant. They suggest we can work on the same branch and push changes to it whenever required. Anyways, they say, we'll be facing merging issues when trying to push.
I think we should open a feature branch per feature. What do you think?
(If this is not the place for this kind of question, please tell me where it does fit)
Thanks!
Whenever you ask any question of the form: "is A different from B", you'd better have some precise definitions of exactly what A and B are.
Unfortunately, the definition of branch in Git is (deliberately) fuzzy. I'll bet you and your co-workers all have slightly different personal definitions. They're probably all wrong too. More seriously, they probably agree on some things and not on others and there are multiple reasonable definitions. See also What exactly do we mean by "branch"?
Git is distributed, so everyone will have their own clone of some Git repository. There may, or may not, be some particular distinguished Git repository—often, this is one that is stored on GitHub—that everyone agrees to treat as a sort of "main", or "master" or "dominant" or whatever word you prefer, centralized source-of-truth version of the repository, so that everyone else's actually-peer repositories are treated as somehow lesser entities. But Git's design is decentralized, with every repository being quite autonomous.
Because of this, every repository has its own independent branch names. Even if you call your branch in your Git dev, and Bob calls his branch in his Git dev, and Carol calls her branch in her Git dev, and so on, these are in fact all independent branch names. This all works fine in isolation. The problem you will encounter is that as Bob tries to talk to Carol, he'll say "in dev ..." and Carol will think Bob means her dev when Bob actually means his dev. If Bob and Carol try to get their two Gits to have Git-repo-sex1 with each other, this gets even worse, because without careful instruction, their Gits will try to mate their two devs.
What that means is that giving everyone their own branch names is helpful.2 This is true regardless of whether Bob's Git talks directly to Carol's, or whether Bob and Carol both have their Gits call up a Git over at GitHub in order to do the Git-repo-mating-dance. It's much easier for us fuzzy-headed humans to talk about "the last two commits in my branch xyz" than it is for us to say "commit b697d92f56511e804b8ba20ccbe7bdc85dc66810 and commit 6ee1eaca3e996e69691f515742129645f453e0e8". The latter is precise and will work in all cases—these two commits are always these exact two commits—but hash IDs are just not suitable for human use.
1Sorry, it's hot out. You connect two Gits together using git fetch or git push. Note that git pull runs git fetch, then a second Git command, so it too is really just using git fetch to exchange commits.
2Note that I keep talking about branch names here. This distinction is useful: If we define branch as series of commits ended by a tip commit identified by a branch name, then at some point, every developer will have his or her own branch—every time someone makes a new commit while on a branch name, he or she makes a new unique commit, which updates that branch name, which creates the new branch. So with or without unique branch names, these developers will have unique branches.
So you mean everybody works on their remote copy and does not push until a feature is finished instead of branching?
This is basically the same if you NEVER want to share or give insight into your feature branches until they are ready to be merged into the master branch. Which is not a good idea in my opinion.
Creating branches gives you the option to make your progress visible to the other members of your group and gives them the opportunity to have a heads up look on what you are changing and possibly even merge your feature branch into their own before you have actually merged your branch into the master branch. Therefore this can also reduce merge conflicts.
Do create branches! It's a helpful practice.
As per good practice, we should keep sync master branch with production code. If there is any release create release branch from master and give to developers. From developer side they have to create own feature branch or jira branch from release branch, do own changes and push back to github. After that raise pull request to release branch, and we have merge in release branch.
