How to work efficiently with branch in git?

Question

I’m trying to define a working scheme to keep my repository on Github organized, but it is difficult to reach a solution.

My "idea":

I thought about keeping the branch in the remote repository master (default) and develop. The branch master will be blocked, will only accept merge after review of pull-request, i.e., contributors will send their contributions to the develop and generate a pull request of this for master.

The Feature/foo, Hotfix/foo and other branches will be branched from the develop, I don’t know if it would be interesting to branch even more with branch topic. Before merging the local branch with develop, should be evaluated the need to apply a full rebase or some commit, aiming to maintain a clean and easy to read historical line, after local merge and push to remote, a pull-request from the master <- develop.

In the text so it was already possible to observe some doubts, we will consolidate them and some more:

• In practice branch topic are really useful and used?
• Local rebase before push is a good idea, in which situation it would be advisable?
• It would be more advisable to change my CHANGELOG.Md file in the develop branch, or create a release branch, change there and then merge with master and develop?
• When merging a master <- develop, should I use merge request (which takes all merge commit + 1), or merge squash (which generates only 1 output commit)? Because of your suggestion?

Due to the importance of the next topic, I decided to separate it from the previous ones:

When I will perform a pull-request master <- develop a conflict in will always occur, this is referring to the file CHANGELOG.Md, whereas new data is always entered at the top, git will always file a change for which an automatic merge cannot be executed. How to solve this problem?

Possible solutions:

• In the case of Github this suggests to merge the develop <- master, resolve the conflict, apply the control commit, and complete pull-request/merge;
• I create a release branch from develop, merge release\xxx <- master, resolve conflicts, apply proper commit, perform merge master <- release\xxx and develop <- release\xxx;
• Or would you have another "better" approach? By best I mean community approaches to collaborative projects, which are proven to be but efficient.

---

Final doubts:

By following the wake of git flow, after creating the branch release, should merge this with the mater and develop, whereas my master is protected in Github (accepting merge only via pull request), should I upload this branch to the remote and generate the pull-request for the master? And to develop it, I merge locally and push?

Note: I believe that this doubt is part of the head of many people.

Answer 1

I find Gitflow an efficient and organized approach, below follows a link and image to illustrate better:

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

Answer 2

Come on, since many of the doubts kept hammering in my head, I decided to study the subject a little but in depth. Considering the knowledge acquired, I will try to answer the questions that previously represented absolute doubts:

• In practice, branch topic are really useful and used?

Branch topic can be used to have greater control of "long" outflows. Features that generate many steps can be divided into branch topic, so a more detailed timeline can allow for more controlled partial regressions; in this case the topic branch is relevant (useful), so it’s a great scenario to use this approach.

• Local rebase before push is a good idea, in which situation it would be advisable?

Yes, it is valid for changes that have not yet been pushed into the remote repository. Situations may be the most several possible, as a commit to change an incorrect comment in the code, correct an error that should not be present in the previous commit, such as forgetting a line delimiter, among others. In short, especially when we generate unnecessary commit, but use this feature wisely, try not to rebase if you’ve already pushed the commit to the remote.

• It would be advisable to change my CHANGELOG.Md file in the develop branch, or create a release branch, change there and then merge into master and develop?

Preferably in the release branch, this is a branch created to prepare the release of a new version... Therefore, in this branch we can consolidate a CHANGELOG already with the appropriate references to the commit that contain the aforementioned changes, change data in README or make other small adjustments.

• When merging a master <- develop, should I use merge request (which takes all merge commit + 1), or merge squash (which generates only 1 output commit)? Because of your suggestion?

The merge request in my opinion allows greater traceability, control and readability of the history

Final doubts:

• By following the wake of git flow, after creating the branch release, should merge this with the mater and develop, whereas my master is protected in Github (accepting merge only via pull request), should I upload this branch to the remote and generate the pull-request for the master? And to develop it, I merge locally and push?

Depends. If the lock in master has been released to contributors or admins, the merge to the master can be done locally and then pushed. If it is blocked even for Admins, a pull request can be generated from a release branch to master, or even from the develop itself.

Following workflows like git-flow is something interesting and very valid, but it’s good to keep in mind that each project has its own features and approaches, so you need to modify management processes whenever necessary.