klj613--

7 ms·

1. 1.▲
   by klj613-- 13y ago

   git is a SCM and should not be on production systems. instead you should have a build server which builds up a package (rpm, deb, tarball?) which is then used to deploy across the production environments. you should also not compile JS&#x2F
2. 2.▲
   by klj613-- 13y ago

   Arch + Awesome .. + urxvt + vim
3. 3.▲
   by klj613-- 13y ago

   Please use rebase... but only if you understand it! Do not commit to your commits... I experiment on branches... I use commits as stashes... I end up with 100s of local branches... - Only rebase non-shared commits. Normally people say "dont
4. 4.▲
   by klj613-- 14y ago

   you need agent forwarding to ssh into a server to do a git pull from _that_ server. e.g. a dev vm.
5. 5.▲
   by klj613-- 14y ago

   Personally I think its better using the CLI for git. I commit very often however I rewrite the commits. In other words, I mess with my history and it is a good thing (My commits ain't final, in other words... "I do not commit to my commits"
6. 6.▲
   by klj613-- 14y ago

   1. `git pull` = fetch + merge If the merge has conflicts, then you got to solve the conflicts and do the commit manually (entering the commit message) If the merge doesn't have conflicts, then the merge commit is automatic. 2. `git commit -
7. 7.▲
   by klj613-- 14y ago

   Best way to learn git is in the command line (get away from any GUI). And then play with repositories to see what the commands actually do. "Don't mess with history"? I don't have to commit to my commits as long as my commits ain't public.