Git to najpopularniejszy system kontroli wersji. Pomaga hordom programistów pracować lepiej, wydajniej i bardziej elastycznie. Pomimo że liczy sobie już ponad trzynaście lat, wciąż wiele osób używa go źle, zabijając w ten sposób produktywność. Czego nie robić, aby sobie nie zaszkodzić?

Git is simple but different – it is probably the most popular version control system (vcs) used in it projects around the world. It is also very often misused because although it is very similar to other vcss at the api level, it is very different underneath. Let’s take a look at the nuts and bolts of git to understand it better and, as a result, to use it properly and effectively.

Czasem potrzeba połączyć commity, aby zapewnić ich większą czytelność lub po to, aby je uporządkować. W tym wpisie pokażę, jak można to zrobić.

Quite often when you play with dependency updates or project configuration it’s needed to clean the solution. Especially if other teammates claim it works on their machine (or even on build server). Unfortunately neither “dotnet clean” nor “Clean” command in Visual Studio work as expected and sometimes leave some leftover. So here’s the trick that I learned from one of my colleagues...

Wersją roboczą nazywam pliki na którymi pracujemy, to te gotowe do zmiany. Zmiana gałęzi, zmiana HEAD naszego repozytorium powoduje również zmianę wersji roboczej. Zazwyczaj ta zmiana jest bardzo szybka, ponieważ git jest bardzo szybki, ale… im większe repozytorium i większe zmiany między wersjami, to czas potrzebny na przełączanie rośnie. Czasochłoność przełączania powiększy także IDE, bo zmiana plików projektowych pociągnie za sobą ekran konieczności przeład...

Jeżeli chcesz zignorować pliki, aby nie były proponowane do dodania, używamy wpisów w pliku .gitignore, które znajduje się najczęściej katalogu głównym naszego repozytorium. Problem w tym, że ten plik jest dzielony z wszystkim, który korzystają z tego repozytorium. A co w przypadku, gdy chcemy zignorować pliki, które znajdują tylko na naszym komputerze? Na przykład jako jedyni w zespole lubimy korzystać z jakoś narzędzia, które generuje jakieś pliki. Nie chcemy...

In order to keep your git environment in a good shape you need to clean up branches from time to time. It is especially difficult in case of build servers which complete pull requests on behalf of developers (like VSTS). It’s easy when you have just a few branches to review, but if you forget to do some cleaning for longer while then it’s getting painful. For sure you do not want to remove effects of your work by accident during cleanup.

Problem which needs to be fixed: Project has two main directories with a lot files. Some of files are almost the same. Some changes to those files should be transfered to other main directory.

Let’s say we remove (by mistake) feature/Democratic branch with force (cause branch is not merged into master). git branch -D feature/Democratic1git branch-Dfeature/Democratic To revert that change we need to find SHA1 of last commit made on that branch. Where to look? If you use terminal look at branch deleting command.

Ostatnimi czasy natknąłem się w internetach na model pracy z repozytorium GIT wykreowany przez Vincenta Driessena. Jego podejście sugeruje by trzymać się dwóch głównych gałęzi o nazwach master i jej podgałęzi rozwojowej develop. Gałąź master odzwierciedla docelowy kod programu jaki znajduje się na produkcji z niej...