Looking for a general suggestion as I occasionally run into errors in branches in my iOS git efforts. I create branches from dev to isolate changes as per usual. I start out with everything tracked, including pods. I commit often from Xcode to remote, and only use SourceTree to manage higher level stuff like branches, merges etc.
BUT.. every so often, when i return to a branch and compile before restarting efforts, i see "no such file or directory" errors for a file or three from other branches. I just don't see what i am doing wrong, unless staging every file is my mistake.
Is this enough for somebody to offer advice? If not, and if the question is too general, feel free to wipe it, thank you.
Related
We are using visualstudio.com TFS to store the source code. We have DEV, STG and PROD branches. now I want to automate build and release to IIS server.
But it looks like to me that TFS compiles the code from the branch where I commit to, and that's the only build, after that I can install the same binary on all the servers.
But it doesn't seem to be ok, because what if we find a bug on the live code, so we need to fix it, but we already have new code in DEV, and we don't want to revert, and install the old code with the fix on the dev server?
What I think we should do is to merge the code from DEV to STG, from STG to PROD, but I couldn't find any module for that. And it looks strange, I would be surprised if I am the only person whats to do this, especially because it is doable with Jenkins.
thanks
I typically discourage automating merging of code between branches; merging should be a deliberate action. When someone expresses that desire, it's usually a sign of a problem with the branching model and deployment model they're using.
Code promotion branching (where you have one branch that corresponds to each environment, as in the scenario you described) is a bad practice because it encourages you to build different sets of binaries for each environment. You build something for a lower environment, test it, validate it, then totally disregard that testing and rebuild from source. That should terrify you, especially for production branches -- you have no idea if what you just built is going to work properly.
Current thinking is to minimize the number of branches you have, and instead isolate in-progress work behind feature toggles so that features that aren't ready for production can simply be disabled, but still allow deployments to take place. With sufficiently mature feature toggling practices and testing practices in place, you can actually eliminate branching entirely and work out of a single branch, promoting binaries to production whenever your automated and manual QA process deems the version they're testing is good.
Assuming you're using TFVC, if you want to maintain a code promotion branching strategy, then you'll need to maintain multiple builds and releases, one for each branch/environment. Typically, in this kind of scenario, I'd eliminate the stage branch entirely. Anything that goes to the Dev branch is built and deployed to Dev. Anything that goes into the Prod branch is built and follows a deployment pipeline from staging->production. Hotfixes can go directly into the prod branch and be merged backwards. There are tons of strategies for branching; you'll need to read up on the subject and design a branching and release strategy that works best for your team.
Do you really need a Branch to CheckIn / CheckOut Code in TFS i.e, just add files to a folder ?
What would be advantage to Branch in that case ?
You do not need a branch to check in and check out.
Branches however provide you with the ability to make changes to more thank one version of your code at once. Lets say that you have one folder at $/ProjectA/MyAwesomeApplication/Master. You can happily work away, checking in and releasing. At some point you find a bug in production that needs fixed immediately. However MASTER is well beyond what was last released and you don't want to deploy those changes yet.
You know which build is deployed and thus which changeset. You can branch MASTER at that changeset (the past) and create $/ProjectA/MyApplication/QuickFix. There you can fix that bug and ship, then merge back into MASTER and delete that branch.
Now obviously this is expensive and time consuming. A better way would to move forward and just ship what is in MASTER. If you have feature flags and good testing them you should be able to do that. There are however always those exceptions to that rule, and that's where branching comes in.
If you are using Git in TFS rather than TFVC the story is different.
I have spent a long time looking for an answer regarding merge conflicts with project.pbxproj files. My merge conflicts mainly occur with Cocoapods. It seems that if I add a pod on a branch, then try to merge it into another, many many merge conflict arise in the project.pbxproj file of my Pods project. I would simply go trough and fix these conflicts manually, but there are way to many for this to be reasonable. Has anyone else encountered this problem and found a reasonable solution. This issue has plagued me for sometime now and I am only asking this question as a last resort. After creating a couple of new features on separate branches, having this much trouble including them into my project is very frustrating. Any help would be very much appreciated.
As long as you're not making changes, which you probably shouldn't be, to the Pods.xcodeproj file, then the source of truth is always what is generated with pod install. Therefore if there are many conflicts you can just delete the project and regenerate it.
I've run into this on a fairly regular basis. I have a recipe that works most of the time. We use Git-flow, so are typically trying to merge feature branches into develop. Memory being what it is, often the first time we notice this is when GitHub warns of a conflict.
Commit (or stash) all outstanding work on your local feature branch.
Run pod deintegrate (docs here)
Commit the branch. It’s temporarily in an unusable state. This will be resolved momentarily.
Switch to the latest develop
Again, run pod deintegrate
Commit changes to develop. Don’t push these changes up to origin. This commit will be deleted shortly.
Switch back to your working branch.
Merge in your local develop. Hopefully this will be conflict free.
Run pod install, run the apps and check that everything works as expected.
Commit the merge. Delete the local develop commit (i.e. git reset to origin)
Push working branch changes.
You may also want to consider using a hook to prevent pushes of integrated projects. This puts the onus on the developer to pod deintegrate before pushing changes up (and also requires other developers to pod deintegrate before merging from develop) but does remove one potential source of conflicts if using a cloud repo provider that manages your workflow like GitHub.
It's also worth splitting out file-add operations into their own commit to reduce the noise.
Following by this guild: https://github.com/CocoaPods/CocoaPods/issues/3093
For CocoaPods to say that message, the project will have <<<<<<<, >>>>>>> or ======= on a line indicating it has a conflict which hasn't been resolved.
It is possible that there is still the conflict markers and the file is still in a conflict (git only says it's resolved because it was told it has been resolved regardless of the conflict markers).
You can find them in your file by running the following:
grep -E '<<<<<<<|>>>>>>>|=======' /path/to/project/project.pbxproj
I can't figure out the best way to do this and it has happened a few times where I mess myself up that it'd be nice to know a possible good way for this. On master, I have our main project. We finally got approved to use ARC in iOS and I created a new branch for that to not mess with the main working master branch. I also took the time to delete some unneeded files in my ARCBranch. What I want to do is use this branch for development for the next release. I'd like to pull in the changes from master to the ARCBranch. So I switched to ARCBranch, and did
git pull origin master
I got conflicts, some which were straightforward because I could see the code, others being changes in the pbxproj file where I cannot tell what's what. I did see
<<< HEAD ==== >>>. I can't tell what I need to do here. I can't open it in Xcode, only a text editor. I tried just deleting those <<< === >>> characters since I saw one person on SO say that you typically want both changes and that you could always do that. This didn't work for me. I was wondering if there is a better way to do this change. Maybe somewhere where I can see each change by change happen? Thanks.
Instead, you could try
git rebase master
This would apply the changes commit by commit. If there are conflicts, it would stop there, so that you can resolve them and do
git rebase --continue
to finish applying all the patches.
It failed to auto merge so it marks the conflicting blocks of code and leaves them both so you can decide and remove one yourself.
While I am rebasing our branch, rest of the team continues working on code. Rebase lasts about 1-2 hours. I'm doing it from merge in context menu when you right click the folder to merge, so nothing special here.
Team members check-out code, alter it but they do not check in. What risks this approach has? What is the best practice for this situation? How your team handles such cases?
I think what you're suggesting is a fairly standard approach and just to make sure I understand the question, here is a scenario.
There is a Main branch. From this Main branch 2 development branches have been created (devA and devB) these branches will be used to make changes to the code for 2 seperate projects.
The development in devA has reached a stable state and has been merged in to the Main branch. Now you want to merge the changes from Main in to devB
In devB the developers have been coding changes and have a number of files checked out. You don't want to make the developers check in their changes to devB and you don't want to initiate a code freeze whilst the rebasing takes place.
If the developers have been checking in changes to devB on a regular basis since the branch was created, you will porbably see merge conflicts when you try to merge the devA changes from the Main branch. Someone familiar with the code and requirements for both "projects" will need to help resolve those merge conflicts. Once the conflicts have been resolved you'll probably want to check that the code compiles and that any unit tests run and pass. If you have compilation errors or unit tests fail then this will need investigating.
Once you're happy that the merge from Main to devB has been sucessful then the developers with files checked out in devB can start to check in changes. If the files they have checked out were not changed as part of the merge from Main then the files will check in as normal. If however they have files checked out that were updated as part of the merge, TFS will bring up the merge conflict resolution tool and the developers will need to resolve any conflicts before they can check in the code.
Hopefully the above is resaonably close to the process you're currently following? If I've missed anything, or missed the point entirely then let me know.
This isn't as nice as it could be, but it's a common approach and one that we use.
The risk to this approach is that you could end up spending a lot of time fixing merge conflicts, especially if you have a large codebase with a lot of developers changing the code in a lot of branches.
To mitigate any problems, it's best to rebase as early and as often as possible. Early because if you save everything up till the end of devA's project, then the changes could have a significant impact on devB. Often because the number of conflicts per merge is minimised, making conflict resolution simpler and less error prone.
Setting up a "continuous integration" build will also help as you'll see compilation problems sooner rather than later. If you're using TFS 2010 then Gated Checking may also be helpful.
I'm not 100% sure that this answers your question so let me know if I've missed anything