Is It Necessary For Dev Branch And Main Branch Up To Date?
I am confused about some concepts in Git.
I try to use GitHub for my codes.
I have a branch
main and I treat it as my deployable branch.
Then, I create a
dev branch from the
main branch for my development.
My workflow is whenever there are new changes, I will add to
dev and test it.
If everything is alright, I will merge it to 'main' for deployment.
So, I add some changes to
dev and make a
pull request merging it to
However, I notice the
dev branch is 1 commit behind
main after merging. I can see
main contains one extra commit from the
merge pull request.
Should I make
dev branch always up to date regarding to
main and why?
If so, how can I do it?
tl;dr: In your case, the extra commit is due to merging using
--no-ff as evidenced by the "merge pull request" message, so you don't need to merge that commit back into
Whether you need to merge
main back down into
dev depends on why
main is ahead of
dev by some number of commits. As mentioned in Sıddık Açıl's comment, after the merge, if the two branches don't have any differences, meaning they differ by commits only, then you don't need to bring that commit from
main back into
dev. One way to differ in commits only is if you are using
--no-ff when mergeing
main. That forces the creation of a merge commit even when one isn't necessary. Note if you are using
--no-ff, then over time you will build up additional merge commits on
main that aren't in
dev, so next time you'll have 2 commits, then the time after you'll have 3 commits, etc. (Unless you delete
dev and re-create it from
main, or just reset it to
main, after every deployment, in which case that number will never get higher than 1.)
However, immediately after the merge, if
git diff origin/dev..origin/main does have differences, then there must be changes on
main that were never merged into
dev. In that case you probably should merge
main back into
dev to keep it up to date with those changes. That being said, the better time to do that would have been immediately after new commits went directly to
main, because if you wait until afterward it's likely that you tested something different than you deployed. Note the first time you have a hotfix into
main, you will bring all of those extra merge commits from the PRs back into
dev along with it, and that's fine. Just don't be surprised when you see it! (This won't happen if you happen to reset
main right after deployments.)
To summarize some rules of thumb:
- If you add changes directly to
main, then merge
- After merging
main, as long as the two branches diff is empty, it's OK to have extra commits on
Side Note: I like using
--no-ff in this application so I can see all the Production deployments with a
--first-parent view. Some people prefer to instead allow fast-forward merges and tag each production deployment, and then compare a tag with the previous tag to obtain the same information. (I actually use
--no-ff and still tag). It comes down to personal taste.
- → Authenticate with a cookie using laravel 5.1 and jwt
- → Finding a specific GitLab tag from PHP
- → React: How to publish page on server using React-starter-kit
- → babel-loader, webpack, ES2015 modules: "Element type is invalid"
- → Create a function-attribute of a function, which is, in its turn, a method of an object literal
- → Model Validation in laravel 5.1 not working
- → GIT fatal: loose object
- → Laravel validation required rule not working
- → Axios array map callback
- → Where does this `webpack://` come from for `webpack-dev-middleware`?
- → error when trying to modify project in laravel forge
- → GitHub Pages and Jekyll content duplication and SEO issues
- → Use Laravel repositories with Datatables