Work with Git without using local branches

After reading another article about Git , I just could not fail to describe my approach to the solution of the issue, which does not pretend to be particularly original. I have been successfully using git for the last year, creating a minimum of local branches. I will not insist that doing it right or wrong is just sharing my experience. And for all who are interested in "how" - I ask under the cat.

Disclaimer

I did not try to get rid of and translate into Russian such well-established words in our circle as “commit”, “staged” files, fork, pull request (does anyone read a git man in Russian?).

I know that Git can be used without a central server, but in my case (and most often) in projects there is something from GitHub, BitBucket or their analogs.

Probably, this article is not aimed at getting to know Git. Rather, I recognized myself in the author of the article I mentioned: once I was tired of a bunch of local branches lying in my copy. And at that moment I already had a good understanding of the nuances of the Git commands, and I decided to risk trying to work without local branches. The experience was successful - and I want to share it.
')

Let's start with the question: “what functions does the local branch perform?”

Most often, it only keeps track of the deleted analog (with the same name or not - it does not matter), constantly synchronizing with it. It is easy to transfer local changes over what is in the remote analog by typing git pull [--rebase] . But you can still have uncommitted changes (both in the index / stage and not staged files).

You need:

1. save uncommitted commits
2. keep unfixed files, possibly separating staged from not staged, perhaps even breaking up these files into 3-5 different versions of changes.

As a result, we usually use git stash, create new local branches, which again increases their number.
Our original branch remained tied to a remote one, but newly created branches lost this advantage - and you still have to learn the extended syntax of the git push command. How often do we do git push not HEAD states (except with tags and deleting a remote branch)?

And what else is a local branch carrying in difference from a local commit? And who had the error “There is no tracking information for the current branch” when typing the git command? Every time you have to remember the command of binding a local branch to a remote one. And if my local branch needs to be linked to two repositories? And when git merge b you need to remember, does your b match with origin / b - is it better to do git merge origin / b right away?

"But I have branches that are not tied to the remote!"

Here it is necessary to clearly understand the answers to the following questions:

1. When was the last time I worked with this thread?
2. When will it be sent to a remote repository (or frozen into one of the branches, which will fall into the repository)?
3. Why is this thread not sent to the repository now?

I am working on several projects. But in each project over one task at a time. Because HEAD, I most often are in the state of that very task. And only in the case of postponing the task “for later” I create a local branch, without sending it to the server. Why not git stash? Stash is easy to lose by clearing. Since “task switching” occurs infrequently, one has to recall the git stash syntax in order to add a meaningful description of the changes made (and not the name of the commit on which the stash was made). Isn't it easier to just make changes to a commit, the syntax of which I use dozens of times a day — with not only descriptions, but dates also? When these branches fall into the general list of local branches, it becomes even more dangerous to clean the list of local branches. Then I decided for myself that I did not want to see all branches sent to the repository locally in the git branch - I can always do git checkout origin / b instead of git checkout b .

Imagine that you are sick or have gone on vacation or for any other reason do not go to work - where can someone get what you worked on (your unsent local branches)? That is why I prefer to have them as little as possible.

What if?

From the above recipe, it begs a simple one: “commited? checked? - start it! ”

“But what if you don’t have time to check?”
If you suddenly fall ill, and your work may be needed by someone, it is better to do a git push anyway. Depending on the importance of the stability of the branch, changes can be sent to a branch with a different name.

If these changes are not needed by anyone, and I do not want to work on these changes at home at night, only in this case I leave the changes without git push.

Well, the last option: "not yet commited." Then the task to which I switch is most likely very important, not tolerating deposition. And this means that I will soon return to the current state: I am creating a branch, a change comm. When I come back, I easily find the branch I need (I don’t have enough of them) and continue to develop, deleting the branch.

So what if git status shows “Not currently on any branch”? Proper use of git log will fill in the missing points. And so - the procedure remains the same: git add, git commit. Only git push origin HEAD is changing : b (I hope everyone is already using git-autocomplete, which helps you quickly type in the names of branches?)

And what if git push regected? How to do without git pull [--rebase] ? I have not used git pull for a long time - I don’t want to remember the syntax of another command: it is easier for me to do git fetch origin and, depending on the situation, either git merge, or git rebase, or just git checkout origin / b (if there are no local commits). Especially this approach helped me to control each step in cases where I had several remote repositories - and they had to be intertwined with each other (which version lies in releases / b is clearer than the version in branch b ).

The life of the branches after pushing

It all depends on the workflow in your team. Most often, the repository server is synchronized with the task tracking system (for example, JIRA). Systems like BitBucket have the option to delete branches after a pull request merge based on this branch. In general, everything lives on the remote repository according to the configured rules (the main thing is sometimes to do git remote prune origin ), and does not affect my work with Git. However, knowing the merit pull request from the console also never hurts!

Instead of an afterword

Everything that you have locally is your own. No one wonders how many local branches you have in the repository - your team sees only what you have “started” (unless, of course, your local version of the project is a remote repository for others). And so, organize work with local Git entities, as you see fit - no one has the moral right to judge you for this until the "running" result of your work suits everyone.

My result has been satisfied with my team for the past year.