Czasem zdarza mi się, że dodam do projektu jakiś plik i zanim wrzucę go do repozytorium, to on jednak okazuje się niepotrzebny. Do tej pory usuwałem ten plik ręcznie, albo w Eksploratorze Windows albo wpisując komendę: rm <ścieżka do pliku>, gdzie z racji tego, że projekt jest spory, to ścieżka do pliku zawiera w sobie kilka folderów. Jest jednak lepsze rozwiązanie.

Ostatnio bardzo mocno „katuję” swój mózg Gitem….hmmmm…uprzyjemniam mu chwile Gitem. Z racji tego, że w pracy nie mam możliwości poużywać sobie Gita w miarę często, eksperymentuję w domu na swoich pet-projects. Używam, używam, używam i nudzi mi się już ciągłe wpisywanie komend w konsoli. Rzecz jasna nie zamienię jej na inne narzędzie do pracy z Gitem, ale kiedy już pamiętasz te bardziej popularne komendy, odechciewa się. Pisałem już od dodatkach do PowerShella, również w kontekście Gita. O ...

Jeszcze parę lat temu, gdyby ktoś mi powiedział, że mam zrobić jakikolwiek rebase, to uciekłabym daleko. Wszelkie akcje w konsolowym GitBashu napawały mnie przerażeniem. Dzisiaj już wiem, że konsola nie gryzie i można z jej pomocą zrobić wiele ciekawych rzeczy - np. przydatny rebase interaktywny.

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.