Answers: <p>You can use "<a href="https://danielkummer.github.io/git-flow-cheatsheet/" rel="nofollow noreferrer">git flow</a>" or more simple "<a href="https://about.gitlab.com/2014/09/29/gitlab-flow/" rel="nofollow noreferrer">gitlab flow</a>".</p>
  
  <p>Our small team merge into master on release or sprint ends.</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-03-21T16:07:33.810Z
Answers: funny how this is a comment really, but the most upvoted answer that doesnt really answer anything
Answers: 4c74356b41
Answers: CC BY-SA 4.0
Answers: 2019-03-22T07:54:06.767Z
Answers: Thats cuz it answers everything 
Answers: Vasiliy  Shakhunov
Answers: CC BY-SA 4.0
Answers: 2019-03-22T07:54:54.930Z
Answers: which is the equivalent of nothing
Answers: 4c74356b41
Answers: CC BY-SA 4.0
Answers: 2019-03-22T10:44:58.377Z
Answers: Depends on what you wish to see ;)
Answers: Vasiliy  Shakhunov
Answers: CC BY-SA 4.0
Answers: 2019-03-15T06:22:33.347Z
Answers: 2019-03-15T06:22:33.347Z
Answers: Vasiliy  Shakhunov
Answers: <p>There are many theories about git branching models. You know about "git flow" <a href="https://nvie.com/posts/a-successful-git-branching-model/" rel="nofollow noreferrer">https://nvie.com/posts/a-successful-git-branching-model/</a></p>
  
  <p>But in practice that will slow you down in most cases. Remember Amdahl's law - put the effort where the usage is. At my workplace we only branch when making a merge request. This way we won't have to work for days with sham work like "merge to master" which will create impediments just because somebody was branching for the sake of branching. That works for us.</p>
  
  <p>So I suggest that you commit to master and only branch when making a merge request. This is almost controversial in some cases, but I am all open for discussion. </p>
  
Answers: CC BY-SA 4.0
Answers: 2019-03-22T14:54:49.213Z
Answers: At least somebody posted that link so I did not need to. I think that Vasiliy above nailed it though. Just pick something and stick with it. Keep it simple.
Answers: Randy L
Answers: CC BY-SA 4.0
Answers: 2019-03-16T01:08:11.627Z
Answers: 2019-03-16T01:08:11.627Z
Answers: Niklas Rosencrantz
Answers: <p>It depends, pull request reviews should be done before merging to master. If you are using CI/CD, that would occur as often as you can schedule releases. I prefer the fork and pull request workflow, keeping the base repository cleaner. The devs can organize how they choose on their ends in their forks as long as they are routinely fetching from the base master branch. </p>
  
  <p>If a dev quits, no one wants to be confused by what he/she was working on, so there is a plus with fork and pull there as well. Likely the next guy will start over from the approved master branch anyway.</p>
  
  <p>Integration tests happen after merge to master, then there are conditions that must be met prior to release within the CI/CD pipeline that if not met will break the build. Use the same branch for all environments, with environment variables if there are differences in environments. You can use labels or the merge requests themselves to describe what’s released. You don’t necessarily need feature branches. It just depends on the complexity of your project(s) and your team. More branches = more complicated from my perspective, particularly with dependencies on multiple repositories. Don’t tell the devs how to work, if you can avoid it, just set the requirements for approvals, rollbacks, and workflows necessary to guarantee you can report effectively to your management. Keep it simple. Good devs will figure out how to work together on their own.</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-03-16T19:31:47.297Z
Answers: 2019-03-16T19:37:48.623Z
Answers: 2019-03-16T19:37:48.623Z
Answers: Jesse
Body: <p>We have 2 branches (master/dev) + some feature branches and 2 environments (production/dev). Our team is a very small people. What are the best practices of merging dev to master? </p>
  
  <ul>
  <li>Every morning?  </li>
  <li>After integration tests?  </li>
  <li>How about merging master with dev and then testing (hotfixes) then merging master to dev? </li>
  <li>Some release branches?</li>
  </ul>
  
  <p>I don't want to create anything too complicated.</p>
  
