GIT for subversion users (etc scm)

Git is another source control system similar to subversion, cvs, and others. Why similar, but not “new”, “fast” and so on? SCM (source code management) is primarily a tool that allows you to perform the operations necessary for one developer and the team as a whole. When each tool has its advantages and disadvantages.

In this article we will focus on the main functions, without comparative analysis (so as not to repeat the millions of notes on the web). And we will show an example of how to use git when working with subversion.

The main functions that we need: viewing the history of changes, rolling back to any point, the ability to create code branching. Subversion (cvs) implements all of these requirements, and many developers use them daily. Running these commands leads to the execution of server-side algorithms, which allows other developers to see our changes. There is a small problem with this approach: the developer may want to commit an intermediate work, without sharing the results with the team. In addition, the developer may want to make a branch of the project to test the idea - the result will also be available to everyone.
If there are several people in a team, and everyone makes a branch for each idea, then soon we will get hundreds of absolutely useless data. As a result of this, there are policies in teams when and how to create branches.
At the same time, the branching tool is still good and should not be abandoned.
As a result, it is worth choosing a scm system with support for this functionality. These systems still implement the same commands, but each developer is given their own local repository. At the same time the project will consist of several distributed repositories.
In this article we will not consider the process of distributed development.

We use subversion

')
Every morning you run ' svn update ' to synchronize your local working copy with the central repository. Then you get the task through the tracker and start thinking. Suppose you have two solutions to a problem and you need to try both to choose the best one.
After coding the first version and testing, you get some results. Now you need to try the second way. Here the problem arises, what to do with the existing changes? We cannot make a commit because the solution is not ready. You can comment them out, make a copy of the files on the disk and TP, but in any case, this is not very convenient. Ideally, it would be convenient to have both versions, and commit only for the selected solution.
This is where git comes on stage. And you can use it transparently for other team members.

Add some Git.

For definiteness, we will keep our project in the folder: ACME. Those. this is a working copy from your subversion and it contains a .svn folder (.svn is in all subfolders of the project).
' svn status ' will show the current status.

First of all, we need to do the initialization. In ACME, run:
git init
This will create a local git repository that lives in the .git folder. Please note - .git is only in the top folder of the project.

Run:
git status

You will see that all files are marked as untracked. Before adding files, exclude .svn
Open .git / info / exclude and add: ' .svn * '. Now git status will not respond to .svn.
Add the whole project to git:

git add .
git commit -am "initial file import"

In turn, svn status will show the folder. Git. Since we do not need it, ignore it:

svn propset svn:ignore .git .

Now the project files are in both systems: subversion and git. In terms of subversion, the work process has not changed: you use update, commit, and so on.

Suppose you have an idea to test, see how git will help us ...
Run git status to check that the project status is updated. If there are modified or new files (as a result of svn update ) just add them and make git commit . Note that you are in the master branch.
You can create a branch for your idea.

git branch idea
git checkout idea

or

git checkout -b idea

git status will show you in a new thread. git branch will show all branches.
You can make all changes, make commits, tests and so on. At any time you can go to the translation branch

git checkout master

and back

git checkout idea

Working with the idea branch you can create additional branches ...

After making all the changes and checks it would not be bad to return the changes to subversion. First, you can run svn status to view the changes and make svn commit . This is the simplest way, but I recommend taking additional steps.
We will make the branch master mirror for subversion: i.e. svn update and svn commit we will run only being in master.
As a result, we need to transfer the changes to the master:

git checkout master
git merge idea

Since we did not make any changes to the master, the system will make a simple merge forward and we will be able to commit to svn.

You can delete a waste branch:

git branch -d idea

If you mess up something, you can always remove .git and re-init.

Conclusion

In general, git is an almost perfect tool for testing ideas, adding new functionality, and fixing bugs. As best practice, it is recommended to create a branch for each non-cosmetic change. In the continuation is to read about the commands: checkout, add, branch and merge.

Andrew Romanenco
andrew@romanenco.com
www.romanenco.com/gitsvn