Using git in flash development

I began to write this article a long time ago, but I was ahead of it (8.
The main idea was to explain to the flasher brothers how to work with git. In the article I tried to describe my personal experience, and not just to list the obvious advantages of git. Therefore, it will be useful to all.

First of all I will be happy with additions and corrections. And of course questions.

What is git

git is a distributed version control system. It differs from SVN by the lack of need for a central repository (which would still be good to keep) and ease of working with branches (branch). Initially, I decided to try it at work after reading this article , which I recommend.
')
In my company, I was able to transfer client development to git and still have not regretted a minute. From time to time I come across arguments about which version control system is better, I often have to explain how I still like git.

Why git

We all understand that using a version control system is vital. git in daily use proved to be very good and allowed to solve a number of problems. I will give the main advantages and "chips".

1. Distribution
   You can create a repository in a local folder just by writing
2. Having a stable client
   The development process without branching looks like this: version ... development ... version ... development ...
   It can be seen that at each moment of time the presence of a stable version, where you can fix bugs and release, is not guaranteed. Or rather, it turns out that it is possible to fix a certain caught bug only by completing the development of the current version. Simple branches in git allow you to get at any time the version of any previous release and work with it without interfering with the ongoing development. Fix bugs in a separate thread, merge into the previous release and into the current development.
3. The convenience of use
   git stores all its data in one directory, and does not spawn everywhere .svn folders. You can switch a project from one branch to another with just one team or a couple of clicks in the client. At the same time, the contents of the project folder are replaced with a new one, which corresponds to the selected branch. For different branches do not need to create new folders or projects. In most cases, Flash Builder will update all classes and recompile dependencies.
4. There is no need for a permanent connection to the central repository.
   As I have already said, all Comits are saved locally and become part of a common repository only when they are directly pushed into it. It is difficult to imagine, but sometimes it turns out that there is no access to the Internet, but you need to work. Or do you usually forget to set up a VPN to a working repository. Pleases the speed of komitov and the feeling of complete control over the local copy.
5. Convenient partial commits
   Immediately before the commit committee, the files that will be included with git add are marked. At the same time, there is an opportunity to make part of changes in a file in a separate commit, and not the entire file.
6. Ability to hide changes.
   There is an interesting opportunity in git - stash uncommitted files and then retrieve them again. Sometimes it is useful in this way to transfer or temporarily roll back changes, for example, I often forget to switch branches.
7. Availability of graphic clients.
   For git, there’s not a big selection of graphical clients. I liked SmartGit GUI client the most. It is cross-platform and is available for non-commercial use free of charge. It has all the necessary functions, but still sometimes you need to get into the Terminal and execute a couple of git commands. It would be nice to understand them. For Vinda, there is TortoiseGit , on Mac I used GitX for a while, but then it was much worse than SmartGit. For Eclipse (that is, for Flash Builder) there is an EGit plugin that I haven’t liked for a long time. It will be necessary to return to it again, especially since he has just been updated. Perhaps this is not a client trick, but part of the git distribution, but nevertheless, I would like to mention another cool display of branches. In a complex project looks like a map of the subway of New York. I love such abstract pictures.

Todo or what else you need to check

I never bothered to put git-svn and connect git repositories with their svn copies, because we officially use svn in our company, but we could not bear it anymore. I hope everyone will end up with git and it won't be needed.

In the meantime, I offered GitHub as an interesting option for storing projects with access control. But, you see, corporate securiness, etc. (although the code is stolen right and left without it). I myself use it for my personal projects. Comfortable.

Installation and Setup

Git Mac / Linux


First you need to install git itself. The linuxoids will no doubt figure it out themselves, but most likely they have already installed it. Makovody can download the distribution from the official website or install via MacPorts . How to install MacPorts is also not difficult to figure out.

In MacPorts, open the Terminal and enter.

sudo port

Most likely, it will not allow you to install anything through the admin account, so we call via sudo and enter the password. Further we look what repositories which are beginning with git are.

list git*

Something like this will appear on the screen.

git-core @1.7.2.1 devel/git-core
GitX @0.7.1 devel/GitX

GitX is a GUI client about which I already wrote. We are also interested in git-core. To install it, you need to write

install git-core

You can verify the installation by typing git --version in the console.

To access remote repositories you need an SSH key. Generating it on a Mac is no problem.

Git Windows

For Windows, there is a msysgit port. Download the latest version and install.
Git is originally foreign to Windows. There may be some problems with this. For example, for some time we could not get it to work with remote repositories. Swore at the ssh key. Thanks to GitHub for solving this problem. So, do not try to generate a key with Putty. To generate the correct key you need:

1. Run Git Bash console from Start -> Programs -> Git
2. Run ssh-keygen -t rsa -C "your@email.com" to generate the key

GUI client

Now we put my favorite SmartGit . Very pleased that it is cross-platform.

During the installation of SmartGit, if it does not find the .gitconfig file, it will ask for the name and e-mail to be used in the commit information.

Line breaks

When working with the git repository from different operating systems, sooner or later (better sooner) you encounter the problem of line breaks . The community has not come to a common opinion, but GitHub recommends the following settings:

1. Creating a repository is better not from a Windows machine.
2. On Linux and Mac, set the core.autocrlf parameter to input
3. On Windows, set core.autocrlf to true

This is done either by git config --global core.autocrlf true or by editing .gitconfig. There must be added

[core]
autocrlf = true

With these settings, Mac users will work with LF line breaks and commit LFs to the repository, while Windows users will work with familiar CRLFs, but commit LFs.

If you do not immediately configure line breaks, then each time you push most of the files will be marked as changed, although there are no changes to them. At the same time, such files appear from time to time, they have to manually revert. Tell me, if anyone knows what can be done with this?

Translation of an existing project

This method assumes a complete loss of the history of SVN. Start, so to speak, from scratch.

Make a project svn export to get rid of .svn folders. Or in the root of the project, run the command find ./ -name ".svn" | xargs rm -Rf find ./ -name ".svn" | xargs rm -Rf

If your project consists of several separate Flash Builder subprojects, it makes sense to immediately move them into one folder and create one git repository in it, rather than a separate one for each subproject. In the future, it will be easier to mark versions of the project as a whole, instead of looking for the desired state for each subproject somewhere in the past. If you decide to move a folder with a project, it is better to remove it from Flash Builder projects (of course, without deleting the contents of the directory).

In the directory with the future git repository, I recommend to immediately create a .gitignore file with the following contents:

bin
bin-debug
bin-release

This will tell git to not include compiled project binaries in the repository.

Next, launch SmartGit, select Open an existing working tree and specify the folder with the project. SmartGit will create a new repository in it.

Immediately you need to find in the list a .gitignore file, select it, click the Stage button and Commit. The first commit message let it be something like “initial commit”. Now, if you update the current state of the directory, all the files mentioned in .gitignore will disappear. You do not need them. Select all the other files, Stage, Commit, in the commit window tick the Amend foregoing commit ... checkbox, thus instead of the new commit you will add the current change to the last one (perhaps you will see many messages LRL in ... - this means that git following the settings changes the ends of lines of files that are added to the repository to the correct LF).

Congratulations, you now have your git repository.

If you suddenly created a repository before setting the correct settings for line breaks, then follow the instructions of GitHub and run the following script:

# Remove everything from the index
$ git rm --cached -r .

# Re-add all files to index
# You should get lots of messages like: "warning: CRLF will be replaced by LF in <file>."
$ git diff --cached --name-only -z | xargs -0 git add

# Commit
$ git commit -m "Fix CRLF"

# If unix / Mac OSX clone then optionally remove
correct the line endings.
$ git ls-files -z | xargs -0 rm
$ git checkout.

If you deleted a project from Flash Builder, now is the time to add it again (via File -> Import -> Flash Builder Project) and make sure everything works. You may have to make some changes, for example in the import paths and configs, if you transferred projects to one folder. After the changes, do not forget to commit them.

Work with the project

If you have not read this article , I recommend doing it now, because the process described below for working with a project in git is almost completely taken from there. While writing this article, I still work on Mail.ru and write social game clients on Flash. Hence some specificity.

Since we are using git, we will fully use its main feature - branches. So, all my projects consist of a set of branches with different functions and a strictly defined algorithm for working with them.

• master - the main branch contains only release versions that are now online. They are tagged (tag) with the date of filling. From the few informative version numbers I refused. If suddenly something breaks on the combat server, we easily switch to master, make a branch from it, fix the bug and merge it back (plus to other branches so that the same bug is not fixed later)
• develop - the main developer branch. Reflects the stable state of development, which sometime in the future will go into release and will be deleted in the master.
• dev- * - branches for individual features. Many of them are local and do not fall into the main repository. They are developing specific new features of the game. It may be very small changes to one or two commit, or maybe a huge patch that grows a month or more.
• fix- * - local branches of urgent fixes. Usually appear from master, less often from develop. Immediately merzhatsya in the right places.
• release - a temporary branch for release, which will be merged into the master and will be deleted. At the right moment, he fights with develop, and the necessary changes are made to it before pouring.

The algorithm works as follows:

• Practically for every change, a development branch is started up, which will either eventually be developed, or be removed as unnecessary.
• Branches of more or less large changes go to the central repository, small ones usually remain locally with the developers.
• I try to control the merging of big features by looking at the changes made. It is very convenient at this stage to cut off any shit.
• During preparation for release, a release branch is created, which is then merged into the master. It makes temporary changes that are not needed anywhere else, for example, “we need to hide this button in this release, because the functionality is not yet ready.” At this stage it is better not to have big bugs, because then you have to make a separate branch with fixes of these bugs and constantly switch between it and release.
• After filling, release merzhitsya in master and is deleted. The current master state is tagged with a fill date.
• Development continues.

Thus, we always have the source of the current online version, where you can quickly make some changes. Each developer is busy with his own business and does not dirty his sterile central repository with his dirty experiments. At the same time, the history of the komits continues to be recorded, which can always be raised if necessary.

Problems I encountered

Of course, not everything is as perfect as you might think. On the way to enlightenment, I nevertheless had to go on a rake, which I will write about below. Perhaps this information is useful to someone.

1. Admin Resistance
   I tried several times to explain why we need another version control system, because there seems to be an excellent SVN. Admins complained that git is difficult to integrate into the existing system of distribution of rights and access control of resources on the network. This matter did not move from a dead center, I had to keep the “central repository locally”.
2. Peer training
   Colleagues had to be forced to switch to a new version control system, understand how it differs from the usual SVN and learn how to use the new software. Nothing complicated in fact, but you need to be prepared for subsequent ongoing questions.
3. The problem of line breaks
   I already wrote about the problem and its solution above, but since it specifically carried out my brain for a while, I could not write about it in the “problems” section. It is very important to fix line breaks at the very beginning of the project when there is only one branch . Then it will turn into a solid headache.
4. Hands from the w…
   As for Unix-like systems and the command line, my hands are obviously growing from the wrong place. Being a central repository on a Mac for some time, I constantly had to face the following problems related to the fact that I didn’t set everything up right from the start: locked files and file owners. In some way, the git repository files became locked up so that in any way, they didn’t want to unlock even from the root itself. Google prompted a script that recursively unlocks files in a directory. After pushing me from my fellow developers, some files were taken over by nobody, which led to a complete inoperability of the repository. I had to recursively set the directory every time, like, sudo chmod -R 777 /users/valyard/Work/work/Panda/.git/
sudo chmod -R 777 /users/valyard/Work/work/Panda/.git/

   In the end, I wrote a script that did these two things on all projects, and ran it from time to time.
5. Take a closer look at what is going to the repository, and what is not
   Of course, compiled binaries and graphic assets should be immediately added to .gitignore. We have an ant script in our project to build junk and it is a little different on different machines. Perhaps it was worth adding there too, but I just made two different scripts: for Windows and for Mac.
6. Annoying project files
   For some reason, Flash Builder from time to time in the project metadata considers it his duty to move half the lines from top to bottom, which makes him useless, but annoying git when displaying changes. But, nevertheless, I do not consider project files to be a bad idea.
7. Problem generating ssh keys on windows
8. Dislike flashlers to the console
   As it turned out, flashers do not like to work in the console. And GUI clients provide only a small part of the git functionality. Sometimes you have to climb into the command line to perform some kind of operation more complicated.

Useful tips

A couple of words at the end.

1. Make sure you understand the differences between git and svn.
2. Try to bring it to the authorities.
3. Find a person who can correctly configure the main git repository.
4. Try to still use the same IDE in the team, then you can commit the project files.
5. Divide the project into several repositories.
6. Do the commits and merzes more often, after all, even such a cool tool like git cannot automatically merge two branches with a two-month history of commits. Have to sit down to manually poke the buttons.
7. Do not repeat my mistakes.
8. Do not listen to those who scold git.

useful links

• Installing a git public server on Mac OS
• Project model by which we work
• Useful resources
• Great Pro Git Book
• SmartGit is my favorite GUI client
• Great article on Habré and an excellent guide from there

Total

But all the disadvantages were blocked by huge advantages. There were moments when I was ready to kiss my ass for having transferred the project to git, which I wish you (of course, don’t kiss me in the ass, but transfer the project to git)!

PS Questions.

1. How and who controls the merger with the main branch (master) and is there a mechanism for delimiting the authority to perform such operations?
   Controls the main flasher on the project. In my projects I do it. At the git level, I don’t know if there are any distinctions in the available operations.