Comments: CC BY-SA 4.0
Comments: 2019-03-15T08:27:26.617Z
Comments: There isn't any right answer for that. It depends on your workflow. As Vasily says, it's a good practice to use git flow. We work in the same way, merging to master dev branch and the  end of each sprint. Also if you need to create a hotfix, that will be inmmediately merged into master an deployed in production as soon as it's finished (with all test passed)
Comments: RuBiCK
Comments: CC BY-SA 4.0
Comments: 2019-03-15T15:04:32.127Z
Comments: Yeah I always wanted to use gitflow. So probably we will move into direction of gitflow. Does gitflow also work well for repos that are dependent on each other?
Comments: sacherus
Comments: CC BY-SA 4.0
Comments: 2019-03-18T09:48:42.323Z
Comments: With git flow you manage the workflow and branching for a single repo. You should use the same flow for each git repo, including the submodules
Comments: RuBiCK
Comments: CC BY-SA 4.0
Comments: 2019-03-22T07:16:45.383Z
Comments: You should explain why you have those branches (what do you want to use them for). IMHO the branch structure **and** merge strategy are the result of picking a workflow/development strategy, not the other way around...
Comments: Dan Cornilescu
Tags: <continuous-integration><git><continuous-deployment>
Title: What are the best practices of merging dev to master?
UserDisplayName: sacherus
ThreadText: # What are the best practices of merging dev to master?
  
  (Asked by: username_0 on 2019-03-15)
  
  We have 2 branches (master/dev) + some feature branches and 2 environments (production/dev). Our team is a very small people. What are the best practices of merging dev to master?
  
  * Every morning?
  * After integration tests?
  * How about merging master with dev and then testing (hotfixes) then merging master to dev?
  * Some release branches?
  
  I don't want to create anything too complicated.
  
  **Tags:** continuous-integration, git, continuous-deployment
  
  > **Comments:**
  > **username_1**: There isn't any right answer for that. It depends on your workflow. As Vasily says, it's a good practice to use git flow. We work in the same way, merging to master dev branch and the  end of each sprint. Also if you need to create a hotfix, that will be inmmediately merged into master an deployed in production as soon as it's finished (with all test passed)  
  > **username_0**: Yeah I always wanted to use gitflow. So probably we will move into direction of gitflow. Does gitflow also work well for repos that are dependent on each other?  
  > **username_1**: With git flow you manage the workflow and branching for a single repo. You should use the same flow for each git repo, including the submodules  
  > **username_2**: You should explain why you have those branches (what do you want to use them for). IMHO the branch structure **and** merge strategy are the result of picking a workflow/development strategy, not the other way around...  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_3 on 2019-03-15. Score: 3
  
  You can use "[git flow](https://danielkummer.github.io/git-flow-cheatsheet/)" or more simple "[gitlab flow](https://about.gitlab.com/2014/09/29/gitlab-flow/)".
  
  Our small team merge into master on release or sprint ends.
  
  > **Comments:**
  > **username_4**: funny how this is a comment really, but the most upvoted answer that doesnt really answer anything  
  > **username_3**: Thats cuz it answers everything   
  > **username_4**: which is the equivalent of nothing  
  > **username_3**: Depends on what you wish to see ;)  
  
  ---
  
  ### Answer by username_5 on 2019-03-16. Score: 1
  
  There are many theories about git branching models. You know about "git flow" <https://nvie.com/posts/a-successful-git-branching-model/>
  
  But in practice that will slow you down in most cases. Remember Amdahl's law - put the effort where the usage is. At my workplace we only branch when making a merge request. This way we won't have to work for days with sham work like "merge to master" which will create impediments just because somebody was branching for the sake of branching. That works for us.
  
  So I suggest that you commit to master and only branch when making a merge request. This is almost controversial in some cases, but I am all open for discussion.
  
  > **Comments:**
  > **username_6**: At least somebody posted that link so I did not need to. I think that username_3 above nailed it though. Just pick something and stick with it. Keep it simple.  
  
  ---
  
  ### Answer by username_7 on 2019-03-16. Score: 0
  
  It depends, pull request reviews should be done before merging to master. If you are using CI/CD, that would occur as often as you can schedule releases. I prefer the fork and pull request workflow, keeping the base repository cleaner. The devs can organize how they choose on their ends in their forks as long as they are routinely fetching from the base master branch.
  
  If a dev quits, no one wants to be confused by what he/she was working on, so there is a plus with fork and pull there as well. Likely the next guy will start over from the approved master branch anyway.
  
  Integration tests happen after merge to master, then there are conditions that must be met prior to release within the CI/CD pipeline that if not met will break the build. Use the same branch for all environments, with environment variables if there are differences in environments. You can use labels or the merge requests themselves to describe what’s released. You don’t necessarily need feature branches. It just depends on the complexity of your project(s) and your team. More branches = more complicated from my perspective, particularly with dependencies on multiple repositories. Don’t tell the devs how to work, if you can avoid it, just set the requirements for approvals, rollbacks, and workflows necessary to guarantee you can report effectively to your management. Keep it simple. Good devs will figure out how to work together on their own.
  
  
  ---
  
  