Рассмотрим UnicodeReader из Google, который делает все это для вас.
Charset utf8 = Charset.forName("UTF-8"); // default if no BOM present
try (Reader r = new UnicodeReader(new FileInputStream(file), utf8)) {
....
}
Зависимость Maven:
com.google.gdata
core
1.47.1
У вас действительно должен быть рабочий процесс, который позволяет делать все это путем слияния:
- x - x - x (v2) - x - x - x (v2.1)
\
x - x - x (wss)
Итак, все, что вам нужно сделать, это git checkout v2. 1
и git merge wss
. Если по какой-то причине вы действительно не можете этого сделать, и вы не можете использовать git rebase , чтобы переместить ветку wss в нужное место, команда для захвата одного коммита откуда-то и применения его в другом месте будет git cherry-pick . Просто проверьте ветку, к которой вы хотите применить его, и запустите git cherry-pick
.
Некоторые способы перебазирования могут вас спасти:
Если ваша история выглядит так:
- x - x - x (v2) - x - x - x (v2.1)
\
x - x - x (v2-only) - x - x - x (wss)
Вы можете использовать git rebase --onto v2 v2-only wss
, чтобы переместить wss непосредственно на v2 :
- x - x - x (v2) - x - x - x (v2.1)
|\
| x - x - x (v2-only)
\
x - x - x (wss)
Тогда можно сливаться! Если вы действительно, действительно, действительно не можете добраться до точки, в которой вы можете выполнить слияние, вы все равно можете использовать rebase для эффективного выполнения нескольких выборочных действий одновременно:
# wss-starting-point is the SHA1/branch immediately before the first commit to rebase
git branch wss-to-rebase wss
git rebase --onto v2.1 wss-starting-point wss-to-rebase
git checkout v2.1
git merge wss-to-rebase
Примечание: причина, по которой требуется некоторая дополнительная работа для этого заключается в том, что он создает дублирующиеся коммиты в вашем репозитории. На самом деле это нехорошо - весь смысл легкого ветвления и слияния состоит в том, чтобы иметь возможность делать все, делая коммиты в одном месте и объединяя их там, где они нужны. Повторяющиеся коммиты означают намерение никогда не объединять эти две ветки (если вы решите, что захотите позже, у вас возникнут конфликты).
Вы можете создать патч из коммитов, которые вы хотите скопировать, и применить патч к месту назначения ветвь.
Используйте
git cherry-pick <commit>
, чтобы применить
к вашей текущей ветке .
Я бы сам, вероятно, перепроверил коммиты, которые я выбираю в gitk
, и выбрал бы их, щелкнув правой кнопкой мыши по записи коммита там.
Если вы хотите действовать более автоматически (со всеми его опасностями) и предполагаете, что все коммиты со вчерашнего дня произошли в wss, вы можете сгенерировать список коммитов, используя git log
с ( - довольно
, предложенный Джефроми)
git log --reverse --since=yesterday --pretty=%H
, так что все вместе, если вы используете bash
for commit in $(git log --reverse --since=yesterday --pretty=%H);
do
git cherry-pick $commit
done
Если что-то пойдет не так (есть большой потенциал), у вас проблемы, так как это работает при проверке в реальном времени, так что либо ручной выбор вишни или используйте перебазирование, как предложено Джефроми.