What is the use case for git for a single developer?

Question

git

Hello.
Finally, I want to understand git and understand how to use it correctly for working alone.
I have 1 project, computer and laptop on which this project is being developed. Accordingly, I need to have the current version of the project files on both machines.
Suppose I did something on my computer, left it unfinished, committed it to a local repository and pushed it to the server. The next day, working on a laptop, I received files from the server and continued to work. But with such a use case, there will be a bunch of commits on the server with unfinished functionality. In fact, the remote repository will become just a place to synchronize files.
How to do it differently and correctly? Create a "dev" branch, and commit everything unfinished to it? And only then in master?

Answer 1

You make a master branch, a dev branch and separate branches for separate features.
You make 2 sites - one project itself (main) - roll out master to it, the second site is a test site - roll out the dev branch to it. You develop the rest of the branches, merge them with dev, roll them out for testing, if everything is fine there, then merge dev with the master. Just when you sit down for a laptop, if there is a new master, do git pull and pull the new version

Answer 2

You work in a branch dev, periodically pouring it into master. For large tasks (not included in one commit), make separate branches from dev.
Pouring devinto master, do it with a key --squashlike this:

git checkout master
git merge --squash dev

There can theoretically be conflicts if you made commits in masterparallel with devwhich you need to resolve, and then you add and make one big commit:

git add -A
git commit -m "Merged dev: %кратко (или нет) основные изменения%"
git push

And so that hanging commits with logical incompleteness do not annoy your eyes, you can merge them before mergeusing the interactive rebase:

git checkout dev
git rebase -i master

An editor will open with a list of branch commits dev. Here you can blind the hated commits using the command squash(and then you will be offered to edit the message) or fixup(they won’t offer here) and then do it git push --force(for one it’s not critical, it’s better to use in the crowd --force-with-lease.
Or there is another option - to stick to the previous commit right away with git commit --amend
Well and after mergeyou can already masterhang on the version label.

Answer 3

There is a very simple rule - right, the way it is easier.
You can even use master to synchronize all files, it's okay if there is an active development stage, you are the only developer, and the release is still very far away. And if you know how not to jump from one unfinished task to another.
As soon as you need to make releases, you can already get confused with master, staging, feature branches, etc., but only as needed.
PS. Since we are acting on the KISS principle, instead of a command line utility, it is better to use a convenient GUI, for example, on a Mac, this is Source Tree (in my opinion, the coolest program on my laptop).
It will also help to work with git more correctly - manually review and stage each changed file, and not through git add -A.

Answer 4

If you do not fix bugs in the old version, while making a new version at the same time, then you do not need separate branches.
To get started, learn how to make clear commits. So that the changes (files included in the commit) and the purpose of these changes (the commit comment) match

Answer 5

It's simple, you work on a computer. Before you finish, commit and push everything. Sat down at the laptop doing pull.
If you are cutting a new feature, or something global, it is better to create a separate branch, and until everything is done on it. In fact, this is not necessary, since in any case all commits and history will be visible anyway, and it’s not realistic to mess up one, even if you do everything on the master.
The main thing is not to forget the simple rule, sat down at the pull computer before leaving the push computer.

Answer 6

understood nothing

Suppose I did something on my computer, left it unfinished, committed it to the local repository and pushed it to the server

why do you need to commit to a local repository?

But with such a use case, there will be a bunch of commits on the server with unfinished functionality. In fact, the remote repository will become just a place to synchronize files.

Whoop!! And what do you need? So that every commit is a complete change? Break the task down into smaller subtasks.
Personally, when I do something alone, my project - I use git as a means of file synchronization. Grab your head. For several years of sawing my code, I have never needed anything from the git, in general, although more than once the project has been rewritten, changed architecture, etc. I need a github solely as a means not to squander the code and at work to incline to dig into my shit code when there are no tasks.
I wrote a method, did layout or refactoring - push. I don't even write comments.

Answer 7

For synchronization between two computers I use syncthing.
git and github (as remote master) is used for meaningful commits with completed improvements.
So I have a clean commit history, no rebases or other dubious activity to bring the history in order are not needed.
But that doesn't change the use of branches. A separate feature - a separate branch. Almost working - I merge in dev. After testing medju dev in master. I try not to commit directly to the master, except maybe some readme updates and other paraphernalia.
In master there is a code in which I am sure that it is working because the master is sometimes downloaded (the project does not require assembly because it is on pit and bash and is easily installed from source).
When the version is fully mature, I create a release (directly on github), and along the way, pour it into the PPA on launcpad (this has nothing to do with development itself - this is automatic delivery of updates to users).

Answer 8

I also use the develop branch for this, but lately I'm more and more inclined to think that this is not necessary.
It might be worth trying, in addition to the git, to use some Dropbox and push only completed meaningful things.

Answer 9

If you work alone, it will be easier for you https://pijul.com/

Answer 10

Commit everything as it is to a separate branch (dev or thematic task), upon completion of the task, rebase for the beauty of the story and merge into the master.

Answer 11

I use master as my main development branch, where I try to push mostly working and finished code. For the development process, I create separate topic branches, which I put in order with git rebase before merging with the master (well, periodically for long-lived branches).
I prepare the production code (releases) in a separate branch and merge the release branch with master and production.
Non-working code and all sorts of imperfections I commit only to thematic branches and add the prefix "WIP" (work-in-progress) to the description of the commit and sometimes I add information about what else I wanted to do, but did not have time to do.
As I understand it, this is predominantly a gitflow policy, with a touch of Gilab flow (when the development branch is master).