3 min episode 3 of 24
In this video, we’ll show you the very basic workflow of version control and which steps are involved.
First of all, you’ll need a repository. Let’s say you’re starting a new project on your local computer and already have some working files on your disk. In that case, you can simply create an empty repository and start version controlling your project.
If you’re getting on board of an existing project, chances are that someone else has already uploaded the project to a remote server. In that case, you can download or “clone” a copy of the project to your local machine. This will provide you with a full-blown repository on your disk - and of course the project’s working files, too.
Now that you have a repository, it’s time to work on your project. Change files, edit, delete, copy, or move them. In any way you like, and in any application. You can use your favorite IDE, editor, file browser, or image processing app. There’s really nothing to watch for in this step.
After some time of working, you’ll want to take a look at which files you’ve modified - and how exactly you’ve modified them. Git will provide you with an overview of your current changes.
You might have finished a part of a feature, or maybe fixed a bug. You can new record this state of your project as a new revision. But before you can save a new commit in your local repository, you have to tell Git which changes you want in that next commit. For, just because a file was changed doesn’t mean it will automatically be in the next commit.
Instead, you have to add these changes to the “Staging Area”.
With a couple of staged modifications, you can now wrap them up in a new commit. Together with some metadata - like the author’s name, the current date and time, and a good message - this is saved as a new revision in the local repository.
After some time, you might want to look at the project’s commit history. This shows you which commits were made and helps you understand how the project evolved.
Finally, you might want to exchange commits with your coworkers. That’s what remote repositories are for: each member of your team can publish her changes there and download new changes from others. Note that this step is completely optional; if you’re working on your own, it might be you never need this - and happily work with version control on your local computer only.
That’s the basic workflow when using Git for version control. Thanks for watching - and see you soon in our next video.