Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I've got several questions about the latest function GitHub nested in VS2013 ( I didn't install any other 3-rd party Git tools).
If I fork a project in the GitHub website as a server side, and I clone the project into my local disc and do editing, deleting , adding files……, then:
1) If I "commit" all the changes, will these changes impact my forked project on the server side?
2) If I then "Push" all the changes after commit, will these changes impact my forked project on the server side?
3) If I then "Push" all the changes after commit, will this also send a pull request to the original project where I forked so that the original author knows I've sent some changes and maybe he/she can do merges?
4) If I click "Pull", and if the original has some changes (differing from mine), will my fork project be synchronized with the latest version from the original one?
5) If I click "Fetch", what will happen? what's the most difference between "Fetch" and "Pull" in VS2013?
1) If I "commit" all the changes, will these changes impact my forked project on the server side?
No, when you do a commit locally this affects the local branch, not the remote one.
2) If I then "Push" all the changes after commit, will these changes impact my forked project on the server side?
Yes, pushing your branch is how you "sync" the local and remote versions.
3) If I then "Push" all the changes after commit, will this also send a pull request to the original project where I forked so that the original author knows I've sent some changes and maybe he/she can do merges?
Yes, my recollection is GitHub will do this.
4) If I click "Pull", and if the original has some changes (differing from mine), will my fork project be synchronized with the latest version from the original one?
What happens depends on your pull strategy. You could trigger a merge or a rebase. This will depend on your settings. In either case, yes you will "sync" with the remote branch.
5) If I click "Fetch", what will happen? what's the most difference between "Fetch" and "Pull" in VS2013?
Doing a fetch will tell Git to bring in the changes from the remote to your local Git system but it will not merge or rebase the changes in to any branch. Here is a simple equation for you to remember:
git pull = git fetch + git merge/rebase
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.
I have small experience using git repos. So i'm a little bit confusing, trying solve my problem.
I use Xcode installed (not vie terminal) git system and remote github repo.
The problem is for some reasons I've been commiting code for last 2 weeks not inside my master branch (it's the only one), but somewhere else (in source control navigator it seems on project level (high blue folder with project name)). So because of that i coudn't and still cant push changes to github.
if i select master branch, the last commit was 2 weeks ago. However if i select highest blue folder with project name, i see fresh commits.
How can i carry over all commits (or at least the last one) back in my master branch, which is connected with remote github repo and not lose data?
And what actually happened?
From your comments, it appears that somehow you ended up in a detached HEAD state, to which you have made several commits. However, it is easy to get out of this situation. Just checkout a new branch from your detached HEAD state, and then merge this branch back to master:
# from ac4c47c
git checkout -b your_branch
git checkout master
git merge your_branch
Then, you may push master to GitHub. Or, you could push your_branch to GitHub and open a pull request back to the master branch. Note that if you have unfinished work currently in your working directory and/or stage, you should finish it and then commit before creating your_branch.
Our team started using TFS few months back and we are learning as we progress. We first checked in our existing code to TFS thereby creating a Main Branch. We then created a Development Branch from this Main branch.
We just did a release and I merged Development branch with Main. It asked me to map Main branch folder on my workstation. Done that Merge completed successfully. But after merge I noticed on server that change sets are still old and source code on server has not changed.
looking further I noticed that the changed file is marked as 'merge pending'.
When I opened solution from mapped folder of main branch, I did see that all changes from Development branch merged to Main are in pending state.
Questions
Do I always have to check in pending changes after each merge in TFS
Is is possible to merge source code on server instead of from
workstation (All code in development is in Checked in state).
I am using VS2012 (if that matters)
Please advise, especially if I am taking a wrong approach with TFS.
In answer to your questions:
Yes, you always have to check in pending changes. Pending changes are local to your machine, they give you the chance to review the result of the merge locally before they are committed to the server. This is especially important because the merge may result in a conflict that you need to resolve before you can check in.
I don't think that this is possible (although I never researched this specific question). This is, again, because of the possibility of a conflict that needs to be resolved manually. Even if you perform a merge programmatically via the TFS API, the merge will happen locally.
Don't worry, you are doing the right thing. Only one word of warning regarding merges in general: Before you attempt a merge, always make sure that you perform a "get latest" operation on the target branch! The source branch does not need to be up-to-date on your local machine because the merge operation will get the source branch data from the server. But the changes will be merged with whatever version your local target branch files have, so if these are not up-to-date you will get unexpected results.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
Suppose a deployment pipeline is going on. SVN tagging and development version change is going on. At that time a developer is committing his changes. so there is a chance that CI server releasing the new committed untested changes to the production or some other conflicts occure. How can I handle this situation. Do I need to lock the entire trunk until the build pipeline completes. Is there any other work around.
If I understand correctly, you assume the following steps
after a commit, the build server will check out the current trunk (let's say revision A),
perform the build,
execute some tests,
tags the trunk if the tests are successful
and deploys to production (still only if tests are successful)
The "crazy" developer commits between step 3 and 4 and thus creates revision B. Now you assume that the build server will again check out the latest revision (which would be revision B). This behaviour could indeed cause some trouble.
However, the build server should do all the steps based on a specific revision which is not a problem in common setups. E.g. Jenkins usually has a check-out step at the beginning of the job. If there is a tagging step in the end, you will usually not want that Jenkins blindly tags the current trunk (causing the problem you describe) but instead tag the revision that is checked out in Jenkins' workspace.
Additionally, please consider that there should be at least some manual approval step before anything gets deployed automatically to production. This is usually mentioned in the context of continuous delivery as far as I can see.
The key to continuous delivery is IMHO that you are able to deploy the current version of your source code at any time at the push of a button. IMHO it does not mean that every commit should be deployed automatically.
I'm developing an iPhone application with another developer. Our git repository is situated on the remote server.
So we are working with our working copies and then we do commit, pull, push one by one and we get our local working copies synchronized with server and with each other.
Everything worked fine until this day. Other developer successfully pushed his changes to the remote repository, and now it is my turn: commit, pull changes from the remote repository, maybe merge them somehow and then push my working copy to the server.
But when I'm trying to pull changes (using xcode's built-in git) I'm getting an error:
"The operation could not be performed because "%reponame%" has one or more tree conflicts".
Please, guide me through the process of solving this problem. And, please, provide useful tips to avoid this problem in future.
I guess xcode uses option to force fast-forward merges when pulling from repository. That is not bad idea, becouse it prevents you from undesired merges.
Try to use git pull --rebase (resp. check some appropriate checkbox in xcode), it should remove your changes, download new version and then apply your removed changes back. Conflict will occur at the last step so you will solve it and commit that changes again. Then you can push them on server.