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!
Related
Someone upgraded our TFS to Azure Dev Ops a couple of years ago. If I drill down one of the repositories in a project, there are dozens of folders some of which have branches within them. The icon I have boxed in red I assume is a branch:
I have created a brand new repository in DevOps via the browser interface, and while I have been able to create a few folders with projects, files, etc..., I cannot find a way to create a branch within a folder.
In Repo -> Branches, I see a New Branch button, but that branch will be created at the repo root. There does not seem to be a way to place a branch within an existing folder.
Is that correct? If not how can it be done? Perhaps via the command line somehow? Is this structure in the other repo because it was converted/imported from TFS?
There are two version control systems available in Azure DevOps / TFS:
TFVC (Team Foundation Version Control) and Git.
TFVC is a centralized version control system and is considered feature complete and no longer undergoing development. You can have one TFVC repo per Team Project. It supports folder-level branching within the repository. The screenshot you posted is from TFVC.
Git is a modern version control system. It is fundamentally different from TFVC on a deep technical level and does not support folder-level branches; branches are only at the repository level.
If you created a new repository within the team project containing your TFVC repo, it is, by definition, a Git repository.
The branches and merging strategies that you follow for TFVC and for Git are generally not interchangeable because of these core differences.
So to succinctly answer your question: You can't do what you want to do. If you are using Git, please look up common Git branching models such as GitFlow and GitHubFlow and choose one that is appropriate for your development scenarios.
In Repo -> Braches
You could create new branches within an existing folder with the format:
Folder Name/Branch Name
In TFS 2013 how can I overwrite all folders and files under a specific folder with data from another branch?
I have a main and two dev branches and different functionality has been added to the same solution in both dev branches. Main is in sync with one dev branch. Now all functionality that has been added to the dev branch which is not in sync is now obsolete and I want to sync the solution in this branch with whats in main. As the solution differs alot between main and the obsolete branch a traditional merge wont work.
Why not just delete the branch (or rename it for archive purposes), and create a new branch off MAIN?
Another option is to rollback all changesets in the Obsolete-Dev branches history, then do a merge from MAIN.
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 planning to add my iOS project to GIT hub and I am new to the GIT branching and taging.
Please suggest a simple and good branching structure for development and production.
If i create one branch for development and one for production(master), is it possible to create sub branches under development?
Help is highly appreciable.
You can branch from any commit in git. All branches are equal. Why don't you try it out?
SCM organisation tends to be project-specific, so, whatever works for you is good. Your clients should never see your entire repository anyway.
First of all, branching in Git is unlike branching in Subversion or any other Central VCS.
Guess you need one major branch, and from there you can make all possible branches you need. Just remember to merge what you want to keep.
E.g. you branch for production (guess solving problems (branch even per problem)) and you branch for development (sub branching again if needed). And later on you can combine (merge) the changes from the production branch back to the master and all the stuff from your development branches that you want to keep.
But there is no best way - that depends on your use cases.
I usually branch per problem (production / issues) and merge it back if solved.
The development branch(es) I only add when needed (f.i. before acceptance testing).
YMMV.
Assume you have a tarball named ios_project.tar.gz with your initial work. You can place it under git revision control as
follows.
$ tar xzf ios_project.tar.gz
$ cd project
$ git init
Git will reply
Initialized empty Git repository in .git/
You've now initialized the working directory--you may notice a new directory created, named ".git".
Let the master be as is. I would recommend you to create two branches one for development and another for production. Do all your code modifications which you are unsure of in your development branch, and when you are sure about your work, push it to the production branch and apply a tag on it so that it is each to track the production line at a later stage.
In addition to this if you would like to share it with others, then have the repository as a shared directory. And clone it on any other development machine, create a local branch tracking the development branch on this machine, do changes, push to origin.
Following set of commands would be useful at a very basic level:
git clone git#repository_path_on_network/folder_name
git branch usrname_activity_dev --track origin/branch_in_repository
git checkout usrname_activity_dev
git add filenames
git commit -m "comments"
git push origin usrname_activity_dev:branch_in_repository
git checkout local_production_branch
git rebase usrname_activity_dev
git push origin local_production_branch:production_branch_on_repo
git tag tag_name
git push origin local_production_branch:production_branch_on_repo --tags
These are very basic commands. I would suggest you to further go through the internet. You will find a lots of commands according to every situation you are in.
Take a look at Git flow. Python scripts to help apply this are available here.
I have read :
"Best practices for using git with CVS"
"How to export revision history from mercurial or git to cvs?"
, and neither suit my needs.
At work we use a remote CVS repo. Access to this repo is handled via eclipse CVS tools, and in-house eclipse plugins that are built ontop of team tools for eclipse. This means we can't move to a better vcs.
However I would like to use Git on my local machine (to enable personal branching) such that I can accomplish the following:
Create branches in Git and then once finished and merged back into my local trunk, commit back to the cvs repo using the eclipse team tools etc.
My plan is something along the following lines:
Copy the checked out files to another folder [gitRepo].
Create a master git repo in gitRepo
Branch in gitRepo and make changes.
Commit to gitRepo
Copy gitRepo back to checked out files
Sync with remote cvs.
I was planning on using eGit for eclipse however I believe that the CVS and .git files will compete for ownership of the versioning.
Are there any tools or suggested work flows to help me manage this? Also how well does Git play with CVS files. And vice versa since I don’t want them to infect each other.
The reason the former links are of no use is they commit straight to the cvs repo from the git repo and this worries me as I do not wish to infect the cvs repo by accident.
It should also be said that changes in the GitRepo do not need to persist into the CVS repo, for example I don’t need to see every push to the git repo reflected in the remote CVS.
~Thanks for reading.
You perfectly can create a git repo directly within a CVS workspace (much like directly within any other VCS tool.
Make sure git will ignore any .cvs resources, and make sure CVS will ignore the .git.
Any Git commit won't be directly reflected in CVS.
The only trick is for Eclipse to display only Git or only CVS informations and label decoration.
For that I would configure two different Eclipse perspectives in which I will de-activate one or the other VCS tool.
I have done exactly this at work and I found the following practices helpful:
Keep any one (master in my case) branch always in sync with CVS. Do not use this branch for your development. Periodically update this branch to get the changes made by the rest of the team. If these changes are relevant to your current work do a merge master from your dev (or any other appropriate) branch.
When you are ready to check in to CVS switch to the master branch and merge the changes from the appropriate branch (dev, feature etc. as appropriate). Run your tests!
You employer most likely will keep a back up of the CVS repos. You will have to find a way to keep your git repo backed up. One way is to add a mirror repository in a Dropbox folder and use a post-commit hook to update it after each commit.
Before you leave work switch to the master branch. I once made the mistake of running CVS up -d on a dev branch in the morning and ended up quite confused. Adding a script to automatically switch to master before updating helps.