git rebase

你把 master rebase 到你的分支上？然后还能不加 --force push?

这是什么操作。。

master 开保护 禁止直接 push

用 sourcetree，命令行太难了不会

git reflog 可以查看呀

rebase 出的 commit 中的 author (你) 和 commiter (你那个勇敢的同事) 会变成不同人

如果还要再强的证明, 你可以给自己的 commit 加上数字签名

给 master 分支保护，合并的时候提 MR ,这样大家就知道你的代码不是直接改 master 是合并上去的了
另外仓库分远程和本地，只要提交到远程的是 commit 干净清晰，本地可以按照自己风格来

虽然审错题了，不过给 master 加保护没错，这样向 master 合并代码不是在客户端本地，而是用账号登录到远程仓库，
足以证明虽然 commit 是你写的，但却是别人是把 commit 合到 master 了

所以一人一个 branch 有什么好处吗？

别人一看 master，Committer 是你同事啊，关你啥事……

虽然我也不是很懂，但是我见过的例子都是
git checkout mybranch
git rebase master
在自己的分支上解决可能的冲突，然后
git checkout master
git merge mybranch

@msg7086 出现在 master 上的所有我的 commit 的 commiter 都是那个勇敢的人 对吗？ 我还在地铁上、到公司就看一下

这种 push 得加--force 吧？而且冲突的文件的最后提交者是你同事又不是你，为什么会认为你违规操作？难道发现你是最后提交者就自动背锅了？

@billgreen1 我大致理解这样操作的意思，这样 master 上的 commit 会在没有 merge 的情况下出现在你的分支（这个不违规，我们这是反过来操作的，属于违规），当你的 commit 出现在 master 是在合并到 master 之后出现的，我们这情况是在没有任何 merge 的情况，我的 commit 出现在 master

不要把私钥或 github/gitlab 密码告诉别人就可以了

这样做 是直接把你的分支 merge 到了 Master 吧。 如果是这样的话， 提交者会是你同事，不是你。

master 不止你一个人看到，你还给它 rebase，会造成一种情况就是同一个提交会有不同的几个 hash，查历史的时候会造成一点混乱，个人不推荐

master 分支上怎么可以 rebase

只有在自己的分支上 rebase，然后 push

永远不要在公共分支上变基

@yanhejihe 对的，是不合理，如果在 aBranch 上，git rebase bBranch , 并且 bBranch 上的提交都先于 aBranch 上的提交，有什么方法可以判断一个 commit，在 rebase 之前，是在 aBranch 还是在 bBranch 上提交的吗

@msg7086 我 commit 的时候，author 和 commiter 的信息都是我，别人 rebase 之后，这两个信息没有变动啊

这样，应该不好吧，这个意思是 master 在你的分支之上了，算是 merge ？而且 commit 进去的顺序也不对吧，比如 master 现在指向一个 A_commit 你的分支指向 B_commit 那么你这样操作完之后 A_commit 在你的 B_commit 之上了是不是。感觉应该 git pull --rebase; git rebase master myBranch 然后再提交一个 pr, ok 了， 那么 git checkout master; git pull --rebase 然后 git merge myBranch; 然后 git push origin -u HEAD:refs/heads/master;

Github 的话你的 commit 加上 GPG 签名，开 master 分支保护。

@thomaswang 我这里没问题。