This isn't my idea, I just use it and it works for my personal stuff. I've come at this from a slightly different direction (and I use mercurial, but philosophically its the same). This default will change in a later version of git, but can be overrode by setting fault in a configuration file or by specifying the matching refspec: git push : If you find yourself working on more than one topic branch throughout the day but don't want to push each one individually to the remote, git push will by default push all matching branches to. As long as you're willing to rebase them into a more intelligible history, it's quite effective in practice. Commit work in progress to those branches as often as you'd like. The best solution is keeping a local repository on each machine and sharing topic branches between them via a remote. It's easy to overwrite one another's work, and you end up spending as much time air traffic controlling who's deploying the repository as you do working in it. At first it seemed like a good idea as the repo doesn't change often, but over time it's become quite a nightmare. We use a shared repository for scripts, creatively named the scripts repository. Using one repo shared over a network is fine, unless you're also sharing it with other users.You can pull and push this branch from both machines with little effort, and when it's ready to merge into master or production rebase it to create a more maintainable history. When using multiple machines, however, you occasionally need to commit work in progress. As a result I spend a great deal of time making my production branch's history logical, replicable, and debuggable. I believe production history should be pristine. There are two key concepts to handling them well. I deal with both of your proposed solutions daily. Is there a third handle on this situation? Maybe some third party tools are available that help make this process easier? If you deal with this situation regularly, what do you suggest? Lastly a minor point is that all the git commands to keep multiple branches up to date can get tedious. I also don't want to have to leave my computers on all the time so I can fetch from them directly. But the downside I see is that you might not always be able to access code from your other machines, and I certainly don't want to push all my WIP branches to github at the end of every day. My intuition says that everyone generally goes with the first option. Never worry that you forgot to push code from your other non-hosting machine, which is now out of reach, since you were working off a fileshare on this machine.No need to do git pulls every time you switch machines, since your code is always up to date.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |