0

I have a question regarding Git. The place where I work has 2 developers: myself and another guy. We both developing a VB.NET project using Visual Studio 2008 and all the code and the company documents are all stored in a central local server.

So at the moment if both of us have to work on the same project we copy the code stored in Server1:/Code to our local documents folder and just tell each other what files we are using so we are not working on the same files. At the end of the day we copy our bits back to the server (making sure I don't override his files and vice versa).

I have looked into Git and it seems that it will solve this "Don't change the code of FileA because I am using it" type of problem and will enable us to work on the same project at the same time: i.e we both get a copy of the code from Server1 and develop and we merge both at the end of the day back to the server (or am I wrong?).

Now I have read parts of ProGit book and I get the bit where you add files and do commits but am not sure how both of us will be able to use it at once.

A few questions here:

  1. Where will I create the Git repository? The code is stored in Server1/Code and in Code we have various projects so I guess I have to create the repository in Server1/Code?
  2. After I create the repository, how do we both get a copy of, say project A stored in Server1/Code/ProjectA? Will we just copy paste the folder or use Git?
  3. Because each of us will have our own copy in My Documents and work on that copy throughout the day, how will we merge the files at the end so that nothing gets lost? Let's say I have created a new Form in VS2008 with a button and some code behind it and the other guy has changed some code somewhere else? Or for example, I add some code to FormA and he adds some code to FormA too? How do we merge them at the end?

As I said I have installed git and git extensions on my pc at home and had a play with it and do not mind using either git bash (command line) or git GUI.

Any help will be greatly appreciated guys.

simont
  • 57,012
  • 16
  • 110
  • 130

3 Answers3

2

Given the distributed nature of Git, there are literally hundreds of different workflows, so this is only one example.

Another example of a popular workflow is described here

Where will I create the GIT repository? The code is stored in Server1/Code and in Code we have various projects so I guess I have to create the repository in Server1/Code?

You would create the repository on the Server1/Code:

git init && 
git add . && 
git commit -am "Initial commit"

The above adds everything to the repository (you maybe want to exclude some files, so put what you want to exclude from the repository in a .gitignore file in the root of the project first)

After I create the repository, how do we both get a copy of, say project A stored in Server1/Code/ProjectA? Will we just copy paste the folder or use GIT?

If you use a share you can clone with git file mode:

git clone file:////<host>/<share>/<path>

Because each of us will have our own copy in My Documents and work on that copy throughout the day, how will we merge the files at the end so that nothing gets lost? Let's say I have created a new Form in VS2008 with a button and some code behind it and the other guy has changed some code somewhere else? Or for example, I add some code to FormA and he adds some code to FormA too? How do we merge them at the end?

You typically work in a local branch:

git checkout -b local_feature_branch

When you are done, you can see what changed on the "server" using git fetch origin. This will only update your view of what happened on the server, it will not pull down the changes.

When you are ready to push your changes up to the server:

1) Commit changes

git commit -am "My changes"

2) Pull down changes on server to your local branch:

git checkout master && git pull origin master

3) Merge or rebase your feature branch to local copy of master

Merge:

git merge local_feature_branch

Rebase:

git checkout local_feature_branch && 
git rebase master && 
git checkout master && 
git merge local_feature_branch

Read up on the difference between merge and rebase in answer below:

Git workflow and rebase vs merge questions

If there is a conflict (for example if you both edit the same form etc.), git tells you that there was a merge conflict and what files to merge. After doing the merge you do add the merged file:

git add merged_file

And commit:

git commit -am "Merged with master"

Finally you push the changes back to the "server":

git push origin master
Community
  • 1
  • 1
