I have a scenario, where two developers are working parallel in a same branch of TFVC. Developer A and Developer B checked in from their respective branches and committed file changes.
Is there any work around to push only dev A's changes on the server and keep dev B's changes dormant?
Any help would be much appreciated. Thanks in advance
You could try creating a branch(V1) from main branch, remove changes of the developer which shouldnot go to deployment from V1 and deploy V1.
https://learn.microsoft.com/en-us/azure/devops/repos/tfvc/branching-strategies-with-tfvc?view=azure-devops
I will suggest you to switch to Git as it more user friendly. Resources and help are easily and readily available for GIT
https://www.nebbiatech.com/2017/06/22/choosing-git-tfvc-vsts/
Related
Pretty new to Git - been using TFS and simple commit/push/branching, so any help appreciated - have spent all day reading and running tests and beginning to think my requirement may not be possible.
There are two of us in the office; Dev 1 doing mostly compiled C# server code, and Dev 2 mostly exclusively web page related work. However, as there are only two of us we do need to cross over fairly regularly, particularly with client Javascript functionality.
We've been doing the "mate I'm working on foo.js" method of source control for client side code, and its worked for a while, but we are doing bigger projects and it's becoming a liability.
Our set up is as below, all on an internal network:
Dev 1's machine
Dev 2's machine
Local Windows Server running IIS that serves the websites under development
Shared drive pointing to the IIS root
So, and this is the rapid development cycle I'd like to try and keep, Dev 2 browses to the site under development edits the script / css / html files on the shared drive, hits F5, and the updates are immediately visible. This is a huge benefit for fast working with client side code.
The problems usually occur when Dev 1 needs to make a change to some scripted functionality that happens to require a style change, the same files are opened and saved by both devs, and one of the change sets is lost.
So I'd like to prevent this! However as far as I understand, Git requires the devs to have local repositories so changes can be done without affecting anyone else at all, and then conflicts are merged on commit?
I have set up a test repository on the local server and tried a few scenarios, but as I kind of expected, the scenario where both devs save the same open file is not tracked because neither set of changes has been committed, so as before, only the last set of changes is visible anywhere.
Is there any way of having these type of changes to the same physical file tracked? Or if not, a setup that does track them properly but at least maintains a rapid workflow as close as possible to the above?
Use branches.
Git has a very good branch system. Just create a branch for the work you do - you can even create a branch for every feature you want to implement. And when you "finished" the implementation, merge the branch back to master. So both - and more - developers can work based on a working master version and add there code to the common codebase if it works.
So, the workflow could look like this:
Dev1 and Dev2 clone the repo: git clone ....
Dev1 works on feature A: git checkout -b A (this creates a lokal branch A)
Dev2 works on feature B: git checkout -b B
Dev2 finishes his work: git push (on the first call you get a error message about the upstream, the errormessage contains exactly the line you need to create correct upstream, just copy it)
git checkout master; git pull back to master branch and pull
git merge B this merges B into master
Dev1 need longer for the job and wants to update to newest codebase:
git checkout master; git pull; git checkout A; git merge master branch A of Dev1 is now on new codebase.
If you have to work on different features at the same time, there exists also a good system in git. Based from master branch, create a new branch in its own folder - so that both branches are checked out at the same time and there is no need to git checkout <branch> to switch between them:
git worktree add -b <branch> <path>, like git worktree add -b A ../A
now you can switch to it trough filesystem (cd ../A) and work on both (or others you created the same way)
If you use github or gitlab, you can protect the master branch and create rules to make merges into it (called pull requests). With appveyor, travis-ci and others there exists services where you can let unittests run and give the pull request free it the unittests do not fail. Based on such a workflow, every developer can work on a running codebase.
About conflicts: With the workflow up there they do not happen as long as both versions didn't modify the same line. But you get a message at the (local) merge, and in the files it is good explained what you can do:
(we create a file with a b c in each line, in master we edit b to e, in our branch A we edit b to d, we commit both and merge master into A)
a
<<<<<<< HEAD
d
=======
e
>>>>>>> master
c
Ideally, you would:
isolate the common files in one separate Git repository
separate source control (the remote Git repository) from deployment (files copied on IIS root)
That way, each of you can:
push to a common remote bare repository: configure it to deny any non-fast-forward push. In case of concurrent pushes, you will be forced to pull first, resolve any conflict locally, then push back: there won't be any change overridden or lost that way.
setup a server-side hook in order to (on the server) pull from said bare repository, through a post-receive hook (example here).
reference that common repository in your own development repo through a Git submodule.
The goal is to keep separate:
project-specific development from common client Javascript functionality.
versionning from deployment.
The problems usually occur when Dev 1 needs to make a change to some scripted functionality that happens to require a style change, the same files are opened and saved by both devs, and one of the change sets is lost.
…
Is there any way of having these type of changes to the same physical file tracked?
To get this you need some sort of collaborative editor, that's out-of-scope for any existing vcs I know of.
Or if not, a setup that does track them properly but at least maintains a rapid workflow as close as possible to the above?
You need separate files, separate saves (i.e. a vcs) and a workflow that automates as much as possible of the pull-and-push publishing loop.
Since you're not working on the same physical files, before publishing you need to sync your changes with whatever the other guy(s) on your team have published since last you looked. Decide how you want your final history to look; for small-team work like this rebasing onto a shared linear history is often a great place to start, so git config pull.rebase true. Then when you're ready to publish the changes you've saved, commit, pull, push is your cycle; if you and your buddy are making changes even in the same file it'll still apply cleanly in one go so long as the changes aren't immediately-adjacent or overlapping.
Downvote if you want... but I need a set of simple basic steps that we can follow. We have VS Enterprise, no GitHub add-ons installed. We have a an empty repo created on GitHub. What do each of the developers do after that? There's a local repo, right? Should there be another project on the local machine that commits to the local repo or do we open the project in the repo? If yes, how do we create that other project? What about the .sln file that VS lovingly puts in a separate folder? We have been at this for hours and believe me we have tried every combination of commit/push/sync/goat sacrifice except the right ones. We cannot reproduce consistent results such that two developers can work against the same remote repo. Sometimes one developer can push and he doesn't see the files pushed by the other developer. Sometimes the Commit Message text box lights up but the Commit button is disabled. I thought I was reasonably intelligent until I started working with GitHub.
I'll give you the broad steps you need to do. You may need to fill in a bit of the detail. THis is how I would work it. I am sure you could get many other opinions.
Create the repo on GitHub (which You already have done.)
Each developer should then go to the GitHub repo and fork the repo under their own GitHub account.
Each developer then needs to clone their repo to their local machine. (That's the beauty of Git. Every developer has the entire repo locally.) You can do this in VS2015 by choosing: File -> New -> Repository -> Clone.
Go to your on-line repo and get the URL of the repo that you will be cloning. Enter it into the New Repo dialog box in VS.
When working on the project, each developer should create a temporary feature branch, which they push to their own GitHub repo. They can then push their work as often as they want without it conflicting with other developers.
When a developer thinks that their work should be merged into master, they should go to GitHub and issue a "Pull Request" for their feature branch.
Their PR can then be discussed among the team before it is accepted.
Once it is accepted and merged into master, the developer can delete their feature branch locally and on GitHub, if he likes.
Since "master" on the team repo has now been updated, each developer will need to pull down master from the team repo to update their own local and remote repos.
It sounds more like an how-to-use git issue. You probably first need to see how two collaborators work on same project with git. I donot think either VS or GitHub has anything to do here, as both only provides you git gui tool regarding this issue.
Our TFS Source Control is setup like this:
TFS Project
Solutions
WebApp1Solution
WebApp2Solution
Libraries
SharedLibrary1
Web Applications
WebApp1
WebApp2
When I open solution WebApp1Solution, it loads my workspace with projects from Libraries and Web Applications folder.
I would like to suspend my current workspace environment for both web apps and all shared libraries and start working on a specific version of this code from an earlier label (our last deployment). We do not have any branching as of yet.
From what I've read, I think these are my options:
1. Shelve pending changes on the solution and get the specific label version of the solution. What would happen when I check any changes back in?
2. Create a branch in Source Control from the specific label version. Would I have to create the branch on all of the folders in the different locations? How would I switch back and forth between my current code and new branch code?
Any help or advice will be greatly appreciated! Thanks!
Just create a branch at your TFS Project folder into a development folder. You should actually be doing this normally for all of your development. Your mainline branch should never contain anything except for your production deployable codebase. You should always be able to get latest of your mainline and build and run as the production end product.
All developers/teams of developers should have their own TFS folder where they can branch from mainline, make changes, test, etc... then once it has passed all approvals, merge it to mainline and destroy your devline.
As for "switching" your branch is a separate folder from your mainline. You can open both at the same time in different instances of Visual Studio, just like opening two solutions at once. Branching creates a copy of the folder/solution/project structure from the point of your branch. Then when you merge it back it reports differences and attempts to merge. If there are conflicts you will be prompted to review and resolve them. Most of the time TFS does a good job at auto-resolving, but I always carefully review all conflicts before selecting a method of resolution.
I've looked around the site but I couldn't find an answer that covers mine entirely, so please excuse me in advance if I missed it.
I inherited a VB.NET project that didn't have source control (it started as a pet project of a long-gone dev and nobody ever bothered after that to put it in), and by a friend's suggestion I thought about using Git for source control.
The project is a niche product that is customized and sold according to the customer's specs, so that brings the problem that even if 95% of the code is the same for all the customers, sometimes up to 10% of the code is changed and tailored for each customer, by changing or adding lines to existing functions, sometimes adding whole blocks of code, but there's no commonality in the changes between different customers (a function changed in one might not be changed in another).
To complicate things further, due to maintenance contracts, updates made to the baseline app have to be replicated in the customer's branches should they want them, and sometimes changes we make for a specific customer are good enough that we want to put them in the baseline app and replicate them to the other customers, BUT keeping the customizations for each customer!
So with my little knowledge of Git, I thought it would be like:
(customer 1)
C1-----
(main) /
A------B------D
\
\ (customer 2)
C2-----
\
\ (customer 3)
C3-----
...but I can't see how it's going to work after that:
Can I merge SOME changes from the customer's branches into the main trunk WITHOUT merging others that are only useful for that customer?
Can I merge SOME changes from the main trunk into each customer's branches WITHOUT losing the customizations in those branches?
Can I "mark" specific lines of code so they are not merged/committed?
Three or more devs will be working in this, each in his own machine but pushing changes to the company's repository for synchronization. What are the implications for this process?
Right now, every customer has a separate folder and separate project files with all their source code. How would be the import process to put those folders them into Git?
All of this must be done with Visual Studio, with Gitextensions and the Git Source provider for VS. Is it supported, or it has to be done with the console?
Thanks and sorry again if it overlaps with another answer.
I'm relatively new to git and normally use PoshGit for all my operations, so while I may not be able to help you with everything, I hope I can help with some things:
Can I merge SOME changes from the customer's branches into the main trunk WITHOUT merging others that are only useful for that customer?
Can I merge SOME changes from the main trunk into each customer's branches WITHOUT losing the customizations in those branches?
From what I understand, both of these operations can be achieved by using git cherry pick, which allows you to pick a particular commit from one branch, and add it to another without merging the branches together.
For example, assuming you want to add a change made to customer1's repository, to customer2:
First you get the hash ID of the commit from customer 1 that you want to insert into customer2
git checkout customer1Branch
git log
commit 2e8c40025939e8cf41dec70f213da75aa462184b
Author: xxxxxxx
Date: xxxxxx
This made a change that you want...
You then copy the first few characters of the hash you want to cherry pick, change to customer 2's branch and cherry pick it into the branch.
git checkout customer2Branch
git cherry-pick 2e8c40025939e8c
Now, if you do a git log, you'll see your cherry pick at the top. A similar tutorial can be found here (http://nathanhoad.net/how-to-cherry-pick-changes-with-git)
Can I "mark" specific lines of code so they are not merged/committed?
You may find help from a similar question was asked and answered here:
Commit only part of a file in Git
Three or more devs will be working in this, each in his own machine but pushing changes to the company's repository for synchronization. What are the implications for this process?
Since GIT is a fully Distributed VCS, each dev on your team will effectively have a full clone of the central repo on his own machine (complete with full history of that repo.) This means that log history queries and other requests (such as finding out who did what) don't need to go through your central server, but can be done privately and offline by each dev.
Similarly, the changes that each dev makes will become available to all of you (for example, all new branches will be available), but it can sometimes be frustrating to be working on the same features if you're not quite used to git.
As always its a good idea to commit early and often, this will decrease the tension you're likely to face when changes clash. you should also set some structure to when pushes are done, especially if you rely on each other's work to continue.
Another idea you may want to try is having one person in charge of the repo and having him merge changes and patches to help coordinate your efforts.
Right now, every customer has a separate folder and separate project files with all their source code. How would be the import
process to put those folders them into Git?
EDIT
Thanks for clarifying what you meant by this question. You could expand on a similar approach adapted from the answer given here: How do you create a remote Git branch?
Create a new mainline branch for your BASE project and push it to your remote repository.
cd baseProjectDirectory # navigate to your main project directory
git init # git initialize the dir
git add . # recursively add all files in directory to git repo
git remote add <remote-branch-name> <remote-url> # Add the url to your remote directory to your git repo
git commit -m "Initial commit of base project"
git push <remote-branch-name> <local-branch-name>
This will establish your Baseline project on a remote repository called remote-branch-name under a branch called local-branch-name.
You can then navigate to your other projects and repeat these steps putting your repositories under different branches on the same remote, by using new local branch names, i.e. instead of using the local-branch-name when creating a branch, just use a new branch name, such as git checkout -b new-local-branch-name
so if, for example your base project push (the last line of code) was:
git push clientproject base
Where "clientproject" is the name of your remote, and "base" is the name of your local branch, you can just change the line to:
git checkout -b client1 # Creates new branch named client1
git branch -d base # Deletes base branch
git push clientproject client1
Note that while it's not strictly necessary to delete the "base" branch before continuing, it does keep your repository cleaner and is thus considered good practice. Don't worry about losing anything though, your entire git history from base will be copied to client1 on checkout.
Also note: Since your situation requires you to do this from different directories, you'll probably be deleting a branch named "master" and not "base".
Pushing like this will keep client1 on the "clientproject" remote, but will place the project under on a new branch called client1, complete with its own history.
The same steps can be used for the rest of the projects. If I've lost you anywhere along the way, I suggest reading the above link (it's much more concise than I am).
All of this must be done with Visual Studio, with Gitextensions and the Git Source provider for VS. Is it supported, or it has to be done
with the console?
I haven't yet used VS with Git, but I assume most if not all these operations would be supported since they are native git commands.
Hope this helps.
i have an open source ruby project on github, where my master branch represents what has been released, and my dev branch represents what will be released next.
the master branch is ~ 80+ commits behind the dev branch, and the dev branch contains fairly significant architectural changes.
a contributor has sent me a pull request for changes that were made based on the master branch. i want to pull those changes into my dev branch without having to re-write them or do a ton of merge conflict resolutions (which would essentially be rewriting the changes anyway).
what are the best practices for handling a situation like this?
One solution would be:
"Any patches that doesn't apply in a fast-forward manner is rejected."
You could ask your contributor to fetch your dev branch and to replay (rebase) his/her relevant commits on top of the fetched dev branch.
Once those changes works in that dev environment, then he/she can make a new pull request.
That way, you report the extra work on the contributor, and once this refactoring is done, you can enjoy the contribution by applying it simply on top of your current dev.