GitHubやってる?
■ このスレッドは過去ログ倉庫に格納されています
0001仕様書無しさん
2013/03/17(日) 21:28:29.830002仕様書無しさん
2013/03/17(日) 22:28:31.68http://ikura.2ch.net/test/read.cgi/curry/1362352810/
0003仕様書無しさん
2013/03/17(日) 22:41:16.100004仕様書無しさん
2013/03/18(月) 14:50:22.640006仕様書無しさん
2013/03/20(水) 17:29:35.11違法派遣(偽装請負・多重派遣・偽装出向・事前面接等)についての刑事罰
【告訴権者=業務委託、準委任、共同受注、業務請負契約および特定派遣(契約・正規)、一般派遣、正規社員】
�@職業安定法第44条の労働者供給事業の禁止規定に違反(1年以下の懲役または20万円以下の罰金)
■偽装請負・多重派遣・偽装出向・多重出向
■事前面接(顔合わせ・面談・職場見学等)と履歴書・職務経歴書・スキルシート等提出による労働者の特定(※)
(音声録音で立証可能)
�A労働基準法第6条(中間搾取の禁止) (1年以下の懲役又は50万円以下の罰金)
■多重派遣・多重出向
※違法派遣(派遣労働者の特定)→派遣法で認められた派遣労働者ではない→労働者供給事業→職業安定法44条違反というの
が前提となる法解釈となります。派遣法における罰則が軽微なのは法律の不備や労働者軽視などが原因ではありません。
違法派遣は全て職業安定法44条で裁くことが可能なため、刑罰の重複を避けるために派遣法には軽微な罰則(主に裁量行政による)しかないのです。
使用者に有利な民事訴訟や労働関係諸局への通報等の対極にあるのが書面(告訴状)による刑事告訴(※告訴先は検察の直告班)です。
労働関係諸局への通報・斡旋による軽微な「適正化」や監督・指導に対して、法律に定められた刑事罰を問うことになり、
違法派遣業者にとって有罪は考えられる限り最大の処罰となります。同時に刑事罰を受けた
担当者が取引先に与える悪印象を考慮すれば、通常会社側は告訴が受理された時点で告訴取り下げに
動くのが妥当でしょう。懲役、前科がつく刑罰が下される可能性から、告訴取り下げの和解金は高額となることが多いのです。
告訴の流れとしては、
刑事告訴⇒告訴受理⇒告訴取下げ要請⇒取下げ和解金入金⇒告訴取下げ
となります。告訴の懲役刑適応は犯罪者個人に対してのみですので、告訴する対象は
派遣先・派遣元 社長
派遣先・派遣元 担当者・責任者・管理役員・取締役
派遣先・派遣元 人事管理担当者・人事管理役員・取締役
が妥当です。刑事告訴取り下げの和解金額は犯罪者個人と交渉するとよいでしょう。(告訴状は人数分提出する必要あり)
0007仕様書無しさん
2013/03/23(土) 12:35:18.32http://togetter.com/li/410607
0009仕様書無しさん
2013/04/03(水) 12:01:45.720010仕様書無しさん
2013/04/11(木) 06:28:22.680011仕様書無しさん
2013/05/01(水) 16:49:46.490012仕様書無しさん
2013/05/08(水) 22:22:39.090013仕様書無しさん
2013/05/10(金) 02:25:06.00http://engawa.2ch.net/test/read.cgi/poverty/1368116873/
0014仕様書無しさん
2013/06/02(日) 18:45:26.600015仕様書無しさん
2013/06/03(月) 18:56:26.450016仕様書無しさん
2013/07/11(木) NY:AN:NY.AN0017仕様書無しさん
2013/08/06(火) NY:AN:NY.AN0018仕様書無しさん
2013/08/07(水) NY:AN:NY.AN0019仕様書無しさん
2013/08/07(水) NY:AN:NY.AN自分は仕事のrepoをgithubに置きたくはないなあ。
0020仕様書無しさん
2013/08/07(水) NY:AN:NY.AN0021仕様書無しさん
2013/08/10(土) NY:AN:NY.ANWeb上でできるから、仕事場を選ばないってのはうまく使えばすごいメリットになると思う
まぁ日本じゃありえないけどな(´・ω・`)
0022仕様書無しさん
2013/08/11(日) NY:AN:NY.AN0023仕様書無しさん
2013/08/11(日) NY:AN:NY.ANだがGitはいいものだ。SVNにはもう戻りたくない
0024仕様書無しさん
2013/08/12(月) NY:AN:NY.AN0025仕様書無しさん
2013/08/12(月) NY:AN:NY.AN開発スタイルが全く違う。
gitを使った場合
「バリバリ新機能実装中だぜ。20%ぐらい作ったな。」
「おっ、実装中に現バージョンの部分にバグがを見つけた」
「これすぐに現バージョンを修正した方がいいな」
「master(≒trunk)から新しいブランチ作成だ」
「現バージョン修正したぜ」
「新機能は、(修正済み現バージョン)から、ブランチを切ったことにしなきゃいけないからrebaseだ」
「バリバリ新機能実装中だぜ。30%ぐらい作ったな。」
「よしコミットだ」
「バリバリ新機能実装中だぜ。40%ぐらい作ったな。」
「よしコミットだ」
「バリバリ新機能実装中だぜ。50%ぐらい作ったな。」
「ちょwww 最初のコミットにファイル追加漏れがあったwww」
「よし、最初のコミットを修正だ」
「バリバリ新機能実装中だぜ。60%ぐらい作ったな。」
「お、このサブ機能、先にリリースしておいたほうが良くないか?
「よし一部分を切り出し、先にリリースし、そして今の作業をリリース後からの追加開発という形に訂正だ!」
という風にgitの開発は複数のブランチを作成し、修正履歴を最終的な理想の形に正しながら開発する。
002625
2013/08/12(月) NY:AN:NY.ANgitはソフトウェアを開発するためのツールという位置づけ。
0027仕様書無しさん
2013/08/12(月) NY:AN:NY.ANSVNでもできなくはなさそうだけど、よりやりやすいってことだよね多分
俺も触ってみよう
0028仕様書無しさん
2013/08/12(月) NY:AN:NY.AN0029仕様書無しさん
2013/08/14(水) NY:AN:NY.ANtechcrunch.com/2013/08/13/github-adds-trending-page-to-filter-by-project-programming-languages-and-developers/
みてみたけど前のほうが一覧性があって言語別の
人気が分かって良かったなと思ったわ…
unityとかと同じで左上の窓からキーワード検索で
情報を絞り込むデザインに統一したいのだろうな
0030仕様書無しさん
2013/08/15(木) NY:AN:NY.ANURLの大変更でも行ったのか?
0031仕様書無しさん
2013/08/16(金) NY:AN:NY.AN0032仕様書無しさん
2013/08/16(金) NY:AN:NY.ANこれだからGitHubは人気になったんだろう。
0033仕様書無しさん
2013/08/16(金) NY:AN:NY.AN0034仕様書無しさん
2013/08/17(土) NY:AN:NY.AN0035仕様書無しさん
2013/08/18(日) NY:AN:NY.ANこれこれ、コミットとブランチを好きにできて、コミット順を入れ替えたりsquashしてまとめて数コミットに作りなおしたり
こういうのをやって理想の修正にしてからpushっての、すごい便利だし気持ちいい
SVNなんてブランチ切るのもおおごとだし、一度Gitな開発スタイルになれたら、SVN戻れる気がしないわw
0036仕様書無しさん
2013/08/19(月) NY:AN:NY.AN賢明な判断だ、使いやすくなった
0037仕様書無しさん
2013/08/27(火) NY:AN:NY.AN0038仕様書無しさん
2013/09/24(火) 17:21:03.880039片山博文MZコスモ ◆T6xkBnTXz7B0
2013/09/24(火) 18:07:45.290040仕様書無しさん
2013/09/24(火) 18:22:52.85Release したやつなら、名前のとこクリックしたら右上にDeleteボタンがあるべ
0041仕様書無しさん
2013/09/24(火) 22:24:26.82Hubられた
0042仕様書無しさん
2013/09/25(水) 01:30:47.680043仕様書無しさん
2013/09/25(水) 16:14:18.820044仕様書無しさん
2013/09/25(水) 17:06:43.850045仕様書無しさん
2013/09/25(水) 17:56:37.880046仕様書無しさん
2013/09/25(水) 17:57:13.060047仕様書無しさん
2013/09/25(水) 18:02:55.320048仕様書無しさん
2013/09/25(水) 20:58:46.830049仕様書無しさん
2013/09/26(木) 01:51:59.290050仕様書無しさん
2013/09/26(木) 02:21:06.300051仕様書無しさん
2013/09/26(木) 02:22:44.840052仕様書無しさん
2013/09/26(木) 02:24:09.94/ ''、
/ ヽ、
,-',,,,,,,,,,,,,,,,,,, ,,, ,,,,ゝ、
/ ゝ
/ '
l ,‐'´ ̄ ̄  ̄ ̄`ヽ、 l
l ,.‐=====、小.‐=====、 l
t-l =ニ・ニ=l l =ニ・ニ=::l l
l^l ゝ、::::::::::ノ ゝ:::::::::::: l
l  ̄ ̄  ̄ ̄ l
l l < どっこいしょ!
ヽ ∩∩ /
ヽ ヽ、_____,.‐' /
l l LLLLLLLLLlヽノ
l ヽ、TTTTTTTTTノ
ヽ ニニニニニニ/
ヽ、 /
l 、___ /
ノ\ ∧__
-:''"゙ `ヽ、,.‐'´ `''‐、
所ジョージ
0053仕様書無しさん
2013/09/26(木) 03:49:11.080054仕様書無しさん
2013/09/26(木) 03:50:42.18GitHub以外のOSSホスティングサービスのスレってある?
0055仕様書無しさん
2013/09/26(木) 09:32:22.72bitbucketかGoogle codeあたりだよなあ。
0056仕様書無しさん
2013/09/26(木) 23:17:45.27google code もイマイチ感あるし、
手軽さとかも考えたらGitHub、非公開ならBitbucket、の2択って感じじゃね
0057仕様書無しさん
2013/09/26(木) 23:19:41.28githubにコミットするファイルが複数あり
幾つかのファイルはCRLFで、それ以外のファイルはCRになっています。
この状態で改行コード変換は一切せずにコミットすると、githubをブラウザでみたときにCRLFのファイルだけ中身が文字化けして正常に表示されません。
チェックアウトしてデータを確認するとデータ自体は正常でした。
CRLFファイルをブラウザ上で正常表させるにはどうしたらいいでしょうか?
005857
2013/09/27(金) 00:35:22.08改行コードを統一しない理由は編集側の問題というよりは実行環境のためです。
例えば
batファイルや
shファイルなどが混在しており、
どちらかの改行コードには統一したくない状況でファイル本来がもつそのままの形式でpush,pullしたいのです。
ですのでクローンした場合も、この状態が維持されないと、shやbatが動作しなくなります。
改行コード変換なしだと動作上は問題ないですが、github上でコードがみれなかったりするのはちょっと困るので・・
どうしたものかと質問したしだいです。
0059仕様書無しさん
2013/09/27(金) 08:26:02.450060仕様書無しさん
2013/09/27(金) 11:46:28.40Microsoftにいってくれとしか…
0061仕様書無しさん
2013/09/27(金) 12:40:23.91現Macを含むUnix系 LF
じゃないの?
CRは昔のMacとかだよね?
0062仕様書無しさん
2013/09/27(金) 13:24:37.430063仕様書無しさん
2013/09/27(金) 16:10:55.64http://git-scm.com/book/ja/Git-%E3%81%AE%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%9E%E3%82%A4%E3%82%BA-Git-%E3%81%AE%E5%B1%9E%E6%80%A7
0065仕様書無しさん
2013/09/30(月) 12:00:47.690067仕様書無しさん
2013/10/01(火) 01:55:32.91ttp://blog.qnyp.com/2013/05/28/pull-request-for-github-beginners/
0068仕様書無しさん
2013/10/01(火) 03:36:43.60Fork A Repo
https://help.github.com/articles/fork-a-repo
0069仕様書無しさん
2013/10/05(土) 17:11:54.86http://engawa.2ch.net/test/read.cgi/poverty/1380941226/
0070仕様書無しさん
2013/10/05(土) 17:21:21.99クライアントアプリの話じゃねーの?
0071仕様書無しさん
2013/10/24(木) 02:39:24.67テンプレートで出したとき {{year}} とか {{fullname}} ってのが出てくるけど
これって自分で手動で書き換えろってことなん?
0072仕様書無しさん
2013/10/24(木) 09:32:33.140073仕様書無しさん
2013/10/25(金) 16:28:48.260074仕様書無しさん
2013/10/29(火) 17:52:42.67さっき凄くきれいな女の人と道ですれ違ってさ
その人のおっぱいとおまんこをチュッパチュッパしたいと思ったんだ☆⌒(´>ω・`)b
0075仕様書無しさん
2013/10/29(火) 21:37:24.76その後の編集時だけ手動書き換えが必要みたいだけど
0076仕様書無しさん
2013/11/01(金) 02:22:09.89github で fork と pull request に挑戦。 - KUROIGAMEN(黒い画面)
http://kuroigamen.com/15
0077仕様書無しさん
2013/11/01(金) 04:14:57.220078仕様書無しさん
2013/11/05(火) 19:52:04.18http://wiki.algomon.com/wiki/%E4%BA%8B%E5%89%8D%E9%9D%A2%E6%8E%A5
0079仕様書無しさん
2013/11/06(水) 04:16:47.460080仕様書無しさん
2013/11/06(水) 08:58:30.14Github使わにゃできんことが仕事で必須ってわけでもないし、効率云々言うほど我々の仕事に革新があるわけでなし
0081仕様書無しさん
2013/11/06(水) 12:20:42.27そうやなー勿体無いわ
0082仕様書無しさん
2013/11/07(木) 04:22:31.61システムはこれから必須だと思うけどね
0083仕様書無しさん
2013/11/08(金) 20:22:20.60http://hiroponz.hateblo.jp/entry/20130516/p1
0084仕様書無しさん
2013/11/20(水) 15:41:53.97http://toro.2ch.net/test/read.cgi/tech/1384821518/
0085仕様書無しさん
2013/11/24(日) 10:44:38.97http://www.itmedia.co.jp/enterprise/articles/1311/21/news045.html
0086仕様書無しさん
2013/11/27(水) 22:02:06.27githubでさ、とある人のプロジェクトにプルリクエスト送る時さ、
自分の所にForkするじゃん?
そしてマージされたら、Forkした自分のリポジトリって
みんな消してるの?
検索すると、Forkしたものだと思われる同名のプロジェクトが
いくつか見つかったりして、どれがオリジナルかわかりにくく混乱することがある。
こういことがあまり起こらないように、必要なくなったら
自分のやつは消すのがマナーなのかな?と。
0087仕様書無しさん
2013/11/27(水) 22:18:13.280088仕様書無しさん
2013/11/27(水) 23:35:45.21そもそもプルリクエスト送るためにforkしなくていいらしい
ローカルで編集したやつをそのままリクエストすればいいって話だった
GitHub初心者だから実際どうやるのかは知らんけど
0089仕様書無しさん
2013/11/27(水) 23:45:53.37https://help.github.com/articles/using-pull-requests
そのままリクエスト?本当に出来るん?
0090仕様書無しさん
2013/11/27(水) 23:52:40.50それっぽい方法説明してそうな項目ないよ
0091仕様書無しさん
2013/11/27(水) 23:58:43.37これは開発プロジェクトのメンバーの一員になってやる方法だよね
0092仕様書無しさん
2013/11/27(水) 23:59:15.150093仕様書無しさん
2013/11/28(木) 00:00:35.38これ見てもローカルから直接pull request送る方法無さそうだし
0094仕様書無しさん
2013/11/28(木) 00:01:10.570095仕様書無しさん
2013/11/28(木) 00:02:19.50開発メンバーの一員に加わることで
そのリポジトリへの直接的なアクセス権を得る方法で
同一リポジトリ内でのブランチ間でのpull requestだよ
0096仕様書無しさん
2013/11/28(木) 00:05:09.90cloneするためのURLは公開されてるからね
ソースコード取得だけならGitHubへの会員登録すらいらないでしょ
0098仕様書無しさん
2013/11/28(木) 01:38:26.55マージされて要らなくなったら
消してるのでしょうか?
0099仕様書無しさん
2013/11/28(木) 02:18:14.09https://help.github.com/articles/tidying-up-pull-requests
>Tidying up Pull Requests
>
>You end up with a lot of defunct branches after Pull Requests have been merged or closed.
>So we've provided a way for you to clear out these branches as part of your regular workflow.
0100仕様書無しさん
2013/11/28(木) 02:20:01.07>
> Using Pull Requests
> Creating a pull request
> Merging a pull request
> Closing a pull request
ヘルプのこれら全てがTidying up Pull Requests の項目と関連付けられてることからして
GitHub的にはディスク使用量を減らすために積極的に削除してほしいってことでしょ
0101仕様書無しさん
2013/11/28(木) 02:37:11.55>マージを実行すると、GitHub上でupdate-readmeブランチからmasterブランチへのマージが行われます。
>また、マージ済みのブランチを削除する「Delete branch」ボタンが出現します。
>通常は元のブランチは不要になるので、遠慮なくボタンを押します。
遠慮なく削除していいらしいよ
0102仕様書無しさん
2013/11/28(木) 02:39:49.74http://toggtc.hatenablog.com/entry/2012/03/12/023108
0103仕様書無しさん
2013/11/28(木) 02:53:50.39http://toggtc.hatenablog.com/entry/2012/03/12/030155
>A.ブランチの削除
>Formulaが無事に本家に取り込まれて、作業用ブランチが用済みになったからブランチを削除したい、という場合は以下のようにします。
0104仕様書無しさん
2013/11/28(木) 10:42:41.950105仕様書無しさん
2013/11/29(金) 11:57:44.65http://wiki.algomon.com/wiki/%E4%BA%8B%E5%89%8D%E9%9D%A2%E6%8E%A5
0106仕様書無しさん
2014/02/25(火) 07:28:02.20こんなの仕事で使ってる奴ってどうでもいい案件の糞プロジェクトぐらい?
っつーか仕事で使ってるやついんの?w
0107仕様書無しさん
2014/02/25(火) 19:18:30.320108仕様書無しさん
2014/02/25(火) 19:19:01.820109仕様書無しさん
2014/02/25(火) 19:19:33.15http://toro.2ch.net/test/read.cgi/tech/1384821518/
0110仕様書無しさん
2014/02/26(水) 00:56:28.350111仕様書無しさん
2014/04/01(火) 19:28:43.92仕事させれるってのが強みの一つだと思うよ
インターネット経由で世界のどこにいても仕事できる、させれる
もちろん、セキュリティ云々の意識はコーダーのスキルとかに依存するだろうから、
今の日本の企業の多くじゃ即採用とはならないだろうけど、
そのあたりも加味した契約をすれば会社的なリスクは下がるしな
そういった事を考えた上で在宅コーダーを採用してる企業は日本にもある
0112仕様書無しさん
2014/04/01(火) 21:06:43.84http://anago.2ch.net/test/read.cgi/software/1393852602/
0113仕様書無しさん
2014/04/14(月) 06:28:00.07Git 9
http://toro.2ch.net/test/read.cgi/tech/1397276540/
0114仕様書無しさん
2014/04/14(月) 23:13:20.03http://toro.2ch.net/test/read.cgi/tech/1384821518/
0115仕様書無しさん
2014/05/20(火) 23:50:10.91コミットするときはmasterではなくてbranchにしろと言われているリポジトリです。
�@フォークする
�Aローカルにcloneで持ってくる
�Bリモートにフォーク元のGitHubのmasterリポジトリをaddする
�Cローカルにブランチを作る
�Dローカルのブランチを修正する
�Eローカルのブランチに変更をコミットする
�FGitHubのブランチに変更をコミットする
�GGitHubのフォーク元のmasterリポジトリにpull requestを出す
�Hマージされたらブランチを削除
�Iローカルでfetchする
こんな感じになるんですかね・・・?
0118仕様書無しさん
2014/05/20(火) 23:58:12.560120仕様書無しさん
2014/05/23(金) 10:26:45.240121仕様書無しさん
2014/05/30(金) 22:43:21.760122仕様書無しさん
2014/06/19(木) 00:41:59.39これの話題ってあまりないね
0123仕様書無しさん
2014/06/19(木) 20:42:10.840124仕様書無しさん
2014/06/20(金) 00:58:03.002週間の期限付けてセキュリティかけて
貸出している。貸し出しの予約待ちまでいる状態。
■ このスレッドは過去ログ倉庫に格納されています