Reasons not to commit to master
Clash Royale CLAN TAG#URR8PPP
Reasons not to commit to master
In each manual and documentation about Git you can see the single advise - "Do not commit to master". So, if you need to add some changes to master, you need to create a new branch and merge it. Therefore, I interesting to know why? Which advantages it this behavior? For example, you have no need in a separate branch if you wanna to revert a change - you can do it using a commit hash.
Here I found a one reason - if you have many commits, it will be easyer to merge branch with master then push commits one after another
http://waterstreetgm.org/git-why-you-should-never-commit-directly-to-master/
But what if your workflow is divided into many small tasks and each of this tasks fit to the one commit. So, each branch contains one commit. What are the reasons not to commit to master in this case?
If your branches would contain a single commit, I see nothing wrong with committing directly to master.
– destoryer
Aug 20 '17 at 20:46
Did the answer help you solve the confusion? If yes, you can mark it as answer. And it will also benefit others who have similar questions.
– Marina Liu - MSFT
Aug 21 '17 at 6:49
2 Answers
2
If you're working with multiple people you should always have separate branches and only merge with the master when the bit you're adding/changing is finished and fully tested.
If you're on your own small project there isn't as much of a distinction. If your adding functionality, tags could be used just as well to be able to come back to a given commit.
Not committing to master prevents colliding commits and having to merge each time 2 people change the same file.
Your last paragraph is a bad practice because if 2 people are working on the same file and you didn't sync often (what you call 'merge often'), the probability that one of the 2 will have to solve a big merge hell increase with time and number of commit in the branch. And so, increase a lot to introduce a bug during a merge. Bad practice and one of the worst when working in feature branches.
– Philippe
Aug 21 '17 at 7:57
Well I specifically mean merging on every commit, is there a best practice for how often to sync? I would think it is very project dependent.
– Simon Hobbs
Aug 21 '17 at 13:03
The best (and theoretical) practice is 'as soon as you can' to do real continuous integration (that's the aim of 'trunk base development'). But indeed each project has to find its tradeoff because that could be a little costly...
– Philippe
Aug 21 '17 at 14:33
Those who said never or always are often (always!?! ;-) ) wrong...
Like you will discover once you understang git, there are often multiple ways to do the same things and your choices will mostly be team choices.
There is absolutely no rule that prevents to commit on master. There are advantages and inconvenients to the 2 ways of doing.
For example, the post you linked is more a problem that the writer didn't master git than something else. In less than 5 minutes, he could have create its new branch and reset its local master to the remote ref and pushed one commit on master.
master
master
Here is a list that is not exhaustive...
Using feature branches :
Pros:
Cons:
rebase
merge
Using "trunk Base development" (and 'feature toggles'. Real good development practice that you should have a look) :
Pros:
Cons:
Choose the one that suits your team and stick to it most of the time and apply the other where you think it make more sense and solve a problem you encounter...
By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.
At minimum, you could run automated testing on each branch to verify it won't break a stable branch. IMO, it is about stability and security.
– osowskit
Aug 20 '17 at 16:35