Transcription
It's a bit scary, honestly. Well, it happens. It's my first, first, first time with a podcast, right? Then congratulations. I think that in any case, everything will be fine, we will succeed. Okay, well, let's start, as already, right? Hello everyone. My name is Sergey Sychev. Today I have Stas Daneev as my guest. Stas, hello. Hello. Today, Stas and I will break down a topic like working with Git. In fact, today we will talk about some of the basics of working with Git. That is, this video will be more intended for those who are just entering this topic. So Stas will tell and show generally how to get involved, how to start using this tool. So. And first, Stas, I'll ask you to tell us a little about yourself, how you got into 1C, what you did in this area, and where you are currently, right? Hello everyone again. I was born and raised in the Far Eastern city of Khabarovsk. And I got acquainted with 1C quite a long time ago, when I was working, when I was still a student. It was 2001. At that time, I was studying to be a programmer, software engineering at the Khabarovsk Technical University. And, well, of course, I thought about what to do after university, where to go. The choice in the IT field then was, well, very small. Either go into databases, learn SQL, or 1C. I also learned about 1C after databases. One of my friends called me and said: "Do you want to study to be a programmer?" There is an entrepreneur who is looking for an intern, a programmer student. Well, you'll learn, you'll do some paperwork, you'll gain some experience that is relevant in the market. I naturally agreed, went to the first lesson. So, this was my first mentor. At that time, there was no concept of mentorship, mentoring, but I started learning directly from a mentor right away. I want to ask you right away, what year was that? It was 2001. I see. I even remember clearly, it was December 2001. So, before New Year, I wrote my first processing in 7.7. Yes. I started my path as a student programmer with a mentor. When I came for our first conversation, it was offline. Two people were present. The first thing they told me was that in 1C there are several versions of the platform, there is the current version 7.5, but just yesterday the super new, super modern 7.7 came out. We will teach you on it. And so I began my journey in 1C. On the very first day, I wrote my first external processing. As I remember now, it was a register of invoices in version seven for accounting. How did you manage to do that on the very first day? It's truly amazing. Yes. So, they immediately showed me how the configurator is structured, what objects exist, what algorithms. So, we immediately opened the module and started programming, creating algorithms. Since I was already a student in software engineering, on the software engineering faculty, I already knew some programming languages, the basics, so, the basics of programming, we just opened the modules and started writing code. So, they told me what objects exist, what methods they have, right, as it's called now. And we went straight into procedures, loops, and forward. We made a layout, filled it with the necessary data, and got a report. Okay, tell us what happened next, how did your career develop? Then, after some time, when I realized that I could already do something independently, I had my first and only client at that time, from whom I even earned a small income, about 2,000 rubles a month, I started thinking about increasing my income, because I wanted money. And I looked through ads. Back then, a newspaper with job advertisements was popular, and I called, called several companies. In one of them, I was invited for an interview and hired. It turned out to be a franchise, one of the Khabarovsk franchises, where I had a quite successful start. I studied several standard configurations, passed the 1C Specialist exam for Trade and Warehouse 7.7. For the same configuration, in our training center, which was created by our franchise in the city, I developed my own course for Trade and Warehouse 7.7 and taught it in our training center. At that time, there were no methodological materials from the 1C company, but I wanted to expand, promote, yes, the knowledge of 1C, bring it to people. And when the director organized this training center, he was looking for guys who would be willing to create their own courses. And this was my first experience of creating and teaching my own course. Tell me, how long after you got into 1C did you start teaching your own course? How much time passed? If we talk about my internship, it lasted about eight months, seven-eight months, I don't remember exactly. After that, I worked at the first franchise, how to work with clients, the client base, somewhere, well, another year, probably. So, about a year and a half to two years from scratch to teaching, so to speak, right? Here's a small teaser that we will also talk about at the end of our video about what Stas is doing now, including what courses he has now. Well, this will be after we show the entire demonstration of working with Git. Today, Stas will also demonstrate all this work, will show the basics of working with Git. So, well, there will be something interesting at the end. So. And I ask you, Stas, to continue. What happened next? How did your career develop further? Well, then, actually, I worked in franchises for about five years in different ones. There were two or three of them. And then I moved to fixed positions, to fixed positions. One company, then another. And here, here's a question from the audience, why fixed positions? I wanted to delve deeper into specific projects, not just run around, updating configurations, reports, and creating print forms, but I wanted to immerse myself in some large project. I wanted a large project, to lead this project, and to make a significant contribution to the business development. And it seemed to me then that a fixed position was very well suited for this. At that time, such vacancies began to appear. And I moved to one of these companies, started working. I don't even remember what company it was. I've changed over a dozen employers in the past 20 years. So, you, roughly speaking, are talking about how you worked in a franchise, then moved to a fixed position, right, so to a direct employer or an end-user employer. What did you achieve in the end, where are you now, and what are you doing? It was Infostart, Automacon, my penultimate place was 1C, Romania. That is, after I relocated from Khabarovsk to Serbia. I am currently living in Serbia. And my last place of work, where I am currently working, is an international European company with its headquarters in Poland, where I hold the position of a developer. Tell me, how did it happen that 1C is used in an international company? Are all of them Russian-speaking there? No, not all, but, well, specifically our 1C development team is Russian-speaking. These are guys, mostly from Belarus, some part from Russia. We speak Russian among ourselves, right? And the official language of the company is English. And you write in English, accordingly. And we write code in English, yes, all code is written in English, documentation is in English, and comments in the code are also in English. Yes, we recently recorded a video with Alexey Snetkovsky. Well, this is, I understand, your your your previous colleague. Yes, at our previous place, we collaborated very closely with Alexey. Yes, he also, he also talked about this approach. Well, and he said that, in fact, 1C in Europe is one of the tools. Here, essentially, if we are talking about a certain area, well, in the area of accounting systems, it is a monopolist, and there it is, well, alongside other tools. Yes, here, in Europe, it turns out that alongside others, and even not in the first places. Well, as you know, the 1C language ranks somewhere in the hundreds globally, but nevertheless, it is successfully implemented and covers a certain range of business tasks. Okay, let's now, we have introduced the viewers to your career a bit. Now let's move on to, actually, the main narrative, the subject of our conversation, Git. Explain in simple terms, how do you understand what Git is? Git is a version control system, that is, it is what helps not to lose the development history, not to lose the development itself. In general, how I started using Git. When I worked as an architect on the ZUP system in one of the companies, a lot of external peripherals were developed besides the configuration itself. These are exchange rules, external processing, reports. And I wanted to keep all this somehow relatively together and not lose the thread of the narrative. Who developed what, what followed what, in what order, and where is which version. So, one developer developed a processing, it was put in a shared folder, another made changes to it. Which version was the first, which was the second, what exactly was changed. To answer these questions, it was necessary to perform some additional actions. And I wanted to somehow reduce this routine and automate it more. I started, got acquainted with Git then, learned what this system is for, what it allows, and realized that it is the ideal tool for solving such problems. Roughly speaking, Git is a utility on top of the file system that tracks changes in a specific folder. By folder, we mean a Git repository. That is, it is our project, which contains everything and is under the supervision of this system, the version control system, which tracks which file has changed, what exactly has changed in it, and all changes in a chain of commits, that is, a sequence of fixes and versions, are recorded one after another, fixing at the same time who made these changes and what exactly was changed. You've already anticipated my next question. The question is: what's the benefit for a developer? What are the main points that a developer gains when they start using Git? Well, first of all, I really like distributed data storage. I've had very unpleasant moments a couple of times when you immerse yourself in development all day, developing, developing, and then your hard drive fails. Hard drives were not as reliable then as they are now. And a couple of times they failed on me. And everything that was worked on during the day was simply lost. I had to start over. It's a very offensive, unpleasant moment. And Git helps to save from such things. So, when you have not only a local set of your versions and history that you have committed, but also a clone in the cloud on GitHub or GitLab, it's very convenient. So, it's immediate reliability, it's distributed storage. So, at any moment, you can return to a version stored somewhere in the cloud. If, for example, something happens to the local version, that's the first thing. The second is, actually, the versioning itself, when at any moment in time you can look at the versions, what happened at different stages of the project's life, what improvements were made to it. It's a very popular operation now. Well, now I'm working, we also use EDT with Git, of course. We often have to roll back some part of the development or even not roll back, but compare what was done before working on a specific task, on a specific feature, and what has changed after it. What changes were made? Either roll back, or add what was accidentally overwritten from some of the previous versions. Well, I also, look, I see the main features of Git for myself. I'll approach it from a slightly different angle, right? Again, I also had trouble with data saving, with working with data, but the trouble was that my storage failed. Unfortunately, I had such a problem. In recent years, I haven't encountered this, but before, I assume it was due to network problems. So the storage failed, and, you know, I had to restore the storage. So, I have the opposite situation. So, I Yes, we also had many stories with storage. And, you know, at work, in our team, we also had such unpredictable behavior of storage when, for example, even if you committed to storage, right, put your changes there, and the tester takes his local version. And your developments don't arrive there. And we end up with different local versions of the configuration. There was even such a thing, right? Then, look, everything related to the tools themselves, review, if we take GitLab, GitHub, well, there's a developed system and it's very convenient to do it there. Moreover, you can compare not only 1C code, but also different things, I don't know, we Yes, absolutely different, yes, review tools, I agree, are very convenient. Moreover, you can specify comments for each line of code or even for each phrase in that line, indicate to the developer that right here, this and that. Yes, it works, of course, much faster. And the third feature that I really like is all sorts of pipelines, right, that can be launched on the CI side. So, this is, roughly speaking, a pipeline, a scenario that you can also write in 1C thanks to VBScript, right, and automate this part of the developer's work. So, after he, for example, puts changes in the remote repository, run certain tests, run Sonar, I don't know, generate smoke tests, run, maybe, functional, maybe unit tests, syntax check, and so on, and so on, and so on, you can do a lot of cool things. This thing saves me a lot of time. Yes, I agree. Well, I'm not a DevOps engineer myself, so I haven't delved too deeply into these things, but I know, well, our DevOps specialists and Alexey Snetsovsky, right, who really loves this craft. Those guys do wonders, they build releases, they deploy to different things, they integrate languages, anything. The next question is this. How did you learn this tool yourself? So, like, how did you start and where did you begin? How did I start? Like, the moment of starting with Git, I, well, there wasn't such a clear, right, my life with Git, my life without Git. Like, I don't remember a clear boundary, but I remember, yes, that there was some moment of acquaintance, it was interesting to know what it was. And what I started studying first about Git was looking for all sorts of free materials, articles, there were even some free courses. And so, bit by bit, I collected stages and immediately practiced them. So, well, there were specific tasks on the project, I had to solve them right away. And what the storage or the current storage system couldn't handle or was inconvenient, I immediately tried to integrate Git. So. Yes. Let's go with examples. I want to hear examples of what exactly you did. Yes. Well, the first thing was exchange rules, which I really wanted to version, because a whole group of guys and I were working on improving and developing them. It was a complex interaction of many configurations in a large company. And when several developers work on the same exchange rules, I really wanted to see what was being contributed and to consolidate all the changes. That was probably the most powerful trigger when I started delving into Git, put my rules into Git, showed the guys how to update from an external repository and make their contributions. At that time, my article about non-idempotency of file changes when saving exchange rules in Conversion 2 came out on Infostart, when you save the same conversion twice in a row, the order of objects changed every time. So, I made an improvement to the conversion itself, so that only the actually modified changes were visible. It's still on Infostart, and it's still downloaded from time to time, so it's in demand. Tell us something else interesting from the practical part. Where did you need Git at the very beginning? The second point is external reports and processing. Again, not everything was immediately integrated into the configuration, and there were many external tools that also circulated, and they were also improved. Git helped to centralize this control of exchanging different processings, their use, and improvements. The most important thing is making improvements to them, so as not to lose anything. Okay, we've given a little introduction to define what Git is, what benefits a developer gets from it. Now I suggest we move on to the demonstration. I'll ask you to share your screen now. Yes, let's move on to the demonstration. I'll show you right now in practice what it looks like. So, first, I'll create a repository on GitHub. I have a separate account on GitHub for this. I created it specifically for conducting demonstrations for my lessons, for my course. And here I will show how to create a new repository. Clone it to my local computer. And upload an external processing there first. Let's see how the upload to files happens, what happens in Git at that moment, and let's make some improvements and see the changes. So, how to see the changes between two versions in Git, what was before the changes, what was after. And then, probably, we'll upload the configuration to a file. I have a prepared demonstration of a managed application. We'll upload it to files and also put it in Git, see how it's versioned, and probably try to work with branches. Yes, let's go. And, you know, I'll chime in along the way, ask myself, well, ask my questions. Yes, yes, from the perspective of possibly clarifying something, highlighting something, and so on, right? Okay, let's start. And, probably, let's start with the repository, probably for those who, I don't know, how is it more convenient for beginners, for those who are completely unfamiliar with Git, well, probably, yes, let's create a repository. I already have an account on GitHub. And here, yes, I'll, excuse me, interrupt. Friends, we'll skip the moment of how to register on GitHub and so on. We won't show that because it's quite tedious processes. Although they are tedious, they are quite simple, but we won't spend time on them now. We proceed from the position that you have already registered on GitHub and are creating your first repository. Yes. Yes, exactly. Because the whole process can take quite a long time, and the podcast can turn into a series of tedious waits, so to speak. Therefore, I will create a new repository right away. So, in my account, I went to my repositories, clicked the new button, and here I just type the name of the new repository and I'll call it demo. GitHub controls the uniqueness of the repository. Here you can enter a description, so, well, this is good practice on GitHub. Each project should be described, what's happening in it, why it was created. Our project will be public, so any GitHub user can access it. You can also create a README file here. I'll just, excuse me, about the README file. We recently recorded a podcast with Anton Detovets. He actually has an article on Infostart about how to properly format your repository. Including what to write in the README file. But again, I repeat, I probably said this in that podcast, when I look at a repository, I naturally, first of all, read this README. It's displayed on the screen by default, and you understand what's in the repository, usually examples are provided there, and so on. So, even if you have very cool code, but you haven't written anything in the description, well, your repository might not even be looked at. Yes. Yes. There is such a practice that everything we look at on GitHub, we want to know, for what purpose the repository is needed, because it's quite difficult to understand what's happening from the code. And when I open a new repository for myself, the first thing I do is go to the root and look at what's written on the main page in the README. Therefore, the project name, the repository name automatically becomes the project name, unless otherwise specified. And this description of the project automatically goes into the README as the first paragraph. It can be further developed later. So, create repository. Yes, actually, after the repository is created, its main page opens. And this README file is shown here, and the repository name, and the description that I entered. Further, there is a "Code" button, with which you can clone this repository to your local machine. You can clone via HTTPS, the simplest, more simple, more complex, but secure, we recommend using SSH. I'll show the simpler SSH key option. I copy it. You can even copy it here. Everything is done conveniently. And what do I do? First, I'll immediately, what are these tools you have? This is CMDR for me - it's one of the options for working with the command line in Windows. So, to work with Git. Git is a shell in Windows, a console shell. Access from the command line is necessary. You can use graphical GUIs, you can use the command line. I use both. So, now I'll show how it's done from the command line, then I'll show how it looks in Git Extensions. To tell the command line that we are working with a repository, I will first create, actually, a folder. I have created a folder called "podcast" for today's demonstration. And I won't do anything here. I'll just type the command "git" right here in the "podcast" folder. This is the command to initialize a new repository. Just a second, there's also a point here. Well, for this command to execute, you need to install Git on your computer first, right? Yes. So, this is another point that we are leaving out of frame. Installation and configuration of Git. There are also a series of actions to be performed, but I already have Git installed. Yes, yes. Let's, you know, do this. We'll just leave a link in the description later, including how to install Git and so on, so that it's easier for people. Yes, of course, I think so, many have already read my article on Infostart about how to start working with Git, actually, to get into group development. We can just leave a link to this article, everything is described there in detail. And here I am forced to backtrack a bit. First, I need to change the active active folder in the command line. So, that this "podcast" folder becomes the current one. And in it, I will create the Git repository. And here I need to paste this copied link. So, something went wrong. Listen, I usually do "git clone" and then the path to the repository. Clone, yes. Clone and repository. Yes, "git init" is slightly different. This is if we initialize a local repository from scratch first, and then synchronize it with GitHub. A slightly more complex path, in my opinion. Creating a repository on GitHub is much easier. And then just clone it. So, it clones. And in this folder, a subfolder is created with the name of the repository, as on GitHub, "demo". And in it, a service folder ".git", which indicates that Git, which is installed locally, monitors this folder, everything that happens in the "demo" folder. Next, what do we do with our repository? By default, the main branch is created in the repository. Currently, it's the "main" branch. Wait, doesn't your Git show "master" or am I mistaken? Master. I might have changed the settings. Yes. No, no. At the top, it actually says that we are now on the "branch" data, it says "main" there. Exactly. But by default, GitHub creates the "main" branch, yes, with these complications, you know, when, you know, they switched it, it was, damn, humanly, right? First it was always "master", then "main" appeared, and then people started Yes, yes. Well, "main" appeared for what reason? So that you can type less, spend less time clicking keys. And a lot is done in Git for this purpose. Yes, there are two versions of specifying parameters, yes, there are parameters with two hyphens, a long word that immediately means something, and they made
Short versions, there is one minus and just one letter. It is not always clear what it means. That is, you already have to keep a lot in memory to understand what parameter means what. And exactly the same with these branches, uh, yes, there was a master, and now main. Fewer letters, it seems. Easier. Colleagues get confused, unfortunately, since my demo folder was created as a repository, nested in the podcast folder, I will now go inside this folder and here CMDR, the command shell, sees that this is already a repository. There is an active folder, the active branch, the main branch master, which is synchronized with Origin, that is, the remote repository on Gitabit. As the next step, what will we do? Let's export some external processing. I will create it right here. I already have the configuration of a managed application open. Yes, I deployed the configuration itself locally as well, off-camera, even before our meeting. and I am creating an external processing. External processing. I will name it somehow. The habit is to write in Russian, in English, but in this case, it is better to do it in Russian. I will call it example. Some form. and some button. Button to do. Let's also put it on the form and create a handler. Yes, yes, we will definitely create a handler so that the code can be viewed. Let's put it on the form and do something. So, we don't have BSP in the demo. We will write something directly, some kind of message. This one, and I save it as an external processing to the file system. I won't put it in the repository folder for now. I will just do it in the podcast folder. Now, how to put it? Now I want to version this external processing, share it with colleagues from my team, and give them the opportunity to improve it, make their changes or suggestions for changes to this processing. What do I need to do for this? For this, I export its files. There is such a command: "Export files". It was actually created so that you can export external reports and processing for the version control system. Everything is exported into text files, .mxl, that is, what can be physically touched, viewed, and differences compared. I go into the folder of the repository itself. And the rule of good tone is to introduce a certain folder structure within the repository. That is, we don't just dump [music] a mess of our external reports and processing, but divide them into folders. A separate folder will be, for example, forms. All external reports and processing will be stored here. Example. Well, let it be called example as well. So, the processing is exported, it has been broken down into files. What is happening in the repository? A repository event has occurred. I would like you to show how the external processing, into what files it was exported. Well, there are essentially two types of files, right? And show the content of these files too. Yes. Yes. Here is the XFMs folder. Yes, ideally, we should have created another nested folder with the name of the processing or report itself. By the way, there is one nuance. Reports and processing are exported without considering their types, that is, just the name. And if we have an external report and external processing that are named the same, yes, but differ in extension, then here they will have the same names and can overwrite each other. Therefore, you need to pay attention to this moment. That is, the report and processing names must be uniquely stated. So, our processing example. And in the root, an XML file is exported, in which, in which the general structure of the entire processing is described. Essentially, its, essentially, the structure of the entire processing itself. And in the nested folder example, there are subfolders, a forms subfolder, which lists all the forms that are in our external processing. Well, and, uh, if there are other subordinate objects, like layouts, commands, then they will also be exported here in separate folders. In this case, forms, we have one form, and again, in the root, there is an XML file that describes this form in general, what elements are on it, the content of the dialog part, and the Forms subfolder. Here is another folder. And here is the BSL module - this is, essentially, the form module. Open it, let's look at it. Let's look. So, this is our module. Exactly in the same way as we saw it in the configurator. Well, look, again, what description I chose for myself, what is inside this processing. Well, essentially, I formulated it like this, again, so that it would be easier for me to understand. It's a kind of zip archive, which contains two types of files: XMail and BSL. XML is all sorts of settings. BSL is, essentially, pure code in 1C. Well, you, you, how can you supplement this description? I mean, again, very primitively and simply to understand what is inside. Yes, a very good description. Essentially, that's how it is, yes? These are XMLs that describe some kind of structure or dialogs of forms. Well, dialogs of forms, and it's not very convenient to look at them with your eyes. For 1C specialists, it might be unusual. And, of course, you should not modify the form in these text files, because the structure and syntax are quite strict. If something goes wrong, if you make a mistake in literally one character, then the processing will not be assembled, and the form will not run. And the module, with modules it's simpler. A module is a BSL file that simply stores our code in text form, as it is in this module, and returns it back to the module in the same form if we are to reassemble this processing. Here, with BSL files, you can work externally, that is, many work with VS Code. I also love this tool. You can directly improve external modules if you are too lazy to launch the configurator, for example, to reassemble the processing or just push your changes to Git, and this module can already be used. So, what else about the structure, about the content of the repository. You had such a file, Gitignore, tell me about it, what is it for? Yes, Git has a number of predefined system files with predefined names. One of them, the most popular, is the Gitignore file. I already have a prepared example of this file for our demonstration. It looks like this. A dot Gitignore without any extension. And if I put it in the repository, it should be in the root of the repository, on par with the .git folder, this file lists what Git should not version. That is, with this file, we show Git which files, files with which extensions. You can specify masks, extensions, specific names. Or folders are indicated this way using a slash, which should not be versioned. That is, despite the fact that changes with such extensions, with such files there or in this folder will appear in our repository, they will not fly to GitHub. Other developers, other team members will not see this. This is convenient so that they don't wander through repositories and, well, and essentially don't clutter our repositories. Those files that are not of interest to us from the project's point of view. These are all sorts of logs, temp files that appear temporarily, then are either destroyed, or if the data cleaning system works poorly, they are not destroyed, yes, they remain hanging around, but we don't need them in the repository, they won't fly there. Well, our favorite, as it were, TMS DB. I don't know if they appear now or not, but in my time it was a very, very popular file. We called them nightstands. They appear everywhere, wherever you can and cannot. You open a picture in Paint, next to the picture, a Thumbs.db file appears. An absolutely meaningless file, it's unclear what it's for. And, of course, I don't want to commit it, so I always specify it as a separate line in Gitignore. And you tell me, what does it mean to commit now, a little bit, well, we're going to get to that, but what definitions, yes, we're just about to get to the commit. You have, in fact, already reached it. Yes, let me open it in Git extensions, so that it can be done in a graphical form. And explain immediately, what is Git Extension? Understood. Git Extensions is an external shell, an external graphical shell over Git, which allows you to do everything the same, or almost the same, as in the command line. What I'm doing now. Only it's convenient to click with the mouse. For us, 1C specialists, this is more familiar and convenient. Well, look at this, we see this "Create new repository". This is when, conditionally, yes, this is "Create new repository". As it happens, to create a new repository. Here you can also clone from GitHub, yes, and you can simply open it, since the repository is already created, I just point Git extensions to it, podcast demo. Here it is opened. And here, in this main window, the version history will be shown. Now we have exactly one version. This is, essentially, the moment of repository creation, the moment of its cloning. Git Extensions shows that there are still changes in five files. If I stand on this line and open the "diff" tab, the list of changes, then it shows exactly what we managed to do during the demonstration. We created processing, exported it, here it is new, it shows new files with plus signs, and I also put Gitignore. It would be good, of course, to do all this in separate commits. Uh, it all got mixed up into one pile. You can commit separately, but that's better. And why are separate commits needed? In your practice, why? Why separate commits? In my practice, and in development practice in general, separate commits allow you to version code in small steps. This is very convenient if, for example, we need to roll back or take changes from another branch of another developer, specific changes are quite specific, there they are related to one button or related to some separate element on the form. If in one commit, that is, at one moment, many different improvements are fixed in the version, then it will be difficult to isolate something or when we roll back, we will have to roll back to the entire version. Let's summarize here. We have a commit, what is it? It's placing into a. A commit is, essentially, a. It's essentially a new version of our project. It's like making a separate fixation of changes in a repository, placing changes into the repository, and it's better to place them in small changes so that. Yes, it's better in small changes, so it's easier to work. Exactly. So, but we are still talking about placing changes into a remote repository. Well, first into a local repository. Uh-huh. Then we'll upload it, probably, to the remote one. Show me how it can be done. Yes. How can it be done? Uh, now, Git shows that it sees changes in files in my local repository, but nothing has happened with them yet. The version is not fixed. That is, this gray tree, part of our master branch, says that the branch, essentially, has not yet formed. It's just preparing for it. Well, that is, there is data that is ready to become part of our project's history. What do I do to fix this version? I open, I click the "Commit" button. A separate window opens for managing commits, for managing versions. Here, once again, you can see what changes have been made to individual files. By the way, what's convenient. Git shows the specific files that have been changed in the project. You no longer need to dig through the structure in the folders, as we did in the file explorer. Here it simply shows the full path to the file, and on the right, you can see the specific changes in this file. We'll look a little later at what it will look like when something is improved here, that is, when it's created from scratch, here is just the full text of the new file. When it's improved, we'll see the changes here. So. And what do I do? Well, let's do it in separate commits. I'll stage Gitignore right now. That is, what is staging? This is, and this staging area or index, in Git terms, says that it contains a list of those changes that will go into the next nearest commit. And here I write a comment for the commit. If comments were optional in the repository, in Git, you cannot make a commit without comments. You must specify what we have done. So, well, I'll write "Added Git". So, I'll add Gitignore everywhere. Well, let it be in Russian. And there are two buttons here. Commit, essentially, to fix changes in Git, and Commit + Push, to simultaneously perform two commands. The first is commit, fixing changes. And the second, push, is to upload changes to GitHub, that is, to synchronize with the remote repository. So, well, I'll do both at once. The "Commit" command has been executed. And then, before performing the push, that is, sending to GitHub, Git Extensions offers me to select additional parameters. I leave everything here by default and simply send the changes to the remote repository. So. They're gone. So, I added Gitignore. Here it is, the green cat. That is, the version is fixed. And let's go to GitHub and see what happened there. My repository, I'll just refresh it. You can refresh the page, or you can click on the repository title. So, nothing happened. We made one commit, but for some reason it didn't appear on GitHub. I will perform the push command again. Most likely, this command did not go through. I click push and see what it writes here. It gave you a 403 error. Uh-huh. Access error. Access error. Uh, yes, that's because you haven't authorized, right? And that's because I logged into GitHub under a second account, and Git Extensions only supports authorization through the main account. I have, that is, it has direct access only through one main account. This is my my account. Uh, Stanislav Ganeev. And this Stanislav Ganeev 981 is an additional one, which I created specifically for the demo. Well, listen, it's good to show errors right away, so that not everything goes smoothly, so that people encounter what they will encounter. Yes, there is a complex authorization setup mechanism when there are multiple accounts on GitHub. Generally a rare situation, actually. Uh, nobody needs multiple accounts on GitHub, but sometimes it's necessary, yes. I needed a second one for the demo now. What can I do to simplify? I can add my main user, the user of the main account Ganeev Stanislav, as a contributor to this repository. To do this, I go to settings. I select contributions. Here I need to enter the password again. So. And here I need to add a new [music] contributor. Repository. I open management. Ah, yes, add a person who will have access to this repository. And I add it like this. The rights should already be there, they should work. Let's check. So, and we will check this using the push command. Let's push again. [music] Ah, ah. So, yes, I remembered. Uh, that is, in addition to adding my main account as a contributor, I also need to go into this account and accept the invitation to contribute to this repository. So, I have a notification here. Invite. Yes. And I agree that I will contribute to the repository of my second account. So, now let's push. Yes. And the command has now passed successfully. I click OK. Yes, all windows are closed. Now we return to our account for demonstration. I open my repositories. Demo repositories. And what do I see here? Yes, the Gitignore file has appeared. Here it is, essentially, in all its glory, in full form, as we saw it in the local repository. So. And now I want to push the changes we made to the processing, the external processing, essentially, adding this external processing, as a separate commit. For this, I again go to the commit window. This time I say to index all changes, all files. In the comment, I write: "Added external processing" or so, "New external processing". And again, commit and push. So, I refresh. Here it appeared immediately, yes, XFMs with our example processing. There are changes. And we worked in the master branch. That is, now we have essentially performed a series of operations that are analogous to working with a repository. We sequentially, one after another, made different changes to one repository, our configuration. Well, essentially, not the configuration, yes, but we have only exported one external processing to the repository so far, but it is already being versioned. There are two versions of the repository. Show on the GitHub level, well, GitHub, how to view different versions at once, roughly speaking, without downloading. Different versions. Ah, yes, let's make some changes to the module. Well, it's more interesting for us to look at the module. Well, we're more used to it. So, and for this, let's do something else here. Well, for example, let's make a more emotional message. Let's add an exclamation mark. "Make on server". What else can be added? So, we are exporting forms. Let's make it beautiful. Let's add a region. And what is the region called, I don't remember in Russian. Ah, form handlers, yes, form handlers. Forms, form handlers. All right, we've included it in the region. Save. So, now, for this version to appear in our repository, so that Git knows that something has changed in our processing, we need to export it again to external files. I again launch "Export files" to the same XFS folder, save. Yes, replace. And now, if we go to Git, I see that there are two new files and one changed file. The changed file is the processing structure. This is the XML file that is responsible, essentially, for the processing as a whole. It has a new XML node that says that a new subordinate element, template, layout, has appeared, and two new files of the layout itself, which are located, by the way, in a new subfolder. Example, there was a Forms folder, and now layouts have also appeared. So, now I will fix this, these changes. I fix all changes with one commit, I write that a new layout has been created. And I send it to the develop folder. And here Git Extensions complained to me. It saw that the Develop folder does not exist in the remote repository on GitHub. It really doesn't exist there. We haven't updated it yet, haven't synchronized it. And it offers to synchronize it automatically. Create on GitHub. I say, "Yes, create a new branch". So the first question was: create a new branch, and now it says: "Synchronize this branch with the local one". I say, "Yes" again. And now the history of our project has been fixed in a separate develop branch. Master remained untouched, it remained behind. And, by the way, here's an interesting moment, which is the first thing that pleasantly impressed me when I started working with Git, is that when switching branches, you can see changes in the local repository on the fly. I'll open the branch. Ah, here's the example processing. Here I have these two folders. And if I now switch to the master branch, roll back to one version ago, I say switch. Checkout to master. OK. My local folder now takes on the state of the master branch. The templates folder is gone. That is, Git remembered this version in the develop branch, but now the local folder is in the state of the master branch. And here, pay attention to the speed, yes, how this operation happens with a repository. How much time does it take, yes? Yes, a repository takes time, it generally takes time, yes. Ah, yes, it takes time here, it's almost instantaneous. Git does all this instantly, essentially, with this it was, ah, the key goal when it was created, when Torvalds started working on Git, he wanted all this to happen quickly. And it really happens lightning fast. What do we have left to do? We still need to merge these two branches, that is.
To see how the Develop branch version goes back into master and rolls out these changes. We will do this through a pull request on GitHub. And, uh, let's again make, let's define a request. What is it? A pull request is a request to merge code. That is, when we have two parallel development branches. one branch is the main one, so to speak, the one that the project branch, the main project or development branch. And the second branch is the so-called feature branch, that is, the branch in which the refinement is currently being carried out. And when, uh, the feature branch is ready for these changes to be accepted into the main development trunk, uh, a request for code acceptance is made. This is done on GitHub. For this, a special operation is provided, which is called pull requests. What am I doing here? I am creating a new pull request, a new merge request. I say which branch I want to merge, the develop branch, and into which branch, the master branch. And here it's interesting, GitHub again instantly shows us what exactly will be accepted and merged into master. A new template, a new new market, and, in fact, the files themselves. two layout files. I say create request. Here I can additionally make additional comments. In general, on GitHub, absolutely everything is commented on, that is, any step, any movement is subject to commenting. By default, the last commit's comment is substituted into the pull request title. It can be corrected here, and here you can make some of your own, uh, additional comments, explanations, what the changes are, so that the person who will later accept our pull request, uh, is aware of what will change in the project after they click the accept button. I won't write anything here, I'll just say create new pull request. Here it is, created. Uh, and here opens such a window, which is the pull request management window. At the top, it shows the status open request, meaning a decision has not yet been made. Below, again, you can enter correspondence in the form of comments. This can be a process, well, a code review process, as a rule. And here, the most important thing in the center window is the accept pull request button. The green checkmark means that we have no conflicts. Conflict management is another area of Git usage. Uh, so why do conflicts arise in Git at all? Because, uh, unlike a repository in Git, development can be carried out absolutely in parallel. even of the same modules, the same lines of code. And in order to then, uh, correctly combine all these changes, merge them into one, uh, Git tries to do it automatically, but when it sees that refinements have been made to the same line of code from both sides, it no longer knows which one to accept as, uh, as the finished result, the final result. I'll add a little to you here. I'll add a little to you here. So what's the picture, uh, conflicts in working with a repository, there are fewer of them, but they still exist. This is a clear example. This is the doubly modified one, right, when we update to a new release from a supplier, we get a menu where you choose to take changes from one side or the other. This is, well, this is what you do in merging. Comparing merges. Comparing merges, yes, when you, but this is not quite a repository. A repository is still a linear history. It's a centralized version control system. So this is also a version control system, but centralized. So, uh, when refining some object, we capture it in the repository, and another developer cannot access it until we release it. What I wanted to say here is that, well, as a developer, right, when I usually worked, uh, with, let's say, with a repository and where I encountered conflicts only in one place, when it was doubly modified, and when Git appears, then the situation is as follows: technically, there can be more conflicts, but Git itself sometimes resolves them. It itself, let's say, chooses and eliminates conflicts. Well, for example, if you do this in 1C, in 1C and in the configurator, in 1C you will have fewer doubly modified ones, the same ones, because it will resolve some conflicts for you, this system is more advanced. But this is again to the point that conflicts in ordinary traditional development in 1C exist. And there is nothing wrong with that. Of course, when I saw it for the first time myself, I was amazed by these conflicts. I had it not in 1C, I went to Java for a while. I got completely lost there, what it is. But when you figure it out, in principle, you can work with it normally. There is nothing wrong with it. Especially if certain regulations are chosen in the development process, then these conflicts are minimized. Yes. Yes. A lot is resolved by setting up certain team work rules. And regarding conflicts, yes, they are inevitable in Git, because it is a distributed system, modules are developed simultaneously, and a conflict can be created right now, if if I had made a change to the same line of code in the master branch before this pull request and simply tried to merge these two branches. So I don't even need a second developer for this. But in this case, we are going the simpler way. I am simply accepting the pull request without conflicts. It even changes color. Merge, it's merged. And in Git extensions, I don't see these changes now because they are in the remote repository on GitHub, but I can accept all changes. I say pull, uh, fetch all branches. Fetch is when it reads the state of all branches of the repository from the external repository and redraws the tree, but at the same time keeps the master branch active, where I was. If I say, pull merge, then I not only read all changes, but also update my master branch from the remote repository. And here, this history of branching and merging back, it is displayed here in the form of such convenient, understandable infographics. I would like to show, of course, the conflicts themselves and working with the configurator, but I think we have already gone too far. We have explained everything in enough detail, so it's possible that it won't all fit into one podcast. If, friends, you are interested in this topic, write in the comments, we will continue to develop this topic. Yes, either continue, or maybe we'll record a video on YouTube. Yes, we can expand on this topic separately. Simply, if we continue to do this now, I think it will take a very long time. Honestly, we wanted to show more, but it's clear that we need to limit ourselves by time. Why was this approach chosen? Because I also encountered this not so long ago. It was a revelation for me that many developers who work on the 1C platform do not interact with Git. Well, some have heard of it, but do not use it in their work. And therefore, we specifically made such a podcast with explanations, where we showed all the details, how to start. This video, in my understanding, should be enough. Well, and the links that we will post under the video to start using Git, because the benefits we talked about earlier, you will feel them from the very first day. Yes, I support you, Sergey. Indeed, the materials that are published on the platform and that are available on the Runet for Git specifically for 1C development are mainly aimed at the developer already having some idea of Git, but to enter this area, this niche, so to speak, there are very few materials for 1C developers. And with this demonstration, I tried to show how to start using Git from scratch. Unfortunately, we have limited time, and we wanted to show working with conflicts, debugging, and working with the configurator. Our time is running out. We can do this next time, or somehow resolve it through other events. Yes, I, look, we are coming to the final part, so to speak, of our meeting. I want to analyze your activities from the perspective of courses. I know that you have courses, which, among other things, you teach developers with. Please tell us briefly about them. Uh, yes, I have my own course, it's called GitHub for 1C Developers. This is exactly what we started with in the demonstration. Only there everything is more detailed with all the installations, settings, specifically aimed at getting acquainted with Git from scratch and smoothly entering this area of knowledge. applied to 1C. There we analyze working with the configurator, working with the command line, Git extensions in detail, each command, what it does, why I created this course. It's precisely for this reason that entering Git for beginners is a rather laborious process, because there is very little information on the internet. And even if you ask for help somewhere locally in the comments, colleagues who are already immersed in this area and have significant experience, well, some experience, usually answer. And this will not help fill the knowledge gaps to understand what a branch is, why it is needed at all, what merge, commit is, why a file has several states, and so on, and so on. Look, this thing is very useful. Do you know from what point of view? I remember my state when I first saw Git. Well, I repeat, it was on a Java project, it was, I think, in 2012. When I saw this branching, this whole thing, you know, you have two branches here, right, and I saw hundreds of them, and all branches were saved, they were not deleted from the repository. Moreover, there were develops, you know, master develop, then releases, fixes. And all this somehow merged, diverged, one flowed into another. When I saw it, I was shocked, and then I saw conflicts. And when I encountered a conflict for the first time, then I just, well, I had senior colleagues who could tell me. And from that position, when I work with Git now, it's a standard tool for me, I use it, and it's normal. And when a beginner comes and looks at it with fresh new eyes, I can imagine what state I was in when I saw it. Although now, again, there is nothing wrong, I repeat, with it. Neither with these branches, nor with conflicts. Everything is quite simple when you figure it out. But in the first steps, it is really very important that someone helps you here. Yes, yes, precisely to understand this base, how it all works, because there are many differences from a repository. A repository is a quite understandable thing, right, it's a centralized system, but a distributed system requires a little, yes, to look a bit wider and from a different angle. Look, at the end of the meeting, I always ask my guests to tell some funny situation from the 1C topic. I also asked you about this in advance, that I will ask you to do it. Please recall something funny from your life. Uh, yes, I remember you surprised me with this question. Honestly, it was difficult to remember something. There are some, well, there are some curious cases that are not even entirely funny, and even teach something. Well, one such case was really funny when I was working as an architect at 1C:Enterprise, and there were many tasks, large teams, test databases were not ready in time, but we wanted to test some things, look at reports, the status of employees, the status of employee directory elements in the environment of production data, the data that is already in the working database. What did I do? I don't accept employees in the directory, well, of course, you can't accept them, but I just created one directory element and named it Zvonka Pukova ZSR Prednik. And after some time, after a couple of hours, the administrator calls me and says: "Stas, you've blocked the work of our department. All the girls here are laughing out loud and can't work." So, such a case, when I secretly wanted to create one directory element, it turned out that it was immediately noticeable. I even added a prefix so that it would be at the bottom of the list and not catch the eye. Another case. This is when a new employee tested our 1C:Enterprise with her last name. Another story with 1C:Enterprise. It was a project when we were making badges, that is, it was a hypermarket chain. It was decided that all hypermarket employees should have such badges on their chests with a photo, position, and department. And the last name, first name was displayed there. I very meticulously checked the layout of these badges so that it was placed correctly on the label, all these gaps, spaces, the photo was correctly aligned. A female employee with a very long last name came to our department. Honestly, I didn't expect it myself. Her last name had 16 letters. Before that, I had encountered last names with a maximum of 10, 11, or 12 letters. When I made a test print of a badge with her, by selecting her as an employee for badge printing, everything fell apart. That is, spaces started to shift, extra line breaks appeared. There was such a case when a person, I say, "Look," I say, "you've only been working for a month, and you've already tested our configuration." Listen, but how did you fix it? Did you reduce the font size? What did you do? Well, look, reducing the font size in this case is a bad tactic, because all last names will be printed in a microscopic font. And there were two gradations. That is, if it's up to a certain length, one font, after that, another font, so that the sizes were adjusted, right? Yes, yes, yes, font size, but there's a bit of programmatic font size control. Understood. Well, we've covered all the main points. Friends, if you're interested, please write in the comments. We'll cover the issues you ask about, maybe we'll have another meeting. We will definitely post all the links under the video. So you can take all the materials and use them immediately. This includes links to Stas's courses. You can, if you're interested, go and see what's included there. Thank you for listening. Stas. Thank you for coming. Thank you, Sergey, for inviting me. Thank you to everyone who will watch this podcast. Good luck. M.