There are several branches available in git flow.
such as
feature/
release/
support/
hotfix/
bugfix/
I do not need release/ branch and want to merge staging branch (a development branch) directly to master.
What is the best way to achieve this using git flow?
I think this would be mandatory to make release branch for every release in production or your master branch
So There is no alternative way to do this.
Simply flow is as below:
Work on your feature branch
Finish work and merge your feature branch to staging
Make release branch from staging.
Add version and tag than merge it to master amd staging both.
I think this would be helpful for you.
Related
Azure Devops
Scenario : I have branch dev and master. There is commit in dev branch AS Commit1, Commit2, Commit 3 and Commit4 and all this changes release on dev site. Now I have approval for Commit1 and Commit3 to release on production. So how can I merge only commit1 and commit3 from dev branch to master branch
Important Note: I'm sure you know this but I think it's worth mentioning that you haven't actually tested exactly what you intend to release. You may benefit from having another branch, say release, where you put the stuff you decide to release, and then you can periodically reset dev to master to clean it up. (And if you do this I would consider calling dev something like next like gitworkflows, which is a similar concept.)
Solution 1 (Most General):
Create a new branch from master, cherry-pick the commits you want from dev, and merge this "release" branch into master.
Solution 2 (Works if your dev branch has merge commits for each commit brought into dev, and those commits' parent is master.):
Create a new branch from master, merge in each of the branches for the commits, and merge this "release" branch into master.
Solution 3 (Works if your dev history is linear after master, and if you never intend to bring in commit 2):
Disclaimer: this is more of an academic answer and I likely wouldn't actually use this solution in your scenario...
Create a new branch from master, and then perform 3 merges:
git switch -c release master
git merge Commit1 # take commit1
git merge -s ours Commit2 # merge commit2 but ignore it's changes!
git merge Commit3 # take commit3
# merge release branch into master
git switch master
git merge release
I am currently building an Azure DevOps CI/CD pipeline and if it fails, I don't want to keep the code that lead to the fail in my repository. So, if the pipeline fails, I want the repo to be reverted to the last version before that commit. I can't find any help on that. How does this option look like and how can I add this option to my .yaml file?
Thank you so much.
Normally, you can use the git revert command to revert some existing commits.
In your pipeline, you can check out the git repository and the branch where you made the changes. Then run the git revert command to 'undo' some commits.
For more details, you can reference the following articles:
Git - git-revert Documentation
Git Revert
However, as #GeralexGR has suggested, it is recommended that you'd better create a develop branch based on the default branch (main/master) and make changes on this branch. Then build and test the code on the develop branch. Once everything is good on the develop branch, you can create a Pull Request to merge the changes from the develop branch to the default branch.
Our current stash repository has a Master and Develop branch.
Anytime if a developer is working on a story a developer creates a branch and once the coding is done a pull request is raised to merge to develop.
So far it has been good but when two developers are working on different feature branches on a same Repository if a developer merges his changes to develop and other one is still working on, there are issues like merge conflicts and we don't want the two different feature branches to be released together.
I know this is not an issue but we want to avoid release multiple feature branches at a time.
Any thoughts on this on what are the best practices.
I would suggest to create tags after you have merge to "develop" branch. There is no harm if you wish to release code from "master" branch using tags as well.
Honestly speaking there aren't any hard lines drawn on how you wish to release your code from Git hosted repos?
You may like to follow this sequence
rebase the feature brnach of second dev from develop branch to get changes of dev1 and avoid merge conflicts
git checkout feature_branch2
git rebase develop
merge feature-branch2 to develop branch
git checkout develop
git merge feature_branch2
tag the version you wish to release
git checkout provide_version_you_wish_to_release
git tag tag_name
The best practice is that the 2nd developer should first rebase his feature branch from "develop" branch and then merge his changes back to "develop" branch by creating a pull request.
If you don't wish to release changes from two feature branches simultaneously, you can create tags on the "develop" branch after a merge is successful and release code using these tags.
Hope this helps!
I am new to managing code revisions and need guidance on how to merge to code sets. I have a MASTER branch with my latest UI and I have a branch called "Feature-A" with lots of Django additions + template additions to the previous UI files.
Since I am new to Github, I want to take the safest approach incase I need to revert mistakes. Should I make a new brach of master and merge Feature-A into that branch or should I merge Feature-A directly into the MASTER?
Since you're new, I would say the best approach would be to create another branch (clone of master branch) and then merge feature A into that, and see if it works. If not, keep testing feature A to make it compatible. If it works, great! Just remove that extra branch and merge feature A into the master.
I.e.,
git checkout master
Then, create a new branch (git checkout -b 'featuretest')
Now, git branch shows
* master
* featureA
* featuretest
Then, do git checkout featuretest, and git merge featureA to merge it.
If the feature works, great! Remove the branch (git checkout master; git branch -d featuretest)
and do it for real (git merge featureA)
If the feature doesn't work, go back to the feature branch (git checkout feature) and keep testing.
This is the first time I am using Git Hub. So please co-operate with me.
I am working on an iOS project with another developer. Now since we are working on 2 different functionalities, I thought making separate branches for each developer is good way. So my plan in to follow below steps
Create a local branches named functionality1 from the current one using
git checkout -b functionality1
Commit my code in functionality1 branch
Push that branch to the remote using
git push origin functionality1
This will add my branch to remote server. I need branches on remote because I can work from anywhere.
I will merge it in Master branch using
git checkout master
git merge functionality1
Now functionality1 is merged into master branch (provided no conflicts occurred)
Other developer will follow same steps.
We don't want to delete the branches yet.
Now once both branches are merged into master, how can each developer will get the merged code from master branch into their respective branches (functionality1 & functionality2) & then continue on working on same branch (functionality1 & functionality2)?
IMHO you shouldn't unless you really need the new functionality. Because by merging e.g. master back into functionality1 you make it dependend upon the other feature branch. A good read is the gitworkflows(7) man-page.