We crated two branches from the trunk (using TortoiseSVN) ... branch USER and branch PRODUCT
In branch PRODUCT we are working on some new features. (day 1)
In branch USER we correct bug/error as reported by customer. (day 2)
Within a few days, we fixed branch USER and merged back into trunk (day 4)
tested and merged to trunk and made live
Within a few weeks, we finished PRODUCT features and merged back into trunk. (day 10)
We received several conflicted files.
After several hours of trying to fix the errors, I completely messed up the trunk.
We had to re-do coding and kill SVN and re-create the repository.
Very frustrationing .. and we lost a lot of time.
Is there instructions on 're-reintegration' or 'updating' a BRANCH from TRUNK?
Honestly, I dont even know the write questions to ask, as I dont know what process
we needed to perform!
After some playing around and getting some reading/asking questions, there is the process I used:
Start development in your Trunk.
You have reached a stage where you want to branch out and start a different development over the branch. You always branch out from the Trunk.
Lets consider an example, we create two branches Users and Products, both from the Trunk.
Simultaneous development happen on both the branches Users and Products.
Now there comes a stage when development on the branch Users is done. So you re-integrate the branch Users back to Trunk. Testing happens on Trunk and for deployment you use the code in the Trunk.
At this stage Users branch is re-integrated with the Trunk, but still Products branch is as it is.
Users code has been re-integrated with the Trunk and deployed successfully. So now the Trunk has the Users code also. So this code should be merged with the Products branch.
Now the Products branch has the Users code plus the changes that were worked upon in the Products branch itself.
Once the development in the Products branch is done, it can be re-integrated with the Trunk.
Now the Trunk has the code from Products branch and the Trunk is up to date and ready to be deployed to the live server.
I hope this helps others.
Related
So I have an api, webapp and mobile app with each their own repository on Gitlab, each repo has 3 master branches basically:
Production
Beta
Development
Now lets say I create a feature x branch push some changes to it and I think that its ready to be tested internally and push this to the development branch. Feature x gets tested we add some changes to the Feature X that get pushed to the development branch again until satisfied.
Once ready we push it to the Beta environment where we get some feedback from our beta users and based on that we publish it to production.
Problem is that I have to base my feature x branch from one of the main branches which usually is development. Now when I push that feature x branch to the beta branch it creates a bunch of merge problems that has to be solved once solved i am able to merge that feature to beta but the same problem raises again when I push my feature to Production.
So currently I just tried to solve all the merge conflicts, but having to do this every time is quite the hassle.
Any ideas if there is a better way to do this, cause I am not that experienced with proper version control?
I am seeing an error in our release build process. Need your help/suggestions on it.
In our organization, we follow the release strategy like this:
our codebase has microservices/applications located on individual folders like this format
MS-A
MS-B
MS-C
MS-D
Our release processes follow this workflow:
branch-1 has made changes on MS-A and merged it to master
branch-2 has made changes on MS-B and merged it to master
from master we create Release branch R1 and did the release process, where only MS-A and MS-B gets deployed
afterwards similarly,
branch-3 has made changes on MS-C and merged it to master
branch-4 has made changes on MS-D and merged it to master
then from from master we create Release branch R2 and did the release process, where only MS-C and MS-D gets deployed
During release, we basically do a git diff R2 R1 and calculate which folders got updated, and then start deployment of only those folders(i.e. microservices).
Now when there is any error during deployment - we create a bugfix branch from master(which naturally gets ahead of the release branch HEAD now), push the fixed codes there, merge it to master and then we just cherry pick that commit id on the release branch and redeploy it.
So as a result, we had been seeing an issue occuring - when git diff is calculating the changes on two release branches, it isn't taking into account the cherry-picked ids as a part of the previous release but considering it as a part of the next release branch itself.
a short example using the previously described relese workflow example will easily visualize this error:
Lets say, on R1 release MS-A and MS-B got deployed and there was some issue with MS-A for which we raise a bugfix branch B-1. we push the commits on B1 and merge it to master and cherry-pick those commits onto R1 branch. Then after the release R1 is completed, we made changes on MS-C and MS-D and merged it to master and create new release branch R2.
So if i do git diff R2 R1, i want the output to be MS-C and MS-D only, but here we get MS-A, MS-C and MS-D. Git is not considering cherry picked B-1 commits as a part of R1.
Considering the above scenario and keeping in mind I can't make any changes in the entire release workflow process whatsoever, is there any way to fix this issue?
I am using the Android Studio functionality to manage my branches/commits etc.
I have the master branch which is reserved for final versions, then I have my development branch and then I open new branches for any features I want to work on.
I've just noticed that my changes in my new branches are automatically merged into my previous branch.
For example, if I'm on the development branch then create a new branch "Image gallery" and add something, when I go back to the development branch, that thing I've added is already there!
This beats the whole purpose of using branches, what is going on? Did I click anything I shouldn't have clicked?
If we are not commit the changes which we are done in the feature branch(image branch), it will added to the development branch when we change the branch local. First we need to commit the changes which is done feature branch(image branch). Then we need to change the branch to the development.
I'm new to having git set up for multiple users. I typically used it by myself with only one branch. I have a questions that I couldn't find safe answer to via Google:
If I'm currently pulling a feature development branch into my dev server to test the feature and I suddenly discover the need for a hotfix can I re-branch(checkout) the hotfix branch (part of master not dev), pull the files in and start working on/testing a hotfix or will my next "git add ." add the files from the feature branch(which are still on the server) to the hotfix branch therefore mixing the two branches?
If I understand your question, I think your asking if, having changes on the development branch, and then switch to a hot fix branch, will the changes get intermixed with the new branch?
Typically, what I would do is use "git stash save" of any changes on the development branch, checkout the hot fix branch and dothe changes and commit, switch back to the development branch, and then "git stash pop..." To get the development changes back.
You can do "git status" after each step to ensure the working area has what you expect.
I'm in a pickle. I'm using SVN 1.5 at Beanstalk and Tortoise SVN client 1.6.11 x64 on Windows 7.
I'm developing on a branch and have been merging changes from the Trunk into my branch at least once a week. I recently noticed some things weren't working as trunk changes didn't make it into my branch. When I try to do a merge, Tortoise acts as though there are no changes in the trunk to merge. The Test Merge shows no files being added or updated.
I tried to merge my branch back to the trunk, but got a message saying that my branch wasn't up to date and told me to merge a range of revisions from the trunk.
I really don't want to do this by hand. How can I tell Tortoise and/or SVN that my branch is not up to date?
I still don't know what caused this to happen, but I did manage a work around. I instead did a backwards "reintegrate a branch into the trunk". This seemed to work good enough, but not perfect.