ebaxt
  • 8,017
  • 1
  • 31
  • 36
  • Thanks for your reply. As it is one big project we just have it in one folder. I know you mentioned branches in your reply. How many branches should I create and why do I even need them? Sorry if it is a silly question. Thanks –  Feb 18 '12 at 15:25
  • You don't need to create a branch, but I prefer to do it because I can keep my master branch in synch with what is happening on the server. Branching is cheap in git, since they are only pointers into the git object database (tree). I highly recommend watching this video to get an idea of the internals of git:http://vimeo.com/14629850 – ebaxt Feb 18 '12 at 15:33
  • Thanks for the reply and I will watch the video. Out if interest, if I want to copy project 1 from the server into My Documents, will I have to create a repository in My Documents first? And also, can I use git clone file to copy the whole Project1 folder or do I have to copy the files 1 by 1? –  Feb 18 '12 at 15:35
  • git clone copies the entire remote repository down to for example My Documents, so no need to create a local repository first. git clone remote_url is the only thing needed to get going ;) – ebaxt Feb 18 '12 at 15:41
  • by remote_url are you referring to a project stored online or simply to the path where the project is stored, in this case Server1/Code/Project1. Also wanted to thank you for your time and patience ebaxt –  Feb 18 '12 at 15:44
  • remote_url can be the path to a shared dir. Git does not require a centralized server. – ebaxt Feb 18 '12 at 16:03
  • I think my question is answered. Thank you so much for your time and patience ebaxt. Would I be able to ask for advice from you if I need any more help in the future? Either by email or through this forum? thanks one more time –  Feb 18 '12 at 16:06
  • I believe most questions you are going go have starting out with git are already answered on this site :) Git definitely comes with a learning curve but believe me, DVCS is the future of VC. And with sites like github etc. git is an extremely powerful tool to have in your tool belt. – ebaxt Feb 18 '12 at 16:13
0

If you are starting with source control I would suggest starting with SVN. It's just easier.

http://www.visualsvn.com/server/ - this will let you create repository in minutes.

  1. You can create repository wherever you like. Then put code you already have in the repository.
  2. After that install Tortoise SVN and/or SVNMonitor to update from/push to repository. For the first time you checkout code from the repository. It will download all the code to directory you specify.
  3. Using SVN you can also lock file for editing. That way other person won't be able to edit it at the same time. But this is not suggested way of working. Generally merges are not a problem because most of the time you will be working on other stuff then your coworker. But if it happens that you edit the same file the first person will succeed at the checkin and the other person will receive message that someone changed that file. Then he will have to update his version of file with the version from the repository and do the merge and checkin. But often merges are automatic.
Piotr Perak
  • 9,824
  • 9
  • 42
  • 75
  • 2
    It's really rude to answer a question about Git with "Use SVN instead." We don't answer questions about C++ with "Use Java instead", and we don't answer questions about Flash with "Use HTML5 instead." – Dietrich Epp Feb 18 '12 at 15:08
  • Nonsense! Person doesn't know a lot about source control. And you expect him to host his own GIT repository? And look someone suggested TFS. – Piotr Perak Feb 18 '12 at 15:09
  • Imagine someone was starting with programming and looking for tutorials on how to write windows desktop software using assembler because he have heard that assembler is fastest. Is suggesting looking at for example .NET Windows Forms rude!? Think before you add comments. That way you don't look stupid. And if you have no help for OP than stay quiet. – Piotr Perak Feb 18 '12 at 15:36
0
  1. You will have three Git repositories. One central repository (bare), and one private one for each developer. Put the central repository on a server somewhere, put the private copies on your hard drives.

  2. When you want to get a copy of the code, you use git clone. When you want to update your copy of the code, you use git pull, or you use git fetch followed by git merge (which is the same thing). Don't copy a folder with a Git repository manually.

  3. Whenever you finish making a logical change to the project, push the change to the central repository. If the other developer has pushed first, you will get a conflict. So you'll have to pull the other developer's changes, merge them into your code (or rebase, if you want), and push again. If you both make changes to the same piece of code, you'll get a merge conflict when you merge on your local machine. You resolve the merge locally and then push the finished (tested!) version to the central server.

Don't push to the central repository just because it's the end of the day. If at the end of the day you're halfway through a change, you'll end up sharing broken code which is no good for your partner. Wait until you are finished with your change and then push.

As an alternative, you can push to a separate branch on the central server if you've got something in-progress.

Dietrich Epp
  • 182,361
  • 34
  • 307
  • 387
  • Would we be able to pull and push from within Visual Studio using git extensions or do we have to do it manually using the command line? The reason why I am asking is because the project has about 120 forms and it will be a pain to have to write push file a, push file 2 etc 120 times. Thanks –  Feb 18 '12 at 15:26
  • You push an entire branch at a time, which is the entire tree and history. I use Git Bash on Windows, so I am not familiar with plugins for Visual Studio. (`git add` adds a bunch of files to the "index", `git commit` turns the index into a part of your history, and `git push` pushes your history to another repository.) – Dietrich Epp Feb 18 '12 at 17:05