user1218115
user1218115

Reputation:

How to get GIT working in my case?

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.

Upvotes: 0

Views: 249

Answers (3)

ebaxt
ebaxt

Reputation: 8417

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

Upvotes: 2

Dietrich Epp
Dietrich Epp

Reputation: 213328

  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.

Upvotes: 0

Piotr Perak
Piotr Perak

Reputation: 11088

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.

Upvotes: 0

Related Questions