We want to migrate existing TFVC to TFS-GIT using existing team project with multiple branches. I found some tutorials that I could follow to migrate every branches. But their is something that makes me wonder if we can maintain or re-arrange our TFVC branch hierarchy in TFS-GIT?
Let us say we have branch hierarchy like this:
Prod <---> Pre-Prod <---> TEST <----> DEV
And during the migration process into TFS-GIT, we want to re-arrange the branch hierarchy depend on our discretion. Like for example I want to have something like this in TFS-GIT:
Prod <---> Pre-Prod <---> DEV <----> TEST // Just an illustration of what I want.
Is someone here have achieved what we want to do? Can you point me out into the right direction?
Technically, we can migrate Prod branch as master branch and branch out Pre-prod. But for the existing TFVC Dev we have a lot on-going work and change-sets.
Disclaimer : This is my first to do it and I made a research but most of the tutorial I found is only one branch can be migrated. But how about the branch hierarchy? Apology for a naive question.
Migrating all branches from TFVC to git using git-tfs
https://github.com/git-tfs/git-tfs/blob/master/doc/usecases/migrate_tfs_to_git.md#fetch-all-the-history-for-all-branches
Ps: please fix your question because what you call git-tfs is in fact TFS-git (git-tfs is the tool https://github.com/git-tfs/git-tfs/)
Related
I have a scenario where I will sometimes need to cherry-pick some commits from our UAT branch into our MASTER branch. This is because the business sometimes will request that only specific "features" are moved from UAT to production. I need to be able to pick certain commits to move forward as PR.
The issue I am having is that when try to cherry pick from one the commits (from the UAT branch) to master, Azure DevOps give me the error...
"Encountered conflicts when cherry-picking commit "42af19". This operation needs to be performed locally."
I am able to do this same pattern against my UAT, QA and Integration branches, I only have this issue against our master branch. I don't have any conflicts in the source branch so I don't believe its that. I also don't have any special rules for the master branch that should keep me from doing a UI based cherry-pick.
I really can't have our developers do this locally so I am hoping for some sort of option where they can use the UI for this.
We are using ADO to host the repo for our Salesforce code. We use another system that handles the CICD pipeline.
The high-level background for this is that we have may have 2 or more PR's that have been promoted and deployed to UAT, but the business may request that we only deploy certain ones. So some PR's might remain open against master for a few dev cycles. The issue is when other PR's move through and we need to promote them from UAT to master, ALL of the changes are getting added to the UAT > MASTER PR due to the fact that the code in the PR's that are in the holding pattern have not been committed to master, so the subsequent PR's would pick up those changes and try to merge them in, and we don't want that.
The thought is that we could cherry-pick commits from UAT as a PR. These only only contain the files we actually want to deploy, not EVERYTHING.
Hopefully someone can help me out with this scenario as I am a little stuck.
Thank you all very much for your guidance!
I have been working with a similar branching strategy for Salesforce. Normally in this situation, we would do the following:
Create a branch out of master - it will be used only to resolve conflict.
git checkout -b gs-pipeline/...
Cherry-pick a commit there, you can space separate them if there are many
git cherry-pick COMMIT-HASH1 OPTIONAL-COMMIT-HASH2
Solve Conflicts manually, save files, stage them, commit and push
Open Pull Request from gs-pipeline/... -> master
Unfortunately, there is no easy way to solve this within UI as far as I am concerned.
However, when you would down merge from master -> uat(directly or via a separate branch) that may solve your issue. It should be safe as things on master/PRD should already be on UAT and all lower environments.
We currently support two branching strategies; gitflow and trunk-based dev. My company started using what I'd call a hybrid (read not correctly IMO) gitflow model, but the direction of the company is to move to trunk-based development. I like the direction, but what's the best way to do this? I'm looking for best practices, but was unable to find this topic discussed online.
We use GitHub for SCM
In our hybrid gitflow branching strategy, our git projects are not currently (IMO) using the gitflow "master" branch correctly.
Should we:
Create new git projects in GitHub and archive the older gitflow based git projects
Block access to the "master" branches in the gitflow based git projects
Delete the "master" in the gitflow based git projects, and then follow trunk-based dev
Thanks
I was in a similar situation and wanted to switch from Git-Flow to Trunk-Based development.
This is how I ultimately solved the dilemma of a headache-filled attempt of merging massive amounts of code from 'dev' to 'master/main':
TL;DR: Replace 'main/master' with 'dev's code entirely, in your OS. Commit changes. Merge 'dev' into 'master/main'. Lock dev.
Detailed process -
Switch to 'dev' branch
Make a copy of 'dev' on your local drive in another folder
Switch to 'master/main'
Delete all contents from your local drive for this branch's folder, EXCEPT for the .git folder
Copy all the contents, EXCEPT the .git folder, from the backup/copy of 'dev' from step 2 to the 'master/main' branch's folder
Do a 'git status' and see that there are a ton of changes
git commit, and git push
Now your 'master/main' contains exactly what 'dev' does.
Finally merge 'dev' into 'master/main' so history/tooling shows that they converged
Lock the dev branch
Implement Trunk-Based development and CI best practices
Best wishes!
We have a GitHub project (master), every member of the team have a Fork of the project into their own repository.
Once a developer fixed something he create a new branch inside his local forked repo and commit that into remote repository and after that they request a Pull Request so that change go into the master reposiroty.
We publish to production "manually" once a week but we have had issues in production because accidentaly developer had committed to their forked repository and other developer with higher privilegies accept the changes and merge that into master repo, then someone else publish to production and he didnt knew that those new changes didn't passed to QA process.
So, what I want is to create like a Production Repository, so when we have the code in master repo that we know is stable and working then create like a Production branch so if by mistake something is commited and merge into master repo then the code for production publish is not affected.
Any clue or best practice to do this?
Not sure I'm understanding the question correctly, but you can add as many remote repositories as you like. There is a section in the Pro Git book called Working with Remotes that discusses this thoroughly.
In my experience, separating development and production code is typically done with a branching model such as git-flow. You can create separate repositories to solve this problem if you like, but doing so is unnecessary. This is because if developer A submits a PR that's merged by developer B, then developer C will get a non-fast-forward error when they try to commit upstream. This is called a subversion-style workflow. Per the docs:
Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.
If commits to the upstream branch are not being fetched and merged appropriately before pushing, then someone has likely taken it upon themselves to rewrite history.
Your git workflow is good enough to take care of this issue.
First, to fix the issue:
Treat unintended code push as bug and fix it as you would fix any other bug. Best person to perform this activity would be the developer who pushed that code. Developer can just fix it in their fork and submit a pull request. Try not to add any other unrelated code with this pull request.
About Production Branch or Repo:
I don't think you need another Production Branch/Repo (you already have one). As it happened with your current PROD repo, accidental code push can make it to new Branch/Repo too.
Instead use tags/releases feature in GitHub. Whenever state of code in master repo is prod ready, tag it and use the tag for production publish.
I have been working on a project which is on git master branch.
As we are 3 developers work on this master branch and modify the same files, we get much conflicts.
To avoid these conflicts, do I need to create separate branches from the same master branch.
Please suggest me a good development procedure with git branching.
Many shops use the Git Flow model.
This page compares several Git Workflows.
Please refer Atlassian Git Workflow tutorial for centralized and decentralized model.
https://www.atlassian.com/git/tutorials/comparing-workflows/
I am new to version control. I often hear these words Merging and Branching. I also see different developers working in different branches.
Can someone explain the flow on this. What is the difference between Merging and Branching. When to go for Merging and Branching
Branching is about isolating a development effort in a specific history, parallel to the main one.
See "When should you branch?": you branch when you cannot commit on the current branch (because it would break the work of your colleagues)
Merging is about reconciling two different branches.
You merge when you want to take into account in your branch the changes of the other branch you need to merge.
The workflow depends on the tools.
SVN offers either merge-based development or trunk-based development.
Tools with easier branching capabilities (like Git for instance) offer a workflow based on the various development lifecycle steps:
In the concept of git,
Branch is just a pointer to a commit, and will be advanced to the new commit when you make new commit to that branch.
Git has 2 types of branches: local and remote.
git can merge any single commit, not only the head of a branch.
I take the most simple merging workflow as an example.
2 developers are working on a project.
They are working independently based on the same version.
They share the master (main) branch via a server when they complete.
The first developer commit changes and push to the remote branch first. The second developer then synchronizes the changes by pulling changes made by the first developer.
A merge commit will be automatically created.